Re: Alternate entry document model (was: Re: IETF processes (was Re: draft-housley-two-maturity-levels))

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi John,

This is a quick reply to your message.  Please treat it as highly immature.

At 11:23 29-10-10, John C Klensin wrote:
Personally, I continue to believe that the Internet would be
better served by having a lot less difference between Proposed
and Experimental, by changing things (back?) so that getting one
or the other approved and published was really quick, and making
our main standardization/ get the document exactly right /
consensus level the second one.    In that context, I think it
would make less difference whether we had two levels or three
(but I'm the guy who proposed replacing category-levels that are
never quite right with narrative text what could be used to
explain what we really thought about a spec and its maturity).

Keith posted some comments about document quality. The ideas are good but implementing them will create more work. It might be possible to combine the ideas with other proposals to come up with a workable alternative. I don't know whether Keith will find a dilution of the ideas acceptable.

But, if we are going to persist in treating Proposed as "already
refined specification to be implemented and deployed" and in
requiring a very high standard of documentation, specification,
and agreement for Experimental, then it seems to me that the
odds are good that trying to insert Experimental "below"
Proposed would, in lots of cases, just push Proposed up (four
levels?) and make things even slower.

Agreed.

And that would, IMO, increase the justification for documents
bearing a WG-only stamp of approval such as the "snapshot" I-D
plan.  I'm not a fan of that plan because I think we should fix
Proposed, including reduce the time and trouble it takes to get
a spec published as Proposed, but, if we really can't do that,
then formal pre-approval by a WG seems like the right way to go.

Strawman (consciously derived from the current procedures of
another SDO who, oddly, modeled those procedures on what they
thought we are doing a decade or two ago):

Suppose we eliminate "Proposed Standard", replacing it with
"IETF Area Specification" or "Preliminary Specification" (there
are probably better names) with the following properties:

        -- No known technical defects (the present criterion for
        Proposed)

        -- Review and approval only within the (single) area of
        origin, i.e., WG review and AD review and approval (with
        whatever addition input the AD wanted to ask for, as
        now), but no IESG approval process at all.

        -- Published as RFCs, but clearly labeled as
        "preliminary", "possibly incomplete" and "not a
        standard".  I wouldn't expect that to do much good,
        especially if someone were inclined to distort the
        situation for marketing reasons, but we can and should
        try.

        -- Instructions to the RFC Editor to favor speed of
        publication and basic comprehensibility over getting the
        text just right.

Presumably this gets things through the IESG faster, if only
because the number of people who can launch a formal DISCUSS is
reduced to two from 15.  It would also reduce IESG workload on
documents that really are preliminary somewhat which, IMO, would
be A Good Thing.

While my instinct is that RFC publication would be desirable, if
that didn't seem workable we could move the idea a bit closer to
the "Snapshot" idea by posting the document in the I-D series
and giving it a gold star.

It would be difficult to get buy-in if the document is not published as a RFC. Instead of eliminating Proposed Standard, how about allowing the working group output document to be published as Proposed Standard? The approval could be done within the working group only but that might results in documents of questionable quality. If we take your idea of having an area review instead, some problems which a working group might ignore would be caught. It would also look better for labelling purposes.

There will be technical defects and architecturally unsound proposals coming out of this. For those who might say that it is unacceptable, I might point out that there it is already the case.

It could work as follows:

  (i)   Working Group Last Call

  (ii)  Area-wide Last Call - This is for the document to get
        more exposure

  (iii) AD review of comments and document

  (iv)  Document published as Proposed Standard with text saying
        that it represents the consensus of Area X and does not
        represent IETF consensus

  (v)   Document goes into "do or die" track

  (vi)  Working Group writes a revised proposal

  (vii) Last Call and IESG evaluation

  (ix)  Document published as Draft Standard.  It represents the
        consensus of the IETF and benefits from IETF-wide review

  (x)   Deployment report required for document to be moved to
        Internet Standard (I am not getting into what the report
        should be about to keep this short).

The above can also be used for Individual Submissions. The above would reduce the load of work of the IESG and they can focus on the restricted set of documents that try to make it to Draft or Internet Standard. ADs have less documents to read and IETF participants are not overloaded by Last Calls.

Then we have a second level that constitutes a real IETF Spec:
satisfaction of various "nits", full community review, including
cross-area review and evidence of community consensus.  I don't

There are benefits to having cross-area review of documents. It is unfortunately not possible to have that done for all documents currently going for Proposed Standard. What I wrote above would mitigate the problem instead of solving it.

If the WG didn't care about IETF approval, then they don't care.
Nothing stops such a WG from giving up after posting I-Ds today;
with the "Snapshot" idea, they would have equally little (or
much) incentive to move to full IETF review.

There is still the issue of timeliness. It's up to the WG to determine whether it wants to use Experimental or have several experimental proposals to gain experience in choosing the better proposal. The WG cannot blame the IESG for putting up barriers as it has been told that there is an expectation that the issues will have be resolved at some point (Draft Standard) or else its work will go through a reclassification by default.

There are a lot of details that are not covered in the above. Fow what it is worth, it might even be possible to do the above within the bounds of RFC 2026 but that would require some liberal reading of the RFC together with some tweaks to other RFCs.

Regards,
-sm

1. http://www.ietf.org/mail-archive/web/ietf/current/msg64345.html
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]