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

Gomes, Chuck cgomes at verisign.com
Mon Jun 1 20:40:16 UTC 2015


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."


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?


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?


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.  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?


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/a5ed75f2/attachment.html>


More information about the cwg-dtf mailing list