Subject: [newtrk] web-based lists of RFCs

From: Bruce Lilly <[email-masked]>
Date: Mon, 4 Jul 2005 15:50:02 -0400

A quick-and-dirty paraphrase of some ideas that have been floated:
o ISDs as an annotated list of RFCs comprising some related technology
o web-based implementation of ISDs
o ISDs as being of interest for RFP writers.

The following web-based annotated list of RFCs might be interesting to
spur some discussion: http://www.imc.org/rfcs.html

Some opinions:
o while it's nice to have lists of RFCs, reaching consensus on which
  RFCs to include and exclude may be difficult without first getting
  consensus of the purpose(s) of having the list
  - my own personal list of mail-related RFCs includes some of historical
    interest (because they shed some light on why things are as they
    currently are, and because messages tend to be archived and it may
    be useful to be able to read archived information) but doesn't
    include the calendaring stuff
  - sets of categories within lists are similarly somewhat subjective
o lists for long-lived technologies such as mail tend to be long
  - the list at the URI above doesn't include many things that have
    been proposed for ISDs
    * errata
    * commentary on status
      @ the list does have some brief general commentary (interesting
        interpretation of Proposed/Draft/Full Standard)
      @ some RFCs have no status indication at all
o a comprehensive list may be useful in preparation of more specific
  lists
  - a Korean corporate IT department might be quite interested in
    requiring RFC 1557 conformance in an RFP; RFC 2319 not so much
  - some RFCs provide operational guidelines and aren't particularly
    applicable to RFPs or for implementers of hardware or software,
    yet may be of primary interest to operational entities
  - being truly comprehensive, particularly for long-lived, extensible
    technologies is a mammoth undertaking
.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html

---

From: Pekka Savola <[email-masked]>
Date: Tue, 5 Jul 2005 09:36:45 +0300 (EEST)

> spur some discussion: http://www.imc.org/rfcs.html

I guess the point is how much commentary you want to include there, 
and how you want to categorize the specs ("obsolete", etc. -- some 
folks might disagree).

Sooner or later you end up in a situation where you have to figure out 
what's the community consensus for a classification or commentary.

Then, we run out of (currently defined) mechanisms.

draft-ietf-tcpm-tcp-roadmap-04.txt provides IMHO a very nice way to 
tackle this issue.  It also allows a bit more text as the text goes 
through IETF review.  While updating the document may not be as easy, 
I'd say a draft or RFC (maybe refreshed every 2.5-5 years), with the 
current consensus tools, might be the best way we have to provide good 
summaries of IETF technologies.

I'd certainly hope WGs would do more of them.  This might require a 
bit of IESG buy-in though.

-- 
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: Brian E Carpenter <[email-masked]>
Date: Tue, 05 Jul 2005 11:16:54 +0200

Indeed, I see a lot of value in a systematic approach to such a web
based approach. In fact, I find it unfortunate that
http://www.rfc-editor.org/rfcxx00.html
is structured the way it is. A different version of that page
would be very helpful IMHO:

- Experimental and Historic RFCs would be moved out to their own page

- Acronyms and STD numbers would be allocated to PS and DS
documents as well as Standards

- Instead of being split into four sections (STD, DS, PS
and BCP) the page would be in only two sections (Standards Track
and BCP)

- When a Standard has been obsoleted or updated by a PS or DS,
or a DS has been obsoleted or updated by a PS, the obsoleting
document would take precedence in the Standards Track section.

- Pointers to obsoleted and updating documents would be inserted

I believe most of this can be generated automically from the
RFC Index.

    Brian

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter
IETF Chair
Distinguished Engineer, Internet Standards & Technology, IBM

.

---

From: Bruce Lilly <[email-masked]>
Date: Tue, 5 Jul 2005 08:20:08 -0400

> summaries of IETF technologies.

I skimmed through it; it does look nice.  Obviously there were at least
4 previous versions (-00 through -03), and I see that publication has
been requested.  Roughly how long did it take to get from the idea of
writing the -00 version (that would mean of the original document, i.e.
an individual draft if it started that way) to now?
.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html

---

From: "Larry Masinter" <[email-masked]>
Date: Tue, 5 Jul 2005 08:28:54 -0700

What is the basic principle that makes a set of
RFC's "related" somehow? 

One of the basic reasons why RFCs should be considered
together in a relationship is because they tend to occur
in the same IMPLEMENTATION.

So, consider the possibility of building up the relationship
of RFCs through IMPLEMENTATION/INTEROPERABILITY reports.

Let people report in implementations. Each implementation
should list the RFCs (and features within the RFC) that
the implementatation is considered to be an implementation
_of_. If there has been tested interoperability with other
implementations, that can be noted, too.

Then, we could derive the list of "related RFCs" by looking
for "what other RFCs appear in implementation reports
along with this RFC".

We could even derive this list of related RFCs automatically.
The list might not need to be authored, although there should
be some room for commentary or editing the list.

Larry
-- 
http://larry.masinter.net

.

---

From: Bruce Lilly <[email-masked]>
Date: Tue, 5 Jul 2005 08:54:06 -0400

> - Experimental and Historic RFCs would be moved out to their own page

For RFCxx00, OK, for an ISD there may be value in historic and
experimental RFCs being listed ("here are some traps to avoid",
"there is some experimental work of possible interest", "this is
how things used to be (and may still be in archives)").

> documents as well as Standards

1. That would certainly increase the magnitude of what needs to be
   addressed
2. At PS stage, it might not be clear where to put a technology and
   how well the technology might be received by the community.  E.g.
   Sieve seems to be doing well, with a growing number of extensions.
 
> and BCP) the page would be in only two sections (Standards Track

Somewhere, somehow, there ought to be an indication of maturity of
Standards Track specifications (initial specification, reviewed for
interoperability and reasonable for deployment in a disruption
sensitive environment, a high degree of technical maturity and
significant benefit).
 
> document would take precedence in the Standards Track section.

Above all, std-index and RFC xx00 ought to be consistent (at least
at the time of publication of the xx00 document).  Here's a case
where the current rules and labels don't quite work for cases of
consolidation, which in turn is one way of dealing with many
related specifications.  Clearly the Internet Message Format isn't
really untested as would be indicated by the PS label on RFC 2822.
I'm not sure how to fix that; the rule for reset to proposed seems
to be selectively enforced (counterexample to 822->2822 is 1738->
2396->3986, with substantial changes at each step but no reset to
PS).  Maybe one approach would be to amend the rules to permit a
partial reset (DS obsoletes FS), but that wouldn't have helped for
2822, since at the time of publication there were almost certainly
not two independent fully interoperable implementations meeting
all of the format generation requirements and restrictions, probably
the same situation for parsing implementations (and there are a few
errors in the specification itself).  Keeping a WG active to work on
advancement with the goal of meeting the 6-month PS->DS minimum
duration to 24-month review window would almost certainly help
advance Standards Track specifications in a more timely manner.
 
> - Pointers to obsoleted and updating documents would be inserted

Some of the obsoleted ones might be Historic... (vs. "moved out to
their own page").  Links would be a viable approach for the HTML
version, but not the RFC xx00 text document, unless external
references are added to RFC xx00.
 
> I believe most of this can be generated automically from the

Possibly (for that matter, I wonder if the rfc-index itself is
automatically generated from some source data).  One likely
exception would be dealing with the PS obsoletes FS etc. scenarios
.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html

---

From: Pekka Savola <[email-masked]>
Date: Tue, 5 Jul 2005 20:15:18 +0300 (EEST)

> an individual draft if it started that way) to now?

The work began as draft-duke-tcp-roadmap-00.txt (posted on Feb 2004), 
the next version was the WG document.

So you could say from scratch to getting the doc approved probably 
takes 1-2 years, depending on the interest level of the people working 
on the technology.

Always an optimist, I'd say that it could be possible to get these 
approved in something like 6-9 months, but this requires dedication 
from the editors, sufficient interest level from the [WG] 
participants, and resolution skills if tough consensus calls need to 
be made.

But as long as you start classifying the RFCs and/or internet-drafts 
somehow, and add discussion on their applicability etc., I believe the 
requirement on the time spent is roughly equal.  It's the same sort of 
issues (editing, getting the community interested, steering towards 
consensus, etc.) that take time, not the publication format.

---

From: Bruce Lilly <[email-masked]>
Date: Tue, 5 Jul 2005 12:29:54 -0400

> implementations, that can be noted, too.

Aieeeeee!  So for example Mozilla, which implements web browsing,
email, IRC, calendaring, LDAP, DNS client, etc. (N.B. Mozilla isn't
the only implementation of software that does that, there's Microsoft
Outlook, Ximian (now Novell) Evolution, etc.) would form the basis of
a set of RFCs?   It might be easier to list the RFCs which are NOT
applicable to the implementation... maybe we can get by with a handful
of really, really big ISDs.

Many of the RFCs may be Informational or Experimental, and therefore
not related to *standards* per se (that is also true of the lists
mentioned here recently).  Some RFCs (e.g. RFC 1700) might be historic
and/or not terribly interesting as an RFC (since RFC 1700 has
been replaced by a non-RFC set of online data; whether or not an ISD
should reference such non-RFC data is perhaps an interesting question).

"Let people report in implementations..." doesn't really solve the
problem of identifying a set of RFCs, it pushes the work onto
others (who probably have no incentive to do anything).  See RFC
1925 item (6).  It *might* be one way to collect some raw data (given
the lack of incentive, I'm doubtful), but somebody is still going to
have to review that data and make decisions (and different reviewers
would likely make different decisions).
.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html