Subject: [newtrk] Re: I-D ACTION:draft-ietf-newtrk-repurposing-isd-00.txt

From: Pekka Savola <[email-masked]>
Date: Fri, 15 Oct 2004 16:25:18 +0300 (EEST)

On Fri, 24 Sep 2004 [email-masked] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the New IETF Standards Track Discussion Working Group of the IETF.
> 
> 	Title		: Internet Standards Documentation (ISDs)
> 	Author(s)	: J. Klensin, J. Loughney
> 	Filename	: draft-ietf-newtrk-repurposing-isd-00.txt
> 	Pages		: 15
> 	Date		: 2004-9-24

Not much to say here, based on quick read.  Seems like a good idea, 
but I've said this in the past ;-).

The biggest thing missing was that section 10 discussed whether the
external parties reference ISDs or RFCs, but I would have been
interested in having some discussion what IETF RFCs should be doing..  
for example, for normative references especially for documents at
proposed or draft standard.  ISDs vs the specific RFCs?  There are
tradeoffs both ways, I think.

semi-editorial
--------------

8.  Transition
[...]

   o  Omit any applicability, errata, or similar sections.
 
==> but it would make sense to provide the link to RFC-editor's errata 
page for that particular document (esp. if errata exists).

editorial
---------

The
   low level of involvement of the IESG in the classification process is
   probably several problems waiting to happen.

==> "is probably ..." -- is this good grammar ?

   Date.* This is the data the ISD was last updated.  Everything else
 
==> s/data/date/

Initial assignments and drafts should be created on an
      area basis, preferably by directorates or specially-selected
      committees, coordinates with any reclassification efforts to avoid
      duplicate work.

==> s/coordinates/coordinating/ ?

  There is a case to be made that creating this sort of document 
series
   is additional work for the IESG.  In practice, the authors doesn't
   believe it,

==> s/doesn't/don't/

   customers, this mechanism is not likely to help very much either.  It
   does, however, provide a third option, which is to specify the state
   of an STD as of a particular date (even a date in the past or future)
   or within a particular date range.  So, whatever the referencing
 
==> s/STD/ISD/ ?

   The general ideas described here have been discussed on and off for
   several years, but have never been turned into a public documents.

==> remove " a "

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

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

---

From: John C Klensin <[email-masked]>
Date: Sun, 17 Oct 2004 09:39:02 -0400

--On Friday, October 15, 2004 4:25 PM +0300 Pekka Savola 
<[email-masked]> wrote:

>> A New Internet-Draft is available from the on-line
>> Internet-Drafts directories. This draft is a work item of the
>> New IETF Standards Track Discussion Working Group of the IETF.
>>
> Not much to say here, based on quick read.  Seems like a good
> idea,  but I've said this in the past ;-).
>
> The biggest thing missing was that section 10 discussed
> whether the external parties reference ISDs or RFCs, but I
> would have been interested in having some discussion what IETF
> RFCs should be doing..   for example, for normative references
> especially for documents at proposed or draft standard.  ISDs
> vs the specific RFCs?  There are tradeoffs both ways, I think.

I think you are right, although that wasn't the reason I/we left 
it out.  I think the answer depends on what the referencing 
documents are trying to accomplish and what the references have 
to say, i.e., the tradeoff between "current version" and 
"version as of when this doc was written so I know exactly what 
it means".  Even in the latter case, one could reference either 
an RFC or an ISD spec as of some date.  My own guess is that we 
are likely to evolve toward the latter for many purposes, but 
there will still be situations in which a reference to a 
specific RFC would be more important.

I can also imagine references being constructed in terms of RFC 
nnnn, but with a note/annotation pointing to the ISD for updated 
information.

In terms of references across maturity levels, there is 
deliberately nothing in this document that changes those rules. 
There are two reasons for that: (i) If we change the standards 
track in terms of definitions or number of levels, the rules 
will need to be reviewed anyway and (ii) the community will 
really need to decide, with the advice of the RFC Editor, 
whether an ISD that defines maturity levels and risks is an 
adequate substitute for a reference to a more mature document.

> ==> but it would make sense to provide the link to
> RFC-editor's errata  page for that particular document (esp.
> if errata exists).

If it exists, certainly.   Fixed in -01.

> editorial
> ---------
>
> The
>    low level of involvement of the IESG in the classification
> process is    probably several problems waiting to happen.
>

Yes, actually, although it will probably produce an 
arm-wrestling match with the RFC Editor when it reaches them 
:-).  Are you concerned about the singular "is" or the "is 
probably" rather than "probably is" construction?

>    Date.* This is the data the ISD was last updated.

fixed

>       area basis, preferably by directorates or
> specially-selected       committees, coordinates with any
> reclassification efforts to avoid       duplicate work.
>

fixed

>   There is a case to be made that creating this sort of
> document  series
>    is additional work for the IESG.  In practice, the authors
> doesn't    believe it,
>
> ==> s/doesn't/don't/

Sorry.  A symptom of a too-quick merge.  Fixed.

>    customers, this mechanism is not likely to help very much
> either.  It    does, however, provide a third option, which is
> to specify the state    of an STD as of a particular date
> (even a date in the past or future)    or within a particular
> date range.  So, whatever the referencing
> ==> s/STD/ISD/ ?

Sigh.  Another merge symptom.  Fixed.

>    The general ideas described here have been discussed on and
> off for    several years, but have never been turned into a
> public documents.
>
> ==> remove " a "

fixed.

Many thanks for the careful reading.

    john

p.s. to the WG:   To minimize clutter, I am not planning to 
reissue this draft before IETF 61 unless there is either 
overwhelming demand or additional significant comments very 
early this week.   However, an additional draft, 
draft-ietf-newtrk-sample-isd-00b.txt, will be submitted for 
posting before tomorrow's deadline.  It contains some very 
preliminary examples of what these documents might contain.

.