[Tools-discuss] Re: I-D ACTION:draft-ietf-tools-draft-info-03.txt

[Brian E Carpenter <brc at zurich.ibm.com>]

Hadn't had a chance to look at the earlier drafts, so these are basic comments.

> 3.  Scope
...
>    The interfaces required to locate a draft or correlate information
>    about multiple drafts are out of scope.

That's a problem, because is this very fundamental to draft tracking.
I believe these three items must be in scope:

Replaces: <draft identifier>
Replaced by: <draft identifier>
Grouped with: <draft identifier>

All of these are currently supported by the I-D tracker.

> 6.2.1.  Status
> 6.5.  Draft events

I don't see the point of separating these. I think it's
necessary and sufficient that each status/state is timestamped
with entry/exit timestamps (and BTW, a draft can enter the same
state many times, so you could have

AD Follow-up:
in:  2005-10-25 21:50
out: 2005-10-26 00:51
in:  2005-10-26 21:52
out: 2005-11-14 21:53
in:  2005-11-17 00:49

for a draft currently in state AD Follow-up

Also in

> 6.2.1.  Status
...
>    An active or expired draft can be in one or more states related to
>    IESG review activity.  These states are not documented here, but
>    implementations must provide this information using the current state
>    list and state definitions maintained by IESG.

States can have sub-states, so the model needs to be recursive.

Not only the IESG generates states, so the framework should allow
for states generated by the Author(s), Editor(s), WG Chair(s),
WG Secretary, PROTO Shepherd, IESG Shepherd, Secretariat, RFC Editor,
and IANA. These can't all be defined in advance but must be possible
to add.

Incidentally, all of the above actors may need to be associated with
the draft, so the framework needs to allow for that too.

<actor role="author" email="rousskov at measurement-factory.com">Alex Rousskov</actor>

> Appendix A.  Comparison with current procedures
...
>    o  Currently, IETF provides only the latest draft version.  This
>       document requires providing all unexpired versions.  This change
>       allows to maintain a change history useful for draft review and
>       discussion.  The change does not seem to contradict written IETF
>       rules and principles.

Actually that depends on how you choose to read the text of RFC 2026
section 2.2. Also, a meaningful history needs access to expired drafts.
RFC 2026 requires us to remove expired drafts, so that *is* a rule.
Some draft authors really care about this and in some cases have forced
all the unofficial archives to remove superseded drafts. It's rare, but
it can happen. So I would suggest rethinking this - let's be up front
and ask the community to get rid of the rule that expired I-Ds are
invisible, with an opt-out clause.

    Brian







_______________________________________________
Tools-discuss mailing list
Tools-discuss at ietf.org
https://www1.ietf.org/mailman/listinfo/tools-discuss