Subject: Re: [DNSOP] Fwd: Last Call: <draft-cheshire-dnsext-special-names-01.txt> (Special-Use Domain Names) to Proposed Standard

From: Eric Brunner-Williams <[email-masked]>
Date: Tue, 18 Jan 2011 15:48:20 -0500

There are label segments that have semantics.

The "--" violation, prepended by something, "^xn", where "^" indicates 
a label boundary, to indicate a (the current) "IDN" processing.

Bytes within a label with values in excess of 127.

Off hand I can't think of anything else (that is intentional). Along 
the accidental sort-of-intended mumble access of forensic engineering 
are terminating (TLD) labels that brain-dead dead-ware interprets (if 
anyone living were to ask it) character representations of digit 
sequences as v4 addresses that currently has the pants scared off of 
ICANN and some folks from this side of the policy|tech divide.

Everything else seems to just be intentional carve outs of string 
spaces, suited, if there is a purpose, to the (defunct) User Services 
Area Directorate and its inform-the-community mission that "example" 
is not a means to repeat for the bazillionth time the flagship brand 
of Verisign.

.local has sufficient meaning to care about.

John Levin's draft covers some "don't pretend you're ARPA" ground, 
which is a useful restriction on what appears in the IANA root (and 
any other used by every user in China) and in SLDs, assuming that a 
means other than persuasion is available to inform both 
auctions-are-good gTLD operators and ICANN-is-irrelevant ccTLD 
operators that some restrictions are beneficial.

The chief defect of Stewart's draft is that it makes an analogy to the 
semantics of addressing, and postulates a pseudo-technical set of 
implementation responsibilities, and fails to mention ICANN, which has 
some coordination mission.

What isn't a layer 9 is worth documenting. What is at layer 9 should 
be documented as being at layer 9.

Eric

---

From: Tony Finch <[email-masked]>
Date: Wed, 19 Jan 2011 13:41:59 +0000

On Tue, 18 Jan 2011, Eric Brunner-Williams wrote:
> The "--" violation

It is not a violation. Double hyphens have been permitted by the syntax
forever.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO 7,
DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR
ROUGH. RAIN THEN FAIR. GOOD.

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 28 Jan 2011 14:17:06 +0100

I've reviewed this document as part of the transport area directorate's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the
document's authors for their information and to allow them to address
any issues raised. The authors should consider this review together with
any other last-call comments they receive. Please always CC
[email-masked] if you reply to or forward this review.

My comments on the document are:

1. Section 3. I wonder if "Standards Action" is the most appropriate
rule here. My concern with this is that any other body must perform the
work in the IETF and give IETF full change control over this proposal.
This might intended, but I wonder if it is the most appropriate policy.
My suggestion would be to allow IESG approval as a policy also to give
some freedom in the strange cases. I do think an IETF standards RFC is
the preferred way for doing this, but it might be overly restrictive.

2. Section 6.
Why doesn't this document populate this registry with some initial
values. The document it self already lists some of these. So why not
include the ones and a note that they are legacy and does not come with
the new required consideration section?

Best Regards

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: SM <[email-masked]>
Date: Fri, 28 Jan 2011 07:15:50 -0800

At 15:00 17-01-11, The IESG wrote:
>The IESG has received a request from an individual submitter to consider
>the following document:
>- 'Special-Use Domain Names'
>   <draft-cheshire-dnsext-special-names-01.txt> 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

The intended status of draft-cheshire-dnsext-special-names-01 is 
Standards Track.  BCP would have been a better fit is the aim of this 
draft is to create a registry and a procedure for reserved DNS names.

In Section 1:

   '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"'

I suggest dropping that reference as example refers to IPv4 addresses 
discussed in RFC 5735; RFC 2606 is about Reserved Top Level DNS Names.

 From Section 2:

   "Similarly, if a domain name has special properties that affect the
    way hardware and software implementations handle the name, which
    apply universally regardless of what network the implementation may
    be connected to, then that may be a candidate for having the IETF
    declare the name to be a Special-Use Domain Name and specify what
    special treatment implementations should give to that name."

