Subject: [newtrk] Some "standards" really are one-level standards...

From: "Spencer Dawkins" <[email-masked]>
Date: Thu, 16 Mar 2006 09:47:23 -0600

I was looking back at my own Gen-ART reviews recently 
(http://www.alvestrand.no/ietf/gen/art/gen-art-by-reviewer.html), and 
noticed a common thread on several reviews that I wanted to mention.

The following is NOT about one-level versus two-level standards tracks, as 
we have been discussing them, so please clear memory before reading 
further...

We have been using Proposed Standard for things like registry creation and 
the Lemonade profiles, mostly because we don't know what else to use, and 
this leaves with the slightly embarrassing situation that we're creating 
"Proposed Standards" that CAN'T advance (if someone creates two registries, 
that would be a BAD thing, right?).

Scott Bradner has called BCPs "one-shot standards" when he gives the IETF 
Overview tutorial, so I'm pretty sure I know what we SHOULD be using, but we 
use BCPs for so many unrelated types of documents that we've kinda stopped 
using them for "one-shot standards".

JohnK published draft-ietf-newtrk-sd-00.txt about a year ago, which proposed 
moving the process documents that we often publish a BCPs to a separate 
series. This expired draft would make BCPs a reasonable place to publish 
documents that we want to receive "standards-track review", if we un-expire 
it and do something with it.

Maybe one more hallway conversation topic at the Anatole?

Thanks,

Spencer 

.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html

---

From: John C Klensin <[email-masked]>
Date: Thu, 16 Mar 2006 22:03:47 -0500

--On Thursday, 16 March, 2006 09:47 -0600 Spencer Dawkins
<[email-masked]> wrote:

> (http://www.alvestrand.no/ietf/gen/art/gen-art-by-reviewer.htm
> l), and noticed a common thread on several reviews that I
> wanted to mention.
> 
> The following is NOT about one-level versus two-level
> standards tracks, as we have been discussing them, so please
> clear memory before reading further...
> 
> We have been using Proposed Standard for things like registry
> creation and the Lemonade profiles, mostly because we don't
> know what else to use, and this leaves with the slightly
> embarrassing situation that we're creating "Proposed
> Standards" that CAN'T advance (if someone creates two
> registries, that would be a BAD thing, right?).
>...
> JohnK published draft-ietf-newtrk-sd-00.txt about a year ago,
> which proposed moving the process documents that we often
> publish a BCPs to a separate series. This expired draft would
> make BCPs a reasonable place to publish documents that we want
> to receive "standards-track review", if we un-expire it and do
> something with it.

Note that draft-alvestrand-ipod-00.txt, which was recently
posted, suggests, to a first approximation, the same general
idea of moving process documents into another series, with
different rules.  Should the community be sympathetic to that
proposal, we could try to resolve the (fairly few) substantive
differences between the two proposals (either before, during, or
after the 3933 experiment that Harald proposes).

The existence of Harald's document was one important reason I
didn't re-post the draft to which you refer when I posted a
revised version of draft-ietf-newtrk-repurpose-std last week.

> Maybe one more hallway conversation topic at the Anatole?

Perhaps, although, from my point of view, this is one more piece
of the "what should we be doing about Newtrk, PESCI, and process
reformation efforts in general" topic that is on the General
Area meeting agenda (at least in the abstract).  Of course,
Brian may not agree -- I haven't discussed this with him, so I
just don't know.

    john

.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Fri, 17 Mar 2006 08:33:24 +0100

--On torsdag, mars 16, 2006 09:47:23 -0600 Spencer Dawkins 
<[email-masked]> wrote:

> Overview tutorial, so I'm pretty sure I know what we SHOULD be using, but
> we use BCPs for so many unrelated types of documents that we've kinda
> stopped using them for "one-shot standards".

not quite - among recent BCPs, we have:

4289 Multipurpose Internet Mail Extensions (MIME) Part Four:
     Registration Procedures. N. Freed, J. Klensin. December 2005.
     (Format: TXT=21502 bytes) (Obsoletes RFC2048) (Also BCP0013) (Status:
     BEST CURRENT PRACTICE)

4288 Media Type Specifications and Registration Procedures. N. Freed,
     J. Klensin. December 2005. (Format: TXT=52667 bytes) (Obsoletes
     RFC2048) (Also BCP0013) (Status: BEST CURRENT PRACTICE)

4148 IP Performance Metrics (IPPM) Metrics Registry. E. Stephan.
     August 2005. (Format: TXT=23074 bytes) (Also BCP0108) (Status: BEST
     CURRENT PRACTICE)

4020 Early IANA Allocation of Standards Track Code Points. K.
     Kompella, A. Zinin. February 2005. (Format: TXT=13706 bytes) (Also
     BCP0100) (Status: BEST CURRENT PRACTICE)

