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