I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-cheshire-dnsext-multicastdns-12
Reviewer: Ben Campbell
Review Date: 2010-11-23
IETF LC End Date: 2010-11-23
IESG Telechat date: (if known)
Summary: This draft is (probably) almost ready for publication, but I have
several comments and questions that I think should be addressed prior to
publication.
-- General Comment:
I'm sure this has been hashed to death already given the age of this effort,
and that this comment will be greeted with a collective groan, but I am rather
surprised that an (effectively new) protocol with this much depth and
implications appears to be being progressed as an AD-sponsored RFC rather than
as a work group document. I guess this one is up to the IESG, and I won't
object to whatever they choose to do--but I do think that this deserves
rigorous review by lots of people more skilled in DNS arcana than I am.
*** Major issues:
None.
*** Minor issues:
-- Abstract, 2nd paragraph:
The annual fee part is not a technical issue. Seems like a bit of a straw man
here.
-- 5.2, 2nd paragraph: "However, there are other DNS queries where more than
one response is possible and useful, and for these queries a more advanced
Multicast DNS client should include the ability to wait for an appropriate
period of time to collect multiple responses"
How does a client know when it is useful to wait?
-- 6.2:
This section seems to create a lot of work to avoid redundant answers. Is it
really worthwhile from a complexity vs efficiency trade-off?
-- ..., 2nd paragraph: "...it SHOULD delete that answer from the list of
answers it is planning to give..."
The previous section had a MUST level requirement for the corresponding
situation. Are they different on purpose?
-- 6.3:
Shouldn't there be something normative in section 6.3?
"Planning a query" is not well defined, and its likely a querier won't know it
plans to send a query until time to send it. Is the querier expected to
remember observed queries in case it might want to send a duplicate in the
future?
-- 6.4, 1st paragraph: "...record is not less than the TTL this host would have
given..."
Really? If the responder has a short TTL than another responder, should the
first one really let the other increase the value?
-- section 7.6:
I assume this is for backwards compatibility with existing deployed
implementations? If so, it would be worth mentioning that.?
-- 8.1, 4th paragraph: "250ms after the first query the host should send a
second, then 250ms after that a third. If, by 250ms after the third probe, no
conflicting Multicast DNS responses have been received, the host may move to
the next step, announcing."
Normative?
-- 8.2, 2nd paragraph: "...the Authority Section must contain *all* the records
..."
Normative?
-- ..., 3rd paragraph: "The two records are compared and the lexicographically
later data wins."
Seems like there might should be something normative there.
-- ..., last paragraph: "Note that it is vital..."
That would seem to imply something normative?
-- 8.3, 4th paragraph: "A Responder MAY send up to eight gratuitous Responses,
provided that the interval between gratuitous responses increases by at least a
factor of two with every response sent."
Why the option? When would a responder want to send more than two?
-- 8.4, 1st paragraph:
No need to repeat the probe?
-- 10, 1st paragraph: "As a general rule, the recommended TTL value..."
Normative?
-- ..., 3rd paragraph: "A client with an active outstanding query will issue a
query packet when one or more of the resource record(s) in its cache is (are)
80% of the way to expiry."
What does an outstanding query have to do with it? Do you mean to say a cached
record?
-- section 12, 3rd paragraph: "This characteristic is not unique to Multicast
DNS. Although the original concept of DNS was a single global namespace, in
recent years split views, firewalls, intranets, and the like have increasingly
meant that the answer to a given DNS query has become dependent on the location
of the querier."
I don't think this is a fair comparison, as it was not the intent of the
protocol designers for dns to be location specific, and many would consider
this an abuse of the protocol. OTOH, m-dns is, if I understand correctly, is
_intended_ to be location specific.
-- ..., 6th paragraph: "There are no NS records anywhere in Multicast DNS
Domains."
Normative?
-- 14, 1st paragraph: "The option to fail-over to Multicast DNS for names not
ending in ".local." SHOULD be a user-configured option, and SHOULD be disabled
by default because of the possible security issues related to unintended local
resolution of apparently global names."
I have trouble imagining any safe circumstance to enable this. Can you offer an
example?
-- 15, 5th paragraph: "While this kind of name duplication should be rare,..."
Why should it be rare?
-- 17, paragraph 1:
How does this historical note relate to IDNA? Do you mean to say that IDNA is
not needed for mdns? It would be nice to have some consistency here.
-- ..., last paragraph
If a CNAME record creates a name conflict, will m-dns implementations notice
and defend against it?
-- 18, paragraph 3: "... specialized cases where the implementer knows that all
receivers implement reassembly."
How could an implementor know this? Can you list some example cases? It seems
to me that, unless we know of such cases in advance, it might be better to just
forbid this.
-- ..., last paragraph:
If jumbo packets are rare, why not just stick to the 1500 limit?
-- 19.1, paragraphs 1 and 2:
The first two paragraphs seem to make normative statements that are redundant
with the rest of the document. It's best to either state this descriptively, or
clearly attribute the requirements to the authoritative sections. Otherwise if
there is a conflict, it may not be clear to the reader which text is
authoritative.
-- 19.14, paragraph 5: "Until future IETF Standards Action specifying that
names in the rdata of other types should be compressed, names that appear
within the rdata of any type not listed above MUST NOT be compressed."
Is this a new normative requirement, or a restatement of some existing DNS rule
that could be referenced?
-- 22, paragraph 3: "In an environment where there is a group of cooperating
participants, but there may be other antagonistic participants on the same
physical link,..."
I think the sense of this should be more along the lines of "in all
environments where clients cannot be sure in advance that no antagonistic hosts
can exist on the same segment" or something to that effect. Too many network
managers naively believe that no hostile devices can exist on their networks.
-- ..., paragraph 4: "... it is *especially* important..."
Normative?
-- 23, paragraph 4:
This section needs to request registration of an explicit new IANA table along
with the criteria for adding new entries, or explicitly reference an existing
registry, then register the entries. Don't expect IANA to infer this. Also, is
suspect language like "IANA should" would br better stated as "this document
requests IANA to register..."
-- ..., numbered list:
Are you asking IANA to do something with the information about special
treatment of the multicast domains? That level of detail would be unusual in an
IANA registry--more likely they would just reference this document for details.
If you aren't asking them for specific action about this information, then it
should go elsewhere in the document.
-- ..., list item 1, 2nd paragraph:
I'm very skeptical about normative statements of the form of "users SHOULD be
aware...". What should _implementors_ do?
-- ..., list items 4-7:
These seem to put requirements on devices that do not implement this spec. Why
would the implementors of such even read this?
-- ..., 2nd to last paragraph:
Again, this needs to be more explicit about what is requested from IANA.
--, 25.2, "[B4W]" reference:
Is it reasonable to reference something as ephemeral as wikipedia, even for an
informative reference? Remember RFCs live a long time.
-- Appendix A:
Please describe the conclusions, not just the arguments.
*** Nits/editorial comments:
-- Idnits shows 2 warnings and 3 comments. Please check.
-- general:
I would like to have seen some general, non-normative, discussion on how this
all works together before jumping deep into protocol details. I was fairly well
into the document before I understood the transaction-stateless nature of the
mechanism.
-- 5.3, 5th paragraph: "To perform this cache maintenance, a Multicast DNS
Querier should plan to re-query for records after at least 50% of the record
lifetime has elapsed. This document recommends the following specific strategy:"
It might be helpful to include a note about the difference between
retransmitting a query vs re-querying.
-- Section 7:
This section needs some subsections, or other organization. As it is, it jumps
from one topic to the next with little transition and is hard to follow.
-- ..., 2nd paragraph: "The record name must match the question name, the
record rrtype must match the question qtype unless the qtype is "ANY" (255) or
the rrtype is "CNAME" (5), and the record rrclass must match the question
qclass unless the qclass is "ANY""
References? Also, should the musts here be normative?
--... 5th paragraph: "A Multicast DNS Responder on Ethernet [IEEE.802.3] and
similar shared multiple access networks..."
Do you expect responders to vary behavior depending on the underlying network
type?
-- ..., later same paragraph: "...determined by the rules described below."
The way things are organized, it's hard to tell where the referenced rules
start and stop.
-- 7.1, 5th paragraph from end: "For example, the TTL for address records in
Multicast DNS is typically 120 seconds, so the negative cache lifetime for an
address record that does not exist should also be 120 seconds."
Reference?
-- ..., 4th paragraph from end: "name/rrtype/rrclass"
Please avoid using a slash as a conjunction substitute.
"(e.g. for reverse address..."
For, or From?
-- section 7.3, last paragraph: "...SHOULD be randomly delayed in the range
20-120ms, or 400- 500ms if the TC (truncated) bit is set, as described above."
Isn't this redundant with previous sections?
-- 8.1, 6th paragraph: "At the present time, this document recommends..."
Do you expect this to change?
-- 8.2, 4th paragraph:
Inconsistent usage between "the host" and "ourself". Probably best not to
anthropomorphize.
-- 8.2.1:
Inconsistent section hierarchy. The single record case was in the parent
section, but the multiple level case has its own subsection.
-- 8.3, 1st paragrah: "gratuitous"
That seems the wrong choice of words, since such responses are not "without
cause or reason" which is the usual dictionary definition. Maybe "unsolicited"?
(No problem if this is some DNS term of art that I haven't heard.)
-- ..., last paragraph: "as described below in "Conflict Resolution"."
Section number cross-references would be helpful.
-- 9, indented paragraph after numbered list item 5:
It's not clear to me if this is supposed to refer to just item 5, or to item 4
and 5. In any case, the advise that one may simply not notify does not seem
helpful for case 5.
-- 11, 1st paragraph: "These older clients discard all packets with TTLs other
than 255."
Can you provide a reference for this behavior? How old is old?
-- 12, 4th paragraph: "The IPv4 name server for a Multicast DNS Domain is
224.0.0.251. The IPv6 name server for a Multicast DNS Domain is FF02::FB."
Name server _address_?
-- ..., 6th paragraph: "...delegation of all Multicast DNS Domains to the
224.0.0.251:5353 and [FF02::FB]:5353,..."
Missing words?
-- ..., 7th paragraph:
Please expand SOA on first mention
-- 15, last paragraph:
Can you provide section cross references for these safeguards?
-- 13:
Seems like this should be stated early in the document, in the intro, or in a
scope section or applicability statement.
-- 16.3: "...each have their own..."
its own
-- 17, 3rd paragraph from end:
This seems to imply there are no "letters" in UTF8 outside the ASCII range.
-- ..., last paragraph: "The simple rules for case-insensitivity in Unicast DNS
also apply..."
Reference?
-- 18, paragraph 3: "...,a Multicast DNS Responder SHOULD send the Resource
Record alone, in a single IP datagram, sent using multiple IP fragments."
I have trouble parsing this clause. Should "sent using" just be "using"?
-- ..., 2nd to last paragraph: "Ethernet "Jumbo" packet"
Reference?
-- 19.2 and 19.3:
Incomplete sentences
-- 19.12 and 19.13:
References to normative text?
-- 20, paragraph 1: "The value of Multicast DNS is..."
Is assume you mean "a value..." or "one value..."?
-- 23, paragraphs 1 and 2:
Can you provide references or pointer to the existing registrations?
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf