Subject: Re: Gen-ART LC Review of draft-cheshire-dnsext-multicastdns-12

From: Stuart Cheshire <[email-masked]>
Date: Wed, 15 Dec 2010 02:30:58 -0800

On 23 Nov 2010, at 6:49 PM, Ben Campbell wrote:

> *** 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.

It is however a relevant difference that no money needs to change  
hands when using Multicast DNS names; often it does when using  
unicast DNS names.

> -- 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?

I have deleted this section.

> -- 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?

Yes.

> -- ..., 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?

Previously we had thought the Multi-Packet Known Answer Suppression  
case might be harder to implement, but you are right. We have changed  
this to MUST.

> -- 6.3:
>
> Shouldn't there be something normative in section 6.3?

I have changed the "should" to capital letters.

> "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?

See "Continuous Multicast DNS Querying". All active queries have a  
timeline of planned future retransmissions. A Multicast DNS Querier  
knows when it next expects to send a given query, and if it sees an  
equivalent query issued by another host, then it should treat its own  
query as having been sent on its behalf.

> -- 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?

Yes. In the case of misconfiguration it's important that hosts do not  
create a packet storm fighting about it.

> -- section 7.6:
>
> I assume this is for backwards compatibility with existing deployed  
> implementations? If so, it would be worth mentioning that.?

I have changed the document to say:

    If the source UDP port in a received Multicast DNS Query is not port
    5353, this indicates that the client originating the query is a
    simple client that does not fully implement all of Multicast DNS, as
    described in Section 5.1 "One-Shot Multicast DNS Queries".

> -- 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.

> -- 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?

> -- ..., 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.

> -- 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.

> -- 8.4, 1st paragraph:
>
> No need to repeat the probe?

No. The host does not need to repeat the Probing step because it has  
already established unique ownership of that name.

> -- 10, 1st paragraph: "As a general rule, the recommended TTL  
> value..."
>
> Normative?

Yes.

> -- ..., 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.

> -- 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.

The comment in parentheses is not a comparison. It does not state  
intent. It is merely an observation about current reality.

> -- ..., 6th paragraph: "There are no NS records anywhere in  
> Multicast DNS Domains."
>
> Normative?

Yes.

> -- 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.

> -- 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.

> -- 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.

> -- ..., last paragraph
>
> If a CNAME record creates a name conflict, will m-dns  
> implementations notice and defend against it?

A query for the name will generate a response which will signal a  
name conflict like any other response would.

> -- 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.

> -- ..., last paragraph:
>
> If jumbo packets are rare,  why not just stick to the 1500 limit?

Some applications today need more than 1500-byte payloads.

> -- 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.

> -- 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?

It is a normative requirement for Multicast DNS (this document).

> -- 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.

I made this change.

> -- ..., paragraph 4: "... it is *especially* important..."
>
> Normative?

No.

> -- 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..."

This is now covered by <http://www.ietf.org/id/draft-cheshire-dnsext- 
special-names-00.txt>

> -- ..., 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.

This now the "Domain Name Reservation Considerations" section.

> -- ..., list item 1, 2nd paragraph:
>
> I'm very skeptical about normative statements of the form of "users  
> SHOULD be aware...". What should _implementors_ do?

See <http://www.ietf.org/id/draft-cheshire-dnsext-special-names-00.txt>

> -- ..., 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.

> -- ..., 2nd to last paragraph:
>
> Again, this needs to be more explicit about what is requested from  
> IANA.

IANA has clarified they understand this.

> --, 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.

> -- 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.

> *** Nits/editorial comments:
>
> -- Idnits shows 2 warnings and 3 comments. Please check.

Checked.

> -- 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.

> -- 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.

> -- 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.

We have already done many edits to try to organize this section into  
the best order we can.

> -- ..., 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?

Yes.

> --... 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?

We expect implementers using networks substantially dissimilar to  
Ethernet to consider whether the stated time constants are applicable  
for their network.

> -- ..., 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.

> -- 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?

Fixed.

> -- ..., 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?

> "(e.g. for reverse address..."
>
> For, or From?

e.g. names of reverse address mapping PTR records, which are derived  
from IP addresses, and therefor can be assumed to be already unique.

