Subject: Re: Last Call: draft-cheshire-dnsext-multicastdns (Multicast DNS) to Informational RFC

From: Andrew Sullivan <[email-masked]>
Date: Tue, 1 Dec 2009 17:29:00 -0500

Dear colleagues,

I have read draft-cheshire-dnsext-multicastdns-08.  I have some
comments.  This is not an exhaustive or complete review, although I
have shared some previous observations with the authors of the
document.

First, I must emphasise that, while I currently serve as one of the
chairs of the DNS Extensions Working Group, I make my comments as an
individual and not as Chair.  Neither do I in any way speak for the
community or the Working Group.  I also want to emphasise that I was
not involved in the early history of this draft, and had no official
responsibilities of any sort to the DNSEXT WG when this draft came
under discussion there some years ago.

Given the long and painful history of the draft, and that the protocol
it documents is manifestly successful and in wide use, I think it
would be a disservice to interoperability if we did not publish it.
If for no other reason, I support its publication (under the terms of
the question put to us) as an Informational RFC.

I think there are sections of the text that could be cleaned up.
Leaving aside others' complaints about the number of Apple references
in the document, there is a querulousness to the text that is a little
jarring.  Sentences like "It is easy for those of us in the IETF
community who run our own name servers at home to forget that the
majority of computer users do not run their own name server and have
no easy way to create their own host names," despite their evident
truth and probable justification in light of some past comment on a
mailing list, just aren't needed in a protocol document.  If it were
up to me, I'd take that sort of thing out.  That said, I do not
withold my support on this basis.

The IANA Considerations section is a little coy in the way it notes
that the document reserves .local.  Moreover, the action is not merely
to IANA, but strictly to ICANN, and I worry about the procedural rules
for such an action.  If there is a strong reason to put this document
on the standards track, the use of .local is surely it.

I like the way the document emphasises that, in a multicast
environment, many of the assumptions one might make about uniqueness
are wrong.  I think this is quite right, and I hope clients and
implementers will take heed.  

The discussion of port 5353 vs. 53 is comprehensive without rehashing
the entire history of that debate.  (Contrast this with my previous
comment about querulous bits of the text.  One can outline the
background without sounding annoyed by snipers.)

I am unwilling right now to make an argument in favour or against
moving this document to the standards track.  I think there are
arguments to be constructed in both directions, but when I consider
the value to interoperability, it seems to me that getting something
published, even in a flawed way, is more important than picking
exactly the right document stream.

Best regards,

A
-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: SM <[email-masked]>
Date: Tue, 01 Dec 2009 16:21:02 -0800

>on the standards track, the use of .local is surely it.

Quoting Section 3.1:

   "Note that this use of the ".local." suffix falls under IETF/IANA
   jurisdiction, not ICANN jurisdiction."

This draft mentions that the IETF has the authority to instruct IANA 
to reserve pseudo-TLDs as required for protocol design 
purposes.  There is no action requested from IANA for ".local" in the 
IANA Considerations section.

   "In contrast, private uses of the DNS protocol on isolated private
    networks are not governed by ICANN. Since this change is a change
    to the core DNS protocol rules, it affects everyone, not just those
    machines using the ICANN-governed Internet."

Is any other use of the DNS protocol governed by ICANN?

Could the authors please drop the reference to the ICANN-governed 
Internet?  I suggest dropping Section 3.1 as it is not the type of 
content generally discussed in an Informational document.

In Section 6.3:

   "iTunes users are accustomed to seeing a list of shared network music
    libraries in the sidebar of the iTunes window. There is no "refresh"
    button for the user to click because the list is expected to be
    always accurate, always reflecting the currently available libraries,
    without the user having to take any manual action to keep it that
    way. When a new library becomes available it promptly appears in the
    list, and when a library becomes unavailable it promptly disappears.
    It is vitally important that this responsive user interface be
    achieved without naive polling that would place an unreasonable
    burden on the network."

The above is superfluous.

In Section 15:

   "A host SHOULD defend its host name (FQDN) on all active interfaces on
    which it is answering Multicast DNS queries."

What does that mean?

In Section 17:

      "Set-top boxes (e.g. Apple's "Apple TV") connected to a television
       can play music, photographic slide shows, and movies stored on the
       user's desktop computer (e.g. an iMac running iTunes) -- but only
       if that desktop computer is not asleep."

       "Services like Apple's "Back to My Mac" allow users to access data
       on their home computers from remote locations, using screen
       sharing or file sharing -- but only if their computer at home
       is not asleep."

Could the authors please remove such references?

Regards,
-sm

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 2 Dec 2009 09:27:35 -0500

On Tue, Dec 01, 2009 at 04:21:02PM -0800, SM wrote:
> This draft mentions that the IETF has the authority to instruct IANA to 
> reserve pseudo-TLDs as required for protocol design purposes.  There is 
> no action requested from IANA for ".local" in the IANA Considerations 
> section.

There is in fact a request, it's just made indirectly.  That was my
complaint.

I'm aware that the draft claims this is an IETF/IANA responsibility
and not an ICANN one.  I'm not sure I'm convinced, and I think the
IESG should take that into account when making their decision about
the draft.  But I don't think it's a reason to hold it up anyway.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 2 Dec 2009 13:55:23 -0500

On Wed, Dec 02, 2009 at 12:35:11PM -0500, Phillip Hallam-Baker wrote:

> I want my personal machines to be part of the .hallambaker.com DNS
> domain and look for configuration data there. I want my business
> machines to be part of the .defaultdenysecurity.com domain and look
> for configuration data there.

My reading of the draft actually allows you to do this anyway.  So
what's the problem?

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 2 Dec 2009 12:35:11 -0500

I don't think the IESG or ICANN should go there, or anywhere close.

There are three options:

1) Do not reserve .local. This would effectively mean throwing out the
draft as it depends on .local

2) Reserve .local for this particular protocol. This would be
inconsistent with current legacy use and is neither necessary, nor
appropriate.

3) IESG, IANA and ICANN note that by longstanding convention .local is
already allocated for the purpose of local DNS configuration. Then the
IESG notes that this draft specifies an example of such use and that
requires appropriate wording in the draft to note that deployments
must be aware that usage may not be consistent.

There is a final option which would be that devices receive the
default domain name that they are to use for configuration as part of
the DHCP protocol and that this can be overriden. This seems rather
more logical to me than declaring a magic number and considerably more
flexible.

On Wed, Dec 2, 2009 at 9:27 AM, Andrew Sullivan <[email-masked]> wrote:
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf
>

-- 
-- 
New Website: http://hallambaker.com/
View Quantum of Stupid podcasts, Tuesday and Thursday each week,
http://quantumofstupid.com/

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 2 Dec 2009 14:12:01 -0500

The alternative would be to not use .local at all and insist on that
approach as a means of avoiding ICANNs perceived perogatives. I think
that would be a bad idea as the spec would not serve its intended
purpose.

---

From: SM <[email-masked]>
Date: Wed, 02 Dec 2009 13:25:48 -0800

>There is in fact a request, it's just made indirectly.  That was my

I'll second your complaint.  RFC 5226 provides guidelines to authors 
on what sort of text should be added to their documents in order to 
provide IANA clear guidelines.  Indirect requests do not provide 
clear guidelines.

>the draft.  But I don't think it's a reason to hold it up anyway.

I'm ambivalent about having all that in this draft as it is 
Informational.  I would have suggested Standard Track if it wasn't 
for the Private DNS Namespaces section and the style of the draft.  I 
suggest putting the ".local" request in a BCP for IETF Consensus and 
publishing the rest of this draft as Informational.  The better 
approach, in my opinion, for the BCP document would be to have "IANA 
has agreed ..." instead of invoking RFC 2860.

Regards,
-sm

---

From: Joe Abley <[email-masked]>
Date: Thu, 3 Dec 2009 23:18:12 -0500

> that would be a bad idea as the spec would not serve its intended

Given the existing deployed base of this protocol, and the desire expressed by many to document what has been deployed, I don't think that insisting that current practice change is a useful approach.

I read on another list recently the observation that ICANN's draft applicant guidebook already reserves LOCAL as a name that can't be registered as a new gTLD.

http://www.icann.org/en/topics/new-gtlds/draft-evaluation-procedures-clean-04oct09-en.pdf

See the table on page 2-6.

I have no involvement with the new gTLD programme at all, but it seems possible that concern over a clash between a "local" delegation from the root zone and the use of "local" by Apple and others is largely semantic.

No doubt semantic concern can still be valid; however, I think the distinction between real lurking operational danger and theoretical possibility for conflict in the distant future is worth making.

Joe

---

From: Joe Abley <[email-masked]>
Date: Fri, 4 Dec 2009 09:04:11 -0500

On 2009-12-04, at 07:38, Phillip Hallam-Baker wrote:

> 'largely semantic?'

Yes, by which I meant having little practical impact on the business of shifting packets on the network. The other text that you couldn't see due to the searing bright pain you apparently felt when presented with the two words you quoted would perhaps have helped to make that clear.

Joe

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 4 Dec 2009 10:31:02 -0500

> that would be a bad idea as the spec would not serve its intended

I've been puzzling over what to make of that message since receiving
it, and I still don't know.  Since you admit in your last sentence
that leaving .local out would in fact not achieve the goal of
documenting a protocol in wide use (even if in limited cases, and in a
way not apaprently enterprisey enough for your taste), why would you
leave out .local?

A
-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 4 Dec 2009 07:38:17 -0500

'largely semantic?'

Please do not ever use that phrase again as an attempt to dismiss the
importance of an argument

SEMANTICS IS MEANING

EVERY argument in the IETF is an argument in semantics, that is the
alpha and omega of the IETF process.

Arguments over semantics are only trivial when they are post-facto
attempts to redefine the meaning of what has already been said,
usually futile as one party or other attempts to misrepresent the
content. Arguments over the semantics of a contract are not trivial.