Re: "Normative"? (Re: [newtrk] SRD - normative or not?)

John C Klensin <john-ietf@jck.com> Thu, 20 October 2005 19:48 UTC

Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESgPF-0000p0-RN for newtrk-archive@megatron.ietf.org; Thu, 20 Oct 2005 15:48:54 -0400
Received: from mailapps.uoregon.edu (mailapps.uoregon.edu [128.223.142.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09816 for <newtrk-archive@lists.ietf.org>; Thu, 20 Oct 2005 15:48:40 -0400 (EDT)
Received: from mailapps.uoregon.edu (IDENT:U2FsdGVkX1/RzaAAcCJ9rYHYqzbEHQclv1KWzwZB+s8@localhost [127.0.0.1]) by mailapps.uoregon.edu (8.13.4/8.13.4) with ESMTP id j9KJkB6Q023606; Thu, 20 Oct 2005 12:46:11 -0700
Received: (from majordom@localhost) by mailapps.uoregon.edu (8.13.4/8.13.4/Submit) id j9KJkBH1023605; Thu, 20 Oct 2005 12:46:11 -0700
Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by mailapps.uoregon.edu (8.13.4/8.13.4) with ESMTP id j9KJkAJq023601 for <newtrk@lists.uoregon.edu>; Thu, 20 Oct 2005 12:46:10 -0700
Received: from [209.187.148.215] (helo=scan.jck.com) by bs.jck.com with esmtp (Exim 4.34) id 1ESgMc-00042P-0q for newtrk@lists.uoregon.edu; Thu, 20 Oct 2005 15:46:10 -0400
Date: Thu, 20 Oct 2005 15:46:09 -0400
From: John C Klensin <john-ietf@jck.com>
To: 'NEWTRK Mailing List' <newtrk@lists.uoregon.edu>
Subject: Re: "Normative"? (Re: [newtrk] SRD - normative or not?)
Message-ID: <0CD2BF048F97752BFF54332A@scan.jck.com>
In-Reply-To: <1129816903.4314.10.camel@bash.adsl-64-142-13-68>
References: <001901c5d07d$12441bb0$1df1070a@corp.adobe.com> <9A48C561-95E6-4AD4-8F6D-C5202F920D6C@mail-abuse.org> <E7F40996197A9D2E9F2B7C96@scan.jck.com> <20051019155612.GB30745@verdi> <7139B2CC52714EC90000576D@B50854F0A9192E8EC6CDA126> <1129816903.4314.10.camel@bash.adsl-64-142-13-68>
X-Mailer: Mulberry/4.0.4 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: owner-newtrk@lists.uoregon.edu
Precedence: bulk
Reply-To: John C Klensin <john-ietf@jck.com>
Content-Transfer-Encoding: 7bit

I continue to have trouble figuring out any other inherent
difference between ISDs and SRDs besides an issue that now
hinges around a word that no one seem to like.  Because of that,
let me restate things without that word.   Then I'm going to go
back to lurking because I believe that the IESG (via comments on
this list and in Paris and Minneapolis) and the IETF Chair (via
the creation of the PESCI effort) have told us that real
proposals for standards-track changes via the Newtrk WG are
irrelevant.

The ISD proposal was, and is, intended to make a fundamental
change to way in which we consider, review, and publish
standards, or if one prefers, standards-track documents.  Under
that model, Last Calls occur on ISDs, IETF publication is of
ISDs, and the ISDs are the standards.  RFCs become nothing more
or less than technical specifications that are referenced from
ISDs to define the specific details of those standards.  In
principle, ISDs can also reference non-RFC documents as part of
the definition of standards.  ISDs change, RFCs do not.   In
that respect, the ISD proposal was intended to respond to the
very fundamental set of questions that John Loughney wrote up,
and that he and many others have raised, about what is and is
not a standard, what is or is not required to implement a
standard, and how one refers compactly and precisely to
standards. 

As part of that change, ISDs are intended to provide an
optional/ alternative mechanism to deal with the portions of the
"Applicability Statement" and "recommendation level" mechanisms
that we have used very little, probably too little, in recent
years.  As one example, they would provide an easy way to record
and state an IETF consensus position that, to use Harald's
recent example, one just shouldn't bother with some component of
what would otherwise be an element of a standard.

That fundamental change permits evolving the existing
three-stage --really three-category-- standards track with a
model that permits much finer and more adaptable system of
descriptions than the simplistic ordinal set of categories and
to do so without generating more RFCs as an end in themselves.
It is precisely that change which, IMO, puts it on-topic for
newtrk.  It is not clear to me that any proposal to generate new
supplemental documents with no direct standards effect are on
topic for newtrk, but I'll leave most of that argument to others.

One can agree or not with that model of how to "fix" the
standards track.   I find it remarkable that we have had very
little discussion on the model itself, especially recently.
What discussion we have had seems to have been, at least in my
impression, largely supportive.

In addition, there have been lots of discussions about details
that, whether they appear in various documents as examples or
not, are mostly irrelevant to that fundamental model and
decision.  As I have said many times, I (and John L.) put a
number of details into the ISD documents, and Harald, Scott, and
I put a number of details into examples, just to provide a
foundation for discussion.  In particular, none of the following
are important to the ISD concept:

	* The formats of those example details
	
	* Whether representation is in XML, HTML, plain text,
	ISO Standard PDL, or something else is not important
	(except insofar as having the documents be the
	fundamental representation/definition of what is
	standardized requires a level of stability that might
	not be consistent with some formats or representations.
	
	* Whether errata are included, referenced, or not
	touched at all
	
	* Whether a distinction is made between errata that are
	formally approved within an IETF consensus process and
	errata that are not and, if so, what the consensus
	process for the approval might be.
	
	* Whether particular types of text are best included in
	the ISD or referenced to some other repository.

	* Whether is is appropriate to reference documents that
	are not part of the standard (whatever that means) as
	useful ancillary information and, hence, whether it is
	appropriate to reference the same document in more than
	one ISD.  I personally consider this one a no-brainer,
	but others may disagree.
	
	* Whether ISDs have titles, numbers, abstracts, formal
	authors, or a number of other structural arrangements.

	* How the sections of ISDs are ordered

	* Whether we try to produce ISD skeletons for existing
	standards or just leave those standards alone until
	someone gets motivated on a case by case basis.  If we
	do try to produce those skeletons, whether we try to do
	it automatically and accept whatever the automatic
	process produces or, at the other extreme, whether we
	try to organize teams to do protocol archeology,
	describe what they find, and subject their results to
	IETF Last Call.
	
	* And so on, for a fairly long list.

Now, to me, Newtrk has one critical question here if, indeed, it
has any further utility as a WG at all (other than approval of
the decruft stuff).  That critical question is whether we want
to see a new document or metadocument series that has the
"defining what is a standard" property.  Once that question is
answered, I think we (and the relevant AD) need to sort out
whether we have any real agenda left and, if so, a way to answer
the sorts of format and organizational questions identified
above and about whatever other superficial differences exist
between SRDs and ISDs.  

Speaking personally, if we embark on that effort, I don't care
what the critters are called nor do I care which documents are
used as a base/ starting point.  Actually, I have a slight
preference for starting from the SRD documents (again,
independent of what things are called), since Doug seems to have
more time and patience for this enterprise than I do right now.

regards,
    john


.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html