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

From: Brian E Carpenter <[email-masked]>
Date: Wed, 11 Nov 2009 23:25:05 +1300

Who would like to adopt this idea:

http://tools.ietf.org/id/draft-loughney-newtrk-one-size-fits-all-01.txt

    Brian

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 11 Nov 2009 21:05:52 +0900

> 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

---

From: Richard Barnes <[email-masked]>
Date: Wed, 11 Nov 2009 21:33:28 +0900

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:

> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf

---

From: Adrian Farrel <[email-masked]>
Date: Wed, 11 Nov 2009 16:04:11 +0000

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

---

From: Eliot Lear <[email-masked]>
Date: Wed, 11 Nov 2009 17:29:14 +0100

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:
> 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

---

From: John <[email-masked]>
Date: Wed, 11 Nov 2009 11:15:26 -0800

+1

you shouldn' need to be an IETF insider to actually understand IETF standards.

John

Sent from my Nokia N900.

---

From: "Spencer Dawkins" <[email-masked]>
Date: Thu, 12 Nov 2009 06:57:46 +0900

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

> 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.
>
> 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).
>
> ps: see you all in Orange County, where I'm sure this endless debate will 
> continue.
>
>> the people who make it, it is clear that the names of the different 
>> 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.

---

From: Loa Andersson <[email-masked]>
Date: Thu, 12 Nov 2009 02:30:48 +0100

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:
> people with an ITU-T Recommendation with the implication that a DS and 
> PS are significantly inferior to a Recommendation.
> 

-- 

Loa Andersson                         email: [email-masked]
Sr Strategy and Standards Manager            [email-masked]
Ericsson Inc                          phone: +46 10 717 52 13
                                              +46 767 72 92 13

---

From: Tony Hansen <[email-masked]>
Date: Wed, 11 Nov 2009 22:28:23 -0500

One idea discussed over various beverages last night was based on an 
observation about the high bar that most Proposed Standards have had to 
pass over in order to become RFCs: many of them would not have gotten to 
publication without having already gone through interoperability testing.

So the idea is that the shepherding files for such I-Ds could include 
interoperability reports indicating that they *are* already 
interoperable and have successful operational experience, and then be 
published directly at Draft Standard status.

	Tony Hansen
	[email-masked]

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 11 Nov 2009 18:42:46 -0500

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
<[email-masked]> wrote:
>> 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

-- 
-- 
New Website: http://hallambaker.com/
View Quantum of Stupid podcasts, Tuesday and Thursday each week,
http://quantumofstupid.com/

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 11 Nov 2009 22:25:48 -0500

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.

---

From: Tony Hansen <[email-masked]>
Date: Wed, 11 Nov 2009 22:40:53 -0500

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
	[email-masked]

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 12 Nov 2009 12:44:11 +0900

On Nov 12, 2009, at 12:28, Tony Hansen wrote:

> published directly at Draft Standard status

Raise the bar so they stay at I-D level for even longer?  A sizable  
part of the Internet is run on I-Ds, not on PS.

I think the right direction is to publish PS earlier.  If done right,  
it's only six months from there to the DS, you know.  (About half of  
that time the draft is stuck in the RFC finalization process anyway :-).

(My suggestion would be to stop talking about changing the rules and  
instead just find ways to use the current process better.)

Gruesse, Carsten

PS.: And you could spend some time during I-D time already to upgrade  
your downrefs to DS :-)

---

From: Tony Hansen <[email-masked]>
Date: Wed, 11 Nov 2009 23:01:07 -0500

Raise the bar more? Not at all -- that's not what I said. I said that 
the bar has *already been raised* so high that many of our I-Ds have 
already become fully interoperable before they get an RFC number assigned.

What I said, is that if you *have* interoperability and deployment when 
you get the RFC number assigned, go ahead and get published at DS or FS 
status.

Unless there are errata, changing the status from PS to DS to FS should 
be an administrative task, not a wait-for-full-revision-taking-X-years 
chore.

And yes, the above statements are *fully* in line with "use the current 
process better."

	Tony Hansen
	[email-masked]

Carsten Bormann wrote:
> Raise the bar so they stay at I-D level for even longer?  A sizable part 
> of the Internet is run on I-Ds, not on PS.
>

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 11 Nov 2009 22:02:32 -0600

At 09:44 PM 11/11/2009, Carsten Bormann wrote:
>it's only six months from there to the DS, you know.

err... I thought this was minimum of 18 months?

James

