Multicast DNS
RFC 6762

Note: This ballot was opened for revision 15 and is now closed.

(Cullen Jennings) Discuss

Discuss (2009-12-17 for -)
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.

(Ralph Droms) (was Discuss, Yes) Yes

Comment (2011-03-30 for -)
No email
send info
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.

(Jari Arkko) (was Discuss) No Objection

(Ron Bonica) (was Discuss) No Objection

(Stewart Bryant) No Objection

(Gonzalo Camarillo) No Objection

(Lars Eggert) No Objection

Comment (2010-11-30 for -)
No email
send info
  This document has quite a list of ID nits that should be fixed before
  publication (outdated references, not using example domains/prefixes,

(Adrian Farrel) (was Discuss, No Objection, Discuss) No Objection

(Russ Housley) (was Discuss) No Objection

Alexey Melnikov No Objection

(Tim Polk) (was No Record, Discuss, No Objection, No Record, Discuss) No Objection

(Dan Romascanu) No Objection

(Peter Saint-Andre) No Objection

Comment (2010-12-15 for -)
No email
send info
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.

(Robert Sparks) No Objection

(Sean Turner) No Objection

Comment (2010-12-01 for -)
No email
send info
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).