On 2013-04-04, at 17:00, Paul Hoffman <paul.hoff...@vpnc.org> wrote:
> You must have misread the verb tense in my message. :-) "has supplied" is > quite different than "efforts is ongoing". Well, what we have is a design that was put together by ICANN, Verisign and NTIA (the three organisations that maintain and publish the root zone) that was widely discussed by e-mail and in person across five continents prior to July 2010. We heard no dissent or suggestions to change, so that's what we went with. It's entirely understood that lack of feedback doesn't mean improvements can't be made; my point is the origins of the design work, and the venues in which it was widely circulated for comment. There is no IETF-produced documentation for any operational aspect of the system. It was all designed and documented by the root zone partners. The I-D referred to earlier (as a successor to the TA retrieval document we published in July 2010) was not intended to be an IETF work product; it was instead intended to be an individual submission documenting an operational system of relevance to the IETF, published in the RFC series for ease of citation. > This is a serious question: would it be reasonable for ICANN to do a key roll > when there is no IETF documentation on how to recover from missed rolls? Some > might say "yes", but you can tell I would not. Ah, now you're talking about something different -- you're talking about IETF guidance to the relying parties of the system rather than IETF guidance on how the system should be operated. > While I appreciate that ICANN wrote a document, unless you want to say "this > is the the ICANN document you should use to deal with the operation we are > about to perform", it needs to have an RFC stamp on it. That sounds like exactly what we will say, with the minor correction that the root zone partners are working together on this; it's not all ICANN's work. If there was relevant IETF work that we could incorporate into the system, surely we would do so (as we did with 4033-5 and 5011). But the design of the system and the operational procedures associated with it are not products of the IETF, and given the contractual framework within which the work takes place it's not obvious how they could be. Joe _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
