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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf