Subject: Publication Requested: LLMNR document (MDNS-34)

From: Ólafur Gudmundsson/DNSEXT co-chair <[email-masked]>
Date: Wed, 11 Aug 2004 18:34:09 -0400

Thomas and Margaret

Please advance LLMNR on standards track to proposed standard:
(http://www.ietf.org/internet-drafts/draft-ietf-dnsext-mdns-33.txt).

1. Have the chairs personally reviewed this version of the ID and do they 
believe this ID is sufficiently baked to forward to the IESG for publication?

Yes, we have read this document and it has been extensively reviewed and
revised. For the last 2 years an issue tracker has been used to track
open issues and their resolution.

2. Has the document had adequate review from both key WG members and key
non-WG members?
Do you have any concerns about the depth or breadth of the reviews that
have been performed?

Yes, key members of DNSEXT a have read this document.
As the document crosses multiple working groups expertise we are happy to
report that there are number of reviewers from these working groups.
We have no concern about the quality of the reviews.

3. Do you have concerns that the document needs more review from a particular
(broader) perspective?

The only review that this document may need is from architectural point
of view. This is one of at least two proposed mechanisms to provide
name resolution via multicast in server-less environment.
Another one is documented in:
http://www.ietf.org/internet-drafts/draft-cheshire-dnsext-multicastdns-04.txt

4. Do you have any specific concerns/issues with this document that you
believe the ADs and/or IESG should be aware of? For example, perhaps you
are uncomfortable with certain parts of the document, or whether there really
is a need for it, etc., but at the same time these issues have been discussed
in the WG and the WG has indicated it wishes to advance the document anyway.

No concerns with the document.

5. How solid is the WG consensus behind this document? Does it represent
the strong concurrence of a few individuals, with others being silent,
or does the WG as a whole understand and agree with it?

The working group consensus is "rough" there is number of people that
support the alternate proposal, the working group tried hard to get the
two camps to agree on a single specification. We where unable to get some
fundamental technical differences resolved.
The other issue has to do layering, mDNS-33 documents a simple name
resolution protocol without any usage model (only when to use this mechanism
vs DNS) the other proposal has number of optimizations and usage assumptions.

6. Has anyone threatened an appeal or otherwise indicated extreme discontent?
If so, please summarize what are they upset about.

No one has threatened appeal, as stated before there are two camps that 
consider each other "heretics". See answer to #5.

7. Have the chairs verified that the document adheres to _all_ of the ID 
nits? (see http://www.ietf.org/ID-nits.html).

Yes, the document passes all nits.

8. Does the document a) split references into normative/informative, and
b) are there normative references to IDs, where the IDs are not also ready
for advancement or are otherwise in an unclear state?

References are split, and all normative references are RFCs.

9. For Standards Track and BCP documents, the IESG approval announcement
includes a write up section with the following sections:

Technical Summary:
    Today, with the rise of home networking, there are an increasing
    number of ad-hoc networks operating without a Domain Name System
    (DNS) server.  The goal of Link-Local Multicast Name Resolution
    (LLMNR) is to enable name resolution in scenarios in which
    conventional DNS name resolution is not possible.  LLMNR supports all
    current and future DNS formats, types and classes, while operating on
    a separate port from DNS, and with a distinct resolver cache.  Since
    LLMNR only operates on the local link, it cannot be considered a
    substitute for DNS.

Working Group Summary

    The document being advanced is a cumulation of a long process to
    specify a DNS like mechanism to use on a local link. This document
    has gone through large number of changes in its progress and got better
    over time. There is rough consensus in the WG to advance the document.
    There are some issues that are in conflict with the wishes of some
    reviewers.
    Some of these issues are within the core expertise of the
    working group (DNS) but related to Transport (TTL=?). The current
    consensus to use TTL=1 and TCP as much as possible is to prevent
    implementations of this protocol to become DDoS amplifiers.

Protocol Quality:
    This protocol document has gone through number of revisions and been
    greatly simplified from original specification. The protocol is
    clearly expressed and more importantly clearly documented when the
    use of this protocol is applicable.
    This is a complicated protocol but it inherits most of the complexity
    from DNS, packet format, Resource Records, Return Codes etc.
    We judge this protocol description to be of high quality.
    There exists at least one implementation of the protocol.

	Olafur & Olaf

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>