Re: My notes on draft-carpenter-newtrk-questions-00.txt

Douglas Otis <dotis@mail-abuse.org> Fri, 14 July 2006 17:37 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1Rbj-0005YL-Pi; Fri, 14 Jul 2006 13:37:43 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1Rbi-0005XS-1x for ietf@ietf.org; Fri, 14 Jul 2006 13:37:42 -0400
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1Q1h-0004xZ-1q for ietf@ietf.org; Fri, 14 Jul 2006 11:56:25 -0400
Received: from b.mail.sonic.net ([64.142.19.5]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G1Pmd-0000R8-Dm for ietf@ietf.org; Fri, 14 Jul 2006 11:40:53 -0400
Received: from [132.219.6.220] (h06dc-net84db.lab.risq.net [132.219.6.220] (may be forged)) (authenticated bits=0) by b.mail.sonic.net (8.13.8.Beta0/8.13.7) with ESMTP id k6EFefKt004163 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 14 Jul 2006 08:40:42 -0700
In-Reply-To: <Pine.LNX.4.10.10607140650130.32657-100000@shell4.bayarea.net>
References: <Pine.LNX.4.10.10607140650130.32657-100000@shell4.bayarea.net>
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
Message-Id: <50AFB8A5-3FF0-44D7-A56B-9E8CDE9B4219@mail-abuse.org>
Content-Transfer-Encoding: 7bit
From: Douglas Otis <dotis@mail-abuse.org>
Date: Fri, 14 Jul 2006 11:40:38 -0400
To: "C. M. Heard" <heard@pobox.com>
X-Mailer: Apple Mail (2.752.2)
X-Spam-Score: -2.6 (--)
X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f
Cc: ietf@ietf.org
Subject: Re: My notes on draft-carpenter-newtrk-questions-00.txt
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Errors-To: ietf-bounces@ietf.org

On Jul 14, 2006, at 9:59 AM, C. M. Heard wrote:
>
> Very well said.  As I said in my message of 18 June, my advice  
> would be to make a relatively minor set of clarifications to BCP 9  
> (RFC 2026) and move on.  It would also be OK for newtrk to refocus  
> on its original charter of simplifying the standards track.  But I  
> would be very dismayed to see it focus on document relationships.

Few RFCs are stand-alone elements for developing interchange.  When  
flattening document categorization, conveying levels of interchange  
remains problematic.  Evolution of document relationships remain an  
element poorly handled by composing these sets within RFCs  
themselves, which are likely rapidly dated.  A tracking system not  
encumbered with inclusion of normative language ensures a working-set  
can be tracked in a reasonable fashion.  Much of the RFC review  
process and utilization depends upon understanding what is the  
intended set.  The Name.Serial proposals as found in both the ISD and  
SRD proposals provides a means for both tracking this evolution,  
while also stabilizing references used to uncover document sets.   
Often as documents change, reference to the prior set may be  
considered by the community as Stable, whereas the latest set, as  
Current.  Stable versus Current is too dynamic to be tracked by a  
highly formalized process.  The IETF could publish a list of  
interchange categories as just Name.Serial on a web page, for example.

Once the process is understood to be broken, it should also be  
obvious that it would have also been fixed had this information been  
useful.  Those actually using the information have been well served  
by the efforts focused upon providing document relationships.  It  
would also seem more appropriate to categorize the document sets  
rather than individual RFCs.  There could by a set that includes the  
single RFC, but that will likely be the exception and not the rule.

-Doug



_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf