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" < 
on behalf of> 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:

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 

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.

Attachment: smime.p7s
Description: S/MIME cryptographic signature

DNSOP mailing list

Reply via email to