That sounds like a good argument for the IETF declare a domain name 
as "Special Use".  Does ".local" qualify for registration 
(draft-cheshire-dnsext-multicastdns-13)?

Are domain names as defined under this proposal to be considered as 
Internet protocol parameters?

 From Section 3:

   "If it is determined that special handling of a name is required in
    order to implement some desired new functionality, then an IETF
    "Standards Action" RFC [RFC5226] needs to be published describing the
    new functionality ..."

In other words, if an author can get a Proposed Standard through the 
IETF process, he or she can get a registration for a Special-Use Domain Name.

In Section 7:

   'How should DNS Registrars treat requests to register this reserved
    domain name? Should such requests be denied? Should such requests
    be allowed, but only to a specially-designated entity? (For
    example, the name "www.example.org" is reserved for documentation
    examples and is not available for registration; however, the name
    is in fact registered; and there is even a web site at that name,
    which states circularly that the name is reserved for use in
    documentation and cannot be registered!)'

That would be:

    Domain Name: EXAMPLE.COM
    Registrar: RESERVED-INTERNET ASSIGNED NUMBERS AUTHORITY
    Whois Server: whois.iana.org
    Referral URL: http://res-dom.iana.org
    Name Server: A.IANA-SERVERS.NET
    Name Server: B.IANA-SERVERS.NET
    Status: clientDeleteProhibited
    Status: clientTransferProhibited
    Status: clientUpdateProhibited
    Updated Date: 26-mar-2004
    Creation Date: 14-aug-1995
    Expiration Date: 13-aug-2011

By the way, res-dom.iana.org is not responding on port 80.

In the IANA Considerations Section, 
draft-cheshire-dnsext-special-names creates a registry of Special-Use 
Domain Names.  It is customary to populate a new registry with legacy 
entries such as the domain names mentioned in RFC 2606.

Regards,
-sm

---

From: Joe Abley <[email-masked]>
Date: Fri, 28 Jan 2011 11:56:44 -0500

> By the way, res-dom.iana.org is not responding on port 80.

I will let the appropriate people know. Thanks for picking that up.

Joe

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Fri, 28 Jan 2011 21:44:28 +0200

Hello all,

2011/1/28 Magnus Westerlund <[email-masked]>

> the preferred way for doing this, but it might be overly restrictive.

Therefore, I'd like to propose the 'IETF Consensus' or 'IESG Approval' as
the first the most preferable.

> the new required consideration section?

I also commented this section saying the registry, created by this document
is underspecified and does not contain clear guidelines for IANA per RFC
5226.

Finally I really do not know why this document has the intended status
'Standrds Track'.  It is rather the candidate for BCP.

All the best,
Mykyta Yevstifeyev

> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf
>

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Sat, 29 Jan 2011 08:09:08 +0200

> draft is to create a registry and a procedure for reserved DNS names.
I recommended the authors the same in my previous message.
> discussed in RFC 5735; RFC 2606 is about Reserved Top Level DNS Names.
While reading the document I really got confused seeing such beginning 
of Introduction.  That would be better to drop all such confusing 
phrases about IPv4 addresses.

Another issue I'd like to raise is references.  Do the authors consider 
making all references Informative as appropriate?  Personally I think 
the following docs. should be referenced normatively: RFC 1034 and RFC 
5226.  Moreover, shouldn't the document update RFC 2606?

Finally, I'd like to propose to create the sub-registry in th cerated 
registry connected with 'Reserved Top Level Domains' for tracking these 
issues along with other special-use domain names.

All the best,
Mykyta Yevstifeyev
> That sounds like a good argument for the IETF declare a domain name as 
> "Special Use".  Does ".local" qualify for registration