An updated ISD proposal

John C Klensin <> Mon, 05 July 2010 17:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2B4283A69AD for <>; Mon, 5 Jul 2010 10:11:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TSLi+UFkeX4g for <>; Mon, 5 Jul 2010 10:11:19 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 017713A6852 for <>; Mon, 5 Jul 2010 10:11:18 -0700 (PDT)
Received: from [] (helo=localhost) by with esmtp (Exim 4.34) id 1OVpCR-000HHH-Si for; Mon, 05 Jul 2010 13:11:20 -0400
Date: Mon, 05 Jul 2010 13:11:19 -0400
From: John C Klensin <>
Subject: An updated ISD proposal
Message-ID: <E1FD55728D460060648062A8@[]>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 05 Jul 2010 17:11:20 -0000


As mentioned in the analysis of
draft-housley-two-maturity-levels I posted yesterday, I've made
a pass through the old (NEWTRK-vintage) ISD specification.  A
new version is in the posting queue as draft-klensin-isdbis-00.

While the flavor and much of the text of the old version is
still present, it has been significantly revised to address both
some of the issues raised in the last few weeks and the concerns
about workload raised by the IESG of five years ago.

In particular:

	* The "providing information about a document" (the
	maturity level issue) and the "grouping documents" (the
	STD issue) are given equal weight.
	* A lighter-weight transition plan is incorporated.
	* ISD numbers (to be assigned to anything reaching the
	standards-track) and ISD documents are separated (we may
	want to change the name if this goes anywhere).   The
	latter are required only for specifications for which
	information that supplements the RFC is, or should be,
	required anyway, e.g., interoperability reports,
	descriptions of relationships to older versions,
	descriptions of relationships of multiple documents that
	make up a single standard.
	* The minimum information required in an ISD document
	(if one is required at all) is capable of being
	automatically generated.

As the last NEWTRK ISD document and discussions indicated, it is
always possible to dispose of a proposal like this by
nit-picking at the details and ignoring the larger picture or by
complaining that insufficient details have been provided.  I've
tried to strike a better balance in this version than the
earlier one had, but I can only hope that people will try to
understand the principles and that, while I've proposed a
combination of details that I believe will work, details can
always be tuned.

It is long (largely as a result of including enough detail to be
taken seriously), but, if one believes that the problems with
the system run a little deeper than the descriptions in
draft-housley-two-maturity-levels and that they deserve a more
comprehensive approach rather than slapping on patches of
terminology and levesl, it may be worth having a look.