I've responded to some (but not all) of your suggestions below. For
the things I didn't respond to, we'll still consider these suggestions
when the spec is updated in the next few weeks.
On Jul 24, 2004, at 6:21 AM, Freek Dijkstra wrote:
First of all: well written, my compliments! In particular sections 1-3
and
12. I'm not going to comment on the protocol implementation itself. I
think
that's good as it is. I regret that it isn't fully compatible with
LLMNR.
Normally I would recommend that if it is hard to make LLMNR compatible
with
mDNS, then we should make mDNS compatible with LLMNR. But I realize
that's
not realistic. Even if all that need to be done was update the port
number
from 3535 to 3555, it would be non-trivial given the installed base.
Well,
it's a lot harder then that ;-)
Minor nit, but you mean port numbers 5353 and 5355. Note that many
people in the DNSEXT Working group asked that LLMNR be compatible with
mDNS. Some text was even added to LLMNR that says...
"For UDP queries and responses the Hop Limit field in the IPv6 header,
and the TTL field in the IPV4 header MAY be set to any value.
However, it is RECOMMENDED that the value 255 be used for
compatibility with Apple Rendezvous."
Of course, then about three weeks ago, LLMNR was assigned a different
multicast address and a different port number (without announcing this
fact on the DNSEXT mailing list), so this makes you wonder why the
recommendation for a TTL value still exists in their spec. I really
don't think anyone is paying attention to LLMNR at this point.
I do recommend however to get it published as Experimental RFC. I was
once
involved in writing a Standards Track RFC, but despite that it was a WG
item, it was blocked by the IESG. I sometimes still regret we never
published it, even not as experimental.
As we continue to learn from operational experience with mDNS, we will
continue to update the spec as appropriate. At the point where the
spec is "perfect" and doesn't need any further updating, we will
consider our options. If the working group has no interest in the spec
becoming a Standard, then we'll either publish it as Experimental or as
Informational.
* Section 4: Just out of curiosity: for UDP the (IP) TTL is set to
255. Is
this also the case for TCP packets? I assume so. (No, I'm not going to
repeat previous discussions here -- it might be good to be explicit
though,
if this is in discrepancy with LLMNR).
The current draft is admittedly vague when it comes to TCP, and in
fact, the current Darwin mDNSResponder does not support TCP
connections. I agree that we should address the TTL for TCP
connections somewhere in the spec.
* In general: there are a lot of lower-case "should" and "must". It
would be
good to do a search and replace. IMHO, they can all become caps,
except a
few mentioned in this mail.
We've heard this feedback before, and we've tried to make these words
upper-case where it made sense. We'll go back and see if we missed
any, but it sounds like we did.
* page 10, Sections 6.2 and 6,3: "the interval between the first two
queries
MUST be at least one second, [and] the intervals between subsequent
queries
MUST double". I disagree. I can live with the first MUST, but the
second
shouldn't be a MUST, but must be a SHOULD. I have the impression that
this
is done to deal with critics who say multicast is too "chatty". Well,
it is
not. However, this is too strict. I can imagine a ping-like utility for
debugging purposes. That may be disruptive (just like ping), but
should not
break the protocol.
I think the motivation behind the MUST was so the protocol would not be
considered chatty, which plagued AppleTalk. I'd be willing to make the
second MUST a SHOULD.
* Section 6.3, page 11, last two paragraphs: a suggested technique is
discussed to handle DNS record caching if no SOA record with explicit
refresh and retry time are available. Though I think the mechanism is
great,
it should be presented as an example implementation, not as a protocol
requirement. Only really relevant is a reference to half the RR RTT.
(as
mentioned in section 7.1). In section 6.4 another example
implementation is
presented, a Nagle-style algorithm. This is the correct way to present
this.
Suggested change: "To perform this cache maintenance, a Multicast DNS
Querier SHOULD plan to issue a query before the record lifetime has
expired.
This query MUST be made after at least 50% of the lifetime has expired.
[paragraph break] For example, a Multicast DNS Querier may issue a
query to
80% of the record lifetime, [...]". I would concatenate the last
paragraph
to this one, to make it clear it is still an example (and keep this
particular "should" lowercase instead of making it caps).
OK.
* I had the feeling at first that the unicast response bit, as
described in
section 6.4, added too complexity to the protocol for the network
efficiency
it tried to gain. It only helps when multiple machines wake from sleep
or
connect to the network just quickly after each other. When the wake
simultaneous, or it is only one machine, the gain is neglectable.
However, I
now see the advantages. You may consider moving the section after
chapter 8,
though it's not crucial.
Yes, I originally had the same fears as you, that it added too much
complexity. But from testing, we've found that this significantly
reduces network traffic when you have laptop computers that are
continuously sleep/waking on the network.
* Section 6.5 and 13.3: These two paragraph describe the special
meaning of
the first bit of the rrclass field of a DNS record (all other special
bits
apply to the DNS message as a whole). If I understand correctly, the
meaning
of bit of value 1 is:
For a question: unicast response bit, as described in section 6.5
For a response: cache flush bit, as described in section 13.3
Yes, that's correct.
This has a very different meaning. I would recommend to place these
sections
near each other, or clarify the meaning in a new section in chapter 19
(where other special bits are described, but not this one). In
particular,
it is not clear when this bit has the 'unicast response' meaning and
when
the 'cache flush' meaning. What is crucial here: the fact if the QR
bit in
the DNS message say it is a question or a response, or the fact that
the RR
in questions appears in either the question, or in the answer,
authority or
additional section? (this is important for the comment I made at
section 10
below).
* Section 6.6: this section was very confusing when first read. The
reason
is that it mentions the "cache flush bit" which is only introduced 14
pages
later, in section 13.3! I would strongly recommend to move this
section to a
place behind section 13.3, or at least refer to 13.3 here! If it is
moved,
move 6.5 as well; they belong together.
The QU query is relatively new to the mDNS spec. I believe it was
first added in draft 4. We'll consider moving some sections around, or
adding a new section to better explain these bits.
* Section 8: The most important flaw in the document: It is not
documented
who should respond to a query. Though it seem likely that only a mDNS
responder should respond if it has a record that matches the
description, it
is never explicitly excluded that a machine who has the answer in cache
MUST NOT respond. I strongly advise to add this requirement: "A
Multicast
DNS Responder which has a particular answer in cache MUST NOT respond
to a
query, even if no other DNS Responder has responded".
Good suggestion.
* Section 8.1, Page 16, 2nd paragraph: "The resource record TTL given
in a
unicast response SHOULD NOT be greater than ten seconds, [...]". It is
not
clear if this only apply to legacy unicast responses, or also
responses to
"QU" Queries, as described in section 6.5.
It only applies to legacy unicast responses. We should make that more
clear.
* Section 9.1 and 9.3 (Probing and Announcing): I would emphasize that
probing only needs to be done for *records that the mDNS Responders
desires
to be unique*, and that announcing needs to be done for *all records*.
Sounds good.
* Section 9.1, page 18: I would streamline the time-restrictions if
possible.
In general, I feel there are many time specifications in this draft.
The
most crucial time-out seems the assumption that all queries are
answered in
one second.
Actually, it's assumed that queries will be answered within 120ms,
although we plan on adding some new text to the spec that says, if the
TC bit is set on the query, then the responder SHOULD wait between
400-500ms before responding so it has enough time to receive all the
Known Answer packets on a busy 802.11b network. We learned this from
operational experience.
I guess you as protocol designer + implementer can decide best. If
implementing all these time limits pose no problems, then it's fine.
So far, there hasn't been any complaints about the timing, and we've
seen many independent implementations.
* Section 9.1, page 18: In general, I think the important 1 second
limit is
reasonable. However, be aware that there are two issues with the
probing:
First, it specifies to sent three probes within one second. This is in
contradiction with the requirement in section 6.2 that the time between
queries MUST be at least 1 second. You should note this exception in
section
6.2, to keep internal consistency.
Good call. We don't consider probes to be queries, even though
technically they are. We should note the exception.
Second, this behaviour is not ideal in the following situation: at
t=0, mDNS
responder B sents a response with record x, for whatever reason. At
t=0.1,
mDNS responder A wakes, waits (let say 0.05s), announces record y,
which
conflicts with record x. B detects the conflict shortly after, but is
not
allowed to respond until t=1, according to the last line of section
8.0.
However, at t=0.1+0.05+3*0.25 = 0.9, A already decided that there is no
conflict, and announces record y. Perhaps, the restriction in section 8
should be loosened in case of conflicts.
I'll need to think about this some more, but you may have a point.
* Section 10, second paragraph: " Whenever a Multicast DNS Responder
receives any Multicast DNS response (gratuitous or otherwise)
containing a
conflicting resource record [...]". It is not entirely clear what
exactly
the trigger is. I can imagine four triggers:
First, as clearly described in section 13.1, a response with a RR with
different rdate, which the *observer* beliefs it should be unique.
Second, a response with a RR with different rdate, with the cache
flush bit
set (thus the *sender* asserts that the record should be unique).
Third, a *request* with a record in the authority section, as
described in
section 9.2, with different rdate which the *observer* beliefs it
should be
unique.
That request would not be considered a conflict, since the request is
actually a probe that will cause the real owner of that name to
respond. That would not be a trigger for the real owner of that record
to reset to probing state.
Last, a *request* with a record in the authority section, with
different
rdate with the cache flush bit set (if this is possible; it is unclear
if
this bit has the cache flush or unicast response meaning in this
situation).
It is clear that the first situation is a trigger situation, and I
*asume*
the second is one as well. However, the last two are not triggers
according
to the text (it explicitly says "response"). I have the impression
that this
should be a trigger, and thus the text should be updated accordingly.
Same as above. It's only a conflict when two different responders own
a name that's supposed to be unique. In the case that one of the
responders is probing, that responder does not yet own the name.
* Section 10: " It is very important that any host that observes an
apparent
conflict MUST take action." From this sentence I get the impression
that
this means that even a 'third party' mDNS responder, who has a certain
record in cache, and sees a conflicting record on the wire, must also
take
action. However, since it does not advertise the record itself, it
shouldn't
sent out the record, and can't thus take the actions described in
section 9.
I can only conclude that a host MUST take action if and only if it has
an
interest in the record. The text should make a clearer distinction
between
'authorative' and 'cached' records.
Yep. We'll make that more clear.
* Section 14: It is possible to delete the last paragraph, since this
is
already mentioned in the security consideration. You may even move the
first
two short paragraphs to the security consideration as well. Deleting
the
paragraph has the disadvantage to delete the last, hilarious line
though :-)
LOL!
We'll consider moving the paragraphs around, but I think the last
paragraph is important in the theme of zero-configuration. We want to
make it clear that this protocol doesn't need any method to
enable/disable it.
* Section 16: You may consider removing this whole section, and put
this in
a separate document. You can refer to this yet-to-be-published
document in
section 7.4.
Yes, once we have a Sleep Proxy Service document, we would probably
remove that section.
* Section 17, fourth paragraph: You refer to "There are various baroque
representations of international text being proposed for Unicast
DNS.". If
you are referring to the unsightly proposal of using PUNYCODE (who
came up
with that name???) and get domains like xn--de-jg4avhby1noc0d.com,
well,
that's a Standards Track document now: RFC 3490.
OK.
* Section 17, fourth paragraph: "None of these representations may be
used
[...]". Please use proper wording: "Other representation then UTF-8
MUST NOT
be used [...]". Or actually: SHOULD BE, since I think RFC 3490 and
UTF-8 are
not mutually exclusive. And Section 6 of RFC 2119 clearly says: "For
example, they must not be used to try to impose a particular method on
implementors where the method is not required for interoperability."
(yes,
life it hard, you are not allowed to use your own protocol to ditch
other,
inferior protocols ;-) ).
I'll need to confer with Stuart, but I don't think we're going to
change this. UTF-8 is the way to go. No PUNYCODE.
* Section 19.5: Out of curiosity: What is the reason that the TC bit
MUST be
zero for responses? What is the harm, for example, that a packet
crafted as
described in section 18 has the TC bit set, to signal it is going to
sent
more responses?
I believe the reason is that the TC bit doesn't mean much when
responses are being sent via Multicast since it would mean that
everyone would need to make a TCP connection to the responder, which
would be bad. Instead of setting the TC bit when responses don't fit
into a single packet, the responder will just split the response into
multiple multicast responses.
* Section 19.6: More curiosity: what is the reason that most
requirements
are "MUST be zero; MUST be ignored on reception" except for this on
(the RD
bit): "SHOULD be zero; MUST be ignored on reception"? Why the SHOULD
here
all of a sudden?
In general, the reason for this is to make it clear that these things
are not used in the protocol, so they should be ignored. But this
gives us the flexibility to use these fields in a future release
without breaking anyone. I'm not sure about the RD bit, but I'll ask
Stuart.
* Section 19: Add a section describing the top bit in the rrclass
field (the
unicast response/cache flush bit).
We'll consider it.
* Section 24 (security considerations): I strongly advice to spent a
few
words on trust relations. Currently, you do trust everyone on the local
subnet. For example, it is trivial for anyone on the local network to
delete
all others records, for example. On the other hand, you take specific
measures (described in section 4) not to trust anyone outside the local
subnet. I know it is sensitive, but a few words on the IP TTL are very
appropriate here. For example, a difference with LLMNR is that you
explicitly allow questions from other subnets. This could allow for DOS
attacks (if the size of the request is smaller then the response).
However,
I belief this is not a serious threat, but it may be good to mention.
It's not a requirement that responders answer queries from outside the
subnet, but we'll consider adding text for this.
* Section 25 (IANA consideration): I would mention the cache
flush/unicast
request bit, since this as implications for the CLASS parameter
mentioned at http://www.iana.org/assignments/dns-parameters.
Good point. We'll mention that.
* Section 25 (IANA consideration): On the three domains with only
link-local
significance (.local., 254.169.in-addr.arpa. and 0.8.e.f.ip6.arpa.), I
would
either explicitly mention them here, or refer to section 5. (thus
change "as
described in this document." to "as described in section 5 of this
document.")
OK.
Thanks for this excellent feedback. Hopefully we'll address all your
issues in the next version of the draft that we plan on publishing in
the next few weeks.
Best Regards,
-Marc
_______________________________________________
rendezvous mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/rendezvous
Do not post admin requests to the list. They will be ignored.
