draft-carpenter-newtrk-questions

Douglas Otis <dotis@mail-abuse.org> Sat, 10 June 2006 13:27 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fp3Ub-0003zR-6h; Sat, 10 Jun 2006 09:27:09 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fp3UZ-0003zJ-KH for ietf@ietf.org; Sat, 10 Jun 2006 09:27:07 -0400
Received: from a.mail.sonic.net ([64.142.16.245]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fp3UY-0005IC-6R for ietf@ietf.org; Sat, 10 Jun 2006 09:27:07 -0400
Received: from [192.168.2.11] (64-142-13-68.dsl.static.sonic.net [64.142.13.68]) (authenticated bits=0) by a.mail.sonic.net (8.13.6/8.13.3) with ESMTP id k5ADR4Ab001839 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Sat, 10 Jun 2006 06:27:05 -0700
From: Douglas Otis <dotis@mail-abuse.org>
To: Brian E Carpenter <brc@zurich.ibm.com>
In-Reply-To: <448A7209.7080700@zurich.ibm.com>
References: <448A7209.7080700@zurich.ibm.com>
Content-Type: text/plain
Date: Sat, 10 Jun 2006 06:27:01 -0700
Message-Id: <1149946022.18610.66.camel@bash.adsl-64-142-13-68>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.3 (2.2.3-4.fc4)
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352
Cc: IETF discussion list <ietf@ietf.org>
Subject: draft-carpenter-newtrk-questions
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 Sat, 2006-06-10 at 09:17 +0200, Brian E Carpenter wrote:

> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-carpenter-newtrk-questions-00.txt

,---
|The three possible ways forward are:
|
| 1.  Agree that, apart from day to day efforts to improve efficiency,
|     the problems with the existing standards track are not serious
|     enough to justify the effort needed to make substantial changes.
|     Conclude that [RFC3774] exagerrated the problem and we only need
|     to make a relatively minor set of clarifications to BCP 9
|     [RFC2026].
| 2.  Focus on the issue of document relationships, or as the newtrk
|     charter currently says "the creation of a new series of short
|     IESG-approved IETF documents to describe and define IETF
|     technology standards."
| 3.  Focus on the three-stage standards track, or as the newtrk
|     charter currently says "agree on a revised IETF Standards
|     Track... to replace the standards track described in RFC 2026."
'---

Step 2 should be the first step taken to achieve a description of the
relationships in a simple, easy to maintain fashion.  The <name.serial>
provides clarity by offering a name rather than a number that is easier
to remember, and secondly a sequential number to allow a prediction of
the identifier for the next document when it finally emerges.  The
relationships, friendly name, and a clear sequence is missing within the
current structure. 

Once the existence of a relational document is instantiated, then 
Step 3 may seek to flatten the RFC documents by imposing a structure of
similar design to that of Step 2 indicating the level of the
<name.serial> documents and indirectly elevating or lowering the related
documents.  

Once Step 2 and then Step 3 are taken, the person isolated on some
remote island only afforded IETF documents should have little trouble
understanding what should be used to fulfill their goals.

-Doug



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