Re: If you found today's plenary debate on standards track tedious...

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

 



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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]