Special-Use Domain Names
draft-cheshire-dnsext-special-names-03

[Ballot discuss]
Taking over Tim's discuss.

I expected the document to seed the registry with entries (at a minimum) for the
special domain names identified in the introduction:

  Analogous to Special-Use IPv4 Addresses [RFC5735], DNS has its own
  concept of reserved names, such as "example.com", "example.net", and
  "example.org", or any name falling under the top level pseudo-domain
  "invalid" [RFC2606].

Without those entries (or a plan to create those entries), I don't quite see
that this document accomplishes anything.

[Ballot discuss]
Taking over Tim's discuss.

I expected the document to seed the registry with entries (at a minimum) for the
special domain names identified in the introduction:

  Analogous to Special-Use IPv4 Addresses [RFC5735], DNS has its own
  concept of reserved names, such as "example.com", "example.net", and
  "example.org", or any name falling under the top level pseudo-domain
  "invalid" [RFC2606].

Without those entries (or a plan to create those entries), I don't quite see
that this document accomplishes anything.

[Ballot discuss]
I'm holding this DISCUSS for IANA.

From IANA Considerations:

  IANA needs to create a new registry of Special-Use Domain Names.

  When IANA receives a request to record a new "Special-Use Domain
  Name" it should verify that the IETF "Standards Action" RFC [RFC5226]
  includes the required "Domain Name Reservation Considerations"
  section stating how the special meaning of this name affects the
  behaviour of hardware, software, and humans in the seven categories,
  and if so, record in the registry the Special-Use Domain Name and a
  reference to the RFC that documents it.


We strongly feel that IANA should not be the ones “verifying” that the
“Domain Name Reservation Considerations” is in the document and that
it contains the information for the “seven categories”.  It is a
question of who is responsible for verifying the information.  I don’t
think it is IANA.

Since a Standards Action is required to register a special name, this
document should say that the RFC requesting the special-use domain
should contain the domain name reservation considerations section.
The IANA section should just contain the request for the special
domain.

[Ballot discuss]
This updated - I'll retain the #.

The first one is a DISCUSS-DISCUSS

#2) Use of the word "needs" in Section 3 seems like it ought to be MUST.  Is there a time when you wouldn't do the items it suggests?

#3) Shouldn't the "Special Name Considerations Section" just be part of the IANA considerations section?

#4) I'm also going to hold a placeholder discuss for IANA.

[Ballot discuss]
I expected the document to seed the registry with entries (at a minimum) for the special domain names identified in the introduction:

  Analogous to Special-Use IPv4 Addresses [RFC5735], DNS has its own
  concept of reserved names, such as "example.com", "example.net", and
  "example.org", or any name falling under the top level pseudo-domain
  "invalid" [RFC2606].

Without those entries (or a plan to create those entries), I don't quite see that this document accomplishes anything.

[Ballot comment]
1) +1 to including values.  Maybe some from http://www.ietf.org/mail-archive/web/dnsext/current/msg10557.html ?

2) There really aren't any security considerations.  Could move the last sentence to section 4.

[Ballot discuss]
The first one is a DISCUSS-DISCUSS

#1) Is adding a new required section in an RFC done this in way?  It seems like this ought to come from a WG or be part of the style guide?

#2) Use of the word "needs" in Section 3 seems like it ought to be MUST.  Is there a time when you wouldn't do the items it suggests?

#3) Shouldn't the "Special Name Considerations Section" just be part of the IANA considerations section?

[Ballot comment]
Thanks for this effort - I expect this registry (as long as its registration policy is Standards Action) to be a very useful tool.

Will you be updating draft-cheshire-dnsext-multicastdns to explicitly request registration of .local (pointing to section 23 of that draft?)

[Ballot comment]
Although I do not object to publication of this document, I agree that it would be preferable for this document to seed the registry with initial registrations.

[Ballot discuss]
The OPS-DIR review performed by Jouni Korhonen raised the issue bellowed. I would like to see it addressed before approving this document:

o In section 4, check step 2. Do algorithmically generated
  names fall into this category? If yes, these should be
  mentioned in the draft as well. There are a number of cases
  and deployments where names are generated on fly (by the
  end host application) using available execution/service
  environment context awareness, other information sources like
  certain hardware dongles/smartcards and specific suffixes.
  Those are in most cases treated differently in application
  software and occasionally also by the name resolution APIs
  and libs (reference to check step 3).

  If algorithmically generated names fall into special names
  category I see documenting those as a big challenge.. if
  existing legacy also needs to be documented under the newly
  created IANA registry.

[Ballot comment]
I agree with a comment that this document should register existing special names in the registry, or make a more compelling argument about why the registry is needed.

IANA understands that a single IANA action is required to be completed
upon approval of this document.

IANA will create a new registry for "Special Use Domain Names." The
registry will consist of domain names and references to IETF Standards
Action documents that document the special meaning of the name. The
initial registry is empty.
Adding new entries to the registry for Special Use Domain Names requires
Standards Action.

IANA understands that this is the only action required upon approval of
this document.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
Reply-To: ietf@ietf.org
Subject: Last Call:  (Special-Use Domain Names) to Proposed Standard


The IESG has received a request from an individual submitter to consider
the following document:
- 'Special-Use Domain Names'
  as a Proposed Standard

  Abstract

  This document describes what it means to say that a DNS name is
  reserved for special use, when reserving such a name is appropriate,
  and the procedure for doing so.

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-02-14. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-cheshire-dnsext-special-names/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-cheshire-dnsext-special-names/

  (1.a) Who is the Document Shepherd for this document? Has the
        Document Shepherd personally reviewed this version of the
        document and, in particular, does he or she believe this
        version is ready for forwarding to the IESG for publication?

This document is being processed as an AD-sponsored individual
submission.  The authors consider the document ready for publication.

  (1.b) Has the document had adequate review both from key WG members
        and from key non-WG members? Does the Document Shepherd have
        any concerns about the depth or breadth of the reviews that
        have been performed? 

N/A.  The document will be reviewed by the dnsop and dnsext working
groups during IETF last call.

  (1.c) Does the Document Shepherd have concerns that the document
        needs more review from a particular or broader perspective,
        e.g., security, operational complexity, someone familiar with
        AAA, internationalization or XML?

No.

  (1.d) Does the Document Shepherd have any specific concerns or
        issues with this document that the Responsible Area Director
        and/or the IESG should be aware of? For example, perhaps he
        or she is uncomfortable with certain parts of the document, or
        has concerns whether there really is a need for it. In any
        event, if the WG has discussed those issues and has indicated
        that it still wishes to advance the document, detail those
        concerns here. Has an IPR disclosure related to this document
        been filed? If so, please include a reference to the
        disclosure and summarize the WG discussion and conclusion on
        this issue.

No.

  (1.e) How solid is the WG consensus behind this document? Does it
        represent the strong concurrence of a few individuals, with
        others being silent, or does the WG as a whole understand and
        agree with it? 
N/A

  (1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent? If so, please summarise the areas of conflict in
        separate email messages to the Responsible Area Director. (It
        should be in a separate email because this questionnaire is
        entered into the ID Tracker.)
No.

  (1.g) Has the Document Shepherd personally verified that the
        document satisfies all ID nits? (See the Internet-Drafts Checklist
        and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
        not enough; this check needs to be thorough. Has the document
        met all formal review criteria it needs to, such as the MIB
        Doctor, media type and URI type reviews?
Yes.

  (1.h) Has the document split its references into normative and
        informative? Are there normative references to documents that
        are not ready for advancement or are otherwise in an unclear
        state? If such normative references exist, what is the
        strategy for their completion? Are there normative references
        that are downward references, as described in [RFC3967]? If
        so, list these downward references to support the Area
        Director in the Last Call procedure for them [RFC3967].
Yes.

  (1.i) Has the Document Shepherd verified that the document IANA
        consideration section exists and is consistent with the body
        of the document? If the document specifies protocol
        extensions, are reservations requested in appropriate IANA
        registries? Are the IANA registries clearly identified? If
        the document creates a new registry, does it define the
        proposed initial contents of the registry and an allocation
        procedure for future registrations? Does it suggest a
        reasonable name for the new registry? See [RFC5226]. If the
        document describes an Expert Review process has Shepherd
        conferred with the Responsible Area Director so that the IESG
        can appoint the needed Expert during the IESG Evaluation?

Yes.

  (1.j) Has the Document Shepherd verified that sections of the
        document that are written in a formal language, such as XML
        code, BNF rules, MIB definitions, etc., validate correctly in
        an automated checker?
N/A

  (1.k) The IESG approval announcement includes a Document
        Announcement Write-Up. Please provide such a Document
        Announcement Write-Up? Recent examples can be found in the
        "Action" announcements for approved documents. The approval
        announcement contains the following sections:

    Technical Summary

  Certain individual IP addresses and IP address ranges are treated
  specially by network implementations, and consequently are not
  suitable for use as unicast addresses. For example, IPv4 addresses
  224.0.0.0 to 239.255.255.255 are multicast addresses [RFC2606],
  with 224.0.0.1 being the "all hosts" multicast address [RFC1112]
  [RFC5771]. Another example is 127.0.0.1, the IPv4 "local host"
  address [RFC5735].

  Analogous to Special-Use IPv4 Addresses [RFC5735], DNS has its own
  concept of reserved names, such as "example.com", "example.net",
  and "example.org", or any name falling under the top level
  pseudo-domain "invalid" [RFC2606]. However, "Reserved Top Level DNS
  Names" [RFC2606] does not state whether implementations are
  expected to treat such names differently, and if so, in what way.

  This document describes what it means to say that a DNS name is
  reserved for special use, when reserving such a name is appropriate,
  and the procedure for doing so.

    Working Group Summary

N/A.  This document is being processed as an AD-sponsored individual
submission.  The authors consider the document ready for publication.

    Document Quality

The document is short and clearly defines a new IANA registry for DNS
special-use names.