Subject: [newtrk] Re: I-D ACTION:draft-klensin-newtrk-std-repurposing-00.txt

From: Brian E Carpenter <[email-masked]>
Date: Tue, 08 Jun 2004 15:30:04 +0200

I think this is a good idea and should be developed into a final
proposal. One comment is that such documents cry out to be full
of hyperlinks to the referenced documents, so I suggest that they
should break with tradition by being created as HTML documents
rather than plain text. I think this would substantially increase
their utility.

     Brian

> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 
> 	Title		: Repurposing the STD Designation
> 	Author(s)	: J. Klensin
> 	Filename	: draft-klensin-newtrk-std-repurposing-00.txt
> 	Pages		: 11
> 	Date		: 2004-6-7
> 	
> Over the years, it has been repeatedly observed that the STD nnnn and
>    BCP nnnn designation for IETF Standards has not worked well, either
>    as a stable reference for external specifications or as a combined
>    reference for multiple documents that are linked together into a
>    single specification.  This document proposes two changes that have
>    been discussed on and off for some time, but never written up or
>    considered as specific proposals.  The first of these would assign a
>    STD (or BCP) number to a specification when it enters the first level
>    of the Standards Track (or is first designated as a BCP).  The second
>    would turn STDs and BCPs into actual documents that describe what
>    they identify and their publication and change history.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-klensin-newtrk-std-repurposing-00.txt
.
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: Tue, 08 Jun 2004 13:27:03 -0400

> rather than plain text. I think this would substantially

Brian, as you probably know, I've been in positions in which
standards are important procurement tools.  For that purpose, my
intuition tells me that there are substantial disadvantages to
HTML documents, most of them having to do with concerns about
instability of the links.  One could clearly overcome that with
sufficient rules about what gets referenced and how, but that is
a large enough piece of work that I'd hate to make it
prerequisite to seeing if we can reach agreement on this and
trying it.

Of course, if the source for these documents were kept in an XML
form, or some other form from which both archival/firm-reference
text and an easily-used HTML form could be generated, we could,
I think, have our cake and eat it too.  And, fortunately, while
it might require a slightly different DTD, or a tweaked version
of the existing one, we pretty much know how to do that, don't
we?

   john

.

---

From: Keith Moore <[email-masked]>
Date: Tue, 8 Jun 2004 14:16:20 -0400

I also think repurposing STD is a good idea, because it's the best way
that I can see to distance ourselves from the ambiguity associated with 
the term RFC - which seems to be the cause of some of our  problems. 
I'd like to see this developed further to dovetail with whatever newtrk 
comes up with.

Keith

.

---

From: Larry Masinter <[email-masked]>
Date: Tue, 08 Jun 2004 11:43:15 -0700

Brian wrote:
  I suggest that they
  rather than plain text. 

But I think he was talking about:

  The second

That is, there might be http://www.ietf.org/std/std0061.html
that would say

   A One-Time Password System, currently RFC 2289

I found http://www.garlic.com/~lynn/rfcdoc.htm and
http://www.garlic.com/~lynn/rfcietf.htm which seems like a
start, maybe 25% of the information that would be useful.

.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Tue, 08 Jun 2004 12:02:20 -0700

> I'd like to see this developed further to dovetail with whatever newtrk

since this is on the newtrk list, I think that it might be *part* of 
"whatever newtrk comes up with".
It's certainly a large enough change to current process that it should go 
out with IETF consensus; it's not something we can try out in a corner.

                        Harald

.

---

From: John C Klensin <[email-masked]>
Date: Tue, 08 Jun 2004 15:59:07 -0400

--On Tuesday, 08 June, 2004 11:43 -0700 Larry Masinter
<[email-masked]> wrote:

> Brian wrote:
>   I suggest that they
>   should break with tradition by being created as HTML
> documents   rather than plain text. 
> 
>     would turn STDs and BCPs into actual documents that
> describe what     they identify and their publication and
> change history.
> 
> 

I had hoped for somewhat more than that, e.g., at least 

	* an abstract (which might, for a single-RFC standard,
	just duplicate the RFC, or might not)
	
	* any useful information from the IESG "Protocol Action"
	statement(s) or writeups.  Personally I'd rather leave
	it up to the IESG than try to nail down every last
	detail in a specification, but I'd think that, for
	example "this was the product of foobar WG" or "this was
	reviewed in the IETF but is not the product of an IETF
	WG" would be information worth capturing and including.
	
	* history, e.g., 
	
		   RFC 1938 between ___ and the adoption of RFC 2289 in
		___. RFC 1938 was adopted as a Proposed Standard in ___,
		published officially in May 1996, advanced to Draft
		Standard in ___.

	Note that the latter will make us decide something else
	that has never been clear to me (some other things that
	have been proposed will force the same question).  That
	is whether something becomes a (Proposed / Draft/ Full)
	Standard when the IESG approves it and issues a Protocol
	Action notice (those two dates can actually be
	different, but one hopes not enough to worry about) or
	when the RFC Editor publishes.   I think the answer has
	to be the first, if only because we occasionally advance
	specifications without issuing the RFCs (something I'd
	like to see more of, and that this proposal would
	facilitate, but that is another matter).

As Keith commented...

> [...]  because it's the best way
> that I can see to distance ourselves from the ambiguity
> associated with  the term RFC - which seems to be the cause of
> some of our  problems.  [...]

