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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf