I think that there are some issues that are not being mentioned, but
which are important.
In general, there is the issue of impact. This takes many forms. But
the underlying effect is taht protocols which get widely deployed can
have distinctly negative impact on the net. Thus, for many years, the
requirement for routing protocols which could effect changes to core
behavior was that they had to have demonstrated interoperable
implementations for PS. This was acknowledged by all involved to be a
higher standard than 2026 called for. It was an area rule (going back
to about 1992.) On the other hande, there are plenty of things, even in
routing, which do not have those kinds of effects and do not need those
safety measures. But you can not tell without looking.
Similarly, it is important to make sure we check out the congestion
behavior of our protocols before we tell folks to go implement them
widely. Sometimes this is trivial, sometimes it isn't. But ignoring
the question when we are saying "this is ready for deployment" is not a
good thing. One of the positive effects of our current system is taht
because WG knows tha tthye have to clear all the ADs, not just their
own, they actually think about all these issues. And usually manage to
cope with them
To give yet another example, I know of one WG that seriously considered
publishing an Experimental RFC that flat violated existing standards.
The issue was found, and is being addressed. But without cross-area
review (the issue was a transport issue for an Internet WG) it is all
too easy to miss things.
Yes, it would be very good to spot all of these things sooner. I have
not yet seen a proposal that actually works for doing so. But letting
WGs or WGs + ADs approve documents for general advancement is a step
likely to lead to problems.
If all our WGs handed their ADs high quality documents that they had
checked for all these issues, then maybe we could look at this
differently. But LOTs of examples demonstrate taht WGs do not always do
this. (Sometimes WGs give their ADs great documents. Sometimes not.)
Yours,
Joel M. Hslpern
On 10/30/2010 12:23 PM, Yoav Nir wrote:
On Oct 29, 2010, at 10:39 PM, Andrew Sullivan wrote:
If all of those things are right and we're actually trying to solve
them all, then it seems to me that the answer is indeed to move to _n_
maturity levels of RFC, where _n_< 3 (I propose 1), but that we
introduce some new document series (call them TRFC, for "Tentative
Request For Comment", or whatever) that is the first step. Then we
get past the thing that people are optimizing for ("everything stays
as Proposed Standard once it gets published") by simply eliminating
that issue permanently.
Ah, you say, but now things will stick at TRFC. Maybe. But we could
on purpose make it easier to get TRFC than it is now to get PS (say,
by adopting John's limited DISCUSS community for TRFC, or one of the
other things discussed in this thread). Also, the argument about
everyone thinking that RFCs are "standard", and the resulting pressure
to make them perfect and permanent, would be explicitly relieved (at
least for a while), because nobody thinks that TRFCs are standards.
I know how you can get it to approve first: Don't take it to the IESG. Require approval only from the ADs for that area. And don't give them a name that makes them look like some slightly different kind of RFC. Call it "blessed draft" or something like that.
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf