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
- [newtrk] I-D ACTION:draft-ietf-newtrk-repurposing… Internet-Drafts
- [newtrk] draft-ietf-newtrk-repurposing-isd-04.txt Douglas Otis
- Re: [newtrk] draft-ietf-newtrk-repurposing-isd-04… John C Klensin
- Re: [newtrk] draft-ietf-newtrk-repurposing-isd-04… Brian E Carpenter
- Re: [newtrk] draft-ietf-newtrk-repurposing-isd-04… John C Klensin
- [newtrk] Re: I-D ACTION:draft-ietf-newtrk-repurpo… Brian E Carpenter
- Re: [newtrk] Re: I-D ACTION:draft-ietf-newtrk-rep… John C Klensin
- RE: [newtrk] draft-ietf-newtrk-repurposing-isd-04… john.loughney
- Re: [newtrk] draft-ietf-newtrk-repurposing-isd-04… Spencer Dawkins
- Re: [newtrk] draft-ietf-newtrk-repurposing-isd-04… Douglas Otis
- Re: [newtrk] draft-ietf-newtrk-repurposing-isd-04… Brian E Carpenter
- Re: [newtrk] draft-ietf-newtrk-repurposing-isd-04… Douglas Otis
- Re: [newtrk] draft-ietf-newtrk-repurposing-isd-04… Brian E Carpenter
- Re: [newtrk] draft-ietf-newtrk-repurposing-isd-04… Douglas Otis