Re: [newtrk] draft-ietf-newtrk-repurposing-isd-04.txt

Douglas Otis <dotis@mail-abuse.org> Wed, 29 March 2006 20:27 UTC

Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOhG2-0002iF-7b for newtrk-archive@lists.ietf.org; Wed, 29 Mar 2006 15:27:10 -0500
Received: from mailapps.uoregon.edu ([128.223.142.45]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOhG0-0007R8-Q3 for newtrk-archive@lists.ietf.org; Wed, 29 Mar 2006 15:27:10 -0500
Received: from mailapps.uoregon.edu (IDENT:U2FsdGVkX18eWvofT2A6uO39yFlCQcdFDRIxL5XEdpY@localhost [127.0.0.1]) by mailapps.uoregon.edu (8.13.6/8.13.6) with ESMTP id k2TKPLK0003911; Wed, 29 Mar 2006 12:25:21 -0800
Received: (from majordom@localhost) by mailapps.uoregon.edu (8.13.6/8.13.6/Submit) id k2TKPL7c003909; Wed, 29 Mar 2006 12:25:21 -0800
Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by mailapps.uoregon.edu (8.13.6/8.13.6) with ESMTP id k2TKPKTd003904 for <newtrk@lists.uoregon.edu>; Wed, 29 Mar 2006 12:25:20 -0800
Received: from [168.61.10.151] (SJC-Office-DHCP-151.Mail-Abuse.ORG [168.61.10.151]) (authenticated bits=0) by a.mail.sonic.net (8.13.6/8.13.3) with ESMTP id k2TKPJbm011822 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 29 Mar 2006 12:25:19 -0800
In-Reply-To: <442A907F.8030102@zurich.ibm.com>
References: <615BD9B54CB01B41838C323DB9E91AAB0C9111@esebe100.NOE.Nokia.com> <047501c65269$13f784b0$ea087c0a@china.huawei.com> <442A907F.8030102@zurich.ibm.com>
Mime-Version: 1.0 (Apple Message framework v746.3)
Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
Message-Id: <B371C83E-C452-47D9-871B-6E58FD6D1EBF@mail-abuse.org>
Cc: Spencer Dawkins <spencer@mcsr-labs.org>, newtrk@lists.uoregon.edu
Content-Transfer-Encoding: 7bit
From: Douglas Otis <dotis@mail-abuse.org>
Subject: Re: [newtrk] draft-ietf-newtrk-repurposing-isd-04.txt
Date: Wed, 29 Mar 2006 12:25:29 -0800
To: Brian E Carpenter <brc@zurich.ibm.com>
X-Mailer: Apple Mail (2.746.3)
X-Virus-Scanned: ClamAV 0.88/1361/Tue Mar 28 22:50:38 2006 on mailapps
X-Virus-Status: Clean
Sender: owner-newtrk@lists.uoregon.edu
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17

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





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