Re: [DNSOP] New Version Notification for draft-adpkja-dnsop-special-names-problem-00.txt

[Donald Eastlake <[e-mail]>]

I endorse and support Stuart Cheshire's remarks below.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   [phone] (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [e-mail]

On Tue, Dec 29, 2015 at 4:32 PM, Stuart Cheshire <[e-mail]> wrote:

> Hi Joe, Peter, Alain,
>
> I have some feedback on draft-adpkja-dnsop-special-names-problem-00.
>
> There seems to have been lots of recent discussion regarding confusion
> surrounding RFC 6761. I’m a little surprised by this, since I didn’t think
> RFC 6761 was unclear. But then as co-author, that’s my failing. I thought
> it clearly stated our intention, and I thought the IETF Last Call scrutiny
> should have identified any ambiguity, but apparently not.
>
> >    In recent years, using the last label of a domain name (aka TLD) as
> >    switch to indicate how to treat name resolution has been experimented
> >    using the framework of [RFC6761].
>
> Not only the last label. The last _n_ labels are also commonly used as the
> algorithmic method for determining what names qualify as special. Some
> examples:
>
> 10.in-addr.arpa.
> 168.192.in-addr.arpa.
> example.com.
> example.net.
> example.org.
>
> >    This switch practice is not explicitly documented anywhere.
>
> That was the intention of the seven-question list: to have protocol
> specifications explicitly document their “switch practice” -- i.e. how
> their special names are to be unambiguously recognized, and what software
> should do having recognized one of them.
>
> >    Answers to these seven questions provide guidance to the
> >    corresponding seven audiences on how to handle a special-use domain
> >    name once it has been reserved by inclusion in the Registry.
> >    However, they are inadequate for making the determination whether a
> >    particular domain name qualifies as being special in the first place.
>
> You have it backwards. The seven questions were not “what to expect
> *after* this special-use registration is done”; they were the
> justifications *why* the special-use registration should be granted,
> required in a document demonstrating that it (a) provides a result that the
> community judges to be good, and (b) the aforementioned good result cannot
> reasonably be achieved better another way.
>
> >    The lack of a more elegant way to specify a name resolution protocol
> >    in (for example) a URI amounts to an architectural oversight.
>
> I’m not sure I agree that there *is* a more elegant way to achieve the
> desired effect. Unless you intend to actually describe some hypothetical
> “more elegant way” of doing this, I suggest simply removing this
> unsupported implication from the document.
>
> >    It should also be noted that there are other choice than using the
> >    most significant label for a protocol switch.  In particular, a
> >    proposal to move those protocol switches under a specific top level
> >    domain has been discussed (.ALT).  If that architecture choice is
> >    made, some of the questions listed in the sections bellow (sic) would
> >    become moot.
>
> RFC 6761 is not, and has never been, about TLDs. It is about special
> behaviours, and how to trigger them. As such, whether the protocol switch
> is a TLD, or SLD, or 3LD, or whatever, has no bearing at all on “the
> questions listed in the sections below”. The same concerns would apply
> equally, regardless of how the algorithmic determination of “specialness”
> is to be performed. RFC 6761 states that the algorithmic determination is
> *typically* done by looking for a certain suffix (i.e., one or more
> labels). I deliberately did not want RFC 6761 to over-specify this, so as
> to leave the door open for someone smarter than me who might come along in
> the future and propose some new and valid algorithmic determinant that I
> had not anticipated. Clearly a document stating that any name containing
> any label starting with an “x” is now “special” ought to be thrown out by
> the IESG as unreasonable, but there could be other valid ideas beyond my
> current imagination.
>
> >    Note: [RFC6761] mentions the reserved names could be any label in any
> >    random string, not just the rightmost one (or ones).
>
> Can you cite the actual text that says that? I couldn’t find what
> particular text you’re paraphrasing there.
>
> >    What does it mean to have a "non-DNS" entry in the registry
> >    described above?
>
> The answers to the seven questions, and other text in the associated
> protocol specification, are supposed to tell you what it means.
>
> >    Are applications supposed to check that registry to know what to do?
>
> No.
>
> >    Can/Should applications do this check dynamically?
>
> No.
>
> >    What if an application makes this dynamic check and realizes the
> >    name contains a switch it does not know how to treat?
>
> Not applicable. The closest equivalent to the run-time mechanism you’re
> hinting at is something that already exists: The global DNS. Putting in
> authoritative NXDOMAIN results for all appropriate special-use names is the
> best way to achieve the result you want.
>
> >    it is not clear who is responsible for carrying out an
> >    evaluation.  A document which requests additions to the Registry
> >    might be performed by the IESG, by the IAB, by the DNSOP working
> >    group, by an ad-hoc working group, by expert review or any
> >    combination of those approaches.  [RFC6761] provides no direction.
>
> RFC 6761 says:
>
>    When IANA receives a request to record a new "Special-Use Domain
>    Name", it should verify, in consultation with the IESG, that the IETF
>    "Standards Action" or "IESG Approval" document [RFC5226] includes the
>    required "Domain Name Reservation Considerations" section stating how
>    the special meaning of this name affects the behavior of hardware,
>    software, and humans in the seven categories.  If IANA and the IESG
>    determine that special handling of this "Special-Use Domain Name" is
>    appropriate, IANA should record the Special-Use Domain Name, and a
>    reference to the specification that documents it, in the registry.
>
> I confess I has assumed that IANA would designate some person with the
> expertise and experience to evaluate whether “... special handling of this
> "Special-Use Domain Name" is appropriate ...”, much as requests for TCP and
> UDP ports are evaluated. That was my mistake. I should have been explicit
> about the intended review process.
>
> >    For example, is large scale prior deployment an acceptable criteria?
>
> Large scale prior deployment should *not* be required -- that would just
> make squatting a necessary prerequisite for getting a special use name
> assigned. RFC 6761 was intended to provide a legitimate path for proposals
> to be evaluated on technical merit, rather than de facto squatting.
>
> >    Going back to the previous point of prior usage of the protocol, in
> >    the case of LOCALHOST, LOCAL and ONION, those particular domain names
> >    were already in use by a substantial population of end-users at the
> >    time they were requested to be added to the Registry.  Rightly or
> >    not, the practical cost of a transition was argued as a justification
> >    for their inclusion in the registry.
>
> No. The justification for having an entry in the registry was to
> facilitate the desired special behaviour. The particular choice of what
> name went in the registry was influenced by existing usage, but the
> justification for having the entry itself was motivated by the desire for
> special behaviour. If the IETF process went a bit more smoothly, the IETF
> would have more participation in the choice of name *before* it becomes too
> late to easily change that.
>
> As I read it, draft-adpkja-dnsop-special-names-problem seems to focus far
> too intently on the issue names. (But then, that is what ICANN is in the
> business of selling, so maybe it’s not surprising.) The substance of RFC
> 6761 is about enabling special behaviours, and using special names to
> trigger those special behaviours is merely a means to the end. What is
> interesting and important, and worthwhile for the IETF to support, is the
> special behaviours, not the names.
>
> Stuart Cheshire
>
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop
>