Multicast DNS
RFC 6762

Received changes through RFC Editor sync (changed abstract to 'As networked devices become smaller, more portable, and more ubiquitous, the ability to operate with less configured infrastructure is increasingly important. In particular, the ability to look up DNS resource record data types (including, but not limited to, host names) in the absence of a conventional managed DNS server is useful.

Multicast DNS (mDNS) provides the ability to perform DNS-like operations on the local link in the absence of any conventional Unicast DNS server. In addition, Multicast DNS designates a portion of the DNS namespace to be free for local use, without the need to pay any annual fee, and without the need to set up delegations or otherwise configure a conventional DNS server to answer for those names.

The primary benefits of Multicast DNS names are that (i) they require little or no administration or configuration to set them up, (ii) they work when no infrastructure is present, and (iii) they work during infrastructure failures.')

State changed to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation::AD Followup.
Michelle Cotton and Stuart Cheshire are developing text to clarify that names in the IANA considerations section of this document go in the registry defined in draft-cheshire-dnsext-special-names

[Ballot comment]
I cleared my DISCUSS after consultation with IANA.  Document will go to
"Approved - announcement to be sent: Point raised - writeup needed".
I will work with the authors and IANA to clarify that the names that
are described in the IANA Considerations section go in the Special
Use Domain Names registry defined in draft-cheshire-dnsext-special-names.

Also, the authors will provide some clarifying text about the set of addresses
returned by an mDNS responder; spec., the responder MUST return all
available and appropriate addresses.  This clarification addresses some
observed behavior in which an mDNS responder returns only a GUA
when the responder also has a link-scoped address.  If the querier does
not have a GUA, the responder's GUA will not be useful.

[Ballot discuss]
Thank you for providing a new revision that addresses the previous IETF
last call issues.

I found two small concerns that I hope will be really easy to
adddress and will not hold the document up.

I found the use of 2119 language a bit patchy. It would be really good
if the authors took a pass on the document to check consistency. Some
examples from Section 3:

  If this happens, the computer
  (or its human user) SHOULD cease using the name, and may choose to
  attempt to allocate a new unique name for use on that link.

Is that MAY?

  This document recommends a single flat namespace for dot-local host               
  names, (i.e. the names of DNS "A" and "AAAA" records, which map names
  to IPv4 and IPv6 addresses), but other DNS record types (such as
  those used by DNS Service Discovery [DNS-SD]) may contain as many
  labels as appropriate for the desired usage, up to a maximum of 255
  bytes, plus a terminating zero byte at the end. Name length issues
  are discussed further in Appendix C.

Is that RECOMMENDED and MAY?

  In summary: It is
  required that the protocol have the ability to detect and handle name
  conflicts, but it is not required that this ability be used for every
  record.

REQUIRED and NOT REQUIRED?

---

The mDNS port (5353) is currently shown in the registry with Stuart's
coordinates (Stuart Cheshire ). Shouldn't
we be asking IANA to replace or update with a reference to the RFC this
document will become?

[Ballot discuss]
Section 23 provides a list domains that have "only link local
  significance", yet draft-ietf-dnsop-default-local-zones covers all
  of the domains with the exception of .local.  Please remove the
  duplicated material, so that Section 23 covers only the issues
  relating to .local and mDNS.

  Please remove Appendix G.  A protocol specification is not the place
  for this policy statement.

[Ballot comment]
I strongly support publication of this document. However, I have several comments:

1. In Section 5.3 ("Continuous Multicast DNS Querying"), the third paragraph states in part:

  ... the interval between the first two queries
  SHOULD be at least one second, the intervals between successive
  queries SHOULD increase by at least a factor of two

Is there a good reason why an implementation would override these recommendations? If not, do they deserve to be required instead of recommended? Also, perhaps a reference to the "truncated binary exponential backoff" algorithm from the Ethernet spec (IEEE Standard 802.3) would be appropriate here.

2. Section 10 ("Resource Record TTL Values and Cache Coherency") states: "Various techniques are available to minimize the impact of such stale data." Perhaps it would be appropriate to provide a description of, or pointer to, such techniques.

3. Section 23 ("IANA Considerations") contains normative text about how implementations are to handle the the designated link-local domains. This normative text doesn't comprise instructions to IANA and thus belongs somewhere else. Section 12 ("Special Characteristics of Multicast DNS Domains") seems like an appropriate home for this text, i.e., the paragraph starting with "These domains" as well as the seven bullet points that follow.

[Ballot comment]
For consistency with RFC 5395, all occurrences of "pseudo-RR" should be replace with "meta-RR" and it would not hurt to add a reference to RFC 5395 (or the rfc5395bis draft which is being fast tracked).

[Ballot discuss]
Section 23 provides a list domains that have "only link local
  significance", yet draft-ietf-dnsop-default-local-zones covers all
  of the domains with the exception of .local.  Please remove the
  duplicated material, so that Section 23 covers only the issues
  relating to .local and mDNS.

  Please remove Appendix G.  A protocol specification is not the place
  for this policy statement.

[Ballot comment]
This document has quite a list of ID nits that should be fixed before
  publication (outdated references, not using example domains/prefixes,
  etc.)

IANA has two questions about the IANA Actions contained in this document.

IANA understands that the IPv4 and IPv6 link-local multicast addresses
required for Multicast DNS have already been allocated. The IANA Actions
for this requirement are already completed.

Next, the document requests that IANA designate a list of domains which
are deemed to have only link-local significance. IANA understands that
Section 12 of the document identifies:

local.
254.169.in-addr.arpa.
8.e.f.ip6.arpa.
9.e.f.ip6.arpa.
a.e.f.ip6.arpa.
b.e.f.ip6.arpa.

as link-local domains.

IANA QUESTION --> should this designation take the form of a registry?
If so, should it be in a new registry or as part of another registry
related to the DNS? If not, is publication of the designated link-local
domains in an RFC sufficient?

Finally, IANA understands that Multicast DNS can only carry DNS records
with classes in the range 0-32767. IANA notes that classes in the range
32768 to 65535 are incompatible with Multicast DNS. IANA will note this
in the DNS Classes registry located in:

http://www.iana.org/assignments/dns-parameters

and in the IANA Matrix located at:

http://www.iana.org/protocols/

with the intent that any person making a request to allocate a DNS class
value above 32767 would be notified of this limitation before
proceeding. IANA will still accept applications for DNS class values
above 32767. However, IANA will ensure that the requester indicates that
they are aware of how this allocation will interact with Multicast DNS.

IANA QUESTION --> Does the author intend that this apply to DNS Classes
allocated for Private Use?

IANA understands that these are the only actions required to be
completed upon approval of this document.

[Ballot discuss]
It appears from comments by the author that a new draft is planned to resolve issues raised in
IETF LC.  I want a chance to read that version before moving to No Objection.

[Ballot discuss]
I'd like this specification to move forward as is but first we
need to resolve three issues:

- whether the informational category is right (mostly because the
  IPR declaration may have an effect on whether informational is
  sufficient)

- the alternate suggestions for .local should just be deleted
  from the document

- other possible input from the last call thread should be taken into
  account

[Ballot discuss]
This is NOT a discuss. I am simply using this flag in the tracker tool to make sure that I read the right version of the document. I am highly likely to be a YES on this doc. I have been educated about my earlier questions about is this should be PS or not and am happy with the current plan.

[Ballot discuss]
Seems this was a bit premature on the IESG agenda.
Would like to wait for the considerable number of Last Call comments to be addressed in a new revision before reviewing this.

---

Please answer IANAs questions

[Ballot discuss]
It appears from comments by the author that a new draft is planned to resolve issues raised in
IETF LC.  I want a chance to read that version before moving to No Objection.

[Ballot discuss]
It is clear from Last Call discussion there should be a
  new version with major differences.  Wait for it.

  Also, the IPR Statement from Apple says, provides access to
  patented technology only if the document is "a standard
  adopted by IETF."  Since the long-term goal for this
  protocol is a standards track RFC, it is not clear that
  publication as an informational RFC at this time provides
  much value to the Internet community.