Subject: Re: Last Call: draft-ietf-proto-wgdocument-states (Definition of IETF Working Group Document States) to Informational RFC

From: Alfred Hönes <[email-masked]>
Date: Fri, 11 Jun 2010 12:26:10 +0200 (MESZ)

I have reviewed  draft-ietf-proto-wgdocument-states-07
and sent a couple of editorial comments off-list to the author.

IMHO, there remain two major topics to be resolved with this draft:

(A)  regarding automatic transitions

The last paragraph of Section 3.4 says:

:  If a WG Chair or delegate decides not to manually update the WG
:  status of an I-D, the Datatracker may automatically generate two
:  state transitions.  An I-D may be moved into the "WG Document" state
:  automatically if a WG Chair approves the posting of a new version-00
:  I-D that conforms to the 'draft-ietf-wgname-topic-00' file naming
:  convention.  The Datatracker could also move a "WG Document" into
:  the "Submitted to IESG for Publication" state (in the WG document
:  state machine) when the I-D is moved into the "Publication
:  Requested" state in the IESG state machine.

In the first scenario above, it seems reasonable to also move the
*predecessor draft* to the WG state "Adopted by a WG" (for the
adopting WG) automatically, if it is not already in this state.
(cf. Section 3.3.2)

In particular, if the (individual) predecessor draft was subject
to "WG shopping" and the chair(s) of another WG(s) had placed it
into "Candidate WG Document" state for their WG(s), but the chair(s)
of the WG actually adopting the draft had not done so and not placed
the draft in the "Adopted by a WG" state, this all should be cleaned
up automatically in the same manner as described in 3.3.2 for a
transition to "Adopted by a WG" explicitly requested by a chair
of the adopting WG.  Otherwise, misleading state might be left
recorded with the individual draft, and/or even another WG might
adopt it as well, being unaware of the previous adoption.

Therefore, I suggest to amend the above paragraph, for instance:

:  If a WG Chair or delegate decides not to manually update the WG
|  status of an I-D, the Datatracker may automatically generate three
                                                                ^^^^^
:  state transitions.
|  If a WG Chair approves the posting of a new version-00 I-D that
|  conforms to the 'draft-ietf-wgname-topic-00' file naming convention,
|  that I-D may be moved into the "WG Document" state automatically, and
|  if the predecessor individual draft replaced by this draft is known
|  to the Datatracker and not yet in the "Adopted by a WG" state for the
|  WG accepting the new draft as a WG draft, the replaced individual
|  draft should be placed in the latter state.  (The companion
|  "requirements" draft [I-D.juskevicius-datatracker-wgdocstate-reqts]
|  discusses the plausibility controls and consequential actions of this
|  state transition.)
:  The Datatracker could also move a "WG Document" into
:  the "Submitted to IESG for Publication" state (in the WG document
:  state machine) when the I-D is moved into the "Publication
:  Requested" state in the IESG state machine.

(B)  regarding inconsistencies in the behavior of annotation tags

The annotation tags described in Sections 3.5.5 ff. follow the paradigm:

  "Once the condition designated in the name of the tag is fulfilled,
   the tag should be cleared."

Contrary to this, and violating the "principle of least surprise",
the four tags described in Sections 3.5.1 through 3.5.4,
while designated as  "Awaiting XXX Review"
(for XXX in {Cross-Area|MIB Doctor|Security|External}
are explained (in the 2nd para of each description) as follows:

:    Documents tagged with this annotation should retain the tag until
:    the review is complete and possibly until any issues raised in the
:    review are addressed.

Thus, once the XXX review is complete and issues raised therein
are being discussed, confusingly the tag "Awaiting XXX Review"
will persist.
This can be cured by the introduction of four new annotation tags
denoted as "Waiting for Resolution of Issues from XXX Review"
(or similar), but the ensuing overhead might not grant such addition.

Therefore, I suggest to simply change the designation of the four
annotation tags to better account for their description, e.g.:

   "Awaiting XXX Review / Resolution of issues"

The comment log will show then the details.

Note that "resolution of issues" is not the same as "new I-D needed".
The resolution process might well lead to explanations satisfying
the reviewing party without a ne I-D.  But once it is clear that
the resolution will make a new I-D necessary, the WG Chair(s) are
free to clear the original tag and raise the "New I-D Needed" tag.
If they don't, the modified tag names will anyway not mislead the
reader.

Kind regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 11 Jun 2010 11:11:27 -0700

>adopting WG) automatically, if it is not already in this state.

As a WG chair, I heartily disagree. The predecessor versions often have things that were required to be changed before becoming WG docs. Authors are often asked to change things at the same time that they generate the first draft-ietf-wgname-protoname-00 document, and no one should think that the document before that one was "a WG document".

>are being discussed, confusingly the tag "Awaiting XXX Review"

Good catch!

>(or similar), but the ensuing overhead might not grant such addition.

Maybe, but I don't think there is that much overhead.

>The comment log will show then the details.

That works for me as well. That is, you are correct that the current tags do not cover the whole spectrum of what we want, and I don't care if we rename them for double-duty or create a second set of tags for "awaiting resolution".

--Paul Hoffman, Director
--VPN Consortium

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 11 Jun 2010 14:22:09 -0400

On Fri, Jun 11, 2010 at 11:11:27AM -0700, Paul Hoffman wrote:
> 
> docs. Authors are often asked to change things at the same time that
> they generate the first draft-ietf-wgname-protoname-00 document, and
> no one should think that the document before that one was "a WG
> document".

I agree with Paul on this.

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Alfred Hönes <[email-masked]>
Date: Fri, 11 Jun 2010 20:47:54 +0200 (MESZ)

Paul Hoffman responded to my original post:

> At 12:26 PM +0200 6/11/10, Alfred Hönes wrote:
> As a WG chair, I heartily disagree.  The predecessor versions often
> have things that were required to be changed before becoming WG docs.
> Authors are often asked to change things at the same time that they
> generate the first draft-ietf-wgname-protoname-00 document, and no one
> should think that the document before that one was "a WG document".

I would share your heartily disagreement if I had indeed called for
moving the predecessor document to state "WG document".

But that was not intended.  The new WG draft will be "WG document",
the predecessor should go to "Adopted by a WG" / "Replaced by ..." --
that WG state would be held exactly as in the case where the WG chair
declares adoption for his WG, tasks the author(s) to address concerns
of the WG (if any) and re-publish as draft-ietf-wgname-topic-00, and
actively places the individual draft into this new state to terminate
and block further "WG shopping" of the original (individual) I-D;
in that case of a WG chair making full use of the possibilites,
the "Replaced by ..." would be missing initially, but be supplied
as soon as the WG -00 draft is registered in the Datatracker.

Ed is working on a revision of the companion requirements draft,
and so I suggest to defer further discussion of this topic until
it is available and the details it will contain can be looked up.

> Maybe, but I don't think there is that much overhead.

The overhead is on the side of the WG chairs who decide to only make
modest use ot the new capabiliies; to avoid confusion, they would
have to enter another state transition -- ehem, deletion of one tag
and assertion of another one.
If a WG chair wants to document the progress in more detail, he/she
would not see a significant difference; he/she would likely instead
add a comment log entry in this case, if the solution below were
adopted.

> That works for me as well.  That is, you are correct that the current
> tags do not cover the whole spectrum of what we want, and I don't care
> if we rename them for double-duty or create a second set of tags for
> "awaiting resolution".
> 
> --Paul Hoffman, Director
> --VPN Consortium
> 

Kind regards,
  Alfred.