Subject: "Second Last Call" - what's BCP?

From: Spencer Dawkins <[email-masked]>
Date: Wed, 3 Dec 2003 20:15:22 -0800 (PST)

Dear All,

I've tripped over a couple of second last calls (one in a
working group, but one IETF-wide) where an attempt was made to
limit the scope of the second last call to issues raised during
the first last call.

Is there any procedure written down that either allows or
disallows this? RFC 2026 doesn't describe a second last call for
IETF-wide comment, and 2418 doesn't describe a second last call
for WG-wide comment.

I admire the sentiment, and believe this is an existing practice
in other SDOs (I'm thinking IEEE), but just can't find anything
in writing that says we do, or don't.

Spencer

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 03 Dec 2003 20:48:00 -0800

At 08:15 PM 12/3/2003, Spencer Dawkins wrote:
>disallows this?

I don't believe it's ever too late to raise new technical
issues.  But you can use 2418 to hush rehashing of old
issues...

>RFC 2026 doesn't describe a second last call for

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 3 Dec 2003 21:53:50 -0800 (PST)

> in writing that says we do, or don't.

There is indeed a practice in IEEE known as the "recirculation ballot"
in which comments are restricted both in terms of scope (only to changes
made in the most recent draft) and in terms of who gets to comment (only
those people who submitted previous ballots).

Personally, I would not recommend that any SDO adopt this technique since
I have seen it prevent fixes to major specification problems that
ended up limiting the usability of the final specification.

While we should strive to surface major issues earlier in the process,
the right thing to do is fix major issues whenever they arise, regardless
of who raises them.

While rehashing of old issues can and should be limited, I don't believe
that the same can be said of new issues, particularly ones which have
major impact on interoperability or security.  The right thing to do is to
fix them, not sweep them under the rug.

---

From: Avri Doria <[email-masked]>
Date: Thu, 4 Dec 2003 14:37:41 +0900

Never realized that 2418 makes even holding a first WG discretionary.

I guess, like the practice of always holding WG last calls, the 
practice of restricting the scope is common practice not law.

a.

ps.  bet i know who is responsible for the WG example Spencer recently 
tripped over.

---

From: Spencer Dawkins <[email-masked]>
Date: Thu, 4 Dec 2003 05:04:34 -0800 (PST)

Yeah, well, I'm not the process lawyer. I didn't realize until I
looked that 2418 even mentioned WG last calls; the WG chair
training used to point out that "the process didn't require WG
last calls", and I never actually looked up the details.

Spencer, who often does the right thing, but rarely for the
right reasons!

---

From: Ed Lewis <[email-masked]>
Date: Thu, 04 Dec 2003 13:20:38 -0500

On Wed, 2003-12-03 at 23:48, Kurt D. Zeilenga wrote:
> issues.  

I used to tell our group (PROVREG) at an informal WG last call that
"it's never too late to raise an issue, but it can be too late to make
it into 'this' document."

There are three safety belts - the IETF-wide last call, the IESG review,
and the progression on standards track - for a document leaving the WG. 
That, plus RFC means "Request For Comments," which is hardly a "final"
(sounding) state.  I rely on those thoughts to stick to a schedule given
the uncertainty of "engineering progress."

---

From: Spencer Dawkins <[email-masked]>
Date: Thu, 4 Dec 2003 10:41:43 -0800 (PST)

I really like the sound of this note, but my concern is that all
too often the first RFC a working group produces on a topic is
also the last, hence the view that it's more important to get it
right than to get it out.

I believe I'm quoting Leslie Daigle correctly, but she was
quoting Mike O'Dell, and I have no idea what the context was:

  "It doesn't have to finish, but it does have to stop."

I wish we could change things so that we really could say "this
is our best shot, but somebody did raise a hard question, and
we'll have to answer it in the next revision."

But that would be a change. In today's IETF, we don't think it's
a feature to significantly update a standards-track RFC, based
on experience at proposed standard (I invite counter-examples -
did people think deprecation of site-local in IPv6 was a model
we want to follow or not?)

Spencer

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Fri, 05 Dec 2003 15:28:07 -0800

> we'll have to answer it in the next revision."

We've done that at times - check the IESG note on LDAPv3 (RFC 2252), and 
the update done with RFC 3377.
For extra credit, look at the time it took between the various parts of 
that solution :-(

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 05 Dec 2003 16:25:57 -0800

At 03:28 PM 12/5/2003, Harald Tveit Alvestrand wrote:
>We've done that at times - check the IESG note on LDAPv3 (RFC 2252), and the update done with RFC 3377.
>For extra credit, look at the time it took between the various parts of that solution :-( 

To be fair, the 2251/2252 solution was published RFC 2829 and 2830...
(but we forgot to formally "update" 2251, hence the need for 3377
to tie everything together).  It still took way too long.  But
we're still living with poor adoption of both RFC 2829/2830
(strong authentication and appropriate security layers) in LDAP.
While LDAPBIS will make it even more clear that strong authentication
is mandatory-to-implement, the damage to LDAP has already been
done.  That is, it unlikely that strong authentication/layers
will ever become the norm in LDAP.

Kurt

---

From: Kireeti Kompella <[email-masked]>
Date: Mon, 8 Dec 2003 13:55:21 -0800 (PST)

> I don't believe it's ever too late to raise new technical

I don't get this.  A Last Call has a time limit.  Can someone raise
new technical issues beyond that?  If so, why have a time limit?  If
not, why should the fact that a second Last Call was needed to resolve
specific issues extend the time limit for general comments?

> But you can use 2418 to hush rehashing of old
> issues...

As a chair of a WG that seems to want Last Call after Last Call,
I'd be interested in a specific quote from 2418.

Kireeti.
-------

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Mon, 8 Dec 2003 14:13:40 -0800

At 1:55 PM -0800 12/8/03, Kireeti Kompella wrote:
>new technical issues beyond that?  If so, why have a time limit?

So that the next step in the process can happen. After the WG last 
call period is over, the chairs send the document to the AD. After 
the IETF last call period is over, the IESG considers the document.

The fact that the document has moved to a next step should not 
preclude someone coming up with a new technical issue. Note the use 
of the term "new".

--Paul Hoffman, Director
--VPN Consortium

---

From: Spencer Dawkins <[email-masked]>
Date: Mon, 8 Dec 2003 14:21:42 -0800 (PST)

> specific issues extend the time limit for general comments?

See, this is the thing. Last Call time limits in 2026 are
minimums, not maximums, and the intention was (apparently) not
to limit discussion, but to prevent submitting an ID on Monday
that's a proposed standard by Thursday.

For instance, 

   The Last-Call period shall be no shorter than 
   two weeks except in those cases where the proposed 
   standards action was not initiated by an IETF 
   Working Group, ...

Maybe we need to talk about this, since "approving RFCs too
quickly" is apparently no longer the biggest problem we have :-}
But that's the procedure today, if I understand things
correctly.

Spencer

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 08 Dec 2003 17:43:45 -0500

Last calls are supposed to be both an opportunity and a warning.  It is an 
explicit opportunity for comments.  It is also a warnign that after the 
close is not a good time for comments.  Obviously, if you find something 
significant after the close you should still say so.  But from the WG 
Chairs point of view, unless it (the late comment) is quite significant the 
chair can justifiably say
     We have the comments
     We have / will address them
     We have / will check that we have addressed them properly
     And then we will give this to the AD
Otherwise, the comment period simply goes on and on and ...
(I have never seen a "perfect" spec, and I never expect to see one.)

Yours,
Joel

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 08 Dec 2003 15:10:17 -0800

>specific issues extend the time limit for general comments?

See Paul and Spencer's comments. They cover these questions
well.

>I'd be interested in a specific quote from 2418.

I think the repeated Last Call synonym is primarily due
to chairs issuing calls on documents before they, the
editor, and (as best the chairs can judge) the WG
believes the document is ready to be advanced.  Chairs
tend to use Last Calls more as an explicit request for
members to now review the document.  It should be
obvious when used in this fashion, that most calls
won't be the Last.

The key to hushing old issues is documenting consensus.
After the WG discusses an issue, post a summary with
a statement of what you believe consensus to be and
what actions you intend to make based upon consensus.
If WG concurs, take the action.  Later, if the someone
raises the old issue and objects to the action taken,
you just say that that issue was previously discussed
(refer them back to summary) and the action taken
supported by WG consensus.  If that doesn't hush the
old issue, then I suggest you ask your AD for guidance.

For a specific quote, see section 3.3 of RFC 2418:
   To facilitate making forward progress, a Working Group Chair may wish
   to decide to reject or defer the input from a member, based upon the
   following criteria:

   Old
   The input pertains to a topic that already has been resolved and is
   redundant with information previously available;

   ...

---

From: Kireeti Kompella <[email-masked]>
Date: Mon, 8 Dec 2003 16:48:24 -0800 (PST)

> obvious when used in this fashion, that most calls

In CCAMP, it is *very* hard to build/get consensus.  So, even if the
document is ready in the mind of the chairs, there is usually someone
who wants a change, a rewording, or something.

> old issue, then I suggest you ask your AD for guidance.

Excellent suggestion!

>    redundant with information previously available;

Thanks, that helps.

Kireeti.
-------