[Internal-cg] Minorly revised Q1 on RZM and totally revised Q2 on RZM

[Russ Mundy]

Responses inline below.  RussM

On Sep 22, 2015, at 3:50 PM, Alissa Cooper <alissa at cooperw.in> wrote:

> Hi Milton,
> 
>> On Sep 22, 2015, at 11:19 AM, Mueller, Milton L <milton.mueller at pubpolicy.gatech.edu> wrote:
>> 
>> Responding to Alissa's suggestions...imagine the sound of a can of worms being opened.
>> 
>>> -----Original Message-----
>>> 
>>> sub “confirm whether” for “confirm that"
>> 
>> Sorry to be a stickler for language, but I find "confirm whether" to be bad English. "Whether" implies choosing among alternatives; e.g., "whether or not". "Confirm" implies certifying a particular, singular option as acceptable.  I don't think you can confirm whether. One can "determine whether" or "decide whether or not" something meets your requirements, or one can "confirm that" a specific option does meet your requirements. So, in case you think it is too leading (in which case we switch to "determine whether or not"), I would prefer to stick with "confirm that.”
> 
> I do think it’s too leading, unless you can point me to where the CWG has made any comment about the VeriSign/ICANN proposal already. If not, I would suggest “inform us about whether or not”

I’ve read the newer version in the Word docx sent a couple of hours ago and am fine with that wording.

> 
>> 
>>> Please insert a citation to the paragraph or section from the combined
>>> transition proposal that states the CWG’s requirements.
>> 
>> Good catch. Here is the entire question as so revised: 
>> 
>> 1. Due to concerns expressed in the public comment period, ICG asks the CWG-Stewardship to confirm that the Verisign/ICANN proposal for revising Root Zone Management arrangements after the elimination of NTIA's authorization role meets the CWG's requirements as expressed in paragraph 1150, sections 2 and 3 of Part 1 of the transition proposal.
>> 
>> IMPORTANT ADDITIONAL NOTE: 
>> 
>> In searching for the appropriate citation, I discovered paragraph 55 of our own Part 0, in which the ICG (that's us, folks!) says: 
>> 
>> "However, since there is currently no agreement between the RZM and the IANA functions operator for the Root Zone Management process, the ICG notes that some form of written agreement between the IANA functions operator and RZM that clearly defines the roles and responsibilities of both parties is essential for the secure, stable and resilient operation of the Root Zone of the DNS when the NTIA withdraws from the Root Zone Management process."
>> 
>> This text strongly suggests that a written agreement between IFO and RZM is a "requirement." But I cannot find an explicit statement to that effect from the CWG itself. What we do have, is a statement in 1150(2)(b) that:
>> 
>> " the new arrangements must provide a clear and effective mechanism to ensure that PTI can have its change requests for the Root Zone implemented in a timely manner by the Root Zone Maintainer (possibly via an agreement between the Root Zone Maintainer and the IFO)."
>> 
>> "Possibly." Should we, therefore, consider a "written agreement" a requirement? And if so, since we seem to have made it a requirement would it be useful for ICG to ask _itself_ whether the ICANN-Verisign proposal meets that requirement (hint: it doesn't). Or should we approach this issue in some other way?  
> 
> Interested in Russ Mundy’s opinion about the above since he authored paragraph 55. 

As I wrote (received suggestions & rewrote) the section, the primary intent was to point out that no written agreement existed between the IFO & RZM and the CWG proposal was not particularly clear about how this was going to be handled.  On the other hand, it does not seem to be within the ICG remit to define details about the content of the agreement or what organizational entities should sign it.

Since there are root zone management requirements and impacts identified in multiple parts of the CWG proposal including section 1150, annex F, annex K, annex P, annex R and annex S - none of these had any definition or description of how the IFO & RZM would accomplish these activities.

> 
>> 
>> AND AS FOR QUESTION 2:
> 
> All of the below seems fine to me, with one editorial suggestion ...
> 
>> 
>> While searching for the appropriate citation, I may have found the missing reference to splitting of the IFO and RZM functions that everyone believed existed but no one could find. In Annex S, Draft Proposed Term Sheet, page 136 of the full proposal, the second bullet point in the 4th row says:
>> 
>> "Process flow for root zone management involves two roles that are performed by two different entities: 
>>   - PTI as the IANA Functions Operator
>>   - Verisign (or its successor) as the Root Zone Maintainer (RZM)."
>> 
>> The fourth bullet point in the same cell says: 
>> 
>> "Any amendment to the roles and responsibilities of PTI and the RZM with respect to root zone management will require approval of the ICANN board [and the members of ICANN or a special IFR]"
>> 
>> This is problematic. First, the reference to members and a special IFR, which would probably meet the public comment demands for "consultation" and accountability, are in brackets. What does that mean? Second, this text suggests that PTI and RZM are separate organizations (entities) more strongly than the text in 1158 (Principles), which only refers to them as different "roles" or "functions." 
>> 
>> I welcome additional comment on this, but in the interest of time I want to get a specific proposal on the table. So I propose that we update question 2 in the following way:
>> 
>> NEW QUESTION 2
>> 
>> 2. The names part of the proposal contains subtle but significant discrepancies in the way it describes the roles of the IANA Functions Operator (IFO) and the Root Zone Maintainer (RZM). It also seems to contain different requirements for a process to change those roles. Paragraph 1158 in Part 1 of the transition proposal describes the RZM and the IANA functions operator as separate “roles” with distinct functions, and says "should there be proposals to make changes in the roles associated with Root Zone modification, that such proposals should be subject to wide community consultation." On the other hand Annex S, the Draft Proposed Term Sheet (page 136), describe the IFO and RZM as "two roles that are performed by two different entities," and adds "any amendment to the roles and responsibilities of PTI and the RZM ... will require approval of the ICANN board [and the members of ICANN or a special IFR]. 
>> 
>> Which of these two approaches better reflects the consensus of the names operational community: the one embodied in Annex S or the one embodied in paragraph 1158? Paragraph 1158 does not clearly rule out having the RZM and IFO in the same organization, as long as the "roles" and "function" are distinct. Whereas Annex S suggests (in bracketed language) that any change or merger in the roles would be subject to community accountability, 1158 suggests only a “wide community consultation?”’
> 
> The above sentence should end in a period rather than a question mark.
> 
> Thanks,
> Alissa
> 
>> The ICG would like to know what is meant by a wide community consultation. Is it the same as a public comment period? Does it also imply that wide community consensus would be necessary before making the change? The CWG is requested to provide comment or clarification for any further action, as appropriate.
>> 
>> --MM
> 
> 
> _______________________________________________
> Internal-cg mailing list
> Internal-cg at mm.ianacg.org
> http://mm.ianacg.org/mailman/listinfo/internal-cg_ianacg.org