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: ah@xxxxxxxxx |
+------------------------+--------------------------------------------+
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf