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

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

 



---- Original Message -----
From: "Andrew Sullivan" <ajs@xxxxxxxxxxxx>
To: <ietf@xxxxxxxx>
Sent: Friday, October 29, 2010 9:39 PM
> On Fri, Oct 29, 2010 at 01:20:23PM -0700, SM wrote:
> > It would be difficult to get buy-in if the document is not published as a
> > RFC.
>
> Supppse we actually have the following problems:
>
>     1.  People think that it's too hard to get to PS.  (Never mind the
>     competing anecdotes.  Let's just suppose this is true.)
>
>     2.  People think that PS actually ought to mean "Proposed" and not
>     "Permanent".  (i.e. people want a sort of immature-ish level for
>     standards so that it's possible to build and deploy something
>     interoperable without first proving that it will never need to
>     change.)
>
>     3.  We want things to move along and be Internet STANDARDs.
>
>     4.  Most of the world thinks "RFC" == "Internet Standard".

I think that this point is crucial and much underrated.  I would express
slightly differently,
that, for most of the world, an RFC is a Standard produced by the IETF, and
that the number of organisations that know differently are so few in number,
even if
some are politically significant, that they can be ignored.

And that this is something outside our control and that we are powerless to
change.

So whether we have XStandard, YStandard or ZStandard and how we move
between them is irrelevant (to most of the world).

Hence my focus is on how we can get an RFC published in the first place, in a
more
timely manner with, ideally, an improvement in the quality.

Tom Petch


> 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.
>
> Note that this is not to denigrate SM's suggestion, which also doesn't
> seem wrong to me.  But since one of the issues appears to be that
> anything called "RFC" is set in stone, then if we just stop calling
> the early-publication documents "RFC" that and introduce something
> after I-D (which is formally only on the _way_ to some consensus, and
> not actually the product of it), the blockage might be removed.
>
> A
> --
> Andrew Sullivan
> ajs@xxxxxxxxxxxx
> Shinkuro, Inc.

_______________________________________________
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]