Subject: Pre-IETF RFCs to Historic (not really proposing)

From: Mykyta Yevstifeyev <[email-masked]>
Date: Thu, 15 Sep 2011 20:45:16 +0300

Dear all,

I've recently received a message from Ronald Bonica, one of the ADs, 
proposing undertaking an effort to reclassify many pre-IETF (pre-1000) 
RFCs as Historic.  However, I initially had a concern regarding 
community consensus on such effort, and whether it will be accepted so 
that the IESG may claim the former.  Since I've already suggested a very 
similar proposal, and there was a negative reaction of community, I 
assumed the same would happen in the case Ronald pursued the work and 
forwarded it to the IESG.  So am I right?

Mykyta

---

From: Keith Moore <[email-masked]>
Date: Thu, 15 Sep 2011 14:17:23 -0400

My recollection is that this has already been done to a large degree.

Also, focusing on this specific set of RFCs would be a lot of work, for very little actual value to the community.  

On the other hand, I'd be very much in favor of IETF periodically reviewing ALL standards-track RFCs for applicability.  But reclassifying as Historic is rarely appropriate.   Instead what should be done is to write an applicability statement for the protocols for which none exist, or for which the previous applicability statements are no longer correct.  

Keith

On Sep 15, 2011, at 1:45 PM, Mykyta Yevstifeyev wrote:

> Dear all,
> 
> I've recently received a message from Ronald Bonica, one of the ADs, proposing undertaking an effort to reclassify many pre-IETF (pre-1000) RFCs as Historic.  However, I initially had a concern regarding community consensus on such effort, and whether it will be accepted so that the IESG may claim the former.  Since I've already suggested a very similar proposal, and there was a negative reaction of community, I assumed the same would happen in the case Ronald pursued the work and forwarded it to the IESG.  So am I right?
> 
> Mykyta
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf

---

From: Scott O Bradner <[email-masked]>
Date: Thu, 15 Sep 2011 14:36:55 -0400

I'm fully supportive of reclassifying any RFCs that pose a risk to the Internet
to historic but fail to see the usefulness of doing so for RFCs that describe 
unused but non-harmful technologies - seems like busywork and useless at best.

Scott

---

From: Scott O Bradner <[email-masked]>
Date: Thu, 15 Sep 2011 14:39:02 -0400

ps - as Keith points out - a round of this type of effort was undertaken by the newtrk
working group a while back (I was the chair and did not see much reason to
do so at the time but there was consensus in the WG to proceed) - I will note
that it took quite a bit of work to ensure that technologies were actually unused

Scott

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 15 Sep 2011 21:17:41 +0200

On 15 September 2011 20:39, Scott O Bradner wrote:

> as Keith points out - a round of this type of effort was
> undertaken by the newtrk working group a while back

About five years back, IIRC, and with some limiting parameters.
I think this clean up was brilliant, and a new round with new
parameters would be a very good thing.

> I will note that it took quite a bit of work to ensure that
> technologies were actually unused

Again IIRC, you somehow created a list of "candidates", and
folks could object if they felt that something is still used.

If a new round picks only RFCs at a time when the concept of
"normative references" already existed it might be slightly
less work.

-Frank

---

From: Keith Moore <[email-masked]>
Date: Thu, 15 Sep 2011 17:19:16 -0400

> folks could object if they felt that something is still used.

Problem is, the IETF isn't really big enough to have a good idea about whether some technologies are still used.

Example: A few years ago I started doing some work in an industry which makes extensive use of 3-way FTP, because they have very large files that they have to move around, and they need for those transfers to be mediated by 3rd parties.  IIRC, the prevailing view in the IETF ftpext working group was that 3-way FTP was obsolete and should be deprecated due to security issues and because it wouldn't work through NATs.

Keith

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 15 Sep 2011 15:35:35 -0600

On 9/15/11 11:45 AM, Mykyta Yevstifeyev wrote:

> undertaking an effort to reclassify many pre-IETF (pre-1000)
> RFCs as Historic.

Given that these are pre-IETF RFCs, I move that we create a new
designation of "Pre-Historic".

/psa

---

From: Martin Rex <[email-masked]>
Date: Thu, 15 Sep 2011 23:49:24 +0200 (MEST)

Keith Moore wrote:
> 
> Problem is, the IETF isn't really big enough to have a good idea
> about whether some technologies are still used.

+1

Another example:  TLS  "Transport Layer Security".

If you look at the approx. current usage of the existing protocol
revisions:

   SSLv3   (1996):   5%
   TLSv1.0 (1999):  90%
   TLSv1.1 (2006):   5%
   TLSv1.2 (2008):   0%

If we would base the decision to move a protocol revision to historic
on the usage 2 years after publication, then for TLS, we clearly
should have moved TLSv1.2 (rfc5246) to historic this year because
of its complete failure in the marketplace.

Instead, a document describing SSLv3 was (finally) published as
historic informational RFC this year.

I hope we can get the critical mass (and get over blocking issues of pride)
to fix the problems that stick like buckets of concrete on the feet of TLSv1.2
one of these days...

-Martin

---

From: "Spencer Dawkins" <[email-masked]>
Date: Thu, 15 Sep 2011 17:44:15 -0500

I'm speaking as an individual, albeit an individual who helped with the 
decrufting effort in NEWTRK ... http://www.ietf.org/rfc/rfc4450.txt, for 
those who missed it.

> designation of "Pre-Historic".

I think Peter's suggestion is brilliant, but it point out a disagreement 
about what "Historic" means, in the IETF.

Quoting Keith Moore, from later in this thread:

> Problem is, the IETF isn't really big enough to have a good idea about 
> whether some technologies are still used.

Keith is mirroring the criteria used in the RFC 4450 decrufting effort, 
which was "not reflecting documented practice in the world today", which the 
IETF community isn't well-placed to know. So moving things to Historic is 
Really Hard.

A different but related problem is that moving a specification to Historic, 
for at least a significant part of the community, doesn't just mean "it's 
old", it means "and you shouldn't use it".

The issue *I* thought we were dealing with in the decrufting effort wasn't 
specifications that had been superceded or otherwise obsolete (the RFC 2026 
definition of Historic); the problem was specifications that no one still 
active in the IETF had worked on - or at least, no one would admit it! - and 
no one was willing and able to work on.

I thought at the time that our criteria shouldn't be whether anyone was 
USING the specification, what mattered was whether anyone in the community 
had the interest and expertise to maintain or extend the specification. It's 
not as if the RFCs disappear in a puff of smoke when they are recategorized, 
...

I was in the rough on that one in 2005, but since we're looking at another 
bulk recategorization effort, I might make this suggestion again - perhaps 
we could define a new level, which might be called something like "Not 
Maintained", with the criteria as, "we can't identify anyone who is willing 
and able to maintain the specification" That's actually something the IETF 
COULD know. We could ask, and if we hear crickets, "Not Maintained". If 
somebody shows up later, recategorize.

No presumption that you shouldn't use the specification, only that you 
shouldn't expect the IETF to maintain it. And if that's a problem for you, 
please feel free to start identifying people who are willing and able to 
maintain it.

If Mykyta was planning to identify pre-IETF RFCs as "Not Maintained", that 
might be less controversial.

And I'll leave the suggestion to move the Historic parts of 2026 to 
Historic, to someone else :D

Spencer, as an individual

---

From: Keith Moore <[email-masked]>
Date: Fri, 16 Sep 2011 01:08:09 -0400

On Sep 15, 2011, at 6:44 PM, Spencer Dawkins wrote:

> I was in the rough on that one in 2005, but since we're looking at another bulk recategorization effort, I might make this suggestion again - perhaps we could define a new level, which might be called something like "Not Maintained", with the criteria as, "we can't identify anyone who is willing and able to maintain the specification" That's actually something the IETF COULD know. We could ask, and if we hear crickets, "Not Maintained". If somebody shows up later, recategorize.

Part of the problem is the expectation that some single label should entirely define the status of a specification.   There are several almost-orthogonal variables that the community cares about (or should care about):

- currency - does the document (still) reflect best current practice for implementations of this protocol to work well?
- maintenance status - is the specification still being actively maintained?
- technical soundness - does the protocol described meet current criteria for technical soundness?  (okay, this is similar to currency)
- applicability - is this protocol (still) recommended for general use in this space, or for use only in corner cases, or is its use generally discouraged (presumably in favor of something else)?
- maturity - has this specification been implemented for long enough and enough times to have confidence in the quality of the protocol described and the specification for it?
- market penetration - is the protocol widely used in practice?  is it generally necessary for applications in this space to support it?

Trying to collapse all of these into X standard / informational / experimental / historic quite naturally leads to some tension between different interpretations of those terms.

Keith

---

From: John C Klensin <[email-masked]>
Date: Fri, 16 Sep 2011 09:19:14 -0400

--On Friday, September 16, 2011 01:08 -0400 Keith Moore
<[email-masked]> wrote:

>...
> Part of the problem is the expectation that some single label
> should entirely define the status of a specification.   There
> are several almost-orthogonal variables that the community
> cares about (or should care about):
> 
> - currency - does the document (still) reflect best current
> practice for implementations of this protocol to work well? 
> - maintenance status - is the specification still being
actively
> maintained?
> - technical soundness - does the protocol
> described meet current criteria for technical soundness?
> (okay, this is similar to currency)
> - applicability - is this
> protocol (still) recommended for general use in this space, or
> for use only in corner cases, or is its use generally
> discouraged (presumably in favor of something else)?
> - maturity - has this specification been implemented for long
> enough and enough times to have confidence in the quality of
> the protocol described and the specification for it?
> - market
> penetration - is the protocol widely used in practice?  is it
> generally necessary for applications in this space to support
> it?
 
> Trying to collapse all of these into X standard /
> informational / experimental / historic quite naturally leads
> to some tension between different interpretations of those
> terms.

Right.   And part of that, again, is why some of us continue to
press for rethinking the use of categories rather than, e.g.,
seeing if we can improve the deck situation on the Titanic by
stacking two of the deck chairs rather than leaving them
separate or by wholesale repainting of all old-colored deck
chairs to a different color.

But, more important for this particular case, it is why "let's
reclassify all of these" efforts usually (always?) turn into
expensive and time-consuming case by case evaluations.  An
important lesson from the Newtrk "de-cruft" exercise that
Spencer mentioned is that it was intended to quickly and
efficiently get rid of low-lying fruit.  I think it would be a
fair summary to say that, by the time we got finished, it was
clear that "quickly and efficiently" wasn't in the cards and
that there were fewer low-lying fruit than expected.   The
experiment, described in RFC 4450, started with 125 candidate
documents and, approximately 244 messages later (I think not
counting discussions of the approach on the newtrk list or
comments during IETF Last Call), ended up moving 44 documents to
Historic.

FWIW, a quick scan through pre-IETF RFCs yielded a wide range of
answers to Keith's questions, from 

o full standard, vague specification, not being actively
	maintained, widely implemented, working and rarely used
	these days (e.g., CHARGEN (RFC 864) or Quote of the Day
	(RFC 865)) 

to 

o full standard, decent specification that does not meet
	today's standards, not being actively maintained, widely
	implemented, working and very significantly used (e.g.,
	the IP over Ethernet document cluster).

to informational specifications that are of historical interest,
if that, today (RFC 809, 831, 841, or 851 anyone?).   Again, the
point is that this needs to be done on a case by case basis...
and that the level of investment that takes has just not been
justified and almost certainly cannot be.

      john

If we are going to embark on this again (note that , was very
narrow in scope and restricted to

---

From: Ronald Bonica <[email-masked]>
Date: Fri, 16 Sep 2011 09:30:35 -0400

Scott,

On one hand, most of these RFCs do not harm the Internet. However, if we don't clean house periodically, we are left with the following questions:

1) In the future, does the IETF have the latitude to do things that might break these old protocols?
2) If not, must the IETF maintain a cadre of people who are familiar with these old protocols to ensure that they are not broken?
3) If we don't maintain a cadre of people familiar with these RFCs, how should the community react to errata against them?
                                 Ron

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Scott O Bradner
> Sent: Thursday, September 15, 2011 2:37 PM
> To: Mykyta Yevstifeyev
> Cc: IETF Discussion
> Subject: Re: Pre-IETF RFCs to Historic (not really proposing)
> 
> that the IESG may claim the former.  Since I've already suggested a
> very similar proposal, and there was a negative reaction of community,
> I assumed the same would happen in the case Ronald pursued the work and

---

From: Keith Moore <[email-masked]>
Date: Fri, 16 Sep 2011 09:35:58 -0400

My impression is that the IETF quite regularly does new things that break current, actively used, maintained, and even standards-track protocols.  Maybe we should worry about those before worry about breaking older protocols.

Keith

---

From: Keith Moore <[email-masked]>
Date: Fri, 16 Sep 2011 10:10:06 -0400

I hit send too quickly after answering the first question, neglecting to answer the latter two.

2. In general, IETF has a difficult time maintaining a cadre of people with expertise in any particular area.   There's very little representation by applications developers; there's also insufficient representation (IMO) by people who take a long view of maintaining the Internet architecture as opposed to people who are focused on product development and dealing with immediate problems.  Finding a way to attract participation from a diverse range of interests is an important problem, but attracting people who have expertise in old protocols is the least of it.

3. I get the impression that "we" (or maybe just IESG) are taking errata too seriously.  I always thought that the errata reporting mechanism was intended to be relatively informal and low overhead, something more akin to expert review than IESG review.   Now I get the impression that IESG wants to do formal review on all errata before they're published.   That, IMO, is an unnecessary distraction for IESG and less likely to serve the community's needs than the original mechanism.   I also think that it's reasonable for errata to be unverified or for whoever reviews them to be able to say "I/we don't know what to make of this report".   

I think we need a low-overhead and relatively informal mechanism of reporting errata and requesting clarifications, and maybe that it should be expanded a bit to serve as an implementation and interoperability reporting mechanism.  But I don't think that having such a mechanism requires us to maintain expertise in every subject matter area covered by every RFC.

Keith

---

From: Cyrus Daboo <[email-masked]>
Date: Fri, 16 Sep 2011 10:52:18 -0400

Hi Keith,

--On September 16, 2011 10:10:06 AM -0400 Keith Moore 
<[email-masked]> wrote:

> I think we need a low-overhead and relatively informal mechanism of
> reporting errata and requesting clarifications, and maybe that it should
> be expanded a bit to serve as an implementation and interoperability
> reporting mechanism.  But I don't think that having such a mechanism
> requires us to maintain expertise in every subject matter area covered by
> every RFC.

Again I would like to bring up the idea of every RFC having an associated 
wiki page(s). The goal here is to provide a way for implementors to add 
comments, annotations, clarifications, corrections etc to augment the RFCs. 
Whilst such commentary can often be found on IETF mailing lists after an 
RFC is published locating those and searching them can be tedious - plus 
the full history of discussion on various points is often not relevant to 
an implementor - all they need to know is what is the correct way to do it 
now.

Doing something like this would obviously require some investment in 
additional infrastructure. There are also questions about how we would 
maintain the integrity of the information on the wiki pages, but I think 
those are things we can easily address.

-- 
Cyrus Daboo

---

From: "t.petch" <[email-masked]>
Date: Fri, 16 Sep 2011 16:24:07 +0200

----- Original Message -----
From: "Cyrus Daboo" <[email-masked]>
To: "Keith Moore" <[email-masked]>; "Ronald Bonica"
<[email-masked]>
Cc: "Scott O Bradner" <[email-masked]>; "IETF Discussion" <[email-masked]>
Sent: Friday, September 16, 2011 4:52 PM

