> Part of the issue with IANA-instruction documents is that they fail to > expose the considerations that have motivated the proposed action, and > it's this lack of context during the review phase that tends to provoke > a critical reaction. > > I suspect that what the IESG is asking for is a roundabout way of a > consensus call on the proposed instruction to IANA, not publication of > the document. (Here I'm reading the whitespace of the IESG text, not > their actual words!) > > The question of "should it be published?" I interpret as a question of > "should the IETF attempt to direct the IANA to create such a registry as > a part of an IETF standards action?" > > Two subsidiary questions back to the IESG: > > - given that this is not a standards action document, does > publication of the document as informational constitute a clear > and definitive instruction to IANA? > > - under the current division of responsibilities between the > various bodies who claim interest in the DNS, is it the role of > the IETF to undertake such an instruction to IANA in this DNS > space? > > There are a number of subject-oriented questions about DLV, as distinct > from process and role issues that this proposed action also highlights: > > - what key should IANA use to sign this DLV registry? One IANA creates and publishes. This is no different to what ISC did. > - would this key be any different than a hypothetical key that would be > used to sign the DNS root? Why? Why Not? In pure DNSSEC terms it can't be the root key. The only way it could be the root key is if the root is signed and the registry was part of the root zone. > - is this just an ersatz root signing mechanism? Why is this appropriate > given that the alternative is simply a signed root zone? This proposal is a way to move forward without waiting for the politics of signing the root to resolve. This is the classic case of the network routing around a blockage. I do believe that it will eventually resolve but at glacial pace. Generally, DLV trees can work around missing chains of trust. This helps regardless of whether the root is signed or not. You need to get all infrastructure providors to sign their zones before DLV will become irrelevent. > - in the absence of full signing of the DNS from the root down, just how > many DLV spots must a resolver look in? It seems that proliferation of > DLV lookup points is no better (and arguably much worse) than the > original problem of piecemeal DNSSEC deployment - that of key hunting. Hopefully only one. You would use IANA's one if you want to see what the world would be like if the root is signed. You would use ISC's (or similar) if you want to work around missing links in the chains of trust. > Now I'm sure that the author of this document has answers to these and > many more questions, as these considerations are indeed the motivation > for the proposed action. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@xxxxxxx _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf