Re: Alternate entry document model

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