Hi,
I just read draft-cheshire-dnsext-multicastdns-04, and as promised I would
sent my comments to this list.
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 ;-)
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.
That said, here are my comments:
* Introduction, paragraph 3 & 4: mostly "chattiness" is discussed. Maybe
this needs a separate paragraph, similar to the security considerations.
Section 22 is appropriate for this.
* Section 3, page 5 (line 264): "For example, my Titanium PowerBook laptop
computer answers to the name [...]" . All personal remarks give the I-D a
nice personal touch, making it very readable, but I would not use "my".
Suggestion: "For example, a laptop computer may answer to the name [...]".
* Section 3, page 5 (line 273-274): This paragraph discusses conflicts in
flat namespaces. This is duplicate from page 6, where the main point is that
early implementations suggest that this is no issue. Both with AppleTalk,
and now with Rendezvous. Suggested change: remove the text "Like law suits
over global DNS names, ". This is irrelevant, and only distracts from the
main point.
* page 6, last line of section 3: "but it is not required that this ability
be used for every record.". I would say "[...] this ability is used [...]".
But maybe my English is lacking (I'm not a native speaker).
* 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).
* 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.
* 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.
* 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).
* 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.
* 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
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.
* Section 6.6, third line of it: "[...], indicating that they form a unique
RRSET, [...]". Change into: "[...], indicating that the resource record
should be unique [...]".
* Section 7.4 and Section 16 discuss Sleep Proxy Servers. I strongly
recommend to keep this information in one place. For Section 7.4, this means
to delete everything between "In the future [...]" and "[...] were to answer
every query." Though it may be visionary, it is only confusing here if you
don't know what a Sleep Proxy Server is. If you move this text, instead of
delete, consider rewording "as a matter of course"; this is difficult
English for a non-native speaker (twice in document).
* 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".
* 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.
If it is the latter, I have two problems with it.
First, it conflicts with the spirit of section 9.4, 2nd paragraph, which
limits the number of queries to 10 per minute. If a mDNS responder updates
the query after 80% of the TTL, this is already after 8 seconds. Not that
mention that if no reply is received, it can not query after 85% of the TTL,
since that would violate the 1 query/second maximum. I think 60 seconds, or
even 10 minutes is better.
My second problem is that this more-or-less reduces all advantages of the
"QU" Queries: the reason for the QU Queries is to reduce the network load.
However, if the record is requeried after 8 seconds via a regular "QM"
Query, it has a only lead to slightly more traffic.
Clearly, my objections don't hold if this requirement does not apply to
responses to "QU" Queries.
* 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*.
Though the wording as-is is correct, You may change in Section 9.1, first
line: "[...] for all those resource records that [...]" to "[...] for
exactly those resource records that [...]". And in the third line of Section
9.3, make the "all" caps: "ALL". This is nit-picking though.
* 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. If I consider times > 1 sec range: For questions, time between
queries > 1 second, and must double (section 6.2) and must wait > 5 seconds
if >10 failures happened in any 10-second time-frame (section 9.1). For
responses, time between responses > 1 second (end of section 8.0). In
addition, a quarter of the RTT (section 6.5), half the RTT (7.1 and 13.1)
give additional limits. Also, there is a rule of thumb about 1 request/6
seconds (section 9.4).
I guess you as protocol designer + implementer can decide best. If
implementing all these time limits pose no problems, then it's fine.
* 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.
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.
As a side-note: Professionally, I'm working with long, high bandwidth pipes
(> 100 ms RTT, 1-10 Gb/s), and I notice that (USA) state-wide networks
emerge without routers(!), but everything at layer 2 (or even bellow -- the
later, lambda networking, is my speciality). I feel that all times mention
in the draft are sound, even if the average RTT will on a link-local network
will increase. TCP does NOT function properly for these links (!), but at
least I think mDNS will ;-). I like to give it a test: the longest I have
access to is a 300 ms 1 Gbps pipe between Amsterdam and Tokyo (that's
link-local, only a few switches in between, but no routers), but I don't
think this will ad much, but feel free to contact me if you're interested.
* Section 9.3, page 20, 3rd paragraph on this page: " A Responder MAY send
up to ten gratuitous Responses, providing that [...]". I think that should
be "[...] provided that [...]".
* Section 9.3, page 20, last line of section: Remove "as a matter of
course". This is slightly advanced English to a non-native speaker, and
removing it does not change the meaning of the sentence. (And if it does,
change the last "MUST NOT" to "SHOULD NOT").
* Section 9.3, page 20: Change the order of the last two paragraphs. This
brings the SHOULD NOT and MUST NOT paragraphs together, making it more
obvious that they are complimentary instead of a contradiction.
* 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.
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.
* 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.
* Section 12: A compliment for the clear thinking here.
* Section 13: Move this section before the current sections 11 and 12, so
that it comes immediately after section 9 and 10. Since these three (9, 10
and 13) are related, you may as well place them together.
* Section 13.1: If this part comes quickly after section 10, you may as well
decide to integrate the first part of section 13.1 with section 10. I think
this is a particular good description.
* Section 13.3, fifth paragraph, (middle of page 27): "[...] and immediately
re-announce its Ethernet address records [...]". It is not exactly clear to
me what to re-announce. The same RR, on the same link, only without the
cache flush bit set. Or both RR (for each interface), both without the cache
flush but set? (This is minor, I was probably too lazy to think about it, so
no real need to change the text).
* Section 13.2: Introduces a 1 second delay before deleting records after a
goodbye packet: "it gives the other cooperating Responders one second to
send out their own response to "rescue" the records". There may be a very,
very rare condition where the 1 second delay is not enough: e.g. When the
cooperating Responder has already sent out the record just before (let's say
50ms before the goodbye packet), and the RTT on the local link is just too
long (>50ms in this case). (see also my comments on section 9.1). I doubt
this is worth bothering about though, since the record will just be
reinstalled after 50 ms.
* Section 13.5 and 13.6: "[with]in a reasonable amount of time". I would
specify this more clearly, and make it "one second after the last request
was sent out". This is in line with the 1 second delay in section 13.2. I
would make these the same. Again, it is possible that a record may be
deleted just milliseconds to early, but it will be restated shortly after.
* 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!
* 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.
* Section 16, second paragraph: "to determine if Sleep Proxy Service is
available". My first reading was: what on earth is Sleep Proxy Service?
Change to either: "to determine if a service called Sleep Proxy Service is
available" or change the order: "the device determines if a Sleep Proxy
Service is available by using DNS-SD."
* Section 16, second paragraph: Move the sentence "In some networks there
may be more [...] for fault-tolerance reasons." to somewhere at the end of
this section. It is not relevant here.
* Section 16, last paragraph on page 31: "[The reason to] send more than one
goodbye packet is that the wakeup message is [...]". This is not so clear.
Change to: ""[The reason to] send more than one goodbye packet is to ensure
the deletion of the RR in all caches. The wakeup message is [...]".
* Section 17: The reference to RFC2279 (UTF-8) is obsolete: You should refer
to RFC 3629. ([rant]Personaly, I think RFC3629 is very unreadable; I didn't
know what exactly UTF-8 was till yesterday, and neither of these RFCs was
very helpful. The first hit on Google for UTF-8 had more or less the same
content, but much more readable. Sigh... It seems people think they score
points for writing unreadable RFCs.[/rant])
* 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.
* 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 ;-) ).
* Section 19.1, last line on page 33: "cashed resource records". Hmm,
interesting. Perhaps you mean "cached resource records"? :-)
* 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?
* 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?
* Section 19: Add a section describing the top bit in the rrclass field (the
unicast response/cache flush bit).
* 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.
* 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.
* 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.")
With kind regards,
Freek Dijkstra
PS: Stuart, your name did ring a vague bell. I searched my mail archive and
found I once paid you a few bucks for Bolo. Your response: "I hope to
release version 0.99.8 soon. I'm reluctant to make promises I may not
be able to keep [...]". HA! Oh, the memories...
--
Never ask a man what kind of computer he owns. If it's a Mac, he'll tell
you. If not, why embarrass him?
_______________________________________________
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.
