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

Douglas Otis <dotis@mail-abuse.org> Thu, 30 March 2006 19:12 UTC

Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP2Yq-0006lT-1e for newtrk-archive@lists.ietf.org; Thu, 30 Mar 2006 14:12:00 -0500
Received: from mailapps.uoregon.edu ([128.223.142.45]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FP2Yo-0003o2-Kx for newtrk-archive@lists.ietf.org; Thu, 30 Mar 2006 14:12:00 -0500
Received: from mailapps.uoregon.edu (IDENT:U2FsdGVkX19vln9HUkJAIIrXdS3ljHtT8P6/HRvaKJY@localhost [127.0.0.1]) by mailapps.uoregon.edu (8.13.6/8.13.6) with ESMTP id k2UJ9oj6029765; Thu, 30 Mar 2006 11:09:50 -0800
Received: (from majordom@localhost) by mailapps.uoregon.edu (8.13.6/8.13.6/Submit) id k2UJ9owP029763; Thu, 30 Mar 2006 11:09:50 -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 k2UJ9lNc029758 for <newtrk@lists.uoregon.edu>; Thu, 30 Mar 2006 11:09:47 -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 k2UJ9hIB010174 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 30 Mar 2006 11:09:45 -0800
In-Reply-To: <442BD408.60302@zurich.ibm.com>
References: <615BD9B54CB01B41838C323DB9E91AAB0C9111@esebe100.NOE.Nokia.com> <047501c65269$13f784b0$ea087c0a@china.huawei.com> <442A907F.8030102@zurich.ibm.com> <B371C83E-C452-47D9-871B-6E58FD6D1EBF@mail-abuse.org> <442BD408.60302@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: <57966838-A7F8-4492-A9FA-00F0E4143FA9@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: Thu, 30 Mar 2006 11:09:55 -0800
To: Brian E Carpenter <brc@zurich.ibm.com>
X-Mailer: Apple Mail (2.746.3)
X-Virus-Scanned: ClamAV 0.88/1363/Wed Mar 29 12:38:37 2006 on mailapps
X-Virus-Status: Clean
Sender: owner-newtrk@lists.uoregon.edu
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab

On Mar 30, 2006, at 4:50 AM, Brian E Carpenter wrote:

> Douglas Otis wrote:
>> On Mar 29, 2006, at 5:49 AM, Brian E Carpenter wrote:
>>>
>>> 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.
>
> 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.)
>
> Exactly, simplicity and incremental change.

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



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