Subject: Update to draft-ietf-proto-wgdocument-states

From: Ed Juskevicius <[email-masked]>
Date: Thu, 11 Mar 2010 16:10:09 -0500

Hello all.

This is to advise that a revised version of the "WG document states" I-D was
submitted last week.

I would appreciate your review and comments on the draft and, if possible,
your participation in the "wgdtspec" BOF (which Russ has arranged for Friday
morning in Anaheim) to further discuss this draft, and a straw man set
of requirements for Datatracker extensions.

If you have any time to critique the draft before Anaheim, I will appreciate
it.  The I-D is at:
  http://www.ietf.org/id/draft-ietf-proto-wgdocument-states-02.txt

Also, what key discussion points should Russ and I prioritize for the
WGDTSPEC BOF?

Best Regards, and Thanks in Advance,

Ed Juskevicius
[email-masked]

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 11 Mar 2010 17:26:23 -0600

At 03:10 PM 3/11/2010, Ed Juskevicius wrote:
>Hello all.
>
>This is to advise that a revised version of the "WG document states" 
>I-D was submitted last week.
>
>I would appreciate your review and comments on the draft and, if 
>possible, your participation in the "wgdtspec" BOF (which Russ has 
>arranged for Friday morning in Anaheim)

Is the an official BoF with a meeting room, or is it a bar-bof (or adhoc)?

i.e., what are the logistics of this?

James

>to further discuss this draft, and a straw man set of requirements 
>for Datatracker extensions.
>
>If you have any time to critique the draft before Anaheim, I will 
>appreciate it.  The I-D is at:
><http://www.ietf.org/id/draft-ietf-proto-wgdocument-states-02.txt>http://www.ietf.org/id/draft-ietf-proto-wgdocument-states-02.txt
>
>Also, what key discussion points should Russ and I prioritize for 
>the WGDTSPEC BOF?
>
><mailto:[email-masked]>[email-masked]

---

From: Ed Juskevicius <[email-masked]>
Date: Thu, 11 Mar 2010 19:32:44 -0500

There actually is going to be an official BOF for this.

FRIDAY, March 26, 2010
0900-1130  Morning Session I
Palos Verdes  GEN  wgdtspec  Review of Datatracker Specifications (to
support...) BOF
AGENDA FOR WGDTSPEC BOF
IETF 77, Anaheim, CA, USA
Review of Datatracker Specifications to Support WG Chars and Authors
(wgdtspec) BOF
*** Draft - please send additions/corrections to BOF Chairs ***

BOF Chairs: Ed Juskevicius <[email-masked]>
            Russ Housley  <[email-masked]>

Jabber Room: tbd

1. Agenda Bashing (5 mins)
2. BOF Scope and Goals (10 mins)
3. Review WG Document States and State Diagram (45 mins)
  3.1. Introduction to definitions for WG Document States
       <draft-ietf-proto-wgdocument-states-02.txt>
  3.2. Walk through of straw man State Diagram
  3.3. Discussion on preferred or "fast track" path of I-Ds through the
state diagram

4. Requirements specification, to extend the Data Tracker for WG Chairs and
Authors (60 mins)
  4.1  Introduction to strawman set of wgdtspec requirements
  4.2  Review of key considerations and assumption (e.g. who needs
         to input what and when to ensure the Data Tracker is always
         in sync with WG progress)
  4.3  Discussion

5. Next steps (10 mins)

6. Any Other Business (10 mins)

Now, having said all of the above, I don't have anything planned for Tuesday
night yet.  If anyone can't make the official BOF on Friday, I am available
for a less formal chat (e.g. Bar BOF) on Tuesday too.

Regards,

Ed Juskevicius
[email-masked]

On Thu, Mar 11, 2010 at 6:26 PM, James M. Polk <[email-masked]> wrote:

>> This is to advise that a revised version of the "WG document states" I-D
>> was submitted last week.
>>
>> morning in Anaheim)
>  to further discuss this draft, and a straw man set of requirements for
>> Datatracker extensions.
>>
>> <http://www.ietf.org/id/draft-ietf-proto-wgdocument-states-02.txt>

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 11 Mar 2010 18:20:56 -0800

First off, this is a great improvement over the previous draft. It is heartening to see this work moving forwards. The state diagram in Figure 1 should be burned into every WG chairs' brain.

- The abstract assumes that after a draft has left a WG for the first time, it never comes back:
   This document contains definitions for the different states that
   documents (viz. Internet-Drafts) may experience while associated
   with an IETF working group.  The first state occurs when an Internet
   Draft (I-D) is submitted for consideration as a working group item.
   The last state is either when the I-D is sent to the IESG for
   publication, or declared as "dead".
The last sentence should say "In most cases, the last state...". But the abstract should also say somewhere that I-Ds sometimes come back to the WG, such as when the IESG wants a major revision.

- In 3.1.1, possibly add "For example, charters sometime list multiple candidate drafts for consideration by a WG".

- "WG Last Call Completed" from 3.1.6 does not seem like a real state, just a decision place after In WG Last Call. That is, WG Last Call completes when the WG Chairs decide which step to take next.

- 3.3.1 through 3.3.4 say that "Awaiting Cross-Area Review", "Awaiting MIB Doctor Review", "Awaiting Security Review", and "Awaiting Other Review"  are only valid for "Active" and "Parked". They are also valid for "In WG Last Call". Those reviews do not need to be done before WG Last Call, but are appropriate to be done in parallel.

- The substate described in 3.3.8, "Held due to IESG concerns on this Document", should never happen in the current IETF process. The description of the state gives a random AD, or even a group of non-random ADs, power over a document that they do not actually have in the current process. They are just WG participants (at most) until IESG review.

- 3.3.9, "Revised I-D Needed - based on WG consensus", and 3.3.10, "Revised I-D Needed - based on WG last call", can probably be merged. They should both apply to the same states, and the difference is not important enough for two substates.

- In general, you should remove any 2119ish language, such as the "SHOULD" in 3.1.6. (I just got justifiably dinged on this by the IESG in a document I have under review.)

--Paul Hoffman, Director
--VPN Consortium

---

From: Ed Juskevicius <[email-masked]>
Date: Thu, 11 Mar 2010 21:35:53 -0500

Paul, thanks for the feedback!  I appreciate all of your suggestions, and am
willing to incorporate most of them into the next revision of the I-D.

I do have a couple of questions back for you, as follows:

> "WG Last Call Completed" from 3.1.6 does not seem like a real state,
> just a decision place after In WG Last Call. That is, WG Last Call
> completes when the WG Chairs decide which step to take next.
I wonder if we have a different assumption for how long a document may exist
after a "WG Last Call Completed" and before its next state is decided.  If
only a day or two, then I'd agree that we may not need a "state" for this.
If, on the other hand, some documents may be out there for many days (or
weeks) after completiong of a WGLC and before its next state is determined,
then maybe we do need a state for this condition.

> The substate described in 3.3.8, "Held due to IESG concerns on
> this Document", should never happen in the current IETF process.
> The description of the state gives a random AD, or even a group of
> non-random ADs, power over a document that they do not actually
> have in the current process. They are just WG participants (at most)
> until IESG review.
I can remember more than one instance where I've been in a WG meeting, and
watched and heard an AD comment on a document, which effectively resulted in
the WG parking the document for a while, in order to address concerns rasied
be the AD.  This being said, I actually was thinking this substate would be
more likely to describe a case where a document has already been sent to the
IESG for publication and/but the IESG has kicked it back to the Working
Group for some reason.

Regards, and Thanks again ...

Ed

On Thu, Mar 11, 2010 at 9:20 PM, Paul Hoffman <[email-masked]> wrote:

> First off, this is a great improvement over the previous draft. It is
> heartening to see this work moving forwards. The state diagram in Figure 1
> should be burned into every WG chairs' brain.
>
> The last sentence should say "In most cases, the last state...". But the
> abstract should also say somewhere that I-Ds sometimes come back to the WG,
> such as when the IESG wants a major revision.
>
> - In 3.1.1, possibly add "For example, charters sometime list multiple
> candidate drafts for consideration by a WG".
>
> - "WG Last Call Completed" from 3.1.6 does not seem like a real state, just
> a decision place after In WG Last Call. That is, WG Last Call completes when
> the WG Chairs decide which step to take next.
>
> - 3.3.1 through 3.3.4 say that "Awaiting Cross-Area Review", "Awaiting MIB
> Doctor Review", "Awaiting Security Review", and "Awaiting Other Review"  are
> only valid for "Active" and "Parked". They are also valid for "In WG Last
> Call". Those reviews do not need to be done before WG Last Call, but are
> appropriate to be done in parallel.
>
> - The substate described in 3.3.8, "Held due to IESG concerns on this
> Document", should never happen in the current IETF process. The description
> of the state gives a random AD, or even a group of non-random ADs, power
> over a document that they do not actually have in the current process. They
> are just WG participants (at most) until IESG review.
>
> - 3.3.9, "Revised I-D Needed - based on WG consensus", and 3.3.10, "Revised
> I-D Needed - based on WG last call", can probably be merged. They should
> both apply to the same states, and the difference is not important enough
> for two substates.
>
> - In general, you should remove any 2119ish language, such as the "SHOULD"
> in 3.1.6. (I just got justifiably dinged on this by the IESG in a document I
> have under review.)
>
>
> --Paul Hoffman, Director
> --VPN Consortium
>

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 11 Mar 2010 18:50:00 -0800

At 9:35 PM -0500 3/11/10, Ed Juskevicius wrote:
>Paul, thanks for the feedback!  I appreciate all of your suggestions, and am willing to incorporate most of them into the next revision of the I-D.
> 
>I wonder if we have a different assumption for how long a document may exist after a "WG Last Call Completed" and before its next state is decided.  If only a day or two, then I'd agree that we may not need a "state" for this.  If, on the other hand, some documents may be out there for many days (or weeks) after completiong of a WGLC and before its next state is determined, then maybe we do need a state for this condition.

Even if the WG chairs have declared WG LC over but nothing happens for a few weeks (not that that would ever happen in my WGs, of course...), I believe the state is still "In WG Last Call". There is nothing to prevent a somnolent WG member from commenting, and their comments would need to be treated the same as the folks who spoke up earlier. By creating another state, it appears to cut off discussion when discussion is still valid.

> > have in the current process. They are just WG participants (at most)

(I *knew* you were gonna like that one...)

>I can remember more than one instance where I've been in a WG meeting, and watched and heard an AD comment on a document, which effectively resulted in the WG parking the document for a while, in order to address concerns rasied be the AD. 

If that was the intended response, then the substate should instead be called "Parked Due To AD Who Misunderstands RFC 2026". It is a state that should not be instantiated in an IETF tool unless RFC 2026 is updated to allow it, but that would involve many dead bodies.

>This being said, I actually was thinking this substate would be more likely to describe a case where a document has already been sent to the IESG for publication and/but the IESG has kicked it back to the Working Group for some reason.

That's a fine and common substate, but it should be called something quite different, such as "Returned to WG". It is *not* being "held", the concerns are being acted on in some way.

--Paul Hoffman, Director
--VPN Consortium

---

From: Ray Pelletier <[email-masked]>
Date: Fri, 12 Mar 2010 00:45:04 -0500

On Mar 11, 2010, at 9:50 PM, Paul Hoffman wrote:

>> Paul, thanks for the feedback!  I appreciate all of your  
>> suggestions, and am willing to incorporate most of them into the  
>> next revision of the I-D.
>>
>> I wonder if we have a different assumption for how long a document  
>> may exist after a "WG Last Call Completed" and before its next  
>> state is decided.  If only a day or two, then I'd agree that we may  
>> not need a "state" for this.  If, on the other hand, some documents  
>> may be out there for many days (or weeks) after completiong of a  
>> WGLC and before its next state is determined, then maybe we do need  
>> a state for this condition.
>
> Even if the WG chairs have declared WG LC over but nothing happens  
> for a few weeks (not that that would ever happen in my WGs, of  
> course...), I believe the state is still "In WG Last Call". There is  
> nothing to prevent a somnolent WG member from commenting, and their  
> comments would need to be treated the same as the folks who spoke up  
> earlier. By creating another state, it appears to cut off discussion  
> when discussion is still valid.

When the WG Chair declares WG LC Over, "WG Last Call" is over and the  
document enters another state, which could be "Awaiting WG Chair  
Action", shifting the burden of action and attention where it belongs  
- the next steps, not more comments.  Rip Van Winkle, the somnolent WG  
member, can make his case for considering his comments.

Ray

>> I can remember more than one instance where I've been in a WG  
>> meeting, and watched and heard an AD comment on a document, which  
>> effectively resulted in the WG parking the document for a while, in  
>> order to address concerns rasied be the AD.
>
> If that was the intended response, then the substate should instead  
> be called "Parked Due To AD Who Misunderstands RFC 2026". It is a  
> state that should not be instantiated in an IETF tool unless RFC  
> 2026 is updated to allow it, but that would involve many dead bodies.
>
>> This being said, I actually was thinking this substate would be  
>> more likely to describe a case where a document has already been  
>> sent to the IESG for publication and/but the IESG has kicked it  
>> back to the Working Group for some reason.
>
> That's a fine and common substate, but it should be called something  
> quite different, such as "Returned to WG". It is *not* being "held",  
> the concerns are being acted on in some way.
>
> --Paul Hoffman, Director
> --VPN Consortium

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Fri, 12 Mar 2010 11:45:44 +0100

> >I wonder if we have a different assumption for how long a 
> document may exist after a "WG Last Call Completed" and 
> before its next state is decided.  If only a day or two, then 
> I'd agree that we may not need a "state" for this.  If, on 
> the other hand, some documents may be out there for many days 
> (or weeks) after completiong of a WGLC and before its next 
> state is determined, then maybe we do need a state for this condition.
> 
> Even if the WG chairs have declared WG LC over but nothing 
> happens for a few weeks (not that that would ever happen in 
> my WGs, of course...), I believe the state is still "In WG 
> Last Call". There is nothing to prevent a somnolent WG member 
> from commenting, and their comments would need to be treated 
> the same as the folks who spoke up earlier. By creating 
> another state, it appears to cut off discussion when 
> discussion is still valid.

I concur with Paul here.

Keith 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Paul Hoffman
> Sent: Friday, March 12, 2010 2:50 AM
> To: Ed Juskevicius
> Cc: [email-masked]
> Subject: Re: Update to draft-ietf-proto-wgdocument-states
> 
> suggestions, and am willing to incorporate most of them into 
> the next revision of the I-D.
> > 
> >I wonder if we have a different assumption for how long a 
> document may exist after a "WG Last Call Completed" and 
> before its next state is decided.  If only a day or two, then 
> I'd agree that we may not need a "state" for this.  If, on 
> the other hand, some documents may be out there for many days 
> (or weeks) after completiong of a WGLC and before its next 
> state is determined, then maybe we do need a state for this condition.
> 
> Even if the WG chairs have declared WG LC over but nothing 
> happens for a few weeks (not that that would ever happen in 
> my WGs, of course...), I believe the state is still "In WG 
> Last Call". There is nothing to prevent a somnolent WG member 
> from commenting, and their comments would need to be treated 
> the same as the folks who spoke up earlier. By creating 
> another state, it appears to cut off discussion when 
> discussion is still valid.
> 
> > > The substate described in 3.3.8, "Held due to IESG 
> concerns on this 
> > > Document", should never happen in the current IETF process.
> > > non-random ADs, power over a document that they do not 
> actually have 
> > > in the current process. They are just WG participants (at most) 
> > > until IESG review.
> 
> >I can remember more than one instance where I've been in a 
> WG meeting, and watched and heard an AD comment on a 
> document, which effectively resulted in the WG parking the 
> document for a while, in order to address concerns rasied be the AD. 
> 
> If that was the intended response, then the substate should 
> instead be called "Parked Due To AD Who Misunderstands RFC 
> 2026". It is a state that should not be instantiated in an 
> IETF tool unless RFC 2026 is updated to allow it, but that 
> would involve many dead bodies.
> 
> >This being said, I actually was thinking this substate would 
> be more likely to describe a case where a document has 
> already been sent to the IESG for publication and/but the 
> IESG has kicked it back to the Working Group for some reason.
> 
> That's a fine and common substate, but it should be called 
> something quite different, such as "Returned to WG". It is 
> *not* being "held", the concerns are being acted on in some way.
> 
> --Paul Hoffman, Director
> --VPN Consortium
>

---

From: "Spencer Dawkins" <[email-masked]>
Date: Fri, 12 Mar 2010 07:36:21 -0600

Just a couple of comments in this thread...

>>I wonder if we have a different assumption for how long a document may 
>>exist after a "WG Last Call Completed" and before its next state is 
>>decided.  If only a day or two, then I'd agree that we may not need a 
>>"state" for this.  If, on the other hand, some documents may be out there 
>>for many days (or weeks) after completiong of a WGLC and before its next 
> Even if the WG chairs have declared WG LC over but nothing happens for a 
> few weeks (not that that would ever happen in my WGs, of course...), I 
> believe the state is still "In WG Last Call". There is nothing to prevent 
> a somnolent WG member from commenting, and their comments would need to be 
> treated the same as the folks who spoke up earlier. By creating another 
> state, it appears to cut off discussion when discussion is still valid.

The point here seems to be "is there any difference between comments 
received in the working group during a (for example) two-week WGLC period 
and comments received after WGLC ends, but before any action is taken with 
the document after WGLC?"

In working groups I'm familiar with, there is not. What I see is that we 
tend to use the WGLC interval as a minimum, and if screaming continues after 
the original date, we act as if WGLC was still underway, until the screaming 
dies down.

I don't know what the current WG chair training says about it, but for more 
than a decade I know we emphasized the point that technical concerns with a 
document were never ignored because "last call" (whether IETF Last Call or 
WGLC) had closed.

If we have the additional state, we could theoretically tell the difference 
between a WGLC discussion continuing on (because the chair does not change 
the state to "WGLC ended") and a WG chair taking a nap, but that relies on 
the WG chair changing the state and then taking a nap :D

For the working groups I'm familiar with, this isn't a meaningful 
distinction.

>>watched and heard an AD comment on a document, which effectively resulted 
>>in the WG parking the document for a while, in order to address concerns 
>>rasied be the AD.
>
> If that was the intended response, then the substate should instead be 
> called "Parked Due To AD Who Misunderstands RFC 2026". It is a state that 
> should not be instantiated in an IETF tool unless RFC 2026 is updated to 
> allow it, but that would involve many dead bodies.

I'm not saying that Paul IS right here, bbut I'm saying that Paul's first 
comment SHOULD be right - the state is really "someone participating in the 
working group as an individual said something that made us all go 'woah'".

This should have nothing to do with the person raising the concern being an 
AD. At least as I read 2026 (and for what that's worth, the IESG DISCUSS 
criteria/non-criteria document). A technical comment has been raised, and 
the working group needs to respond to that comment.

>>This being said, I actually was thinking this substate would be more 
>>likely to describe a case where a document has already been sent to the 
> That's a fine and common substate, but it should be called something quite 
> different, such as "Returned to WG". It is *not* being "held", the 
> concerns are being acted on in some way.

Thanks,

Spencer

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 12 Mar 2010 10:15:28 -0500

WHen an IETF wide LC is ended, the document moves from IETF-LC to 
another state (typically AD-action or shepherd action needed as I recall.)
Of course, that does not stop someone from posting a comment about the 
document on the IETF last.
And, if the comment is actually well taken, the AD / shepherd should 
take note of the comment even though it is although it is late. 
However, since it is late, it might not affect the outcome, and the 
obligation of response is much lower.

Similarly, when WG Last call completes, the document state changes.  It 
is now pending chair action.  Again, if it take sthe chair time to 
complete the action, and a useful commend comes in late, if possible it 
should be considered.  But that does not mean that the document is still 
in WG Last Call.  Rather it is on the chair's queue, and he is supposed 
to be doing something.  The state tells us who is expected to do what 
with the document.  In WG Last Call means that everything is fine, and 
the action needed is time passage.

Yours,
Joel

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 12 Mar 2010 07:18:18 -0800

At 12:45 AM -0500 3/12/10, Ray Pelletier wrote:
>When the WG Chair declares WG LC Over, "WG Last Call" is over and the document enters another state, which could be "Awaiting WG Chair Action", shifting the burden of action and attention where it belongs - the next steps, not more comments.  Rip Van Winkle, the somnolent WG member, can make his case for considering his comments.

Some WG chairs act this way, but doing so works against the spirit of consensus we are supposed to be fostering. Unless I am missing something, I also don't think your view is supported by the IETF process RFCs; if I'm wrong, by all means let this list know.

--Paul Hoffman, Director
--VPN Consortium

---

From: Ray Pelletier <[email-masked]>
Date: Fri, 12 Mar 2010 10:37:00 -0500

On Mar 12, 2010, at 10:15 AM, Joel M. Halpern wrote:

> Of course, that does not stop someone from posting a comment about  
> the document on the IETF last.
> Similarly, when WG Last call completes, the document state changes.   
> It is now pending chair action.  Again, if it take sthe chair time  
> to complete the action, and a useful commend comes in late, if  
> possible it should be considered.  But that does not mean that the  
> document is still in WG Last Call.  Rather it is on the chair's  
> queue, and he is supposed to be doing something.  The state tells us  
> who is expected to do what with the document.  In WG Last Call means  
> that everything is fine, and the action needed is time passage.

+1

Ray

>>> document may exist after a "WG Last Call Completed" and before its  
>>> next state is decided.  If only a day or two, then I'd agree that  
>>> we may not need a "state" for this.  If, on the other hand, some  
>>> documents may be out there for many days (or weeks) after  
>>> completiong of a WGLC and before its next state is determined,  
>>> course...), I believe the state is still "In WG Last Call". There  
>>> is nothing to prevent a somnolent WG member from commenting, and  
>>> their comments would need to be treated the same as the folks who  
>>> spoke up earlier. By creating another state, it appears to cut off  
>>> discussion when discussion is still valid.
>> I concur with Paul here.
>> Keith
>>> From: [email-masked] [mailto:[email-masked]]  
>>> On Behalf Of Paul Hoffman
>>> document may exist after a "WG Last Call Completed" and before its  
>>> next state is decided.  If only a day or two, then I'd agree that  
>>> we may not need a "state" for this.  If, on the other hand, some  
>>> documents may be out there for many days (or weeks) after  
>>> completiong of a WGLC and before its next state is determined,  
>>> course...), I believe the state is still "In WG Last Call". There  
>>> is nothing to prevent a somnolent WG member from commenting, and  
>>> their comments would need to be treated the same as the folks who  
>>> spoke up earlier. By creating another state, it appears to cut off  
>>> discussion when discussion is still valid.
>>>
>>> WG meeting, and watched and heard an AD comment on a document,  
>>> which effectively resulted in the WG parking the document for a  
>>> while, in order to address concerns rasied be the AD.
>>> instead be called "Parked Due To AD Who Misunderstands RFC 2026".  
>>> It is a state that should not be instantiated in an IETF tool  
>>> unless RFC 2026 is updated to allow it, but that would involve  
>>> many dead bodies.
>>>
>>> be more likely to describe a case where a document has already  
>>> been sent to the IESG for publication and/but the IESG has kicked  
>>> it back to the Working Group for some reason.
>>>
>>> something quite different, such as "Returned to WG". It is *not*  
>>> being "held", the concerns are being acted on in some way.
>>>
>>> --Paul Hoffman, Director
>>> --VPN Consortium
>>>

---

From: Ed Juskevicius <[email-masked]>
Date: Fri, 12 Mar 2010 10:38:47 -0500

Paul Hoffman wrote:

> That makes good sense from a mechanistic view, but is it supported in the
> IETF process documents? The only place I think we have guidance on WG Last
> Calls is RFC 2418, section 7.4, which says nothing about fixed times of
> ending last calls. In fact, all it really says is "The decision to issue a
> working group Last-Call is at the discretion of the WG Chair working with
> the Area Director."
>
> So this raises a point I may have overlooked.  According to RFC 2418,
working group last calls are optional.  My state diagram does not allow the
freedom (at the moment) for a document to avoid at least one WGLC before
being sent to the IESG for publication.

Should I update the diagram?

Thanks,

Ed  Juskevicius

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 12 Mar 2010 07:24:38 -0800

At 10:15 AM -0500 3/12/10, Joel M. Halpern wrote:
>WHen an IETF wide LC is ended, the document moves from IETF-LC to another state (typically AD-action or shepherd action needed as I recall.)
>Of course, that does not stop someone from posting a comment about the document on the IETF last.
>And, if the comment is actually well taken, the AD / shepherd should take note of the comment even though it is although it is late. However, since it is late, it might not affect the outcome, and the obligation of response is much lower.
>
>Similarly, when WG Last call completes, the document state changes.  It is now pending chair action.  Again, if it take sthe chair time to complete the action, and a useful commend comes in late, if possible it should be considered.  But that does not mean that the document is still in WG Last Call.  Rather it is on the chair's queue, and he is supposed to be doing something.  The state tells us who is expected to do what with the document.  In WG Last Call means that everything is fine, and the action needed is time passage.

That makes good sense from a mechanistic view, but is it supported in the IETF process documents? The only place I think we have guidance on WG Last Calls is RFC 2418, section 7.4, which says nothing about fixed times of ending last calls. In fact, all it really says is "The decision to issue a working group Last-Call is at the discretion of the WG Chair working with the Area Director."

What is the value of a state that says "sitting in the WG Chair's queue but no one can else can do anything about it", other than to embarrass the chair?

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 12 Mar 2010 07:50:54 -0800

At 10:38 AM -0500 3/12/10, Ed Juskevicius wrote:
>So this raises a point I may have overlooked.  According to RFC 2418, working group last calls are optional.  My state diagram does not allow the freedom (at the moment) for a document to avoid at least one WGLC before being sent to the IESG for publication.
> 

That would be easier than updating RFC 2418, yes. :-)

--Paul Hoffman, Director
--VPN Consortium

---

From: Russ Housley <[email-masked]>
Date: Fri, 12 Mar 2010 11:22:44 -0500

WG Last Call should be optional.

On 3/12/2010 10:38 AM, Ed Juskevicius wrote:
> Paul Hoffman wrote:
> 
>  
> 
>     That makes good sense from a mechanistic view, but is it supported
>     in the IETF process documents? The only place I think we have
>     guidance on WG Last Calls is RFC 2418, section 7.4, which says
>     nothing about fixed times of ending last calls. In fact, all it
>     really says is "The decision to issue a working group Last-Call is
>     at the discretion of the WG Chair working with the Area Director."
> 
> working group last calls are optional.  My state diagram does not allow
> the freedom (at the moment) for a document to avoid at least one WGLC
> before being sent to the IESG for publication.
>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Fri, 12 Mar 2010 17:46:13 +0100

To me the document in this state is still in WGLC.

If it is believed there is an action on the WG chair to send the document into "Waiting for WG Document Shepherd Write-Up" that needs some form of state associated with it, then I suspect this should be a substate of WGLC, in the same way as "Revised I-D needed" is a substate.

regards

Keith

> From: Paul Hoffman [mailto:[email-masked]] 
> Sent: Friday, March 12, 2010 3:25 PM
> To: Joel M. Halpern; DRAGE, Keith (Keith)
> Cc: Ed Juskevicius; [email-masked]
> >another state (typically AD-action or shepherd action needed 
> as I recall.) Of course, that does not stop someone from 
> posting a comment about the document on the IETF last.
> >And, if the comment is actually well taken, the AD / 
> shepherd should take note of the comment even though it is 
> although it is late. However, since it is late, it might not 
> affect the outcome, and the obligation of response is much lower.
> >
> >Similarly, when WG Last call completes, the document state 
> changes.  It is now pending chair action.  Again, if it take 
> sthe chair time to complete the action, and a useful commend 
> comes in late, if possible it should be considered.  But that 
> does not mean that the document is still in WG Last Call.  
> Rather it is on the chair's queue, and he is supposed to be 
> doing something.  The state tells us who is expected to do 
> what with the document.  In WG Last Call means that 
> everything is fine, and the action needed is time passage.
> 
> That makes good sense from a mechanistic view, but is it 
> supported in the IETF process documents? The only place I 
> think we have guidance on WG Last Calls is RFC 2418, section 
> 7.4, which says nothing about fixed times of ending last 
> calls. In fact, all it really says is "The decision to issue 
> a working group Last-Call is at the discretion of the WG 
> Chair working with the Area Director."
> 
> What is the value of a state that says "sitting in the WG 
> Chair's queue but no one can else can do anything about it", 
> other than to embarrass the chair?
> 
> --Paul Hoffman, Director
> --VPN Consortium
>

---

From: Russ Housley <[email-masked]>
Date: Fri, 12 Mar 2010 12:24:10 -0500

A write-up is needed, even if there is no WG Last Call, for the
publication request to be forwarded to the IESG.

Russ

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Fri, 12 Mar 2010 19:11:14 +0100

So lets be clear, I am not disputing that there is a "Waiting for WG Document Shepherd Write-Up" state.

It is the preceding state "WG Last Call Completed" which I do not think exists, but rather there is a substate of "In WGLC which is "Waiting on chair action" (chair holding token) rather than "Revised I-D Needed - based on WG last call" (editor holding token) or no substate at all (members of the working group holding the token).

regards

Keith

> From: Russ Housley [mailto:[email-masked]] 
> Sent: Friday, March 12, 2010 5:24 PM
> To: DRAGE, Keith (Keith)
> Cc: [email-masked]
> A write-up is needed, even if there is no WG Last Call, for 
> the publication request to be forwarded to the IESG.
> 
> Russ
> 
> > If it is believed there is an action on the WG chair to 
> send the document into "Waiting for WG Document Shepherd 
> Write-Up" that needs some form of state associated with it, 
> then I suspect this should be a substate of WGLC, in the same 
> way as "Revised I-D needed" is a substate.
> > 
> > regards
> > 
> > Keith
> > 
> >> as I recall.) Of course, that does not stop someone from posting a 
> >> comment about the document on the IETF last.
> although 
> >> it is late. However, since it is late, it might not affect the 
> >> outcome, and the obligation of response is much lower.
> >>>
> >> changes.  It is now pending chair action.  Again, if it take sthe 
> >> chair time to complete the action, and a useful commend comes in 
> >> late, if possible it should be considered.  But that does not mean 
> >> that the document is still in WG Last Call.
> >> Rather it is on the chair's queue, and he is supposed to be doing 
> >> something.  The state tells us who is expected to do what with the 
> >> document.  In WG Last Call means that everything is fine, and the 
> >> action needed is time passage.
> >>
> supported in 
> >> the IETF process documents? The only place I think we have 
> guidance 
> >> on WG Last Calls is RFC 2418, section 7.4, which says 
> nothing about 
> >> fixed times of ending last calls. In fact, all it really 
> says is "The 
> >> decision to issue a working group Last-Call is at the 
> discretion of 
> >> the WG Chair working with the Area Director."
> >>
> >> What is the value of a state that says "sitting in the WG Chair's 
> >> queue but no one can else can do anything about it", other than to 
> >> embarrass the chair?
> >>
> >> --Paul Hoffman, Director
> >> --VPN Consortium
> >>
>

---

From: Russ Housley <[email-masked]>
Date: Fri, 12 Mar 2010 13:18:25 -0500

This works for me.  The IESG state machine is similar, after IETF Last
Call, the document moves to either

   - Waiting for Writeup

or

   - Waiting for AD Go-Ahead

Something parallel seems appropriate.

Russ

---

From: Ed Juskevicius <[email-masked]>
Date: Fri, 12 Mar 2010 13:33:07 -0500

So in the case of an I-D that does not go undergo a formal WGLC (i.e.
bypasses the optional step), do we want a substate associated with an
"Active WG Document" to indicate it is waiting for writeup, before being
sent for publication, or should that be a main State of its own?

Regards,

Ed

On Fri, Mar 12, 2010 at 1:18 PM, Russ Housley <[email-masked]> wrote:

> > It is the preceding state "WG Last Call Completed" which I do not think
> exists, but rather there is a substate of "In WGLC which is "Waiting on
> chair action" (chair holding token) rather than "Revised I-D Needed - based
> on WG last call" (editor holding token) or no substate at all (members of
> the working group holding the token).
> >
> > regards
> >
> > Keith
> >
> >
> >

---

From: Ed Juskevicius <[email-masked]>
Date: Fri, 12 Mar 2010 13:35:26 -0500

Sorry, ignore that last message (below) please.

On Fri, Mar 12, 2010 at 1:33 PM, Ed Juskevicius <[email-masked]> wrote:

>   On Fri, Mar 12, 2010 at 1:18 PM, Russ Housley <[email-masked]>wrote:
>

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 12 Mar 2010 10:47:41 -0800

>Sorry, ignore that last message (below) please.

Yes, editing state machines and non-actionable attributes based on email responses is difficult. :-)

Having said that, for our BoF in two weeks to be effective, it would be nice if someone who can both edit state diagrams and can produce large-formatted text is the one whose laptop is connected to the projector. It would be lovely *not* to replay the all-too-common "how do I increase the font on this Internet Draft we are editing while the whole room watches".

--Paul Hoffman, Director
--VPN Consortium

---

From: Russ Housley <[email-masked]>
Date: Fri, 12 Mar 2010 16:43:20 -0500

The state name should probably indicate that the WG chair has declared
WG consensus.

Russ

On 3/12/2010 1:33 PM, Ed Juskevicius wrote:
> On Fri, Mar 12, 2010 at 1:18 PM, Russ Housley <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     > It is the preceding state "WG Last Call Completed" which I do not
>     think exists, but rather there is a substate of "In WGLC which is
>     "Waiting on chair action" (chair holding token) rather than "Revised
>     I-D Needed - based on WG last call" (editor holding token) or no
>     substate at all (members of the working group holding the token).
>     >
>     > regards
>     >
>     > Keith
>     >
>     >
>     >
>     >> From: Russ Housley [mailto:[email-masked]
>     <mailto:[email-masked]>]
>     >> Cc: [email-masked] <mailto:[email-masked]>
>     >>>> From: Paul Hoffman [mailto:[email-masked]
>     <mailto:[email-masked]>]
>     >>>> Cc: Ed Juskevicius; [email-masked] <mailto:[email-masked]>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Sat, 13 Mar 2010 02:11:05 +0100

This generates a few more comments.

1)	I was trying to work out the substates of "Active WG document", and was wondering why they were not the same as "In WG Last Call". To me the substates indicate who has the token, and the same three actors (editor, WG and chair) figure in both states. In particular "Revised I-D Needed - based on WG consensus" and "Revised I-D Needed - based on WG last call" seem to me to be the same substate. Both are giving the token to the editor, and all changes on a WG document (in last call or not), must be based on WG consensus. 

2)	Surely the output state of "Active WG document" where a WGLC is not held is "Waiting for WG Document Shepherd Write-Up", the same as that for "In WG Last Call". If the chair has the token thinking about next state, then it is substate of "Active WG document".

3)	How does the "In WG Call" state get played? I was always of the understanding that in general, once a document was in WGLC it stayed there. Any "2nd" WGLC was merely an extension of the original WGLC. Do we stay in the WGLC state (apart from exceptional circumstances) or do we keep shuttling back between In WGLC and Active WG Document states. Personally I prefer the former rather than the latter. The fact the 1st WGLC has been made is an indication of stability that should be preserved by a state.

regards

Keith

> Sent: Friday, March 12, 2010 9:43 PM
> To: Ed Juskevicius
> Cc: DRAGE, Keith (Keith); [email-masked]
> The state name should probably indicate that the WG chair has 
> declared WG consensus.
> 
> Russ
> 
> > "Active WG Document" to indicate it is waiting for writeup, before 
> > being sent for publication, or should that be a main State 
> of its own?
> >  
> > Regards,
> >  
> > Ed
> > 
> >     > So lets be clear, I am not disputing that there is a 
> "Waiting for
> >     WG Document Shepherd Write-Up" state.
> >     >
> <mailto:[email-masked]>

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Sat, 13 Mar 2010 03:10:35 -0500

--On Saturday, March 13, 2010 02:11:05 AM +0100 "DRAGE, Keith (Keith)" 
<[email-masked]> wrote:

> 3)	How does the "In WG Call" state get played? I was always of the
> understanding that in general, once a document was in WGLC it stayed
> there. Any "2nd" WGLC was merely an extension of the original WGLC. Do we
> stay in the WGLC state (apart from exceptional circumstances) or do we
> keep shuttling back between In WGLC and Active WG Document states.
> Personally I prefer the former rather than the latter. The fact the 1st
> WGLC has been made is an indication of stability that should be preserved
> by a state.

Sometimes the WGLC does not succeed, and the document requires more work. 
Or, new information may become available or a significant issue may be 
raised which causes the WG to reconsider.  Thus, there is a difference 
between a document which has passed WGLC and then changed sufficiently that 
another WGLC was triggered, as opposed to one which went back to being an 
active document.

-- Jeffrey T. Hutzelman (N3NHS) <[email-masked]>
   Carnegie Mellon University - Pittsburgh, PA

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 13 Mar 2010 08:43:29 -0800

The recent thread, and the draft that led to it, has caused people to make up states and substates of the WG process that match their desires for how WGs should move documents to the IESG. Most of the statements on the thread, including some of mine, are unsupported by the IETF process RFCs.

There are no rules for WG Last Calls, nor is there a requirement that such a Last Call happen.

There are no rules for when during the WG process one waits for input from experts outside the WG, given that there is no definition for who is "inside" and who is "outside" the WG.

Ed's document is meant as input to someone adding state information to a draft-tracking tool. However, those states don't formally exist. The tool should have information about states that commonly exist in individual WGs based on the preferences of the WG chairs, but it should not make it seem like all WGs have the same states and the same rules.

--Paul Hoffman, Director
--VPN Consortium

---

From: Al Morton <[email-masked]>
Date: Sat, 13 Mar 2010 12:03:43 -0500

At 11:43 AM 3/13/2010, Paul Hoffman wrote:
>Ed's document is meant as input to someone adding state information 
>to a draft-tracking tool. However, those states don't formally 
>exist. The tool should have information about states that commonly 
>exist in individual WGs based on the preferences of the WG chairs, 
>but it should not make it seem like all WGs have the same states and 
>the same rules.

+1, how to make the last point clear is worth thinking more about, IMO.
that's what I plan to do,
Al

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 13 Mar 2010 17:05:38 +0000

>Ed's document is meant as input to someone adding state information to a draft-tracking tool. However, those states don't formally exist. The tool should have information about states that commonly…
+1.

---

From: Russ Housley <[email-masked]>
Date: Sun, 14 Mar 2010 12:31:04 -0400

The process documents allow a lot of flexibility.  We want the tools to
support what people actually do.  This may mean that there are states
that are used by some groups and not others.  That seems fine to me.

GOAL: Provide assistance

NON-GOAL: Force every WG to do it the same way

Russ

---

From: <[email-masked]>
Date: Mon, 15 Mar 2010 14:26:48 +0100

Paul Hoffman wrote:

> What is the value of a state that says "sitting in the WG Chair's queue
> but no one can else can do anything about it", other than to embarrass
> the chair?

I think an important aspect of adding these WG document states is
improving visibility into the process: what is supposed to happen
next, and who is supposed to do it.

So I'd support having a state that comes automatically after the "In
WG Last Call" timer expires: this signals that the WG chair has the
token for doing something (where "something" may depend a lot on the
situation, of course).

But I don't view this as "embarrassing the chair"; it's just a
reminder that others are now expecting him/her to take some action.

(In my experience, one of the biggest reasons why some documents take
very long in IETF is that there are long time periods when it's not
totally clear who is holding the token -- or even what the small
concrete next step is...)

Best regards,
Pasi

---

From: <[email-masked]>
Date: Mon, 15 Mar 2010 20:26:46 -0400

+1

After a spirited WG Last Call, the next step for a draft is not always obvious and the wise WG chair may wish to take some time to think and consult with authors, WG members, ADs, etc. about the appropriate next step.  For example, if one WG member is raising strident objections with which the author does not agree, it's not always obvious what the mix is between that person being right (saw something that everyone else missed) and/or being on the "rough" end of "rough consensus" (WG understands the concerns and has decided to do something else).  It'd be ok to have this parallel the IESG state, e.g., "Waiting for WG Chair Go-Ahead".

> It is the preceding state "WG Last Call Completed" which I do not think exists,
> but rather there is a substate of "In WGLC which is "Waiting on chair action"
> (chair holding token) rather than "Revised I-D Needed - based on WG last call"
> (editor holding token) or no substate at all (members of the working group
> holding the token).

I disagree.  I always announce WG Last Calls with a completion date (as no deadline often results in no action).  When that date has passed, the WGLC is completed and the document is no longer in WGLC.  
Particularly for the "Revised I-D Needed" substate, I think that there needs to be a state other than "In WG Last Call" in order to give authors some assurance that the next version of the draft will move forward.  The sequence of states I'm comfortable using for a successful WG LC is:
	- In WG Last Call
	- WG Last Call Completed: Revised I-D Needed
		(or Waiting for WG Chair Go-Ahead: Revised I-D Needed)
	- Waiting for Doc Shepherd Writeup

I agree with Keith and Paul that a single "Revised I-D Needed" substate suffices - someone who cares about how/why a revision became necessary can look at the log of draft state changes.

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

---

From: "David Harrington" <[email-masked]>
Date: Tue, 16 Mar 2010 10:32:21 -0400

+1

dbh 

> [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Monday, March 15, 2010 8:27 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: Update to draft-ietf-proto-wgdocument-states
> 
> Chair's queue
> After a spirited WG Last Call, the next step for a draft is 
> not always obvious and the wise WG chair may wish to take 
> some time to think and consult with authors, WG members, ADs, 
> etc. about the appropriate next step.  For example, if one WG 
> member is raising strident objections with which the author 
> does not agree, it's not always obvious what the mix is 
> between that person being right (saw something that everyone 
> else missed) and/or being on the "rough" end of "rough 
> consensus" (WG understands the concerns and has decided to do 
> something else).  It'd be ok to have this parallel the IESG 
> state, e.g., "Waiting for WG Chair Go-Ahead".
> 
> I disagree.  I always announce WG Last Calls with a 
> completion date (as no deadline often results in no action).  
> When that date has passed, the WGLC is completed and the 
> document is no longer in WGLC.  
> Particularly for the "Revised I-D Needed" substate, I think 
> that there needs to be a state other than "In WG Last Call" 
> in order to give authors some assurance that the next version 
> of the draft will move forward.  The sequence of states I'm 
> comfortable using for a successful WG LC is:
> 	- In WG Last Call
> I agree with Keith and Paul that a single "Revised I-D 
> Needed" substate suffices - someone who cares about how/why a 
> revision became necessary can look at the log of draft state
changes.