Proposal finalization process v4
I have consolidated the comments and edits from Milton, Adiel, Joe, and Russ in the attached v4 <https://www.dropbox.com/home/CoordinationGroup/Proposal%20finalization%20pro...>. I accepted changes on all the text where no one had commented for easier reading. I also inserted a few comments/edits of my own the proposed changes, which I repeat below. Step 1a, bullet 3: Milton suggested using "Whether the proposal obtained consensus” instead of “How the proposal obtained consensus.” I am fine with “whether.” I would also be fine with “Whether and how.” In the RFP, we ask the communities to explain “the steps that were taken to develop the proposal and to determine consensus.” I would consider a list of those steps to be the “how.” Step 1b: Adiel suggested adding a bullet about timeliness. I do not think this is actionable and so should not be included. If we get a proposal after the target deadline, I do not believe we are in a position to do anything other than start conducting the assessment in step 1. Of course, if we get a proposal many weeks/months after the target deadline, it will create some chaos for all of the steps afterward, but I don’t really see a lot of value in specifying how we will handle every possible case of that sort that could arise depending on the exact timing and sequence of the arrival of the component proposals. Step 2: Adiel questioned whether the statement that the ICG’s role “is not to draft a single transition proposal” is accurate. I believe it is accurate, in the sense that we are not “drafting” or writing anything of our own. I added the words “of its own” to the end of that phrase to try to make this more clear. Step 2: Adiel questioned the use of the word “unifying.” I agree that “unifying” and “uniform” are confusing. I believe our task is one of assembly. Our goal is to end up with one document, but not to massage the text of the component proposals to achieve “unity.” I have replaced the word “unified” in this section with the word “single” to make this clear. Step 2a: Joe inserted “possibly conflicting” as a qualifier for “overlaps” I don’t understand what a conflicting overlap is, and I think the proposals need to have a coherent story about all overlaps. So I disagree with this addition. Step 2b: Joe asked whether we need to cross-reference the ICANN accountability work. I think this is already covered by the fact that we are already asking "Do the proposals together include appropriate and properly supported independent accountability mechanisms for running the IANA function?” Step 2c: There has been list discussion between Joe and Russ about testing. I suggested some text as a middle ground approach. In the RFP we do ask the communities to describe any testing they do. I’m not quite sure how the test results could conflict with each other or otherwise be problematic in combination, but I’m happy to check for that when we’re assembling the single proposal. Step 5: I have made the latest changes suggested on the list by Milton, which I think address everyone’s concerns. Alissa
Alissa Overlap. Some proposals may cover the same ground in related functions (overlap) but not interfere with each other and create no conflict. That is not an issue needing to be resolved. As to the ICANN accountability cross reference placeholder; it was a holdover question (do we need a placeholder with possible text if we do) more than a drafting suggestion. Joe n 12/9/2014 6:19 PM, Alissa Cooper wrote:
I have consolidated the comments and edits from Milton, Adiel, Joe, and Russ in the attached v4 <https://www.dropbox.com/home/CoordinationGroup/Proposal%20finalization%20pro...>. I accepted changes on all the text where no one had commented for easier reading. I also inserted a few comments/edits of my own the proposed changes, which I repeat below.
Step 1a, bullet 3: Milton suggested using "Whether the proposal obtained consensus" instead of "How the proposal obtained consensus." I am fine with "whether." I would also be fine with "Whether and how." In the RFP, we ask the communities to explain "the steps that were taken to develop the proposal and to determine consensus." I would consider a list of those steps to be the "how."
Step 1b: Adiel suggested adding a bullet about timeliness. I do not think this is actionable and so should not be included. If we get a proposal after the target deadline, I do not believe we are in a position to do anything other than start conducting the assessment in step 1. Of course, if we get a proposal many weeks/months after the target deadline, it will create some chaos for all of the steps afterward, but I don't really see a lot of value in specifying how we will handle every possible case of that sort that could arise depending on the exact timing and sequence of the arrival of the component proposals.
Step 2: Adiel questioned whether the statement that the ICG's role "is not to draft a single transition proposal" is accurate. I believe it is accurate, in the sense that we are not "drafting" or writing anything of our own. I added the words "of its own" to the end of that phrase to try to make this more clear.
Step 2: Adiel questioned the use of the word "unifying." I agree that "unifying" and "uniform" are confusing. I believe our task is one of assembly. Our goal is to end up with one document, but not to massage the text of the component proposals to achieve "unity." I have replaced the word "unified" in this section with the word "single" to make this clear.
Step 2a: Joe inserted "possibly conflicting" as a qualifier for "overlaps" I don't understand what a conflicting overlap is, and I think the proposals need to have a coherent story about all overlaps. So I disagree with this addition.
Step 2b: Joe asked whether we need to cross-reference the ICANN accountability work. I think this is already covered by the fact that we are already asking "Do the proposals together include appropriate and properly supported independent accountability mechanisms for running the IANA function?"
Step 2c: There has been list discussion between Joe and Russ about testing. I suggested some text as a middle ground approach. In the RFP we do ask the communities to describe any testing they do. I'm not quite sure how the test results could conflict with each other or otherwise be problematic in combination, but I'm happy to check for that when we're assembling the single proposal.
Step 5: I have made the latest changes suggested on the list by Milton, which I think address everyone's concerns.
Alissa
_______________________________________________ Internal-cg mailing list Internal-cg@icann.org https://mm.icann.org/mailman/listinfo/internal-cg
Hi Joe, On Dec 9, 2014, at 3:41 PM, joseph alhadeff <joseph.alhadeff@oracle.com> wrote:
Alissa
Overlap. Some proposals may cover the same ground in related functions (overlap) but not interfere with each other and create no conflict.
I don’t have really strong feelings about the actual text here, but I’m still not sure I understand. The whole point of the overlap question is to determine whether the communities implicated by the overlap have specified approaches that are either the same or work with each other. To take a theoretical example, if the IETF said one thing about the administration of multicast IP address allocations and the RIRs say something different, the point of this check is to identify this discrepancy. By definition, every overlap is “possibly conflicting” — that’s the whole point of doing this check. But given that, I’m fine with adding the qualifier, since I don’t think it has any impact on the space of overlaps that we will need to check. Alissa
That is not an issue needing to be resolved.
As to the ICANN accountability cross reference placeholder; it was a holdover question (do we need a placeholder with possible text if we do) more than a drafting suggestion.
Joe
n 12/9/2014 6:19 PM, Alissa Cooper wrote:
I have consolidated the comments and edits from Milton, Adiel, Joe, and Russ in the attached v4 <https://www.dropbox.com/home/CoordinationGroup/Proposal%20finalization%20pro...>. I accepted changes on all the text where no one had commented for easier reading. I also inserted a few comments/edits of my own the proposed changes, which I repeat below.
Step 1a, bullet 3: Milton suggested using "Whether the proposal obtained consensus” instead of “How the proposal obtained consensus.” I am fine with “whether.” I would also be fine with “Whether and how.” In the RFP, we ask the communities to explain “the steps that were taken to develop the proposal and to determine consensus.” I would consider a list of those steps to be the “how.”
Step 1b: Adiel suggested adding a bullet about timeliness. I do not think this is actionable and so should not be included. If we get a proposal after the target deadline, I do not believe we are in a position to do anything other than start conducting the assessment in step 1. Of course, if we get a proposal many weeks/months after the target deadline, it will create some chaos for all of the steps afterward, but I don’t really see a lot of value in specifying how we will handle every possible case of that sort that could arise depending on the exact timing and sequence of the arrival of the component proposals.
Step 2: Adiel questioned whether the statement that the ICG’s role “is not to draft a single transition proposal” is accurate. I believe it is accurate, in the sense that we are not “drafting” or writing anything of our own. I added the words “of its own” to the end of that phrase to try to make this more clear.
Step 2: Adiel questioned the use of the word “unifying.” I agree that “unifying” and “uniform” are confusing. I believe our task is one of assembly. Our goal is to end up with one document, but not to massage the text of the component proposals to achieve “unity.” I have replaced the word “unified” in this section with the word “single” to make this clear.
Step 2a: Joe inserted “possibly conflicting” as a qualifier for “overlaps” I don’t understand what a conflicting overlap is, and I think the proposals need to have a coherent story about all overlaps. So I disagree with this addition.
Step 2b: Joe asked whether we need to cross-reference the ICANN accountability work. I think this is already covered by the fact that we are already asking "Do the proposals together include appropriate and properly supported independent accountability mechanisms for running the IANA function?”
Step 2c: There has been list discussion between Joe and Russ about testing. I suggested some text as a middle ground approach. In the RFP we do ask the communities to describe any testing they do. I’m not quite sure how the test results could conflict with each other or otherwise be problematic in combination, but I’m happy to check for that when we’re assembling the single proposal.
Step 5: I have made the latest changes suggested on the list by Milton, which I think address everyone’s concerns.
Alissa
_______________________________________________ Internal-cg mailing list Internal-cg@icann.org https://mm.icann.org/mailman/listinfo/internal-cg
_______________________________________________ Internal-cg mailing list Internal-cg@icann.org https://mm.icann.org/mailman/listinfo/internal-cg
Many thanks Alissa and everyone else for the comments .. I almost agree to all and have included my own inline below .. Apologies for the late sending .. Looking forward to further discuss on the call .. Kind Regards --Manal From: internal-cg-bounces@icann.org [mailto:internal-cg-bounces@icann.org] On Behalf Of Alissa Cooper Sent: Wednesday, December 10, 2014 1:20 AM To: ICG Subject: [Internal-cg] Proposal finalization process v4 I have consolidated the comments and edits from Milton, Adiel, Joe, and Russ in the attached v4 <https://www.dropbox.com/home/CoordinationGroup/Proposal%20finalization% 20process>. I accepted changes on all the text where no one had commented for easier reading. I also inserted a few comments/edits of my own the proposed changes, which I repeat below. Step 1a, bullet 3: Milton suggested using "Whether the proposal obtained consensus" instead of "How the proposal obtained consensus." I am fine with "whether." I would also be fine with "Whether and how." In the RFP, we ask the communities to explain "the steps that were taken to develop the proposal and to determine consensus." I would consider a list of those steps to be the "how." [MI]: I'm fine with either .. Although I think the point is that we want to ensure 'Whether' the proposal obtained consensus (the steps of which will describe 'How' of course as you rightly mentioned) yet we do not have agreed detailed criteria to evaluate the 'How' steps .. so maybe we should not be focusing on the steps and be more concerned with the result .. Step 1b: Adiel suggested adding a bullet about timeliness. I do not think this is actionable and so should not be included. If we get a proposal after the target deadline, I do not believe we are in a position to do anything other than start conducting the assessment in step 1. Of course, if we get a proposal many weeks/months after the target deadline, it will create some chaos for all of the steps afterward, but I don't really see a lot of value in specifying how we will handle every possible case of that sort that could arise depending on the exact timing and sequence of the arrival of the component proposals. [MI]: Agree with your reasons for not adding this .. Step 2: Adiel questioned whether the statement that the ICG's role "is not to draft a single transition proposal" is accurate. I believe it is accurate, in the sense that we are not "drafting" or writing anything of our own. I added the words "of its own" to the end of that phrase to try to make this more clear. [MI]: Agree with you but also see Adiel's point .. The draft is misleading until you finish reading whole sentence, which is fine for me .. But I can suggest the following alternative: "According to the ICG Charter, its role is to assemble a single transition proposal from component proposals, not to draft its own." Step 2: Adiel questioned the use of the word "unifying." I agree that "unifying" and "uniform" are confusing. I believe our task is one of assembly. Our goal is to end up with one document, but not to massage the text of the component proposals to achieve "unity." I have replaced the word "unified" in this section with the word "single" to make this clear. [MI]: Agree with you and Adiel .. Step 2a: Joe inserted "possibly conflicting" as a qualifier for "overlaps" I don't understand what a conflicting overlap is, and I think the proposals need to have a coherent story about all overlaps. So I disagree with this addition. [MI]: I noted the rest of the discussion on this in later emails .. So basically you and Joe are saying the same thing, whether, in case of overlaps, the different proposals are suggesting the same or conflicting things .. Yet I would suggest saying here "any conflicting overlaps" rather than "all possibly conflicting overlaps" .. The reason is that the latter gives the feeling that we already expect overlaps and we already expect that those overlaps are suggesting conflicting proposals .. Is this the case? Or have I misunderstood it? Step 2b: Joe asked whether we need to cross-reference the ICANN accountability work. I think this is already covered by the fact that we are already asking "Do the proposals together include appropriate and properly supported independent accountability mechanisms for running the IANA function?" [MI]: In fact, I have a question on the second part stating: "Are there any gaps in overall accountability under the single proposal?" .. How are we going to handle such gaps? Will we go back to the relevant operational community only and they coordinate with CCWG-Accountability if necessary or we will coordinate directly with both? Step 2c: There has been list discussion between Joe and Russ about testing. I suggested some text as a middle ground approach. In the RFP we do ask the communities to describe any testing they do. I'm not quite sure how the test results could conflict with each other or otherwise be problematic in combination, but I'm happy to check for that when we're assembling the single proposal. [MI]: I'm fine with the new text you proposed for Step 2c .. [MI]: Step 3: I have a problem understanding the highlighted part of this sentence: "The ICG will coordinate with the operational communities to have public comments addressed within their components before assembling an interim final proposal." Is this meant to say: - "The ICG will coordinate with the operational communities to have public comments on their components addressed before assembling an interim final proposal."? OR - "The ICG will coordinate with the operational communities to have public comments addressed within their communities before assembling an interim final proposal." Step 5: I have made the latest changes suggested on the list by Milton, which I think address everyone's concerns. [MI]: Agree with Milton's proposed text, but I have 2 remarks: - I'm more inclined to concatenate the first 2 bullets (5.a & 5.b) into one that reads "The ICG will post the final proposal on its public web site and transmit it to the ICANN Board." .. The rationale is that I feel those are simultaneous steps whereas as the bullets stands now they give the feeling that those are 2 sequential steps that may have a period of time in between .. - I'm also inclined to precede bullet 5.c with "As conveyed/communicated by the ICANN Board," .. so the whole sentence would read " As conveyed/communicated by the ICANN Board, the Board will send the final proposal to NTIA without making any changes within 14 days of receiving the proposal from the ICG. Any accompanying letter will be posted publicly " .. The rationale here is, rather than speaking on behalf of the Board or say that we are expecting, that we accurately describe the situation .. This is what was conveyed to us from the Board .. Not sure though, language wise, whether it's better/more accurate to say convey, communicate or something else .. Alissa ________________________________
Alissa, others, I think this version looks OK. I did have two observations, however. The first one is related to establishing community opinions: In Section 1 you mention “obtained consensus”, and I wanted to point out that the various communities have more fine-grained concepts relating to their decision processes. The obvious example is IETF’s rough consensus model. I expect that this is recognised by the ICG despite the brief reference of the consensus term. I think the real question is whether the proposals achieved consensus as defined in those community’s processes. Which probably includes both the actual (rough) consensus in the community but also some formal steps (like at the IETF, we have last calls, steering group approvals and so on). Actually if you can make the change s/obtained consensus/obtained consensus (as defined in that community’s process)/ this would probably be clearer to everybody. In Section 2, you say "Do they suggest any arrangements that are not compatible with each other”. As I think I’ve said in the past somewhere, it is not necessary to have alignment on everything under the sun, what matters is alignment on aspects that have an interaction. For instance, does IETF and naming communities agree on the handling of special purpose names, which is one of the areas where there is an interaction. However, compatibility is not required on other things. As a trivial example, the allocation of new TLDs and the allocation of port numbers are very different processes, and do not need to be aligned. I’d s suggest a change, e.g., s/not compatible with each other/not compatible with each other (but need to be)/. Jari
Thank you Alissa, Further comments inline: On Dec 10, 2014, at 03:19 AM, Alissa Cooper <alissa@cooperw.in> wrote:
I have consolidated the comments and edits from Milton, Adiel, Joe, and Russ in the attached v4 <https://www.dropbox.com/home/CoordinationGroup/Proposal%20finalization%20pro...>. I accepted changes on all the text where no one had commented for easier reading. I also inserted a few comments/edits of my own the proposed changes, which I repeat below.
Step 1a, bullet 3: Milton suggested using "Whether the proposal obtained consensus” instead of “How the proposal obtained consensus.” I am fine with “whether.” I would also be fine with “Whether and how.” In the RFP, we ask the communities to explain “the steps that were taken to develop the proposal and to determine consensus.” I would consider a list of those steps to be the “how.”
“Whether and How" will work for me.
Step 1b: Adiel suggested adding a bullet about timeliness. I do not think this is actionable and so should not be included. If we get a proposal after the target deadline, I do not believe we are in a position to do anything other than start conducting the assessment in step 1. Of course, if we get a proposal many weeks/months after the target deadline, it will create some chaos for all of the steps afterward, but I don’t really see a lot of value in specifying how we will handle every possible case of that sort that could arise depending on the exact timing and sequence of the arrival of the component proposals.
I think we need to have a clear statement of what we do about late submission. This is important as we have set a deadline for application and as you mentioned above some may submit theirs few hour after closure and some other may do days after. We need to be clear or give an indication to the community how we will handle that. Our process has to be irreproachable.
Step 2: Adiel questioned whether the statement that the ICG’s role “is not to draft a single transition proposal” is accurate. I believe it is accurate, in the sense that we are not “drafting” or writing anything of our own. I added the words “of its own” to the end of that phrase to try to make this more clear.
Thank, i’m fine with the adding of “of it own” to clarify. Because I believe that our purpose is to come up with a single proposal that is a consolidated version of all the various proposal submitted.
Step 2: Adiel questioned the use of the word “unifying.” I agree that “unifying” and “uniform” are confusing. I believe our task is one of assembly. Our goal is to end up with one document, but not to massage the text of the component proposals to achieve “unity.” I have replaced the word “unified” in this section with the word “single” to make this clear.
Thanks that make it clearer. We may want to discuss this a bit further during the conf call today.
Step 2a: Joe inserted “possibly conflicting” as a qualifier for “overlaps” I don’t understand what a conflicting overlap is, and I think the proposals need to have a coherent story about all overlaps. So I disagree with this addition.
No comment.
Step 2b: Joe asked whether we need to cross-reference the ICANN accountability work. I think this is already covered by the fact that we are already asking “Do the proposals together include appropriate and properly supported independent accountability mechanisms for running the IANA function?”
I think he is referring to ICANN (as IANA function contractor) own accountability?
Step 2c: There has been list discussion between Joe and Russ about testing. I suggested some text as a middle ground approach. In the RFP we do ask the communities to describe any testing they do. I’m not quite sure how the test results could conflict with each other or otherwise be problematic in combination, but I’m happy to check for that when we’re assembling the single proposal.
Step 5: I have made the latest changes suggested on the list by Milton, which I think address everyone’s concerns.
I have made a suggestion about this in the previous version which suggested to remove the sentence “which will either endorse the report, or it will express concerns that will already have been shared with the ICG through the various opportunities for public comment and dialogue”, and make the sentence read “The ICANN Board may send an accompanying letter to NTIA with it own assessment of the proposal if any.” In this version I will suggest to move the step (d) before (c) and for the current (c) I will suggest the following text: “The ICANN Board will send the final proposal to NTIA without making any changes within 14 days of receiving the proposal from the ICG. Any accompanying letter and ICANN own assessment of the proposal will [shall] be posted publicly. While we don’t want to say what ICANN should do, I think we need recognise that they can make their own assessment of the final proposal (even if step (d) provides room for clearing any issue). We want that final assessment (which may not be part of the accompanying letter) to be published. Thanks. - a.
As to the Accountability comment, Adiel's observation that it deals with ICANN's accountability is correct. On 12/10/2014 5:37 AM, Adiel Akplogan wrote:
Thank you Alissa,
Further comments inline:
On Dec 10, 2014, at 03:19 AM, Alissa Cooper <alissa@cooperw.in> wrote:
I have consolidated the comments and edits from Milton, Adiel, Joe, and Russ in the attached v4 <https://www.dropbox.com/home/CoordinationGroup/Proposal%20finalization%20pro...>. I accepted changes on all the text where no one had commented for easier reading. I also inserted a few comments/edits of my own the proposed changes, which I repeat below.
Step 1a, bullet 3: Milton suggested using "Whether the proposal obtained consensus" instead of "How the proposal obtained consensus." I am fine with "whether." I would also be fine with "Whether and how." In the RFP, we ask the communities to explain "the steps that were taken to develop the proposal and to determine consensus." I would consider a list of those steps to be the "how." "Whether and How" will work for me.
Step 1b: Adiel suggested adding a bullet about timeliness. I do not think this is actionable and so should not be included. If we get a proposal after the target deadline, I do not believe we are in a position to do anything other than start conducting the assessment in step 1. Of course, if we get a proposal many weeks/months after the target deadline, it will create some chaos for all of the steps afterward, but I don't really see a lot of value in specifying how we will handle every possible case of that sort that could arise depending on the exact timing and sequence of the arrival of the component proposals. I think we need to have a clear statement of what we do about late submission. This is important as we have set a deadline for application and as you mentioned above some may submit theirs few hour after closure and some other may do days after. We need to be clear or give an indication to the community how we will handle that. Our process has to be irreproachable.
Step 2: Adiel questioned whether the statement that the ICG's role "is not to draft a single transition proposal" is accurate. I believe it is accurate, in the sense that we are not "drafting" or writing anything of our own. I added the words "of its own" to the end of that phrase to try to make this more clear. Thank, i'm fine with the adding of "of it own" to clarify. Because I believe that our purpose is to come up with a single proposal that is a consolidated version of all the various proposal submitted.
Step 2: Adiel questioned the use of the word "unifying." I agree that "unifying" and "uniform" are confusing. I believe our task is one of assembly. Our goal is to end up with one document, but not to massage the text of the component proposals to achieve "unity." I have replaced the word "unified" in this section with the word "single" to make this clear. Thanks that make it clearer. We may want to discuss this a bit further during the conf call today.
Step 2a: Joe inserted "possibly conflicting" as a qualifier for "overlaps" I don't understand what a conflicting overlap is, and I think the proposals need to have a coherent story about all overlaps. So I disagree with this addition. No comment.
Step 2b: Joe asked whether we need to cross-reference the ICANN accountability work. I think this is already covered by the fact that we are already asking "Do the proposals together include appropriate and properly supported independent accountability mechanisms for running the IANA function?" I think he is referring to ICANN (as IANA function contractor) own accountability?
Step 2c: There has been list discussion between Joe and Russ about testing. I suggested some text as a middle ground approach. In the RFP we do ask the communities to describe any testing they do. I'm not quite sure how the test results could conflict with each other or otherwise be problematic in combination, but I'm happy to check for that when we're assembling the single proposal.
Step 5: I have made the latest changes suggested on the list by Milton, which I think address everyone's concerns. I have made a suggestion about this in the previous version which suggested to remove the sentence "which will either endorse the report, or it will express concerns that will already have been shared with the ICG through the various opportunities for public comment and dialogue", and make the sentence read "The ICANN Board may send an accompanying letter to NTIA with it own assessment of the proposal if any."
In this version I will suggest to move the step (d) before (c) and for the current (c) I will suggest the following text:
"The ICANN Board will send the final proposal to NTIA without making any changes within 14 days of receiving the proposal from the ICG. Any accompanying letter and ICANN own assessment of the proposal will [shall] be posted publicly.
While we don't want to say what ICANN should do, I think we need recognise that they can make their own assessment of the final proposal (even if step (d) provides room for clearing any issue). We want that final assessment (which may not be part of the accompanying letter) to be published.
Thanks.
- a.
_______________________________________________ Internal-cg mailing list Internal-cg@icann.org https://mm.icann.org/mailman/listinfo/internal-cg
On 10.12.14 11:37 , Adiel Akplogan wrote: ...
“The ICANN Board will send the final proposal to NTIA without making any changes within 14 days of receiving the proposal from the ICG. Any accompanying letter and ICANN own assessment of the proposal will [shall] be posted publicly.
While we don’t want to say what ICANN should do, I think we need recognise that they can make their own assessment of the final proposal (even if step (d) provides room for clearing any issue). We want that final assessment (which may not be part of the accompanying letter) to be published.
How about "The ICANN board has statet that it will send .... and that it will publish any accompanying communications at that time." That way we do not tell ICANN what to do and we still have our expectations documented. For d) we can be a bit more presumptive, e.g.: "The ICG expects that the ICANN board will participate in the available .... together with the other parts of the community in order to prevent any last minute contention."
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Alissa, wrt 5. last para: I suggest you take the text from the discussion and augment it with what Kuo has typed in the chat room. Let me know if I can help find specific words. Daniel -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iQIVAwUBVIg4+dDY5Emqa716AQIITQ//c38WiyR9lRR2eRY+lpgHOtQPZQcDdDH9 3MsBuDUXz8eYJoeEu4yXDlq9yL+Hq4PcrMMv1TMcqzNorUhW+v6PPepYbbJablg0 RAK6tW7MUdjPX4aK6fwu5PUgQjsMaVxyEdJ5lsg2pPYqrYLa8QA+VwWDDTxYj56b HzOKikdeABBEPKzzqf1oLAqq+OOJoH6ZpvqxDgFDSIPHXYSIWGUUdXGimbeshwen uV19CNR0xUDmwrd0zHoMRSsG3Z7+ZbjPDUuZtQp1dnxTl5nvdKdmzMbaHc+4cD9e DcRnNXvGLgW/ZPGIZEixOf0DvQcb0WVauAzpz85bqId0u59xmadx5B3ZfPYCU0HY aiNyiuw0M83dy3OE7t6gygNPzbkCQSm0juMh6CE2Y/st96ctY7FPASVbh7gXPCpK kcrV9Stj1Gfvvz3qqy4LqVo60uGq1uP6B0n6QgV5cpcK07MNjlHzXWNjSlrwHXUA yqD7HkV06c7tXoWnaaXk0o5d47A+35psD9SjIpWzz1TxTNcip8jmU359V7PS5qvD Ua1bU32fpo8+6xrNxVdaPBl1MZ6yTIdUKLMUQ8LmES1+DTa1PhSRbFWp7fCCEod6 rGuzEyks+JqULq0DplLH6b19cDf0XO/hsKBOCEeV1ihor+qHf4XxR/kdXAZYBfql 5i5GWXKoaKI= =PV+6 -----END PGP SIGNATURE-----
participants (6)
-
Adiel Akplogan -
Alissa Cooper -
Daniel Karrenberg -
Jari Arkko -
joseph alhadeff -
Manal Ismail