At 12:26 PM +0200 6/11/10, Alfred =?hp-roman8?B?SM5uZXM=?= 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".
>(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.
>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
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf