Thanks for the response. Further comments below. I elided sections that I think
have been addressed.
On Dec 15, 2010, at 4:30 AM, Stuart Cheshire wrote:
[..]
-- 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?
Yes, but in the English language sense, not an RFC 2119 keyword.
This confuses me. The point of 2119 is to indicate normative intent. Do you
have some lesser class of normative-ness in mind? Also, see next comment...
-- 8.2, 2nd paragraph: "...the Authority Section must contain *all* the
records ..."
Normative?
Yes. Are you complaining that it's not clear what the sentence means unless
some of the words are in all-capitals?
I'm asking if you intended this to be normative in a 2119 sense, which would
generally be indicated by a capital MUST. If you explicitly don't want it to be
treated as a 2119 keyword, then it's best to avoid "must" at all, since case
alone is a rather poor discriminator.
-- ..., 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?
Yes. I believe it is acceptable to write a specification using English. RFC
2119 keywords are sometimes useful for clarity, but I don't believe there is
any requirement that every normative sentence contain at least one of them.
I'm not asking for one for every sentence, and I am aware that there is a great
deal of variation between IETF documents in how dense they are with 2119
keywords. But when you say something like "Note that it is vital", that
suggests to me that you think compliance is, well, vital. As in the sense that
it is "required for interoperation or to limit behavior which has potential for
causing harm", which would be indicative of a 2119 MUST.
-- 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?
The same reason TCP retransmits more than once: Packet loss.
Sorry, my question was not clear. Can you give guidance on how an implementer
might decide how many to send? Why would it not be the same for everybody?
[...]
-- ..., 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?
See "Continuous Multicast DNS Querying". On your Mac or Windows machine type:
"dns-sd -B _http._tcp". Now you have an active query. Press Ctrl-C. Now you
cancelled it.
We're talking about some sort of monitoring session, right? I guess my
confusion is with the idea of an outstanding "query", as something that appears
to span multiple "queries". The terminology is confusing to me. (And that
demotes my original comment to the editorial section)
[...]
-- ..., 6th paragraph: "There are no NS records anywhere in Multicast DNS
Domains."
Normative?
Yes.
Actually, on re-reading this section this seems more like an observation on
reality than a normative statement, so I withdraw the comment.
-- 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?
On an isolated network, or on some future machine that exclusively uses
DNSSEC for all DNS queries, thereby guarding itself against spoofing.
Some words to that effect in the text would be useful.
-- 15, 5th paragraph: "While this kind of name duplication should be
rare,..."
Why should it be rare?
Because users generally name their devices intelligently. Over the last eight
years this kind of name duplication has not been a common problem.
Sorry, I should have quoted more. Why would it be rare for a multi-homed host
to discover the same name on two different links? That's more than just a
matter of users selecting reasonable names, as each link might point to a
network where someone felt they were being quite reasonable in naming a print
server "printer".
-- 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.
Yes, IDNA is not needed for Multicast DNS.
I think it would be highly unfortunate if we end up saying two different
flavors of DNS use different approaches to internationalization. But if there
are good technical reasons not to use IDNA, then it would be good to state
them. Perhaps the reasons you already mention apply--in which case it would be
helpful to state that. Would you consider IDNA to exist to solve this
"historical" problems in DNS that don't exist in mDNS?
[...]
-- 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.
For example, factory floor CNC equipment, using Multicast DNS over a private
Ethernet network. This is a mostly proprietary marketplace, and CNC equipment
manufacturers know pretty precisely the capabilities of their other
proprietary equipment on the network.
Okay (grudgingly--this sort of thing makes me uneasy, as the IETF nominally
designs for the Internet, not special case networks where people are free to
ignore all sorts of standard requirements. And implementations intended for
special case networks have a habit of escaping onto the Internet. But this
happens enough in other specifications that I don't have steady ground from
which to argue.)
-- ..., last paragraph:
If jumbo packets are rare, why not just stick to the 1500 limit?
Some applications today need more than 1500-byte payloads.
Maybe--but your last paragraph in section 18 seems to say that you can't expect
them to actually work.
-- 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.
Can explain specifically what part you think is redundant, and suggest better
text.
I'm not going to be able to track each one down in a reasonable time frame. But
it seems like most of the 2119 normative language here restates things from
elsewhere. When that is true, which section do you see as authoritative in the
case that an error creeps into one, or in the case that this spec is updated in
the future?
[...]
-- ..., paragraph 4: "... it is *especially* important..."
Normative?
No.
Okay, although this seems to fit into the 2119 definition: "... or to limit
behavior which has potential for causing harm"
[...]
-- ..., 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?
No. Only devices that claim compliance with this spec have to follow these
requirements. No RFC can impose requirements on any implementer unless that
implementer voluntarily chooses to comply with the RFC. RFCs are not laws.
Let me try again: These sections make normative assertions about how the
"normal" DNS architecture should handle the special names. It seems to me that
such "normal" devices explicitly do not implement this specification. They are
not likely to have any reason to know ".local" means something special. If
changes to how unicast DNS devices should work in the presence of mDNS are
needed, then I think we need to do more than mention that in the mDNS spec.
OTOH, this may be handled by the existence of the special-names draft you
mention above.
[...]
--, 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.
People objected to the apple.com reference so we changed it to wikipedia as
being more neutral.
IMHO, wikipedia is a worse choice, as that link could change or go away
tomorrow. But I guess it's not a showstopper either way.
-- Appendix A:
Please describe the conclusions, not just the arguments.
Arguments were made for and against using Multicast on UDP port 53. The
arguments for using a different port were greater in number and more
compelling so the final decision was to use UDP port 5353.
Text to the effect of "...the final decision..." would be helpful in the draft.
*** Nits/editorial comments:
[...]
-- 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.
The document is already long. Others have been asking us to delete
non-normative discussion.
I saw people ask for that when they thought this was intended as an
informational RFC. But in any case, it's a personal thing--I personally find
the organization of the draft hard to follow, and would find a high-level
description helpful. My comments are not binding.
-- 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.
There is no difference between retransmitting a query vs re-querying.
Trying again because you didn't see a response, vs trying later in case
something has changed are fundamentally the same thing? Weren't there backoff
recommendations for the first?
[...]
-- ..., 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.
It doesn't really matter very much. It is merely introduction to the text
that follows.
Given that the phrase "rules described below" qualifies a SHOULD level
normative statement, that seems like more than just an introduction.
-- ..., 4th paragraph from end: "name/rrtype/rrclass"
Please avoid using a slash as a conjunction substitute.
Can you explain what you'd like to see instead?
For example, "name, rrtype, or rrclass" (or "and", depending on the intent)
[...]
-- 13:
Seems like this should be stated early in the document, in the intro, or in
a scope section or applicability statement.
?
Section 13 states that something is out of scope for the document. It's
conventional to make such statements early in the document. For example, if
someone was trying to learn how mDNS is used in service discovery, he might be
disappointed to read this far before they discover he was in the wrong place.
OTOH, there's probably no strong rule about this, so its not a big deal.
[...]
Thanks!
Ben.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf