[DT-F] URGENT: My thoughts on DT-F Replies to Public Comments.

[Alan Greenberg]

At 01/06/2015 04:40 PM, Gomes, Chuck wrote:
>Thanks Alan for taking the first stab at this.  My responses are 
>inserted below.
>
>Chuck
>
>From: cwg-dtf-bounces at icann.org [mailto:cwg-dtf-bounces at icann.org] 
>On Behalf Of Alan Greenberg
>Sent: Monday, June 01, 2015 11:59 AM
>To: CWG DT-F
>Subject: [DT-F] URGENT: My thoughts on DT-F Replies to Public Comments.
>Importance: High
>
>Marika has provided excerpts from the CWG Public Comments that might 
>be applicable to DT-F. I have reviewed them and here is my input. 
>Please indicate whether you concur or how you would alter them. 
>Those potentially applying to DT-F are in PINK.
>
>We have very little time to respond, so I would appreciate prompt replies.
>
>Item 293. My understanding is that DT0D recommended that the NTIA 
>Authorization function related to RZ *AND* Whois changes is not 
>longer needed. Any reference to the RZ authorization function whold 
>be changed to include RZ Whois as well.
>[Chuck Gomes] Agree.
>
>Item 294. This is a valid comment. Although DT-F did not advocate 
>publishing redelegation requests, we did use it as an example of a 
>possible report. I would suggest keeping the example, since it has 
>been an oft-requested report, but adding a caveat to this effect.
>[Chuck Gomes] Agree.
>
>
>Item 297.1 The first part implies that there should be formal 
>"community" participation in the approval process. Although 
>certainly a Public Comment might be warranted, I cannot see having a 
>community vote on such matters (as implied by the word "oversight"). Comments??
>[Chuck Gomes] Introducing public comments in the IANA processes 
>would significantly slow service levels down.  I doubt that AFNIC 
>was suggesting a vote.  I think it might be good to say something 
>like this: "The CWG supports oversight of the IANA processes in two 
>primary ways: 1) transparency of the processes while still 
>respecting privacy concerns; 2) monitoring by the CSC."

[AG] Fine.



>Item 297.2. It is reasonable that there be a linkage between any 
>advisory group that would recommend tat significant changes be 
>approved, and the CSC. I will incorporate that into the next version 
>of the DT-F Recommendations.
>[Chuck Gomes] Agree.
>
>
>Item 300.1. My understanding is that all changes ARE currently 
>verified with registries. David. Does that match your understanding?
>[Chuck Gomes] That is my understanding as well.
>
>
>Item 300.2. It is reasonable to specify that directo customers be 
>included. I am not at all sure I would restrict it to them and IANA.
>[Chuck Gomes] Who else would you include Alan?  Would it suffice to 
>just agree with Nominet on this?

[AG] I would include pretty much the same bodies that we are 
suggesitng be included in the review of major operational changes. 
Certainly SSSAG, Root Zone operators and so forth.



>Item 300.3. Correct. We did decide that it should be the ICANN 
>Board, but it either was omitted accidentally or the decision was 
>made after publication.
>[Chuck Gomes] Agree.
>
>
>Item 304. Noted and the next version of the Recommendations will 
>provide further details.
>[Chuck Gomes] This item has three parts so I think it would be 
>better to separate them like you did on others.  Noting the comments 
>for 304.1 and 304.3 seems fine. But I think we need to say more for 
>304.2 because they are specifically suggesting formation of a new 
>ICANN advisory committee.  My first question is this: if a committee 
>was formed, should it be an ICANN or PTI advisory committee?  My 
>second question is: would one advisory committee work for different 
>architecture and/or operational issues?  I suspect not.  @ Alan: 
>what further details are you referring to?

[AG] As I read it, the 2nd paragraph is referring to what I had 
originally called Board subcommittee that would oversee the review of 
substantive changes. We said this "committee" would not necessarily 
be the actual people that contributed to any given decision but hat 
it would ensure that the appropriate people/bodies are involved.



>Item 306.1. Noted and the next version of the Recommendations will 
>provide further details.
>[Chuck Gomes] It is not clear what is 306.1 and 306.2.

[AG] Sorry, I messed up the numbering here.


>  In our response, we will need to be specific about what we are 
> responding to.  Also, it seems to me that there are more than two 
> comments here to which we should respond: 1) The BC supports the 
> CWG recommendation that the replacement for NTIA approval function 
> should be clearly designated, especially for major operational 
> changes; 2) A solid approval function and transparent process must 
> be defined in details before the transition and must not be left 
> open to be defined at a later stage; 3) it is essential for the 
> recommendation to explicitly establish which entity will have the 
> role of approval, and to explicitly establish the process that 
> would be used for consultation to ensure a high level of community 
> support for major changes; 4) The BC also recommends that the 
> community be given an update on the parallel process of 
> transitioning the Root Zone Maintainer role; 5) we call the CWG to 
> include a mechanism that would enable tracking of content changes 
> in the Root Zone and reversal if necessary. Here are my personal 
> responses to each one: 1) agree; 2) agree; 3) agree and I think we 
> may need to provide details, which I assume is part of what is 
> meant in the response for 306.1; 4) I assume the first response 
> below for 306.2 covers this; 5) Does the IANA team already do this 
> and, if so, we should say that or, if not, should we recommend it?

[AG] Your answers are fine. On the last item, I am sure that IANA 
tracks what they do and could unwind if needed. If it does not, I 
don't think our job is to recommend such changes but it could be 
included in the post-transition review.

Alan



>Item 306.2. We have no power to ensure an update on the RZ 
>Maintainer Cooperative Agreement. "Specifically, we call the CWG to 
>include a mechanism that would enable tracking of content changes in 
>the Root Zone and reversal if necessary." seems to not be related to 
>the previous sentence, but in any case, seems to be something that 
>could be considered in the recommended post-transition review.
>[Chuck Gomes] See my comments on 306.1.
>
>
>Alan
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/cwg-dtf/attachments/20150601/20fa838a/attachment-0001.html>