> -- 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?

No. Unlike single-question queries where responding without delay is  
allowed in appropriate cases, for query packets containing more than  
one question all (non-defensive) answers SHOULD be randomly delayed  
in the range 20-120ms, or 400-500ms if the TC (truncated) bit is set.

> -- 8.1, 6th paragraph: "At the present time, this document  
> recommends..."
>
> Do you expect this to change?

Good point. Removed.

> -- 8.2, 4th paragraph:
>
> Inconsistent usage between "the host" and "ourself". Probably best  
> not to anthropomorphize.

Changed to "from the host itself"

> -- 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.2.1 is a continuation and elaboration of 8.2.

> -- 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.)

Changed.

> -- ..., last paragraph: "as described below in "Conflict Resolution"."
>
> Section number cross-references would be helpful.

Fixed.

> -- 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.

Thanks. That text was supposed to apply to item 4.

> -- 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?

This includes things like network printers implementing draft- 
cheshire-dnsext-multicastdns-04.txt, published February 2004. Some of  
these printers are still around today.

> -- 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_?

Changed.

> -- ..., 6th paragraph: "...delegation of all Multicast DNS Domains  
> to the 224.0.0.251:5353 and [FF02::FB]:5353,..."
>
> Missing words?

Fixed.

> -- ..., 7th paragraph:
>
> Please expand SOA on first mention

Fixed.

> -- 15, last paragraph:
>
> Can you provide section cross references for these safeguards?

Fixed: Section 10.3

> -- 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

I disagree: "clients" is plural.

> -- 17, 3rd paragraph from end:
>
> This seems to imply there are no "letters" in UTF8 outside the  
> ASCII range.

Fixed.

> -- ..., last paragraph: "The simple rules for case-insensitivity in  
> Unicast DNS also apply..."
>
> Reference?

Fixed: [RFC1034] [RFC1035]

> -- 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"?

Changed.

> -- ..., 2nd to last paragraph: "Ethernet "Jumbo" packet"
>
> Reference?

Added reference.

> -- 19.2 and 19.3:
> Incomplete sentences

Fixed.

> -- 19.12 and 19.13:
>
> References to normative text?

Fixed.

> -- 20, paragraph 1: "The value of Multicast DNS is..."
>
> Is assume you mean "a value..." or "one value..."?

Changed:

    Multicast DNS shares, as much as possible, the familiar APIs, naming
    syntax, resource record types, etc., of Unicast DNS.

> -- 23, paragraphs 1 and 2:
>
> Can you provide references or pointer to the existing registrations?

Added references.

Stuart Cheshire <[email-masked]>
* Wizard Without Portfolio, Apple Inc.
* www.stuartcheshire.org

---

From: Ben Campbell <[email-masked]>
Date: Wed, 22 Dec 2010 16:11:04 -0600

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?
> 

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."
>> 
> 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."
>> 

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.
> 

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.)

> 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.

>> 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..."

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.

[...]

>> 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.

> 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.
> 

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.

> 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.

---

From: Douglas Otis <[email-masked]>
Date: Wed, 22 Dec 2010 15:55:12 -0800

On 12/22/10 2:11 PM, Ben Campbell wrote:
>  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?

The IDNA patch for DNS is not a complete or without problems. Although 
RFC4795 indicates compliance with RFC1035, the latest specification 
published by Microsoft, MS-LLMNRP — v20101112
http://download.microsoft.com/download/a/e/6/ae6e4142-aa58-45c6-8dcf-a657e5900cd3/%5BMS-LLMNRP%5D.pdf
includes the following questionable statement:
,---
[RFC4795] does not specify whether names in queries are to be sent in 
UTF-8 [RFC3629] or Punycode [RFC3492]. In this LLMNR profile, a sender 
MUST send queries in UTF-8, not Punycode.
'---
Rather than making the same mistake, leave mDNS as is.

-Doug

---

From: Stuart Cheshire <[email-masked]>
Date: Wed, 22 Dec 2010 21:56:03 -0800

On 22 Dec 2010, at 2:11 PM, Ben Campbell wrote:

>>> -- 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."
>>>
Done

>> 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.
>
Done.

> 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.
Moved to introduction.