While I see the core problem differently than he does, this
would be at least a useful side effect and maybe an important
goal.  From my perspective, it is more important from the
standpoint of those who write or evaluate procurement-type
documents than from that of the implementer/ engineers who have
been largely successful in the past in navigating the RFC
collection... whining a lot sometimes, but still successful.
But to do that job, these need to be real documents from which,
in the extreme case, a market-droid or procurement-droid can
look _only_ at the STD document and figure out what to write
into a spec.

>From that perspective, at least, the materials you (Larry)
cited...

> [...] http://www.garlic.com/~lynn/rfcdoc.htm and

Are useful, but mostly as a listing of STD documents.  While
these two tables may be more convenient for many purposes,
essentially the same list is available in
ftp://ftp.rfc-editor.org/in-notes/std-index.txt, which is
presumably authoritative.

All of this is obviously open to discussion -- I'll play editor
for at least a while, but I consider that my main role in this
was dropping an idea on the table (one that is not new) and
adding enough detail to it that we could discuss those details
and exactly what we are talking about, not just wave our hands
in unison.

Buy, if Larry and others read the spec and concluded that the
above-referenced URLs contain even 25% of the useful
information, we probably need a mockup of a document or two as
an appendix to the I-D.  Text contributions from interested
parties welcome; XML source for the draft is available on
request.

    john 

.

---

From: John C Klensin <[email-masked]>
Date: Tue, 08 Jun 2004 16:11:58 -0400

--On Tuesday, 08 June, 2004 12:02 -0700 Harald Tveit Alvestrand
<[email-masked]> wrote:

>> I also think repurposing STD is a good idea, because it's the
>> best way that I can see to distance ourselves from the
>> ambiguity associated with the term RFC - which seems to be
>> the cause of some of our  problems. I'd like to see this
>> developed further to dovetail with whatever newtrk comes up
>> with.
> 
> since this is on the newtrk list, I think that it might be
> *part* of "whatever newtrk comes up with".
> It's certainly a large enough change to current process that
> it should go out with IETF consensus; it's not something we
> can try out in a corner.

Harald, I completely agree with this.  However, if there is
significant interest in this proposal, it will raise one of
those interesting questions that the WG will need to somehow
parse.  While I tried to write it carefully to avoid any
assumptions on the subject, this could be viewed as either or
both of:

	* Eliminate (as Keith pointed out) the perceived "what
	does 'RFC' really mean" problem in its many
	manifestations without having to tinker with the RFC
	series at all.
	
	* Eliminate at least some of the perceived need to make
	significant changes in the standards track itself by
	making it clear that Proposed Standards are standards,
	just ones that we somewhat less sure about than we are
	about Draft or Full standards, and by permitting us to
	say exactly what we think about particular
	specifications as a key part of our documentation of
	them.

Personally, I think this idea is worthwhile even if we have
neither of those objectives for it.  But, to the extent to which
people feel those objectives are relevant, we will find out if
this helps with them only by trying it.  And might be an
argument for approving some variant on this and adopting a "go
slow" approach to major standards-track reform proposals.  Or
not... but it seems we (starting, I think, with Scott as Chair
and you as AD) will have to figure out a way to decide.

     john

.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Tue, 08 Jun 2004 13:44:39 -0700

Another thing that John's "STD" document series should be:

Archival.

Every version of every STD document should be identifiable, and accessible 
for all time (or until the IETF standards are irrelevant, whichever comes 
first).

Obvious enough that it might get overlooked; I was surprised the other day 
by learning that our secretariat doesn't have any procedure for keeping old 
versions of WG charters.

                 Harald
.

---

From: Larry Masinter <[email-masked]>
Date: Tue, 08 Jun 2004 17:39:13 -0700

> by learning that our secretariat doesn't have any procedure for keeping
old 

??? but

http://www.ietf.org/proceedings/directory.html

has all of the proceedings, and every proceedings has the charter
of every working group at the time of the IETF meeting.

.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Tue, 08 Jun 2004 17:48:13 -0700

> of every working group at the time of the IETF meeting.

yes, the proceedings give us snapshots approximately every 4 months.
Which helps a lot.

.

---

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 8 Jun 2004 22:12:36 -0500

Harald,

I thought that Proceedings for working groups that actually MEET tend
to contain charter snapshots, so that if I wanted to look back on what
PLLC started out with, I'd look at
http://www.ietf.org/proceedings/99jul/45th-99jul-ietf-132.html.

Gee, THAT was depressing. Anyway.

No idea if this is actually a procedure that is written down anywhere,
of course, but it may not be as bad as you think.

Spencer

.

---

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 8 Jun 2004 22:13:59 -0500

Sorry ("read the thread all the way to the bottom...")

.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 09 Jun 2004 10:07:53 +0200

As usual I typed too fast..

What I was thinking is that if STD 0005 wants to refer to RFC 791,
it would contain something like.

The principal normative reference for Internet Protocol (IP) is
[RFC 791].

And in the references you find

[RFC 791] Internet Protocol. J. Postel. Sep-01-1981. ,
available at ftp://ftp.rfc-editor.org/in-notes/rfc791.txt

Now if this is correctly represented in HTML it will be a live link,
and if you print it from a browser or present it in raw ASCII, at least
the link is visible.

That's all I meant, but it would be a significant enhancement, and could
be automagically generated.

    Brian

.