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

Douglas Otis <dotis@mail-abuse.org> Tue, 28 March 2006 20:46 UTC

Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOL50-0006It-Eg for newtrk-archive@lists.ietf.org; Tue, 28 Mar 2006 15:46:18 -0500
Received: from mailapps.uoregon.edu ([128.223.142.45]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOL4y-0006EV-03 for newtrk-archive@lists.ietf.org; Tue, 28 Mar 2006 15:46:18 -0500
Received: from mailapps.uoregon.edu (IDENT:U2FsdGVkX19bpTEsZckSA2xVyZrOD80s6lmb31rxvPg@localhost [127.0.0.1]) by mailapps.uoregon.edu (8.13.6/8.13.6) with ESMTP id k2SKicPE010170; Tue, 28 Mar 2006 12:44:38 -0800
Received: (from majordom@localhost) by mailapps.uoregon.edu (8.13.6/8.13.6/Submit) id k2SKicC1010168; Tue, 28 Mar 2006 12:44:38 -0800
Received: from b.mail.sonic.net (b.mail.sonic.net [64.142.19.5]) by mailapps.uoregon.edu (8.13.6/8.13.6) with ESMTP id k2SKiboq010163 for <newtrk@lists.uoregon.edu>; Tue, 28 Mar 2006 12:44:37 -0800
Received: from [168.61.10.151] (SJC-Office-DHCP-151.Mail-Abuse.ORG [168.61.10.151]) (authenticated bits=0) by b.mail.sonic.net (8.13.6/8.13.3) with ESMTP id k2SKiELU002215 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 28 Mar 2006 12:44:15 -0800
In-Reply-To: <615BD9B54CB01B41838C323DB9E91AAB0C9111@esebe100.NOE.Nokia.com>
References: <615BD9B54CB01B41838C323DB9E91AAB0C9111@esebe100.NOE.Nokia.com>
Mime-Version: 1.0 (Apple Message framework v746.3)
Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
Message-Id: <32466013-612B-401D-8F80-BCAEECAEE5DF@mail-abuse.org>
Cc: john-ietf@jck.com, brc@zurich.ibm.com, 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: Tue, 28 Mar 2006 12:44:22 -0800
To: "<john.loughney@nokia.com>" <john.loughney@nokia.com>
X-Mailer: Apple Mail (2.746.3)
X-Virus-Scanned: ClamAV 0.88/1360/Tue Mar 28 11:21:07 2006 on mailapps
X-Virus-Status: Clean
Sender: owner-newtrk@lists.uoregon.edu
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955

On Mar 27, 2006, at 10:46 PM, <john.loughney@nokia.com>  
<john.loughney@nokia.com> 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
.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html