and there are more in the pipeline - langtags, for instance....

.

---

From: John C Klensin <[email-masked]>
Date: Fri, 17 Mar 2006 08:05:26 -0500

But at least the first two of these (I'm less expert on the
others) are, to me, clearly procedural documents.  Whatever they
are, they aren't protocol specifications.   So, if anything,
this strengthens to point that we should be figuring out a way
to separate out procedural specifications -- for both
registration-type activities and for IETF internal operations,
which may be different -- from protocol specs/ standards.

FWIW, in the original ISD/ Standing [Procedural] Doc model, the
two MIME registration specs would have become part of the MIME
base ISD, while, e.g., RFC 2026, the IPR materials, etc., would
become part of the standing/ administrative document series.
"BCP"s, if there was anything left over that actually needed
that category, could be repurposed back to documents that
actually met all three of the criteria that designation implies.

      john

--On Friday, 17 March, 2006 08:33 +0100 Harald Tveit Alvestrand
<[email-masked]> wrote:

>> Scott Bradner has called BCPs "one-shot standards" when he
>> gives the IETF Overview tutorial, so I'm pretty sure I know
>> what we SHOULD be using, but we use BCPs for so many
>> unrelated types of documents that we've kinda stopped using
>> them for "one-shot standards".
> 
> newtrk
> resources:_____________________________________________________
> web user interface:
> http://darkwing.uoregon.edu/~llynch/newtrk.html
> mhonarc archive:
> http://darkwing.uoregon.edu/~llynch/newtrk/index.html

.

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 19 Mar 2006 22:28:41 +0100

There's nothing in 2026 that limits standards track documents
to be protocol specifications.

There are three words in BCP and I try to consider all of them
when deciding if something should be a BCP. Ditto for the two
words in PS. But that doesn't mean there are no ambiguous cases.

I think that is a separate question from distinguishing procedural
documents from fundamental process rules.

    Brian

   Brian

.

---

From: "C. M. Heard" <[email-masked]>
Date: Tue, 21 Mar 2006 00:08:50 -0800 (PST)

>>>>> On Thu, 16 Mar 2006, Spencer Dawkins wrote:
Spencer> We have been using Proposed Standard for things like
Spencer> registry creation and the Lemonade profiles, mostly
Spencer> because we don't know what else to use, and this leaves
Spencer> with the slightly embarrassing situation that we're
Spencer> creating "Proposed Standards" that CAN'T advance (if
Spencer> someone creates two registries, that would be a BAD
Spencer> thing, right?).

>>>>> On Sun, 19 Mar 2006, Brian E Carpenter wrote:
Brian> There's nothing in 2026 that limits standards track
Brian> documents to be protocol specifications.

No, but it DOES require that standards track documents be
something that can advance, based on criteria of demonstrated
interoperability.  That pretty much rules out such things as
registry creation documents.

Brian> There are three words in BCP and I try to consider all
Brian> of them when deciding if something should be a BCP.
Brian> Ditto for the two words in PS. But that doesn't mean
Brian> there are no ambiguous cases.

Well, it seems to me that there are many cases that are not
ambiguous that are coming out misclassified.

As I have said before, here and elsewhere, it is an abuse of the
standards process (as documented in 2026) to elevate to PS any
document that cannot have multiple interoperable implementations.

Can someone tell me how a document like RFC 3737 can have multiple
interoperable immplementations?

Mike

.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 21 Mar 2006 17:25:16 +0100

> document that cannot have multiple interoperable implementations.

It would be an abuse of process to propose such a thing at DS.
But really, rather than worry about how we deal with the
inconsistencies and ambiguities in today's rules, could we
talk about how to fix those rules?

> interoperable immplementations?

It probably can't, so it will sit at PS for ever, like most things.
A fairly simple fix to the rules would make that OK.

     Brian

.

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 21 Mar 2006 17:14:31 -0600

> A fairly simple fix to the rules would make that OK. 
3737 should have been BCP. I was not doing my job at the time (November 
2003). We knew better.

                 Harald
.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 22 Mar 2006 01:17:22 +0100

> 3737 should have been BCP. I was not doing my job at the time (November 

And you know what? We can't reclassify it, because it contains the magic words
for the standards track rather than the magic words for a BCP.

     Brian

.

---

From: "C. M. Heard" <[email-masked]>
Date: Tue, 21 Mar 2006 17:04:09 -0800 (PST)

On Wed, 22 Mar 2006, Brian E Carpenter wrote:
> And you know what? We can't reclassify it, because it contains
> the magic words for the standards track rather than the magic
> words for a BCP.

Foo.  Yet another thing that's broken about the current system that
would not be a problem under a one-size-fits-all regime ...

//cmh

.