Re: If you found today's plenary debate on standards track tedious...
On Nov 11, 2009, at 5:33 AM, Richard Barnes wrote: From the perspective of the world outside the IETF, this is already the case. An RFC is an RFC is an RFC... --Richard +1 As far as I can tell, 3GPP treats information and experimental RFC the same as standards track just to give you an idea of even how some of the outside world that does standards views the IETF And let me add to the comment about SIP being PS ... some of the most deployed SIP RFCs are informational. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: If you found today's plenary debate on standards track tedious...
+1 But I also agree with part of Adrian's comments. Our vocabulary for describing these things may be sub-optimal and that may have gotten in our way. Perhaps something more along the lines of approved standard, interoperable standard, and verified standard would serve us better than PS/ DS/ Full. But a different piece of vocabulary might be equally important: perhaps we should be talking about recognizing something at a standard at a particular level and not advancing it. I also believe that part of the problem involves what amounts to a positive feedback loop: because few documents are advanced past PS, the IESG feels obligated to impose requirements on approval at PS that go far beyond what is required by 2026. Once documents are polished to a high luster, at the cost of considerable time, for PS, there is little incentive to advance them and, worse, even more impressive requirements are imposed in practice at DS and Full, possibly to give them some distinction beyond Proposed. If we could get back to treating Proposed much as the IEEE used to treat Draft Standard for Trial Use -- no known technical defects in the protocol and documentation that was not required to be more than adequate to explain the idea -- then we might be able to get things into Proposed more quickly and have incentive for document revision and advancement (sic) for those ideas that actually turned out to get traction in practice. Of course, since Brian found one dead horse to kick, I'm semi-obligated to mention another. The ISD idea was to draw things together in a different way, permitting binding several documents together in ways that would deal with the problems Spencer mentions, replacing the rigid PS/ DS/ Full categories with explanatory prose, and binding errata and clarifications more closely to the documents themselves than the RFC Editor version of the errata permits. But neither that idea nor the earlier one Brian mentioned is worth resurrecting and reexamining unless the IESG wants to play and, so far, I've seen little evidence that they do. john --On Wednesday, November 11, 2009 22:40 -0500 Tony Hansen t...@att.com 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. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: If you found today's plenary debate on standards track tedious...
John C Klensin wrote: But I also agree with part of Adrian's comments. Our vocabulary for describing these things may be sub-optimal and that may have gotten in our way. Perhaps something more along the lines of approved standard, interoperable standard, and verified standard would serve us better than PS/ DS/ Full. But a different piece of vocabulary might be equally important: perhaps we should be talking about recognizing something at a standard at a particular level and not advancing it. I also believe that part of the problem involves what amounts to a positive feedback loop: because few documents are advanced past PS, the IESG feels obligated to impose requirements on approval at PS that go far beyond what is required by 2026. Once documents are polished to a high luster, at the cost of considerable time, for PS, there is little incentive to advance them and, worse, even more impressive requirements are imposed in practice at DS and Full, possibly to give them some distinction beyond Proposed. If we could get back to treating Proposed much as the IEEE used to treat Draft Standard for Trial Use -- no known technical defects in the protocol and documentation that was not required to be more than adequate to explain the idea -- then we might be able to get things into Proposed more quickly and have incentive for document revision and advancement (sic) for those ideas that actually turned out to get traction in practice. I think John's hit the nail right on the head here. I would like to go a bit further and say that it's long past time to abandon the name RFC altogether. While I understand and respect the historical underpinnings of the term I agree with those who have commented that for most of the world an RFC is an RFC is an RFC and our fine distinctions like Experimental, Informational etc. are lost. My suggestion would be to name the documents what they are, and to come up with new terms for the documents that reflect the evolution of the process. In the standards track area I think names like the ones John proposed are good, I personally would s/interoperable/deployed/ but that's a detail that can be tweaked later, as can names for some of the other categories of things that are all called RFCs now. Anyone else think that clarifying the naming scheme is a good idea? Doug -- Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: If you found today's plenary debate on standards track tedious...
-Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Richard Barnes Sent: Wednesday, November 11, 2009 4:33 AM To: Brian E Carpenter Cc: IETF discussion list Subject: Re: If you found today's plenary debate on standards track tedious... From the perspective of the world outside the IETF, this is already the case. An RFC is an RFC is an RFC... +1. And if the IETF wanted to change that perception, the IETF needs to create a separate document stream -- which I think was the intent of the BCP and FYI document streams. But FYI and BCP aren't separate because the documents also have RFC numbers. -d --Richard On Nov 11, 2009, at 7:25 PM, Brian E Carpenter wrote: Who would like to adopt this idea: http://tools.ietf.org/id/draft-loughney-newtrk-one-size-fits- all-01.txt Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: If you found today's plenary debate on standards track tedious...
On Wed, Nov 11, 2009 at 10:40:53PM -0500, Tony Hansen wrote: 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. DNSEXT has this problem in spades, partly because it's not zero work to move something along the standards track. Even if the document needs no revision, you still have to meander through the process. This takes time and, as important, the energy to prove that the document really is ready to proceed. What is the incentive to do the work? Why bother? Who is going to spend time and effort on what is essentially a housekeeping task, which is way less interesting than inventing new solutions (or problems)? Especially since you still have to go through last call, at which point every kook on the Internet who has a lot of will (or time on his or, rarely, her hands) has the opportunity to haul out their rusty old axes and start grinding. We have more and more formal rules around determining rough consensus. Meanwhile, the running code is the actual measure of effectiveness, and once there is a broadly stable, already interoperating standard, there's very little incentive to go through the bureaucratic hurdles to demonstrate even less-rough consensus. There's not even the sort of money incentive that causes people to do drudgery in their day jobs: the management responsible for paying salaries are surely unlikely to want to burn expensive engineer time jumping process hurdles if there's not a clear benefit. This all means, to me, that the incentives just aren't there to move most standards. But so what? 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) Surely, this is already an indication that we have more process than is needed. If everyone agrees that something is needed for interoperation, and it's widely deployed like that, why in the world do we require a lot of hoops to include that when we move the document along? Errata are, by definition, strictly speaking part of the original document. If they weren't, they wouldn't be errata: they'd be revisions to the specification. And we all know, of course, that nobody ever tries to use an erratum to make a subtle change to the specification in order to avoid using the standards process, right? A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: If you found today's plenary debate on standards track tedious...
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 t...@att.com 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 t...@att.com 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@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ 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
If you found today's plenary debate on standards track tedious...
Who would like to adopt this idea: http://tools.ietf.org/id/draft-loughney-newtrk-one-size-fits-all-01.txt Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: If you found today's plenary debate on standards track tedious...
Brian E Carpenter wrote: Who would like to adopt this idea: http://tools.ietf.org/id/draft-loughney-newtrk-one-size-fits-all-01.txt Typically, it's better to gain some agreement about tradeoffs among some choices, prior to starting lobbying for a particular choice. This has the distinct advantage of allowing the community to know why it rejected alternatives. And /that/ has the advantage of avoiding morning-after regret. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: If you found today's plenary debate on standards track tedious...
From the perspective of the world outside the IETF, this is already the case. An RFC is an RFC is an RFC... --Richard On Nov 11, 2009, at 7:25 PM, Brian E Carpenter wrote: Who would like to adopt this idea: http://tools.ietf.org/id/draft-loughney-newtrk-one-size-fits- all-01.txt Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: If you found today's plenary debate on standards track tedious...
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@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: If you found today's plenary debate on standards track tedious...
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@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: If you found today's plenary debate on standards track tedious...
+1 you shouldn' need to be an IETF insider to actually understand IETF standards. John Sent from my Nokia N900. - Original message - 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@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: If you found today's plenary debate on standards track tedious...
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
Re: If you found today's plenary debate on standards track tedious...
Adrian, I think both statements are true. I've seen operators putting almost any RFC in RFPs, (actually done it myself) STD, DS, PS, Informational, Experimental, Historic and April 1st. An RFC is an RFC is an RFC! On the other hand talking to folks active in other SDOs you very often hear the no standards argument. Renaming without changing definitions should part of the job. /Loa 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@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Loa Andersson email: loa.anders...@ericsson.com Sr Strategy and Standards Managerl...@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: If you found today's plenary debate on standards track tedious...
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.
Re: If you found today's plenary debate on standards track tedious...
It is really hard to keep management backing for a standards process that does not deliver standards. I know that there are some people in the IETF who would very much like to see the commercial entities banished. And to some extent that has happened, there is a reason that IBM and Microsoft put more resources into OASIS and W3C and I do not think it is because they have more influence there. We are also seeing fewer academics. I don't think that you want participation in IETF activities to be limited to the few people fortunate enough to have managers who understand the nature of the organization and a few individuals of private means. On Wed, Nov 11, 2009 at 8:30 PM, Loa Andersson l...@pi.nu wrote: Adrian, I think both statements are true. I've seen operators putting almost any RFC in RFPs, (actually done it myself) STD, DS, PS, Informational, Experimental, Historic and April 1st. An RFC is an RFC is an RFC! On the other hand talking to folks active in other SDOs you very often hear the no standards argument. Renaming without changing definitions should part of the job. /Loa 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@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Loa Andersson email: loa.anders...@ericsson.com Sr Strategy and Standards Manager ...@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 ___ 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
Re: If you found today's plenary debate on standards track tedious...
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 t...@att.com 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@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