> comments, annotations, clarifications, corrections etc to augment the RFCs.

Lovely idea, but not something I see as part of the IETF's mission.  It is so
easy
these days to set up a web site and wiki page that any editor of an RFC,
producer
of an implementation, can do it if they so choose.  Making it part of the IETF
gives it a standing that the resources available to review it would never be
able to put right any but the most egregious mistakes.

Tom Petch

---

From: Keith Moore <[email-masked]>
Date: Fri, 16 Sep 2011 12:39:10 -0400

On Sep 16, 2011, at 10:52 AM, Cyrus Daboo wrote:

> Again I would like to bring up the idea of every RFC having an associated wiki page(s). The goal here is to provide a way for implementors to add comments, annotations, clarifications, corrections etc to augment the RFCs. Whilst such commentary can often be found on IETF mailing lists after an RFC is published locating those and searching them can be tedious - plus the full history of discussion on various points is often not relevant to an implementor - all they need to know is what is the correct way to do it now.
> 
> Doing something like this would obviously require some investment in additional infrastructure. There are also questions about how we would maintain the integrity of the information on the wiki pages, but I think those are things we can easily address.

This is something that could be implemented on a volunteer basis as an experiment.  If it worked, perhaps IETF could be convinced to take it over.

Keith

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 16 Sep 2011 10:06:21 -0700

> This is something that could be implemented on a volunteer basis as an experiment.  If it worked, perhaps IETF could be convinced to take it over.

Volunteer moderating of such a Wiki could easily lead to the wiki being of little or no value, and being an embarrassment to the IETF. Consider an RFC that might be construed as supporting the use of NATs on the Internet. Open commenting on the RFC could be fodder for certain people commenting about the applicability of the RFC because NATs Are Evil. There would then likely be counter-comments from people who feel that NATs Have Value. Such comments, if moderated, could be very valuable to an implementer who knows about the RFC but not the bigger picture; unmoderated comments would be no more useful than some of the permathreads on the WG list that created the RFC.

Wikipedia is about the only example of working volunteer moderation, and even then, there are cabals that supported by the paid management. Few, if any, of the unmanaged wiki sites have long-lasting value.

--Paul Hoffman

---

From: Ronald Bonica <[email-masked]>
Date: Fri, 16 Sep 2011 13:24:54 -0400

Folks,

After reading responses from Scott, John and Keith, I think that I get it. No matter how low hanging I believe the fruit to be, this isn't going to be cheap or easy. So, I withdraw the proposal and apologize to Mykyta for having wasted his time.

                                                     Ron

> From: t.petch [mailto:[email-masked]]
> Sent: Friday, September 16, 2011 10:24 AM
> To: Cyrus Daboo
> Cc: IETF Discussion; Keith Moore; Ronald Bonica

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 16 Sep 2011 10:44:29 -0700

> After reading responses from Scott, John and Keith, I think that I get it. No matter how low hanging I believe the fruit to be, this isn't going to be cheap or easy. So, I withdraw the proposal and…

Having said that, if the IETF supports a wiki with pages for each RFC, someone going to that page might see comments like "people who used to use this protocol now use RFC xyz instead".

--Paul Hoffman

---

From: Keith Moore <[email-masked]>
Date: Fri, 16 Sep 2011 14:09:00 -0400

> Volunteer moderating of such a Wiki could easily lead to the wiki being of little or no value, and being an embarrassment to the IETF. Consider an RFC that might be construed as supporting the use…

Yes, all of those things are possible.   By saying it was an experiment, I meant to imply that the results might or might not be favorable and something that the IETF wanted to encourage and support.

My concern about having IETF do it right off the bat is that we really don't know how to do it and what it takes to make it work well.   That's why some sort of experiment is indicated.  By lending its support to such an experiment prematurely, IETF would risk more embarrassment than it would if the effort were started outside of IETF and without official backing.   Having said that, I think that such a site would have a better chance of success if it were run by experienced and respected IETF participants, who shared IETF's goals and were in good communication with IETF leadership.

OTOH, were IETF to endorse such an effort, I fear that IESG would want to impose control over it, and thus further distract IETF from its core goals.  I also fear that there would be too much tendency to deliberate every aspect of the site in minute detail on the IETF list.

Keith

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Fri, 16 Sep 2011 21:17:27 +0200

>an implementor - all they need to know is what is the correct way to do it 

It seems unlikely to me that a Wiki would be the right medium for this,
and expecting people to provide summaries of discussions is something I
would find problematic in practise, and I am not sure how the existing
errata system doesn't handle this already, but it should be easy to in-
stall an RT system akin to the one attached to CPAN. When you find some
problem with a Perl module, you can send mail to bug-<dist>@rt.cpan.org
and your mail, alongside replies, with the possibility to close issues
and other things you might expect of a bug tracking system. This could
be done for each RFC aswell (fancy issues like problems with multiple
ones and the corresponding cross-posting included).

Another option would be to simply collect links people found relevant,
some W3C Working Groups employ a system that lets you say "keyword" in
a mail and the mail will be linked from a tracking system, hopefully by
now there is also an IRC interface to that, so you can tag messages at
later points. Collective discussion curating, let it even be as simple
as being able to "tag" certain messages and share those tags, so you'd
be able to, say, mark frequently asked questions thus so the FAQ can be
updated to cover them, is a feature I always missed in Usenet. The only
vaguely working system that has since developed this that I know of is
the family of StackExchange sites, but those do not really translate to
this.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Sat, 17 Sep 2011 11:22:03 +0300

Thanks everybody for taking time to provide their feedback!  Mykyta

15.09.2011 20:45, Mykyta Yevstifeyev wrote:
> I assumed the same would happen in the case Ronald pursued the work 
> and forwarded it to the IESG.  So am I right?
>
> Mykyta

---

From: Alejandro Acosta <[email-masked]>
Date: Mon, 19 Sep 2011 11:44:56 -0430

+1
I also support the idea of every RFC havving the associated wiki.

On Fri, Sep 16, 2011 at 12:36 PM, Paul Hoffman <[email-masked]>wrote:

> >> Again I would like to bring up the idea of every RFC having an
> associated wiki page(s). The goal here is to provide a way for implementors
> to add comments, annotations, clarifications, corrections etc to augment the
> RFCs. Whilst such commentary can often be found on IETF mailing lists after
> an RFC is published locating those and searching them can be tedious - plus
> the full history of discussion on various points is often not relevant to an
> implementor - all they need to know is what is the correct way to do it now.
> >>
> > This is something that could be implemented on a volunteer basis as an
> experiment.  If it worked, perhaps IETF could be convinced to take it over.
>
> Volunteer moderating of such a Wiki could easily lead to the wiki being of
> little or no value, and being an embarrassment to the IETF. Consider an RFC
> that might be construed as supporting the use of NATs on the Internet. Open
> commenting on the RFC could be fodder for certain people commenting about
> the applicability of the RFC because NATs Are Evil. There would then likely
> be counter-comments from people who feel that NATs Have Value. Such
> comments, if moderated, could be very valuable to an implementer who knows
> about the RFC but not the bigger picture; unmoderated comments would be no
> more useful than some of the permathreads on the WG list that created the
> RFC.
>
> Wikipedia is about the only example of working volunteer moderation, and
> even then, there are cabals that supported by the paid management. Few, if
> any, of the unmanaged wiki sites have long-lasting value.
>
> --Paul Hoffman
>

---

From: Melinda Shore <[email-masked]>
Date: Mon, 19 Sep 2011 08:24:05 -0800

> I also support the idea of every RFC havving the associated wiki.

I don't.  I'm basically in Paul's camp, although I don't think the
greatest risk is that there'd be a negative impact on how the
organization will be perceived by the community (although I agree
that there's considerable risk of that).  I wouldn't want to
provide a forum for contentious discussions will never, ever end,
that nothing will ever be resolved, and that people who can't
accept organizational decisions will continue to fight those
battles on the wiki.

I think there's value in wikis to which people can contribute
implementation and deployment notes, but only if there's a way
to head off endless wars about stuff that's already been resolved
by the IETF.

Melinda

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 19 Sep 2011 10:27:29 -0600

> I also support the idea of every RFC havving the associated wiki.

I think that if some people support the idea, they can easily create a
wiki somewhere (e.g., "specsannotated.com") and get to work. If the
experiment has value, we'll figure that out. If not, well, it was just
an experiment.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Ivan Tubert-Brohman <[email-masked]>
Date: Mon, 19 Sep 2011 13:07:45 -0400

> experiment has value, we'll figure that out. If not, well, it was just

I agree.

I was invited to this discussion by Yaron because I'm the creator of
annocpan.org.

First, let me say that I have been pleasantly surprised by the
constructive behavior of annocpan contributors. There has been very
little spam, very little fighting, and very little verbosity (while
there is no strict limit on the size of the notes that people can
post, the "sticky note" metaphor encourages brevity and facts instead
of discourse).

Perhaps the lack of spam and fighting in annocpan is because the
traffic is modest, or due to the non-contentious nature of the
documents that are being annotated. Each page is just the
documentation for a freely available Perl module, take it or leave it,
and is not the documentation for a protocol that people are expected
to follow. It is possible that an annotated RFC would prove more
contentious and noisy, but perhaps not. One way to find out is to try.

Someone asked about the possibility of reusing the annocpan code. It
is of course freely available and written in Perl, but I'm afraid it
might be hard to disentangle from all the assumptions it makes about
the way the (CPAN) documents are organized. But if anyone wants to try
and has any questions, feel free to drop me a line.

When I started annocpan it was as a completely "unofficial" site,
whatever that means in the Perl world (although I did manage to obtain
a grant from the Perl Foundation for support and encouragement). I did
it because I thought it cold be useful, with very little discussion
with the "authorities". Later, when a few other people were convinced
that it could be useful, I got it to look a little bit more "official"
by, for example, getting links to annocpan from search.cpan.org, which
is the de facto "official" CPAN search site.

I do think that annotated RFCs could be useful. You just need to make
sure that it is clear that the annotations are unofficial additions
and that the underlying RFC is the ruling document.

However, my philosophy is that these types of projects are best
started as bottom-up experiments. It is somewhat embarrassing when a
big or respected organization tries to join some bandwagon by building
an official [wiki|social networking site|forum|etc] and it fails. If
one or more lonely experimenters fail, no one notices. But if they
succeed, then they can be embraced by the organization with a product
that is already useful and running. Plus, when you, the experimenter,
start the experiment it is much more efficient to be able to be a
"benevolent dictator" over your experiment, instead of having to
discuss things over and over (be especially wary of "color of the
bikeshed" types of discussions.)

Hope this helps,
Ivan

---

From: "John Levine" <[email-masked]>
Date: 19 Sep 2011 17:16:08 -0000

>experiment has value, we'll figure that out. If not, well, it was just

Agreed.  In my experience, wikis only work well if they have someone
overseeing them to weed out the spam and the flame wars.

Actual data point: the IRTF ASRG has a wiki (http://wiki.asrg.sp.am)
which works reasonably well, but that's mostly because I'm somewhat
selective in handing out passwords so I know who's modifying what.

R's,
John

---

From: Keith Moore <[email-masked]>
Date: Mon, 19 Sep 2011 14:19:43 -0400

> experiment has value, we'll figure that out. If not, well, it was just

This is also my preference.   I have never thought of this as something that IETF should start.

Keith

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 19 Sep 2011 11:29:00 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Keith Moore
> Sent: Monday, September 19, 2011 11:20 AM
> To: Peter Saint-Andre
> Cc: Paul Hoffman; IETF Discussion
> Subject: Re: Wikis for RFCs
> 

I like this idea, for those sufficiently enthusiastic about such a project.  If it's even a little bit successful, the IETF could perhaps maintain a set of links to offsite wikis discussing particular RFCs or suites of them, making it clear the IETF doesn't endorse them.

---

From: Yoav Nir <[email-masked]>
Date: Mon, 19 Sep 2011 21:54:05 +0300

> This is also my preference.   I have never thought of this as something that IETF should start.

http://www.faqs.org/rfcs allows you to comment on RFCs, although I think these comments get erased sometimes. I remember there being some sarcastic comments about RFC 3514.

---

From: Alejandro Acosta <[email-masked]>
Date: Mon, 19 Sep 2011 15:03:08 -0430

> This is also my preference.   I have never thought of this as something

 I believe this is the way to go.

> Keith

Alejandro,

---

From: Marshall Eubanks <[email-masked]>
Date: Mon, 19 Sep 2011 16:20:04 -0400

>  I believe this is the way to go.
Would you view this as an "IETF activity," and thus subject to the Note Well
?

Regards
Marshall

---

From: Alejandro Acosta <[email-masked]>
Date: Mon, 19 Sep 2011 22:29:54 -0430

On Mon, Sep 19, 2011 at 3:50 PM, Marshall Eubanks <
[email-masked]> wrote:

> Would you view this as an "IETF activity," and thus subject to the Note
> Well ?
>

  No, on the contrary, I see this as an activity that can be started by a
bunch on people somewhere else, not even by IETF/ISOC staff. Of course
mailing lists are great, however from my point of view it looks very
interesting to have a wiki where it can be easier to see what have the
people discussed /said about some RFC, comments, doubts, etc.

Alejandro,

---

From: Donald Eastlake <[email-masked]>
Date: Mon, 19 Sep 2011 23:27:54 -0400

I think a wiki per RFC with any sort of official IETF status is a bad
idea that would create many cesspools of controversy.

Donald

-- 
Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

---

From: Joel jaeggli <[email-masked]>
Date: Mon, 19 Sep 2011 21:07:32 -0700

> idea that would create many cesspools of controversy.

6393 of them at present count...

It should not go unremarked that 6393 updates an existing document and
performs a standards action apparently without much controversy. yet
avails itself of the filter our process provides.

joel

---

From: Nathaniel Borenstein <[email-masked]>
Date: Tue, 20 Sep 2011 11:42:40 -0400

> wiki somewhere (e.g., "specsannotated.com") and get to work. 

> Wikipedia is about the only example of working volunteer moderation, and even then, there are cabals that supported by the paid management. Few, if any, of the unmanaged wiki sites have long-lastin…

Is there any reason we can't create this on wikipedia itself, e.g.:

	http://en.wikipedia.org/wiki/RFC3514

We can make use of all the wikipedia governance mechanisms.  It would be independent of the IETF, but it would be a well-known place to go for somewhat-moderated explication of the nuances of important RFC's.  -- Nathaniel

---

From: Alejandro Acosta <[email-masked]>
Date: Tue, 20 Sep 2011 13:05:57 -0430

Hi Nathaniel,

>        http://en.wikipedia.org/wiki/RFC3514

The problem that I see in this case was mentioned previously by Keith and
Hector, wikipedia docs may be modified by the community, the RFCs content
itself should not be modified. It should be a kind of mix between blogs and
wiki.

>
> We can make use of all the wikipedia governance mechanisms.  It would be
> independent of the IETF, but it would be a well-known place to go for
> somewhat-moderated explication of the nuances of important RFC's.

Right!

> -- Nathaniel

Alejandro,

---

From: "John Levine" <[email-masked]>
Date: 20 Sep 2011 19:06:57 -0000

>	http://en.wikipedia.org/wiki/RFC3514

Wikipedia is an encyclopedia, and all that is supposed to go on the
main pages is encyclopedia type material, which this doesn't sound
like.  There's a talk page where you can have arguments, but that's
not particularly well managed or archived.

Setting up a mediawiki system is technically trivial, like 15 minutes'
work.  The hard part is managing it.

R's,
John