Re: Alternate entry document model

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

 



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


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