[newtrk] Re: I-D ACTION:draft-ietf-newtrk-promotion-00.txt

[Brian E Carpenter <[e-mail]>]

These are personal comments only.

At the top level, I believe this is the wrong solution to
the right problem. I already proposed what I believe is the
right solution in draft-carpenter-newtrk-twostep. I'm sure
your local time machine will find this expired draft easily,
but its main point was to combine DS and Standard into
a single grade called Interoperable Standard, thereby
avoiding makework.

Now some direct comments on the current draft.

> 3.  Definition of the Alternate Approval Path
> 
>    Any member (or group of members) of the IETF community (identified as
>    "the proposer" below) may propose that a protocol specification be
>    reclassified as an Internet Standard if the following minimum
>    criteria are met.
> 
>    1.  The RFC documenting the specification, or the last-published RFC
>        if there are more than one, was published at least three years
>        earlier.

This doesn't make it clear what classes of RFC are to be considered.
I assume the main target is older PS and DS documents? But the text
is wider. Surely some definitely need to be excluded - Historic, any
Informational with a proprietary name in its title, anything Obsoleted,
and anything Updated unless the update also qualifies.

...
>    Once an enabling document is generated, it will be submitted to the
>    IAD.  The IESG will initiate a review process as described below.

Not the IAD. The IAD has no function in the standards process. Maybe this
means the IESG Secretary?

> 3.2.1.  Last Call Procedure
> 
>    As mentioned above, there is no pre-Last Call AD or IESG review of
>    enabling documents.  When an enabling document is ready, and has been
>    posted as an I-D, the proposer may request that an IETF Last Call be
>    initiated by request to the IESG Secretary or other individual
>    designated by the IESG and announced to the community.  The person
>    receiving the enabling document will cause the completeness of the
>    enabling document to be checked and will verify that the three-year
>    requirement has been met, then the Secretariat will issue the IETF
>    Last Call.

This pre-last call check is a "faculty" job and not clerical. I don't
see how it can be done other than by an AD or by the equivalent of a
PROTO shepherd.

> 4.1.  IESG Workload
> 
>    To the extent to which this experiment encourages efforts to advance
>    documents that otherwise would continue to rest in the purgatory of
>    resting indefinitely in Proposed (or even Draft) Standard while RFC
>    2026 insists that they be re-identified as historic and abandoned,

Her's my problem. Why invent a whole new process instead of simply
fixing that problem at source by fixing 2026?

> 6.2.  Informative References
> 
>    [decruft]  Lear, E. and H. Alvestrand, "Getting rid of the cruft:
>               Report from an experiment in identifying and reclassifying
>               obsolete standards documents",
>               draft-ietf-newtrk-decruft-experiment-03 (work in
>               progress), January 2006.
> 
>               This document has been approved as a BCP and is awaiting
>               publication.

Nit: it's Informational. (The IESG logged a decision to declassify the
obsolete documents.)

     Brian



.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html