I think this is a very good way forward. It is utterly futile to expect anyone to sit down and work out what it would take to move HTTP 1.1 forward to Standard. Yet it is obviously a standard and the current RFC is clearly good enough for most engineers to figure out. I note that quite a few of the people who have been regular attendees at IETF in the past have been laid off in the past 12 months. There are very few companies that are prepared to invest in standards work these days. Those that do are doing so on a much lesser scale than in years past. It is really hard to justify participation in organizations that provide few indicators for performance reviews. And the issue is not simply what Fred IETFer might say to his manager, it is what his manager says to his boss. None of the calls I get from head hunters are looking for someone to do standards work. On Wed, Nov 11, 2009 at 10:40 PM, Tony Hansen <tony@xxxxxxx> wrote: > Yup, and most of those proposed standards and draft standards should have > been declared full standards *long* ago. > > What we *don't* do well is revising the levels of standards that got > published, became fully interoperable and deployed without needing a rev of > the document. Why is their status still marked 'proposed' or 'draft'? RFC > 2026 does NOT require a rev to the document to move forward if there are no > errata. > > For those specs that everyone has implemented and deployed, but there are a > number of errata that "everyone agrees" are required for the spec to be > useful, here's an idea for a "revision lite" (the diet version of a > revision): recycle the spec almost totally *as-is*, with a section added > called "Verified Errata". Copy in such errata, attach the interoperability > and deployment reports, and publish. > > Tony Hansen > tony@xxxxxxx > > Eliot Lear wrote: >> >> Not THIS again. Let's look at a few of the standards that are commonly >> used today: >> >> HTTP: DS >> SNTP: PS >> SIP: PS >> IPv6 Addressing Architecture: DS >> SMTP: DS & Full standard >> MPLS-VPNs: PS >> BGPv4: DS >> MIME: DS >> XMPP: PS (although it seems the real work goes on elsewhere) >> OSPF: Full standard >> RIPv2: full standard >> BFD: not to be found >> VRRP: DS >> Radius: DS >> DNS base: full standard >> DNS components: varying >> SNMPv3: full (but long before anyone actually used it) >> >> And so you will forgive people who seem confused by our quaint notion that >> there are flavors of standards. We don't do a good job of describing >> maturity with our standards levels. Perhaps we do a good job of using the >> standards levels to make a recommendation. How much SNMPv1 and v2 is out >> there still? Apparently not many people are listening to that >> recommendation. >> >> Does standard matter at all any more? I think so. A good number of the >> base protocols that are run on the computer I type this from are actually >> IETF standards. Yeah (except for software and device management. We blew, >> and continue to blow that one). >> >> So let's get real. John's draft was the right thing to do for NEWTRK. >> But do we really have the stomach for it? Last time out we did not. >> >> Eliot >> ps: see you all in Orange County, where I'm sure this endless debate will >> continue. >> >> On 11/11/09 5:04 PM, Adrian Farrel wrote: >>> >>> Hi, >>> >>>> From the perspective of the world outside the IETF, this is already the >>>> case. An RFC is an RFC is an RFC... >>> >>> I don't think this is a truth universally acknowledged. >>> >>> I have heard the IETF disparaged a number of times on account of "hardly >>> having any standards". For example, a full Standard is equated by some >>> people with an ITU-T Recommendation with the implication that a DS and PS >>> are significantly inferior to a Recommendation. >>> >>> Whatever we might think of the value of this statement and the motives of >>> the people who make it, it is clear that the names of the different levels >>> of RFC are perceived outside the IETF. >>> >>> Over dinner this evening we wondered whether something as simple as >>> looking again at the names of the stages in the three phase RFC process >>> might serve to address both the perceptions and the motivations for >>> progression. >>> >>> Cheers, >>> Adrian >>> _______________________________________________ >>> Ietf mailing list >>> Ietf@xxxxxxxx >>> https://www.ietf.org/mailman/listinfo/ietf >>> >> >> _______________________________________________ >> Ietf mailing list >> Ietf@xxxxxxxx >> https://www.ietf.org/mailman/listinfo/ietf > > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www.ietf.org/mailman/listinfo/ietf > -- -- New Website: http://hallambaker.com/ View Quantum of Stupid podcasts, Tuesday and Thursday each week, http://quantumofstupid.com/ _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf