<html>
<body>
<font size=6>Changes:<br><br>
</font>- 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.<br><br>
- Replace Paragraph 4 in both the III.A.iii and Annex N with:<br><br>
Control of Root Zone Control Management<br><br>
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.<br><br>
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. <b>Comments are
welcome on this issue.</b> <br><br>
<br><br>
<br>
<font size=6>Replies to comments:<br><br>
</font><b>Section III.A.iii<br><br>
</b>Paragraph 2.c <br><br>
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…) <br><br>
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.<br><br>
<br>
Paragraph 4<br><br>
Sidley: title is cryptic, as is text describing "two
functions"<br>
Martin: No changes at the start possible pending a review. RZ Maintainer
may query instructions if there is a problem.<br>
Andrew Sullivan: No change at start, and then anything could
change.<br><br>
Martin's comment on RZ Maintainer being allowed to raise questions is
part of the current operational environment and not change is
envisioned.<br><br>
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.<br><br>
<br><br>
Annex N<br><br>
Paragraph 1.a<br><br>
Andrew Sullivan: Asks why is "act as approver" a very short
term approach and this section seems like
"over-specifying"<br><br>
AG: <br>
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.<br><br>
<br>
Paragraph 2.a<br><br>
Andrew Sullivan: (Paraphrased) If we no longer need the NTIA, why do we
need a new "approver" instead of relying on the MS
Community?<br><br>
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.<br><br>
<br>
Paragraph 3.a<br><br>
Andrew Sullivan: Publication after a decision does not seem to be a big
deal, but before a decision might lead to wider consultation.<br><br>
AG: Publication of approved changes (generally changes requested by a
registry) would allow independent review that what Verisign publishes is
what IANA requested.<br><br>
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.<br><br>
Alan<br>
</body>
</html>