Link-local Multicast Name Resolution (LLMNR)
draft-ietf-dnsext-mdns-47

Minor/editorial points from Gen-ART review by Francis Dupont:

 - 2.1 page 5: the 512 octets default maximum seems a bit too conservative?
 - 2.1.1 C page 6: request -> query (IMHO the document should use only
  the pair of terms query/response)
 - 2.9 page 14: check if SIG(0) is not now RSIG(0) (PS: as far as I know
  the RFC 2931 was not updated so it is still SIG(0))
 - 3.1 pages 17 and 18: linklocal -> link-local (twice)
 - 4.1 page 19: I am not happy with "interpreted as an unsigned integer"
  as this involves an ambiguous byte order (I assume it is big endian
  but it is not specified). I strongly prefer the lexicographical order.
 - 4.2 page 20: same than the previous point.
 - 4.2 page 21: requests -> queries, and replies -> responses
 - 5 page 22: 802.11 -> IEEE 802.11
 - 5.1 page 23: silently discarding them as rapidly as possible ->
  silently discarding them (I don't know a way to slowly discard them :-)
 - 5.2 page 23: link layer security -> link-layer security (the link-xxx
  style seems fine)
 - 5.2 page 23: local-link -> local link
 - 5.3 [a] page 24: same than 2.9
 - 6 page 25: my dictionary has no "coincident", in particular in this
  position... (i.e., there is a possible wording/language problem)

[BC - it's a perfectly fine adjective but an adverb is needed here.]

 - 8.2 pages 26/27: many informative references are for 2002 I-Ds,
  perhaps this can become a problem?
 - Acks page 28: Van-Valkenburg -> van Valkenburg? (please check with him)
 - Open Issues page 30: should be marked as to be removed by the RFC editor.

I'm concerned but OK with this as informational.  I wish I had a better understanding of the risks to applications that believe they're doing DNS when they actually get resolution from LLMNR/mDNS.  There were ominous references to that in last call and I don't know if that's FUD or real as there's nothing in the document that really addresses that.

Nit: "  The use of separate caches is most
   effective when LLMNR is used as a name resolution mechanism of last
   resort, since this minimizes the opportunities for poisoning the
   LLMNR cache, and decreases reliance on it."

Shouldn't this be the DNS cache that is protected from poisoning, or perhaps both?

I agree with Ted and Bill that this is a result of a sub-optimal process. However, I think that it is better to publish the document in order to document the protocol. I agree with Ted that some sort of note would be appropriate, perhaps along the lines that "the working group was not able to reach full consensus".