[CWG-Stewardship] DT-F Changes and comment replies

[Alan Greenberg]

Changes:

- The title for section III.A.iii is replicated, 
once all in upper case and then again under III.A.iii.a in regular case.

- Replace Paragraph 4 in both the III.A.iii and Annex N with:

Control of Root Zone Control Management

Currently updating the Root Zone requires the 
active participation of three parties, the IANA 
Functions Operator, the Root Zone Maintainer and 
the NTIA. The IANA Functions Operator receives 
change requests from various sources, validates 
them, and sends them to the Root Zone Maintainer 
who, once they are authorized by the NTIA, 
updates the Root Zone File, DNSSEC signs it, and 
distributes it to the Root operators.

Post transition there will only be the IANA 
Functions Operator and the Root Zone Maintainer. 
It is clear that the CWG is not suggesting any 
change to this operational relationship at the 
moment, but is considering whether this division 
of responsibility must be maintained in the long 
term, or could be altered in the future, either 
to combine the functions, or two reallocated the 
responsibilities. Proponents of the current 
division believe that having two parties involved 
reduces the chance of errors or untoward action. 
Others believe that we should look at the overall 
system and if and when there are to be changes, 
we should design something that is optimal, 
without prior constraints. Comments are welcome on this issue.




Replies to comments:

Section III.A.iii

Paragraph 2.c

Martin: it is not clear who is funding whom.  I 
think that the budget would be provided by ICANN 
to the PTI Board to support the IANA functions operator's capability
)

AG: Yes, that is the likely source of funding as 
we are discussing now. But the statement is more 
generic. IANA must have adequate funds to allow 
the Root Zone management function to evolve. If 
at some point in the future the funds come from 
somewhere else, the statement is still true.


Paragraph 4

Sidley: title is cryptic, as is text describing "two functions"
Martin: No changes at the start possible pending 
a review. RZ Maintainer may query instructions if there is a problem.
Andrew Sullivan: No change at start, and then anything could change.

Martin's comment on RZ Maintainer being allowed 
to raise questions is part of the current 
operational environment and not change is envisioned.

AG: This section is there because some DT-F 
members felt very strongly that it was important 
to state as an inviolate principle. Others have 
pointed out that double control can reduce points 
of failure, but this particular division of 
responsibilities does not necessarily do that. 
*IF* a division is to be maintained, it is not 
clear that the current division of 
responsibilities is optimal. There has been 
significant discussion within the group AFTER 
this wording was frozen. I have revised the wording.



Annex N

Paragraph 1.a

Andrew Sullivan: Asks why is "act as approver" a 
very short term approach and this section seems like "over-specifying"

AG:
This covers the possibility that the software 
could not be changed in time, or more likely to 
not HAVE to change it at the exact moment of 
transition. It could be used in the longer term, 
but that adds unnecessary work and there is no 
substantive reason to do so. Perhaps it is 
over-specifying but several people intimately 
involved in the actual process thought it was worth including.


Paragraph 2.a

Andrew Sullivan: (Paraphrased) If we no longer 
need the NTIA, why do we need a new "approver" 
instead of relying on the MS Community?

AG: There was (I believe) unanimity that we do 
want this. The belief was that for major changes, 
there should be a formal path to mae the decision 
and not just leave it up to IANA with whatever 
consultation they feel might be appropriate. The 
new big-brother IS the MS community, but embodied 
in an some designated entity. It has been 
suggested that the ICANN Board might be that 
entity, but that needs further discussion.


Paragraph 3.a

Andrew Sullivan: Publication after a decision 
does not seem to be a big deal, but before a 
decision might lead to wider consultation.

AG: Publication of approved changes (generally 
changes requested by a registry) would allow 
independent review that what Verisign publishes is what IANA requested.

The publication of pending redelegation requests 
is both transparency AND an opportunity for wider 
consultation. It is reporting that has often been 
requested. RFC 1591 calls for the involvement in 
the local community, but currently, if a segment 
of the community is not explicitly involved by 
one of the parties, they may not even know a redelegation is being considered.

Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/cwg-stewardship/attachments/20150420/1fb97aef/attachment-0001.html>