Subject: [newtrk] I-D ACTION:draft-ietf-newtrk-repurposing-isd-04.txt

From: [email-masked]
Date: Thu, 09 Mar 2006 15:50:02 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the New IETF Standards Track Discussion Working Group of the IETF.

	Title		: Internet Standards Documentation (ISDs)
	Author(s)	: J. Klensin, J. Loughney
	Filename	: draft-ietf-newtrk-repurposing-isd-04.txt
	Pages		: 28
	Date		: 2006-3-9
	
It has been observed that the current IETF standard designations, STD
nnnn and BCP nnnn designation, have not worked well.  Problems have
been found when one of them is used either as a stable reference for
external specifications or as a combined reference for multiple
documents linked together into a single document.  This document
proposes two changes to these designations.  The first of these
changes would create a new document series and assign a new number
and acronym to a specification when it enters the first level of the
Standards Track (or is first designated as a BCP).  The second would
migrate the concept of STDs and BCPs numbering of RFCs into actual
documents that detail what they identify, their publication
information and their change history.  The document also specifies a
set of minor standards process changes to accommodate and integrate
the new style of doing things that is represented by the new document
series.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-newtrk-repurposing-isd-04.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-newtrk-repurposing-isd-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-newtrk-repurposing-isd-04.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Douglas Otis <[email-masked]>
Date: Fri, 10 Mar 2006 16:53:38 -0800

> http://www.ietf.org/internet-drafts/draft-ietf-newtrk-repurposing- 
> isd-04.txt"

----
It proposes that ISD documents be created and numbers assigned when  
specifications enter the formal standards track (Proposed Standard  
under the model described in RFC 2026), or at IESG discretion,  
earlier, and that the documents be used to track maturation,  
applicability recommendations, and history of those specifications.   
It also outlines the format of those documents, which is expected to  
be different from the format of protocol specification documents and  
the RFC series generally [RFC2223] and briefly discusses a transition  
strategy.
----

This type of document could start early in the development process,  
perhaps even before I-Ds are written where stub values might map  
documents remaining in the to-be-done queue.  Once the "ISD" matures,  
it could fulfill the role of "standard" or "best practice".  It  
burdens this type of document to always place great weight upon it.   
As the "ISD" can self describe its maturity and stature, there seems  
little danger also allowing this document to also help track efforts  
at their outset where greater review is most beneficial.  Even mature  
"ISDs", when revised could reference pending I-D for a significant  
period to allow review of the changes being proposed.  It seems there  
should be a means to indicate a difference between work-in-progress  
and work-accepted akin to I-D and RFC.

I also see this type of document being light weight where a type of  
serialization suffix permits historical review without an ever  
growing list of changes being carried forward and risk becoming an  
encumbrance and needless clutter.

-Doug
.
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: Sat, 11 Mar 2006 08:03:57 -0500

--On Friday, 10 March, 2006 16:53 -0800 Douglas Otis
<[email-masked]> wrote:

> 
>> http://www.ietf.org/internet-drafts/draft-ietf-newtrk-repurpo
>> sing-  isd-04.txt"
> 
> ----
> It proposes that ISD documents be created and numbers assigned
> when  specifications enter the formal standards track
> (Proposed Standard  under the model described in RFC 2026), or
> at IESG discretion,  earlier, and that the documents be used
> to track maturation,  applicability recommendations, and
> history of those specifications.   It also outlines the format
> of those documents, which is expected to  be different from
> the format of protocol specification documents and  the RFC
> series generally [RFC2223] and briefly discusses a transition
> strategy.
> ----
> 
> This type of document could start early in the development
> process,  perhaps even before I-Ds are written where stub
> values might map  documents remaining in the to-be-done queue.
> Once the "ISD" matures,  it could fulfill the role of
> "standard" or "best practice".  It  burdens this type of
> document to always place great weight upon it.   As the "ISD"
> can self describe its maturity and stature, there seems
> little danger also allowing this document to also help track
> efforts  at their outset where greater review is most
> beneficial.  Even mature  "ISDs", when revised could reference
> pending I-D for a significant  period to allow review of the
> changes being proposed.  It seems there  should be a means to
> indicate a difference between work-in-progress  and
> work-accepted akin to I-D and RFC.
> 
> I also see this type of document being light weight where a
> type of  serialization suffix permits historical review
> without an ever  growing list of changes being carried forward
> and risk becoming an  encumbrance and needless clutter.

FWIW, I agree that these are plausible options.  I pointed out
some of the same things about early assignment and tracking in
the newtrk-docid draft and at least one note to the mailing list
about it.  To put the relationship between the two drafts in
context, I see "newtrk-docid" to be ISDs (or, for that matter,
SRDs) without the documents or web pages, just numbers (or
acronyms) associated with RFCs the same way that STD numbers are
today.  Identifier-assigning and the documentation (or lack
thereof) associated with or used to support it are separable
issues.   I don't know if separating them is a good idea or a
bad one --the question is what the community wants (and what the
IESG decides to get behind and/or block).  

To review a piece of that discussion, one disadvantage of
_really_ early assignment is that the folks who confuse "RFC"
with "Standard" today through misunderstanding will be even more
easily misled by usages like "pending standard NNNN" or "ISD
NNNN pending standardization" which, of course, will be true,
but...  It also complicates work for the Secretariat and might
end up forming a historical thread across discarded alternatives
--good for history, but typically bad for understanding a
standard other than historically.    ISO "fixed" that problem by
a formal process for approving the advancement of a document
from "something the committee is working on" to "something that
is still clearly pre-standard but that everyone expected to
evolve into one with most recognizable  features intact".   

I think it would be reasonable for us to do the same thing
although, necessarily, with different mechanisms.   Up to to
that point I think Doug and I are in complete agreement.  The
tricky issue is where and how to set the cutover point.  I
suggested in the newtrk-docid proposal that it should be set at
the Protocol Action unless the IESG concludes, on a case by case
basis and by some formal process of its choice, to do so
earlier.  Other possibilities would be equally plausible; I
think that, if we could get far enough along to actually have a
focused discussion on that issue, we would be making
considerable progress.

      john

.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 27 Mar 2006 12:02:36 +0200

> IESG decides to get behind and/or block).  

If we have designations like STD-0007-is for standards, is there
any reason we shouldn't have designations like STD-0007-isd for
associated descriptors (in cases where they exist)?

     Brian

.

---

From: John C Klensin <[email-masked]>
Date: Mon, 27 Mar 2006 07:45:40 -0500

> associated descriptors (in cases where they exist)?

That had not occurred to me, but, yes, this could be a way to
identify ISDs without requiring that they be available for
everything and so constitutes an implicit transition plan. 

It might, however, sacrifice one of the original goals of the
ISD -- that it, and not the technical specifications it
normatively references, essentially become the standard.  Unless
ISDs are generally available and pervasive, we lose the main
goal of John Loughney's "what standard" draft, i.e., very clear
identification of what makes up the standard and how the pieces
are related for procurement or implementation purposes.  That is
(or was) also one of the key differences between the ISD concept
and Doug's SRD concept, at least as I understand it: ISDs were
expected to be normative and standard-defining, which SRDs are
relatively less formal reference pieces.  Which is better can be
argued either way, but the community needs to decide.  And the
type of reference pairing you suggest might be a reasonable
intermediate step either way.

     john

.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 27 Mar 2006 16:32:04 +0200

It's a number of months since I read -isd-03, so I think I managed
to look at this version with reasonably fresh eyes. Here are a
few personal (non-AD) comments.

Starting at Appendix A.1, I think we should be clear which of the
cited problems the ISD proposal does and does not tackle. Here are
my views:

>    o  Relatively few specifications are now progressed beyond Proposed
>       Standard (PS) to Draft Standard (DS) level, and even fewer to Full
>       Standard (FS).

ISDs are at most a palliative for this problem. They don't fix it.

>    o  There is no formal bug reporting or tracking system in place for
>       IETF specifications.

ISDs offer a vehicle for this.

>    o  The periodic review of protocols at PS and DS levels specified in
>       are not being carried out...

ISDs are at most a palliative for this problem.

>    o  No individual or body is given the task of 'maintaining' a
>       specification after the original WG has closed down.

ISDs offer a vehicle for this.

>    o  Few Specifications Progress Beyond Proposed Standard.

ISDs are at most a palliative for this problem.

>   o  There is no Formal Bug Reporting or Tracking System.

This item seems to be present twice.

(Incidentally, it seems that RFC 3774 didn't identify the very real
problem that ISDs would solve best - the fact that it is hard for
outsiders to find out exactly which documents constitute a given
standard.)

The reason I started with this aspect is that my personal opinion
is that ISDs *alone* aren't enough - until newtrk offers real
solutions to the other problems, we aren't done.

(AD hat on for a moment - so I'd like to see revised goals and
milestones to solve all these problems.)

Now jumping to the beginning of the draft:

> 1.3.  This Proposal and the Standards Track
> 
>    This document is, explicitly, a proposal for changes to the IETF
>    Standards Track and associated procedures, not a proposal for, e.g.,
>    a supplemental document series with informational and perhaps
>    informal value.  If approved, it would
> 
>    o  Eliminate and replace the STD numbering series with a formal
>       mechanism for identifying standards that is more suited to today's
>       realities and IETF procedures.

As I suggested on the -docid thread, my preference is to grandfather
the STD numbers in.

>    o  Change the rigid sequencing of the RFC 2026 standards maturity
>       level category levels and the "downreferencing" problem discussed
>       in [RFC3967] and elsewhere to a more flexible arrangement in which
>       the relationships among various documents could be explicitly
>       discussed and explained, rather than just being assigned simple
>       and often somewhat inappropriate categories.

We had a short thread under "A different approach to the downref rule"
which I think indicated a good way to handle this.

>    o  Provide an alternate mechanism for expressing the properties of
>       "Applicability Statements" (AS) and recommendations for use (the
>       "requirement levels" of Section 3.3 of RFC 2026) without
>       eliminating the availability of formal ASs as an alternate model.

Yes. In my recent critical reading of RFC 2026 I found the AS text to
be the weakest part of it.

>    o  Eliminate the use of the BCP category for Applicability Statements
>       and other information about the status of standards-track
>       documents, including any implementation or interoperability
>       reports that are published as RFCs.

We could do this (it might even involve reclassifying some existing BCPs
as ISDs.)

>    o  Change the IETF's current environment in which RFC numbers are the
>       general identifier used for standards.  Instead, RFC numbers would
>       return to their original role as serial document identifiers.

My first reaction on reading this was "Good luck!" In fact I don't think
we will ever eliminate RFC citations - what we can do is attempt to add
ISD citations when multi-document sets are needed.

> 3.  A New Document Series
...
> 
>    While RFCs are permanent, ISD documents are expected to evolve and
>    incorporate changes over time.  However, they are also expected to
>    include explicit change histories, or a method of easily and
>    accurately generating such histories...

Why wouldn't an ISD be constructed as a string of pearls (latest first,
with a link to its predecessor)? Some sort of diff tool could be
available. This would relieve the editor of each version from building
a change history.

> 9.  Operational Issues
> 
>    There is a case to be made that creating this sort of document series
>    is additional work for the IESG...

I think the real point is that there is additional work for
the WGs or independent authors concerned, and some of it is ongoing
work to deal with revisions and corrections.

...
>    Regardless of what organizational arrangements are responsible for
>    updating and maintaining these documents, and in spite of their
>    containing a cumulative change history, they should be treated as
>    archival -- at least as archival as the RFC series.

And now I'm going to get heretical. If they are archival material,
and if their change history can be a string of pearls, why exactly
can't they be published as RFCs? Again going back to the -docid
thread, why can't STD-0007-isd be physically published as RFC 4999?

     Brian

.

---

From: John C Klensin <[email-masked]>
Date: Mon, 27 Mar 2006 10:29:35 -0500

Brian,

I'm going to need to study this, ideally after comments from
others, but I've got an airplane calling... so probably later
this week.   In the interim, one comment....

--On Monday, 27 March, 2006 16:32 +0200 Brian E Carpenter
<[email-masked]> wrote:

>...
>>    o  Change the rigid sequencing of the RFC 2026 standards
>>    maturity level category levels and the "downreferencing"
>>       problem discussed in [RFC3967] and elsewhere to a more
>>       flexible arrangement in which the relationships among
>>       various documents could be explicitly discussed and
>>       explained, rather than just being assigned simple and
>>       often somewhat inappropriate categories.
> 

draft-klensin-norm-ref-00.txt was dropped into the I-D queue
last Thursday afternoon, so I expect it to be posted RSN.  It
may not be exactly the right approach, but should at least be
sufficient to get a focused discussion started.  I'll leave it
to you (as AD) and Scott to figure out where it should most
efficiently be discussed.

More soon...

      john

.

---

From: <[email-masked]>
Date: Tue, 28 Mar 2006 09:46:49 +0300

John & Brian,
 
>> If we have designations like STD-0007-is for standards, is there any 
>> reason we shouldn't have designations like STD-0007-isd for 
>normatively references, essentially become the standard.  
>Unless ISDs are generally available and pervasive, we lose the 
>main goal of John Loughney's "what standard" draft, i.e., very 
>clear identification of what makes up the standard and how the 
>pieces are related for procurement or implementation purposes. 
> That is (or was) also one of the key differences between the 
>ISD concept and Doug's SRD concept, at least as I understand 
>it: ISDs were expected to be normative and standard-defining, 
>which SRDs are relatively less formal reference pieces.  Which 
>is better can be argued either way, but the community needs to 
>decide.  And the type of reference pairing you suggest might 
>be a reasonable intermediate step either way.

I'm not wedded to my idea, but I do note that I had a lot of possitive
feedback about proposing some solution to actually defining what
a standard is, and I'm using standard in a broad sense.  I'm
hearing lots of complaints that implementing IETF protocols is becoming
quite difficult as implementaters have to rifle through a half a dozen
or so RFCs just to implement a protocol; or the IETF needs to 
charter a WG just so we can figure out what we mean.

YMMV,
John

.

---

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 28 Mar 2006 07:11:08 -0600

From: <[email-masked]>
> charter a WG just so we can figure out what we mean.

I am not wedded to "what standards?" either, but I'm at least engaged to the 
idea that we might be able to figure out what a standards-track protocol is, 
and tell someone else.

I do note that

- Not everyone immediately needs ISDs, but the people who do, need them, 
like, five years ago. Go to http://rtg.ietf.org/~fenner/ietf/deps/index.cgi 
and type in "rfc 3261" for an amusing object lesson.

- Jonathan Rosenberg has 16 other active I-Ds, but thought it was worth his 
while to put 
http://www.ietf.org/internet-drafts/draft-rosenberg-sip-hitchhikers-guide-00.txt 
together (and he's a pretty busy guy).

- http://www3.ietf.org/proceedings/05nov/sip.html does not actually describe 
the mixed panic and amusement that broke out when the chairs showed a new 
charter milestone that included "moving SIP to Draft Standard". The 
consternation involved both (1) at least 2000 MUSTs in the SIP 
specifications, as counted by Robert Sparks, plus (2) no one actually 
knowing what SIP was ("we need something like the TCP roadmap for SIP").

- I would LOVE for it to be possible to implement SIP by reading a 
half-dozen RFCs. That would be an order of magnitude reduction in the 
current situation (even "core SIP" has more RFCs than that).

At this point, we seem to be headed back for yet another round of "is there 
really a problem?" discussions. "There really is a problem", probably not 
for everyone (it may be well-understood what SHIM6 is), but for enough 
people to justify moving forward on ISDs, independent of whether Newtrk does 
anything else or not.

We have been very conservative about RFC 3933 experiments involving the 
standards track. Perhaps there are a small number of protocols that need 
ISDs, and the rest do not. Given a choice between bootstrapping ISDs, 
solving a real problem, and looking for broader applicability, and another 
round of navel-gazing, should we consider moving forward with an ISD 
experiment?

Thanks,

Spencer 

.

---

From: Douglas Otis <[email-masked]>
Date: Tue, 28 Mar 2006 12:44:22 -0800

On Mar 27, 2006, at 10:46 PM, <[email-masked]>  
<[email-masked]> wrote:

> I'm not wedded to my idea, but I do note that I had a lot of  
> positive feedback about proposing some solution to actually  
> defining what a standard is, and I'm using standard in a broad  
> sense.  I'm hearing lots of complaints that implementing IETF  
> protocols is becoming quite difficult as implementaters have to  
> rifle through a half a dozen or so RFCs just to implement a  
> protocol; or the IETF needs to charter a WG just so we can figure  
> out what we mean.

The SRD approach attempted to establish a relatively static named  
reference to a set of RFCs that comprise various aspects of an  
endeavour.  The set, much as an I-D becomes an RFC, could commence  
with a prefix prior to the first Internet-Draft being written, and  
carry forward to being accepted when the prefix is removed, and all  
underlying documents become RFCs.  The IESG could then utilize this  
serialized reference when deeming standards and thereby avoid the  
down reference problem by flattening the status of individual RFCs.

The SRD approach avoided adding text beyond a general description of  
the endeavour.  As part of this effort, DTD and XSLT files are  
included to facilitate creation of the XML document and subsequent  
conversion to an HTML page providing relevant links.  The serialized  
aggregation of RFCs in this set offers a stable reference, and  
provides a good overview some may regard as a standard.  By not  
modifying content of the RFC through ancillary text, this ensures  
underlying RFCs are better maintained.  With the SRD aggregation,  
extensive RFC updates will not create confusion.

Once an SRD document is established, a name.serial reference offers a  
meaningful touchstone for assessing compliance.  An individual RFC  
could be used by many different endeavours, where rating compliance  
through aggregation remains problematic.  The IESG could publish,  
based upon the defined set of RFC documents (SRDs), their view of a  
compliance level obtained when adhering to the set.  This IESG view  
could make recommendations for RFC updates before allowing a set to  
be considered compliant at some level of interoperation.  The basic  
SRD goal was to ensure a motivation always remained for updating RFCs  
and thus ensuring their relevance.

The ISD approach attempted to combine views of compliance within the  
same document combining the set of RFCs.  To facilitate this effort,  
RFC sections could be modified or struck as needed within the ISD.   
Although this would provide a standard when completed, processing  
composite documents with virtual edits involves additional time and  
necessitates more difficult review and use.  If this ISD process  
proves cumbersome, very few ISDs would be produced and fewer ISDs  
would remain relevant.  Rather than updating both the RFC and the  
ISD, the approach with the least effort would be to abandon  
maintenance of RFCs.  A desire to affect the fewest number of  
documents could lead to massive ISDs needing review with increasingly  
divergent RFCs.

The SRD approach initially requires no process changes, and avoids  
aggregation of combined documents needing virtual edits.   
Maintenance, review, and use is best done with smaller and complete  
documents.  The SRD template can be offered as a simple tool.  Once  
established and adopted, separate assessments can be applied based  
upon SRD references with respect to compliance.  Once SRDs are  
generally available, flattening the designation of individual RFCs  
becomes practical.

-Doug
.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 29 Mar 2006 15:49:51 +0200

...
> At this point, we seem to be headed back for yet another round of "is 
> there really a problem?" discussions. "There really is a problem", 
> probably not for everyone (it may be well-understood what SHIM6 is), but 
> for enough people to justify moving forward on ISDs, independent of 
> whether Newtrk does anything else or not.
> 
> solving a real problem, and looking for broader applicability, and 
> another round of navel-gazing, should we consider moving forward with an 
> ISD experiment?

Well, shouldn't we discuss the docid draft first? My personal opinion is
that it looks like a fairly straightforward first step, and leaves the
way open for people to write ISD-like documents (or, if you prefer,
Applicability Statements on steroids) without even going outside
RFC 2026.

     Brian

.

---

From: Douglas Otis <[email-masked]>
Date: Wed, 29 Mar 2006 12:25:29 -0800

On Mar 29, 2006, at 5:49 AM, Brian E Carpenter wrote:

> ...
>> At this point, we seem to be headed back for yet another round of  
>> "is there really a problem?" discussions. "There really is a  
>> problem", probably not for everyone (it may be well-understood  
>> what SHIM6 is), but for enough people to justify moving forward on  
>> ISDs, independent of whether Newtrk does anything else or not.
>> We have been very conservative about RFC 3933 experiments  
>> involving the standards track. Perhaps there are a small number of  
>> protocols that need ISDs, and the rest do not. Given a choice  
>> between bootstrapping ISDs, solving a real problem, and looking  
>> for broader applicability, and another round of navel-gazing,  
>> should we consider moving forward with an ISD experiment?
>
> Well, shouldn't we discuss the docid draft first?

The concept of extending the STD numbering scheme to sub-STD  
categories places the association role onto the RFC-editor.   
Assigning an organizational effort will be needed to some degree for  
existing documents.  Compared to the SRD scheme, this organization is  
introduced later in a draft's lifetime, although the WD designation  
allows predictive assignments of RFC numbers by the IESG to hasten an  
associative categorization.  Of course, a favorable comparison for  
the DocID scheme would be with respect to the current STD  
assignment.  (Not a very high bar.)

As an alternative, a scheme could permit originators to indicate  
where the draft is expected to reside within an hierarchal lineage  
and category.  As the draft matures, this pre-assignment would reduce  
the burden the DocID scheme would place upon the RFC-editor.  Using  
several numbering schemes, where a document could be reassign to a  
different sequence, also introduces a level of complexity and confusion.

The SRD approach utilized name.serial references and sub-categories  
of core, extension, guidance, replaces, experimental, and companion  
(other SRDs).  With an SRD, the same I-D or RFC could appear in  
several simultaneous definitions.  This flexibility is not a property  
supported by the simultaneous  conformance-mnemonic:number:category  
scheme proposed in the DocID draft.  The SRD approach allowed  
separate maturity levels to share a common user-friendly text-label.   
These standardized sequences could reference the SRD name.serial and  
treat RFCs as a flattened set.  When a higher serial number exists  
for the text-label, it would be understood to represent the same  
endeavour in a different state.  The prefix/serialization scheme used  
by the SRD allows a simple prediction of the next state designator.  
(There would be no need to predict RFC numbers.)  The SRD approach  
offers a simpler maturity designation and a comprehensible  
association of documents related to a common endeavor.

Multiple sequences and IESG predictive RFC numbering do not seem a  
good method for communicating what documents are related to an  
endeavour, and which documents represent stable interoperability.  It  
should be possible to provide web based tools that allow both WG and  
individuals to assemble their view of what belongs within an RFC  
set.  The IESG and external organizations could then offer  
designations based upon those documents.  The RFC-editor would then  
not be left deciding what is needed for a particular endeavour, and  
in what category a document should reside.

-Doug

.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 30 Mar 2006 14:50:16 +0200

Douglas Otis wrote:
>>> problem", probably not for everyone (it may be well-understood  what 
>>> SHIM6 is), but for enough people to justify moving forward on  ISDs, 
>>> independent of whether Newtrk does anything else or not.
>>> We have been very conservative about RFC 3933 experiments  involving 
>>> the standards track. Perhaps there are a small number of  protocols 
>>> that need ISDs, and the rest do not. Given a choice  between 
>>> bootstrapping ISDs, solving a real problem, and looking  for broader 
>>> applicability, and another round of navel-gazing,  should we consider 
>>> moving forward with an ISD experiment?
>>
>>
> The concept of extending the STD numbering scheme to sub-STD  categories 
> places the association role onto the RFC-editor.

I thought it was explicitly placed on the IESG.

>  Assigning an 
> organizational effort will be needed to some degree for  existing 
> documents.  Compared to the SRD scheme, this organization is  introduced 
> later in a draft's lifetime, although the WD designation  allows 
> predictive assignments of RFC numbers by the IESG to hasten an  
> associative categorization.  Of course, a favorable comparison for  the 
> DocID scheme would be with respect to the current STD  assignment.  (Not 
> a very high bar.)

Exactly, simplicity and incremental change.

     Brian
> 
> As an alternative, a scheme could permit originators to indicate  where 
> the draft is expected to reside within an hierarchal lineage  and 
> category.  As the draft matures, this pre-assignment would reduce  the 
> burden the DocID scheme would place upon the RFC-editor.  Using  several 
> numbering schemes, where a document could be reassign to a  different 
> sequence, also introduces a level of complexity and confusion.
> 
> The SRD approach utilized name.serial references and sub-categories  of 
> core, extension, guidance, replaces, experimental, and companion  (other 
> SRDs).  With an SRD, the same I-D or RFC could appear in  several 
> simultaneous definitions.  This flexibility is not a property  supported 
> by the simultaneous  conformance-mnemonic:number:category  scheme 
> proposed in the DocID draft.  The SRD approach allowed  separate 
> maturity levels to share a common user-friendly text-label.   These 
> standardized sequences could reference the SRD name.serial and  treat 
> RFCs as a flattened set.  When a higher serial number exists  for the 
> text-label, it would be understood to represent the same  endeavour in a 
> different state.  The prefix/serialization scheme used  by the SRD 
> allows a simple prediction of the next state designator.  (There would 
> be no need to predict RFC numbers.)  The SRD approach  offers a simpler 
> maturity designation and a comprehensible  association of documents 
> related to a common endeavor.
> 
> Multiple sequences and IESG predictive RFC numbering do not seem a  good 
> method for communicating what documents are related to an  endeavour, 
> and which documents represent stable interoperability.  It  should be 
> possible to provide web based tools that allow both WG and  individuals 
> to assemble their view of what belongs within an RFC  set.  The IESG and 
> external organizations could then offer  designations based upon those 
> documents.  The RFC-editor would then  not be left deciding what is 
> needed for a particular endeavour, and  in what category a document 
> should reside.
> 
> -Doug
> 
> 
> 
> 
> 
> .
.

---

From: Douglas Otis <[email-masked]>
Date: Thu, 30 Mar 2006 11:09:55 -0800

> I thought it was explicitly placed on the IESG.

Section 3 paragraph 2 has the RFC-editor making initial  
serializations and categorizations.  When new documents are  
processed, then the IESG decides.  This places a substantial share of  
the effort onto the RFC-editor.  The SRD approach allows this process  
to be carried forward by members of the IETF, where final acceptance  
is determined by the IESG, and where publishing and consistency  
checking is handled by the RFC-editor.  The SRD approach offers more  
than just recommendations to the IESG, while also providing a better  
overview for checks done by the RFC-editor.

The DocID draft, although moving in the right direction, delegates  
efforts that might be done by the IETF community.  The SRD draft was  
to illustrate providing requisite tools for such an IETF effort was  
possible.

>> Assigning an organizational effort will be needed to some degree  
>> for existing documents.  Compared to the SRD scheme, this  
>> organization is introduced later in a draft's lifetime, although  
>> the WD designation allows predictive assignments of RFC numbers by  
>> the IESG to hasten an associative categorization.  Of course, a  
>> favorable comparison for the DocID scheme would be with respect to  
>> the current STD  assignment.  (Not a very high bar.)
>

RFCs not exclusive to a single endeavour requires fragmentation of a  
numbering scheme, which might impact categorization as well.  DocID  
favors fragmentation.  The SRD approach requires less change to  
existing procedures, does not require set fragmentation, nor require  
predictive assignments of RFCs.  The next sequence in the name.serial  
reference of an SRD would be where a new change to an existing  
endeavour could be found.  Once SRDs are widely established, a small  
change to the procedures would be to transfer rankings of the  
individual RFCs to SRDs.  From that simple transition, RFCs would  
hence offer a flat ranking and thus not create an impediment that  
still exists within the DocID numbering overlay.

-Doug

.