The same is true of SMTP. RFC822 is the 'standard', We have a broken model. There are not enough hours in the day for the IESG to spend time deciding whether HTTP has reached a sufficient maturity level to be considered a full 'standard'. That may or may not be a problem. But the RFC 2822/822 issue is much worse, we are telling people to respect the wrong standards.
Now my recollection of last go around is not that 'we' didn't have the stomach for it. On the contrary. What happened was that the debate went off into a closed room for the decision to be made and the peons were told that there would be neither change nor an explanation but they were to continue to congratulate themselves for being part of an organization with such a sterling tradition of transparency, openness and consensus based decision making. On Wed, Nov 11, 2009 at 4:57 PM, Spencer Dawkins <spen...@wonderhamster.org> wrote: > As I begged at the mike last night, let's make sure that this problem > actually causes pain before spending one more second discussing it. > > Just for completeness :-| > > There is also the question of standards where we DO NOT WANT people to > implement the full standard and say they are through - without PS updates, > disaster happens. > > You don't need to look further than TCP. The full standard (STD007) is only > RFC 793, with no slow start, no congestion avoidance ... that stuff is all > in PSes. And we can't even add them to STD007, because they aren't full > standards. > > Does this matter? A company that I worked at several years ago thought they > were supposed to implement the full standards for TCP and waiting for the > other "in-process" standards to become full standards - that wouldn't work, > but we were doing passive network monitoring and not transmitting any > packets, so it would have been Mostly Harmless. > > John told me he had the same experience at HIS company (before he explained > that our standards levels are usually meaningless), and they DID transmit > packets - they've probably made hundreds of millions of UAs (guess which > technology this is), and they would probably have made a pretty serious dent > in the Internet if they made another few hundred million UAs that provided > HTTP (for example) and implemented TCP without congestion avoidance or slow > start. > > On the other hand, we didn't add congestion avoidance or slow start to TCP > until the net actually collapsed LAST time, so maybe that's what it would > take for us to decide that fixing the standards track is worth doing. But we > need to decide how much pain the standards track as defined today causes > first, or we'll go through another round of endless discussions and still > have STD007. > > IMO. > > Spencer > >> 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. > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > 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@ietf.org https://www.ietf.org/mailman/listinfo/ietf