>  (About half of

+1

James

---

From: Tony Hansen <[email-masked]>
Date: Wed, 11 Nov 2009 23:44:07 -0500

RFC 2026 section 6.2:
     6 months from PS => DS
     4 months and 1 meeting for DS => FS.

As John notes though, the clock currently begins after RFC publication 
time. There's no allowance granted for time already spent in jail.

	Tony Hansen
	[email-masked]

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 12 Nov 2009 14:20:32 +0900

Tony Hansen wrote:
> observation about the high bar that most Proposed Standards have had 
> to pass over in order to become RFCs: many of them would not have 
> gotten to publication without having already gone through 
> interoperability testing.
>
> interoperable and have successful operational experience,
Note that a short version of this is already included in the shepherding 
document.
> and then be published directly at Draft Standard status.

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 12 Nov 2009 10:49:29 -0500

> RFC 2026 does NOT require a rev to the document to move forward if there  

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?  

> 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
[email-masked]
Shinkuro, Inc.

---

From: Eliot Lear <[email-masked]>
Date: Thu, 12 Nov 2009 16:55:24 +0100

I guess the question I have is why bother having any of these levels at 
all?  What legitimate purpose are they ACTUALLY serving?

Eliot

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 12 Nov 2009 11:23:21 -0500

If you read the definitions and theoretic criterial for Proposed versus
Draft, it makes a lot of sense. Proposed is just "proposed" and
non-injurious to the Internet. Draft required interoperability of
independent implementations and is the first level where widespread
implementation is recommended. This distinction makes a lot of sense.

The problem is the constantly escalating hurdles in practice to get to
Proposed...

Thanks,
Donald

On Thu, Nov 12, 2009 at 10:55 AM, Eliot Lear <[email-masked]> wrote:

>> observation about the high bar that most Proposed Standards have had to pass
>> over in order to become RFCs: many of them would not have gotten to
>> interoperability reports indicating that they *are* already interoperable
>> and have successful operational experience, and then be published directly
>> at Draft Standard status.
>>
>>    Tony Hansen
>>    [email-masked]
>>

---

From: Tony Hansen <[email-masked]>
Date: Thu, 12 Nov 2009 11:36:09 -0500

If we had three stages that were named

	untested standard
	interoperable standard
	widely deployed standard

would that make any difference? Those names match what 2026 says PS, DS 
and FS are supposed to represent. But the hurdle to move a standard from 
the status of "untested" (PS) to "interoperable" (DS) has been rather large.

In a discussion with Russ Housley this afternoon, we talked about how 
eliminating the DOWNREF problem has indeed broken the logjam somewhat, 
and that there HAVE been standards moving forward to DS recently, and 
even a FEW moving to FS. I consider this encouraging news. Hopefully we 
can chip away at a few more of the logjams.

"More study is needed." -- anon

	Tony Hansen

Donald Eastlake wrote:
> On Thu, Nov 12, 2009 at 10:55 AM, Eliot Lear <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     I guess the question I have is why bother having any of these levels
>     at all?  What legitimate purpose are they ACTUALLY serving?
> 
>     Eliot
> 
> 
>         One idea discussed over various beverages last night was based
>         on an observation about the high bar that most Proposed
>         Standards have had to pass over in order to become RFCs: many of
>         them would not have gotten to publication without having already
>         gone through interoperability testing.
> 
>         So the idea is that the shepherding files for such I-Ds could
>         include interoperability reports indicating that they *are*
>         already interoperable and have successful operational
>         experience, and then be published directly at Draft Standard status.
> 
>            Tony Hansen
>            [email-masked] <mailto:[email-masked]>
> 
>         [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>
> ------------------------------------------------------------------------
>

---

From: Eliot Lear <[email-masked]>
Date: Thu, 12 Nov 2009 19:33:33 +0100

On 11/12/09 5:23 PM, Donald Eastlake wrote:
> If you read the definitions and theoretic criterial for Proposed 
> versus Draft, it makes a lot of sense. Proposed is just "proposed" and 

*IN THEORY* it once made a lot of sense, but please show me how it has 
EVER made sense in practice.

> The problem is the constantly escalating hurdles in practice to get to 

That is A problem but IMHO not The Problem.  Another problem is that I 
know of very few profit-making ventures that really want to devote their 
employees' time to an activity that gains them not one single additional 
bit of functionality.

Eliot

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 11 Nov 2009 23:10:07 -0500

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 <[email-masked]> wrote:
> Yup, and most of those proposed standards and draft standards should have
> been declared full standards *long* ago.
>
> 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
>        [email-masked]
>
> Eliot Lear wrote:
>>

---

From: John C Klensin <[email-masked]>
Date: Wed, 11 Nov 2009 23:28:27 -0500

--On Wednesday, 11 November, 2009 23:01 -0500 Tony Hansen
<[email-masked]> wrote:

> Raise the bar more? Not at all -- that's not what I said. I
> said that the bar has *already been raised* so high that many
> of our I-Ds have already become fully interoperable before
> they get an RFC number assigned.
> 
> What I said, is that if you *have* interoperability and
> deployment when you get the RFC number assigned, go ahead and
> get published at DS or FS status.
> 
> Unless there are errata, changing the status from PS to DS to
> FS should be an administrative task, not a
> wait-for-full-revision-taking-X-years chore.

Tony,

I'm very sympathetic to this.  But I note two things.  The first
is that the powers that be have decided that the clock doesn't
start running until a document is actually published -- one
cannot start counting from approval without some changes in
procedures (or at least in interpretation).  Second, one of the
big things we often accomplish when moving to Draft is a giant
increase in document quality.  IMO, we should be encouraging
that by not holding up publication at Proposed for fine details
of document quality (as long as there are no "known technical
defects"), leaving document fine-tuning for PS-> DS.  That
objective runs a little counter to what you are suggesting, I
think.

> And yes, the above statements are *fully* in line with "use
> the current process better."

Plus or minus some modifications.

    john

---

From: "Martin J. Dürst" <[email-masked]>
Date: Fri, 13 Nov 2009 18:42:32 +0900

A related point, but from another direction:

My impression currently is that Full Standards never get revised again. 
Unless I'm wrong, we may have to revise this practice if we go to a 
model with only one standards category, because sometimes it indeed 
makes sense to update a document.

Regards,   Martin.

-- 
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:[email-masked]

---

From: Dave Cridland <[email-masked]>
Date: Fri, 13 Nov 2009 12:09:16 +0000

On Fri Nov 13 09:42:32 2009, "Martin J. Dürst" wrote:
> My impression currently is that Full Standards never get revised  
> again. Unless I'm wrong, we may have to revise this practice if we  
> go to a model with only one standards category, because sometimes  
> it indeed makes sense to update a document.

No, they do - consider the recent revising of RFC 821 and RFC 822.

Just to throw in some different experience, though, the XSF (which  
does the non-core work on standardization of XMPP) has a three level  
standards track, documented in XEP-0001 - that's  
http://www.xmpp.org/extensions/xep-0001.html - which starts off with  
Experimental, then Draft, then Final.

XEPs, unlike RFCs, get edited in-place, and there's no real  
equivalent to Internet Drafts - "protoXEPs" do exist, but they're  
usually not much more that sketches of what is hoped to be achieved.

Experimental XEPs are conceptually the equivalent of adopted  
working-group drafts, therefore - albeit the XSF has no individual  
submission as such. Experimental XEPs can be changed by their authors  
without oversight or review.

Draft is roughly centered between the IETF's Proposed Standard and  
Draft Standard states, with the difference that the specifications  
are intented to be well-reviewed and stable by Draft, but haven't had  
to be field-proven yet. However, to hit this state they do need  
oversight and review, and any changes from this point on need the  
same.

Final is - roughly speaking - a "cheap" Full Standard. Ive no doubt  
we're not quite as rigorous as the IETF is, here. Final doesn't mean  
immutable, either, it can still be edited.

This mechanism works within the XSF for a number of reasons, not all  
of which are applicable to the IETF. For example, the XMPP community  
as a whole is highly engaged with the standards process, by  
comparison with a lot of the IETF's target communities. Thus making  
work more visible at an earlier stage within the standards community  
overflows into the wider XMPP community very easily. In turn, this  
supports a shorter standards-track (the XSF's is, from this  
perspective, three stage rather than the IETF's four-stage).

We took a serious effort, there, too, to ensure that even at  
Experimental stage, a protocol can be implemented and deployed as  
safely as possible - this eliminates the cases where, for example, an  
IMAP I-D has been deployed and subsequently changed in incompatible  
ways. Again, this supports wider buy-in to the specification's  
development, by avoiding penalizing implementors.

Finally, use of stable identifiers for a particular work item means  
that implementors who are less well engaged can track items of  
interest more easily.

There may well be ways that people feel the XSF is worse than the  
IETF in terms of the design of it's standards process, but as a  
whole, having observed both cases quite closely over the past few  
years, the XSF has a tendency to use its process for positive goals -  
ie, it helps us more than it hinders.

I'm not even sure whether the differences truly matter compared with  
the differences that a highly engaged developer community makes, but  
I do think that if there are perceived problems with the IETF's  
standards process, then it's worth looking at other examples that do  
seem to function well.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 16 Nov 2009 18:30:53 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 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...
> 
> 

+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

---

From: John C Klensin <[email-masked]>
Date: Tue, 17 Nov 2009 06:51:40 -0500

+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
<[email-masked]> 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

---

From: Doug Barton <[email-masked]>
Date: Tue, 17 Nov 2009 16:47:51 -0800

> 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/

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 24 Nov 2009 09:19:22 -0700

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.