Re: Summary of the LLMNR Last Call

Margaret Wasserman <> Wed, 21 September 2005 15:06 UTC

Received: from localhost.localdomain ([] by with esmtp (Exim 4.32) id 1EI6BX-0000In-AW; Wed, 21 Sep 2005 11:06:59 -0400
Received: from ([] by with esmtp (Exim 4.32) id 1EI6BU-0000IS-KV; Wed, 21 Sep 2005 11:06:56 -0400
Received: from (ietf-mx []) by (8.9.1a/8.9.1a) with ESMTP id LAA27171; Wed, 21 Sep 2005 11:06:54 -0400 (EDT)
Received: from [] ( by with esmtp (Exim 4.43) id 1EI6HV-0004y3-Sq; Wed, 21 Sep 2005 11:13:12 -0400
Received: from [] (account margaret HELO []) by (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 526330; Wed, 21 Sep 2005 11:08:19 -0400
Mime-Version: 1.0
Message-Id: <p0620077dbf5720926d8e@[]>
In-Reply-To: <29723.1127313120@munnari.OZ.AU>
References: <p0620071dbf52f99dab4c@[]> <29723.1127313120@munnari.OZ.AU>
Date: Wed, 21 Sep 2005 11:06:52 -0400
To: Robert Elz <kre@munnari.OZ.AU>
From: Margaret Wasserman <>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88
Subject: Re: Summary of the LLMNR Last Call
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

Hi Robert,

Our process, as currently instantiated, has three stages after a 
document is submitted to the IESG for review/approval:

1. AD Review -- the responsible AD reviews the document and 
determines if is ready for IETF LC.  Sometimes other things happen at 
this stage, like review by certain specialist groups (such as the MIB 
doctors) and/or resolution of AD Review comments.
2. IETF LC -- the document goes to IETF LC, after which the 
responsible AD determines whether the community has consensus to 
publish the document.  Any issues raised in IETF LC need to be 
addressed before he document is approved by the IESG.
3. IETF Evaluation -- the full IESG reviews the document on a 
telechat, stating positions (yes, no objection, discuss, abstain or 
recuse) on the document.  Any discuss positions have to be resolved 
before the document is forwarded to the RFC editor for publication. 
For a standards track document, there must also be at least one 'yes' 
position and at least 9 'yes/no-ob' positions for a document to be 
approved for publication.

It was my job (as responsible AD for DNSEXT) to perform the AD 
review, send the document to IETF LC, determine whether or not we 
have IETF consensus to publish the documen and make sure that any 
substantive issues raised during IETF LC are addressed before sending 
the document to the IESG for review.

In my opinion, based on the results of the IETF LC, the IETF LC 
raised two substantive technical issues with this specification, and 
the IETF community does not currently have consensus to publish this 
document as a Proposed Standard.  If the WG continues to believe that 
this document should be published as a Proposed Standard, they will 
address these technical issues (through changes to the document, 
informing the community why changes are not needed, or other means) 
and produce a document that will achieve IETF community consensus.

Like all decisions made by ADs, my decision is, of course, subject to appeal.


At 9:32 PM +0700 9/21/05, Robert Elz wrote:
>     Date:        Sun, 18 Sep 2005 10:09:07 -0400
>     From:        Margaret Wasserman <>
>     Message-ID:  <p0620071dbf52f99dab4c@[]>
>I am not going to comment on the substance of the issues, or the
>doc in question, as I haven't been following what is happening with
>it, nor have a read a recent version.
>But ...
>   | Based on these conclusions, I do not intend to forward the LLMNR
>   | specification to the IESG for review and approval.
>What kind of process is going on here?    As I recall it, from rfc2026,
>it is the IESG that issues last calls, when it has a doc for review, and
>the IESG that decides if a last call has passed or not (that is, the IESG
>takes input from the comments received during the last call to help it make
>its decision on what to do with the doc that has been presented to it).
>How did we ever get an IETF last call on a doc that hasn't even gone to
>the IESG (apparently) but is still (apparently) under AD review ?
>And how does one AD (alone, apparently) get to draw conclusions based upon
>the results of the last call ?
>What is happening here?   Can't the IETF manage to either follow its
>own documented processes, or change them in the approved way?

Ietf mailing list