Subject: [newtrk] The ISD stuff

From: John C Klensin <[email-masked]>
Date: Mon, 07 Feb 2005 13:10:57 -0500

Hi.

Within the last 24 hours, I've sent two drafts off for
Internet-Draft posting.  I assume announcements will show up in
a day or so.

(1) The base ISD document,
draft-ietf-newtrk-repurposing-isd-01.txt.  This version is
believed to incorporate all of the conclusions reached at the
last IETF meeting and on-list since that meeting, and to
identify the remaining significant loose ends as "notes in
draft".  While it isn't yet reflected in the document, I am now
convinced (and I think that John Loughney and Scott Bradner
agree, but they can speak for themselves) that trying to get
every last detail reflected in this document is not likely to be
productive.  Sooner or later, we will need to say "ok, IESG,
your job to sort the details out in practice; in a year or so,
we will come back and reissue this document to reflect
then-existing practice and fine-tune as needed".   My preference
is to do that sooner rather than later: with this revision, and
revisions of the "examples", I think we are getting close to the
point of diminishing returns.  And it would be, IMO, really good
to get the ISD concept in place before the "cruft cleaning"
effort produces documents to be last-called.    So, let the
nit-picking begin.

(2) A new document, draft-ietf-newtrk-sd-00.txt.  It proposes a
"standing documents" series to accommodate IETF procedural
documents since there seems to be consensus to not include those
documents as ISDs.  This document is very skeletal and is mostly
intended to provoke and anchor a discussion as to whether an
additional document series is actually needed.  If it is,
someone will need to provide most of the content of the I-D and
a decision will have to be made as to how and where to process
it (it is, by definition, not a "new standards track" issue even
though I contend that this WG is the right place to make an
initial decision about necessity).    I want to stress that I'm
not convinced, one way or the other, that an additional document
series is the right thing to do and that this is the right time
to do it.  But our discussions are usually better when there is
some sort of document in front of us.

   john

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

---

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 9 Feb 2005 22:31:59 -0600

> documents

Hi, John,

I owe you detailed comments on both of these proposals, but before I 
forget - "SD" doesn't work for me because (1) "standing document" 
seems odd, but especially because (2) "ISD" and "SD" seem awfully 
close (and potentially confusing). Maybe "Procedural Document" or 
"PD"?

Spencer 

.

---

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 9 Feb 2005 23:27:56 -0600

Hi, John,

More questions than comments, probably...

- ISDs make a lot of sense to me because we're likely to run into 
multiple versions of a protocol on any given day "in the wild", so 
saying "SIP as of 2005/01/01" seems helpful), and having an ISD 
describe all the things that SIP has been seems useful. I Would Have 
Thought that procedural documents tend toward flag days ("all IDs 
submitted as of 2005/01/01 have to start with THIS boilerplate"), so 
I'm not as sure that having SDs for process descriptions is as helpful 
as having ISDs for protocols.

- The SD draft explicitly calls out the notion that we want something 
lighter-weight than RFCs, because RFCs are too darned heavy-weight to 
re-process every time someone wants to (hypothetically) change 
something about our IPR disclosure process, so It Would Be Nice to 
have an indirect pointer SD that contains all the words that have 
changed since the procedural RFC was chiseled in stone, and everyone 
please look at the SD before you look at the RFC. It seems to me that 
another way of handling this is by leaving all of the text in an SD 
and punting completely on process RFCs (since the process RFC 
essentially becomes the grain of sand in the middle of the pearl). I 
agree that an SD would make a lovely repository for id-nits - is there 
any value to having the SD point to an RFC that describes "id-nits as 
practiced by the Fred Baker IESG", and then gives all the 
adds/changes/deletes that we're marching under today?

But, surely, others must also have reactions to this proposal. I'll 
shut up now, and let others react.

Spencer

p.s. My apologies for whining about "SD" based on the abstract. I see 
you were also whining about the series name in the text! 

.

---

From: John C Klensin <[email-masked]>
Date: Thu, 10 Feb 2005 14:38:01 -0500

--On Wednesday, 09 February, 2005 22:31 -0600 Spencer Dawkins
<[email-masked]> wrote:

>> (2) A new document, draft-ietf-newtrk-sd-00.txt.  It proposes
>> a "standing documents" series to accommodate IETF procedural
>> documents
> 
> Hi, John,
> 
> I owe you detailed comments on both of these proposals, but
> before I forget - "SD" doesn't work for me because (1)
> "standing document" seems odd, but especially because (2)
> "ISD" and "SD" seem awfully close (and potentially confusing).
> Maybe "Procedural Document" or "PD"?

I don't like "sd" either, I just borrowed a handy precedent (and
"directives" felt really strange and always has).  As to what
the final choice should be, I really don't care although I'd
like to be first in line to vote against SD.

But the important issue, IMO, is for us to decide whether we
want and need these things.  If the answer is "no" then a
debate about we should not call the documents we won't have
would be a colossal waste of time.

   john

.