Subject: RE: [newtrk] web-based lists of RFCs

From: <[email-masked]>
Date: Tue, 5 Jul 2005 09:25:24 +0300

Bruce,

You might also note that the IPv6 working group has an additional page at
http://playground.sun.com/pub/ipng/html/ipng-main.html

It lists IPv6 by Status and by function:
http://playground.sun.com/pub/ipng/html/ipng-main.html#SPECS

It is fairly outdated now, but it seems that this was something that has
been needed, at least for IPv6.

John

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of ext Bruce Lilly
> Sent: 04 July, 2005 22:50
> To: NEWTRK
> Subject: [newtrk] web-based lists of RFCs
> 
> 
> 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
> 

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

---

From: Bruce Lilly <[email-masked]>
Date: Tue, 5 Jul 2005 09:37:52 -0400

> been needed, at least for IPv6.

Another good example of a complex technology, John.

In scanning the std-index, it appears that there are roughly 4 categories
of STDs w.r.t. effort involved to generate an ISD-like document:
1. those which are not applicable, either because the STD is itself a
   summary (STD 1, a.k.a. RFC xx00, STD 2, now replaced by the online
   IANA data) or the technology is obsolete
2. single-RFC STDs which are probably unrelated to some larger existing
   STD category per se, such as Jon Postel's STD 20-25.  Some of these
   could possibly be combined under a general category.  (some, e.g.
   RFC 866, should probably be updated (no security considerations
   discussion!)).
3. Massive undertakings for core technologies (mail, DNS, IP, TCP, telnet,
   maybe SNMP + MIB).  All span many RFCs, some span multiple STDs for
   the same technology (telnet + options, for example).
4. The rest -- probably moderate effort required

The first category would obviously (?) not warrant an ISD.  The second
category probably warrants some consolidation -- an ISD for the discard
protocol alone seems somewhat silly, whereas an ISD grouping the simple
network protocols (discard, echo, chargen, etc.) might be sensible; that
of course would mean fewer ISDs than STDs.  The third category would also
involve some consolidation (fewer ISDs than STDs), but the main issue is
who is going to do the work.  I suspect that there are only a few STDs
in the fourth category.

All things considered, I suspect that the 66 STDs might result in perhaps
a dozen or so ISDs, and about half of those would require major effort.
Adding DS and PS technologies which have not yet reached FS maturity would
of course involve more ISDs.

Which is related to the issue of who is going to do the work.  The massive
undertakings cross not only WG boundaries but IESG Area boundaries (e.g.
S/MIME (Security area) is clearly related to mail which is an Applications
area technology).  Managing the effort is likely to be a challenge.

Looking back at the IESG comments on ISDs, there were two suggested paths:
1. "light-weight replacement" for the Standards Track, "ISDs very simple"
2. "document series for roadmap documents", "fairly complicated to write"

ISDs as I understand the characteristics and considering the various
existing summaries of RFCs that have been recently pointed out seem to
be consistent with the second approach and incompatible with the first
(even a list of RFCs with no annotation would be a significant effort
for core technologies, and would require ongoing maintenance in many
cases).

So I have a related question for the IESG:
If even a "very simple" list of RFCs is going to require cross-WG
(where WGs even exist for the technology), cross-area effort, how
does the IESG suggest accomplishing the work and managing that effort?
(that of course also applies to the "complicated" alternative, even more
so)
.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html