So as not to incur the wrath of Tim (again), (He knows what I mean.)
On 9/12/16, 16:19, "DNSOP on behalf of Suzanne Woolf" <dnsop-boun...@ietf.org on behalf of suzworldw...@gmail.com> wrote: >As we discussed in Berlin, we need to move forward with adopting a problem >statement draft for further work on special use domain names. >The drafts are: >https://datatracker.ietf.org/doc/draft-tldr-sutld-ps/ >https://datatracker.ietf.org/doc/draft-adpkja-dnsop-special-names-problem/ I've read both, the -03 of the former and -06 of the latter. Grading them strictly on providing a concise problem statement regarding issues with the Special Use Domain Name registry, "draft-adpkja-" stays more on topic than "draft-tldr". I had been holding off on replying for a number of reasons. There's been more than enough words spilled over this already and over a fairly long duration - without much milestone-hitting progress. Still, as esoteric as this topic has become, I believe that having a Special Use Domain Name registry is important. I don't want to see it wither away because no one wants to fix it. It is important to have a means to document the uses of domain names that are not DNS compatible, specifically referring to the difference between the zone administrators of the DNS as described in STD 13 documents and the administrative models implemented via distributed hash tables. The IETF needs a stronger registry for these names. The "draft-adpkja-" is more helpful in this regard as it focuses on the registry today and addresses specific shortcomings (even if I'd edit them some - but that's what a WG document is for). "draft-tldr-" covers a far wider net, covering far ranging issues, winnowing them down to an actionable set would require more time. For example, "draft-tldr" describes this: "enforce ... authority over any third party who wants to just start using a subset of the namespace". For a while I was concerned about this use case too, but it is simply something that cannot be treated in documents. In my notes on the document, I kept repeating - it's not about control or authority but about maximizing interoperability. I say this as an example of places where "draft-tldr" is trying to describe a problem much more expansive than what "needs solvin'" (at this moment, at least). Aside - I had other comments on "draft-tldr", including whether it was wise to introduce new terminology in a problems statement document. In a solutions document, perhaps, but in a problems statement the new terms cause more confusion. When I came to section 4.2 my note was "what was SUTLIN again?" This might fall in to the layer of nits but structurally, creating a new vocabulary seems to indicate a solution path is already in mind.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
