[ih] "The Internet runs on Proposed Standards"

[Vint Cerf]

Brian is pretty much right - the "draft" step was to try to assure that
independently implemented instances of a protocol would interwork
successfully as a way of judging the quality of the spec. Copying the ISO
sequence seemed reasonable at the time. Pragmatically, we have tended to
deploy even soon than "draft" would imply.

v


On Thu, Dec 1, 2022 at 9:16 PM Brian E Carpenter via Internet-history <
internet-history at elists.isoc.org> wrote:

> I'm not sure whether this actually started before RFC1310 (March 1992),
> but certainly since then there have been multiple steps on the standards
> track: Proposed Standard, Draft Standard (no longer assigned) and Internet
> Standard.
>
> (Rumour has it that this started in pure imitation of the ISO standards
> process. Vint can probably speak to the truth of that.)
>
> But, as I first heard from Fred Baker, "The Internet runs on Proposed
> Standards", because most IETFers can't be bothered with the bureaucracy to
> take the next step. Draft Standard was abolished for new work to reduce the
> bureaucracy, but it hasn't had much effect. We did advance IPv6 to Internet
> Standard, but most WGs just don't bother.
>
> In any case, the formal "STD" designation doesn't really mean much.
>
> For a current non-IETF effort, I've drawn a diagram about how to interpret
> the status of RFCs. It can be found at
> https://github.com/becarpenter/book6/blob/main/8.%20Further%20Reading/8.%20Further%20Reading.md
>
> Regards
>     Brian Carpenter
>
> On 02-Dec-22 09:52, touch at strayalpha.com wrote:
> > On Nov 30, 2022, at 1:36 PM, Jack Haverty <jack at 3kitty.org> wrote:
> >>
> >> Well, maybe...
> >>
> >> RFC5227 describes itself as a proposed standard.  Has it subsequently
> become an actual standard?   I don't see it in the "Official Internet
> Protocol Standards" maintained at rfc-editor.org but maybe it had later
> revisions.
> >
> > That distinction isn’t all that significant. There are a LOT of
> protocols that never progressed beyond the initial “PS” status:
> > https://www.rfc-editor.org/standards#PS
> > Progression requires not only some specific hurdles, but also the will
> and effort of someone to walk the spec through that process. The latter is
> more often the limitation.
> >
> >> If it or a descendant is a Standard, does that prevent the creation of
> "tools" such as the Flakeway I described?  RFCs are full of "SHOULD" and
> "MUST" directives, which systems such as Flakeway probably violated.  If
> RFC5227 was universally and correctly implemented, would it prevent someone
> from implementing a Flakeway-like tool, assuming of course they don't feel
> the need to follow the RFCs' rules?
> >>
> >> If RFC5227 et al do in fact prevent such behavior, how does one know
> whether or not the proscribed mechanisms are actually present in one's
> equipment?  I just looked and I have 54 devices on my home Ethernet.   Some
> are wired, some are wifi, and from many different companies.  How do I tell
> if they've all correctly implemented the mechanisms proscribed in the RFCs?
> >
> > The IETF provides no mechanisms for protocol validation. That’s true for
> all MUSTs, SHOULDs, and MAYs for all protocols.
> >
> >> So, is it really "fixed" even today?
> >>
> >> I guess it depends on how you define "fixed”.
> >
> > Doesn’t it always? :-)
> >
> > Joe
> >
> >
> --
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history
>


-- 
Please send any postal/overnight deliveries to:
Vint Cerf
Google, LLC
1900 Reston Metro Plaza, 16th Floor
Reston, VA 20190
+1 (571) 213 1346


until further notice