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
- [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