Link-local Multicast Name Resolution (LLMNR)
RFC 4795

Note: This ballot was opened for revision 47 and is now closed.

(Mark Townsley) Yes

(Jari Arkko) No Objection

(Ross Callon) No Objection

Comment (2006-07-05 for -)
No email
send info
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".

(Brian Carpenter) (was Discuss) No Objection

Comment (2006-07-06)
No email
send info
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.

(Lisa Dusseault) No Objection

Comment (2006-07-18 for -)
No email
send info
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?

(Lars Eggert) No Objection

(Dan Romascanu) No Objection

(Bill Fenner) Abstain

Comment (2006-07-05 for -)
No email
send info
I'm piggybacking on Ted's abstain.  The development of this document is something for the IETF to be ashamed of.

(Ted Hardie) Abstain

Comment (2006-07-05 for -)
No email
send info
I've entered an Abstain on this, rather than a discuss, because I believe the energy to work on this document is pretty severely limited.  I would be happier with the document with an IESG  note saying, basically, "Published as a record of discussion".

Other than the really basic issue that they didn't resolve the interoperability with deployed rendezvous/bonjour, my concerns are around the continuing MPD around the relationship to the DNS.  The use of "DNS TTL" in 2.8, for example, when the TTL record in the LLMNR record is apparently meant (yes, it reuses the packet format, and I think I get what they mean, but this kind of confusion doesn't help).  The other aspects of the interaction are similarly confusing:

   In order to to avoid creating any new administrative procedures,
   administration of the LLMNR namespace will piggyback on the
   administration of the DNS namespace.

Given the scope of this, one of the issues is that these fundamentally aren't administered like the DNS namespace; saying they are just doesn't make sense and adds to confusion.  I do appreciate the advice not share the LLMNR and DNS local cache.

(Sam Hartman) (was Yes) Abstain

Comment (2006-07-20 for -)
No email
send info
[declaration of potential conflict: the Kerberos group at MIT is
closely associated with Apple.  We do not currently receive direct
funding from Apple although we have in the past.]

I agree with Cullen and Ted.  There should be an interoperable
standard solution to this need; it should be one that people actually
use.  Publishing this protocol and encouraging its implementation is
not a step in that direction.

Publishing this as a record of discussion may be reasonable.  However
we need to be very clear in the IESG note that we are not publishing
in the hopes of encouraging wider deployment.

I too believe this document represents a huge process failure.

(Russ Housley) Abstain

Comment (2006-07-14 for -)
No email
send info
  The concerns raised by Ted and Bill are significant.

  The header on the title page inicates that this document is intended
  for Standards Track.  Of course, the ballot indicates that this
  document is intended for Informational.  This clearly needs to be
  corrected if the document is approved for publication.

(Cullen Jennings) (was No Record, No Objection) Abstain

Comment (2006-07-19 for -)
No email
send info
A solution to this problem is useful. IETF should manage to provide a standards track approach to it. I do not believe that moving this forward gets us closer to having that or helps the longer term goals of having the IETF produce interoperable standards.

Magnus Westerlund (was No Objection, Abstain, Discuss) Abstain