Paul Hoffman responded to my original post:
> At 12:26 PM +0200 6/11/10, Alfred Hönes wrote:
>> 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)
>
> 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.
>
>> (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.
>
> Good catch!
>
>> 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.
>
> 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.
>> 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.
>
> 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.
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf