Subject: Re: Where to find IETF recommendations?

From: Mark Nottingham <[email-masked]>
Date: Tue, 1 Mar 2011 22:01:06 +1100

This is a very good question.

I've considered setting up a wiki page or similar to serve this purpose for the HTTP family of specifications. However, it's not clear what authority it would have, and it's not clear whether people would be able to readily find it.

If we can find a way to do this, and to cut through the clutter of all of the other information, it would be very helpful IMO. I'm not sure where it would start, though.

Cheers,

On 01/03/2011, at 3:19 AM, Worley, Dale R (Dale) wrote:

> ________________________________________
> From: [email-masked] [[email-masked]] On Behalf Of Shane Kerr [[email-masked]]
> 
> My question is... how is this advice expected to trickle out into actual
> use? There are more than 6000 RFCs, and they don't seem to be organized
> in a useful way that I can find.
> _______________________________________________
> 
> In practice, you have to be "up on the field", to be part of the ongoing discussions.  Other standards organizations are better organized about publishing their recommendations, but always, in practice, you have to be aware of what is being done by the systems you need to interoperate with.
> 
> Dale
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf

--
Mark Nottingham   http://www.mnot.net/

---

From: "t.petch" <[email-masked]>
Date: Tue, 1 Mar 2011 11:44:57 +0100

Shane

What  I carry with me - used to be on a diskette, now on a stick - is the index
to RFC, available from the same source as RFC themselves.  Plain text, compact,
easy to search.  The caveat is you never know whether the people choosing the
title of an RFC will have abbreviated a common term or not, so a search for SNMP
will not find all SNMP related documents.  For some, you must search for 'Simple
Network'.  Ditto for any IETF protocol or technology such as IP Next Generation.

It contains title, date, authors and updates/obsoletes/obsoleted which I find an
excellent summary.  The older, obsolete ones are often the better written and so
a better starting point for the first venture into a technology.

Tom Petch

----- Original Message -----
From: "Richard L. Barnes" <[email-masked]>
To: "Shane Kerr" <[email-masked]>
Cc: "Bob Hinden" <[email-masked]>; <[email-masked]>
Sent: Monday, February 28, 2011 7:30 PM
Subject: Re: Where to find IETF recommendations?

> As far as I know, what you're looking for doesn't exist, although it would
probably be good if it did!
>
> One thing that does crop up here and there are "hitchhiker's guide" RFCs, such
as this one:
> <http://tools.ietf.org/html/rfc5411>
>
> Beyond that, the best way I know of to look for IETF recommendations on a
subject is using the search feature on the tools pages:
> <http://tools.ietf.org/html/>
>
>
>
>
> On Feb 28, 2011, at 5:35 AM, Shane Kerr wrote:
>
> > Bob,
> >
> > Are recommendations actually published as BCP?
> >
> > I only see one BCP with "IPv6" in the title, published back in 2004.
> > Compared to this, the ipv6ops working group alone has produced dozens of
> > informational RFCs:
> >
> > https://datatracker.ietf.org/wg/v6ops/
> >
> > At least one of these are even explicitly recommendations:
> >
> > https://datatracker.ietf.org/doc/rfc4890/
> >
> > Some are targeted at protocol developers, some at vendors, some at
> > operators. It's quite a mixed bag. :)
> >
> > I'm not complaining, I just want to know if I am missing an obvious
> > place.
> >
> > --
> > Shane
> >
> > On Mon, 2011-02-28 at 12:10 +0200, Bob Hinden wrote:
> >> Shane,
> >>
> >> Like this one, aren't recommendations usually published as BCPs?
> >>
> >> Bob
> >>
> >>
> >> On Feb 28, 2011, at 11:44 AM, Shane Kerr wrote:
> >>
> >>> All,
> >>>
> >>> I just happened to notice this document on ietf-announce today:
> >>>
> >>>
http://datatracker.ietf.org/doc/draft-ietf-intarea-server-logging-recommendation
s/
> >>>
> >>> It seems quite reasonable.
> >>>
> >>> I ask because I was going to forward this to an IPv6 operations list,
> >>> and thought "hm... what about the rest?" and I realized I did not know,
> >>> and did not even know how to find out.
> >>>
> >>> Any advice would be appreciated. Thanks!
> >>>
> >>> --
> >>> Shane
> >>>

---

From: Shane Kerr <[email-masked]>
Date: Tue, 01 Mar 2011 13:18:12 +0100

Mark,

FWIW, this came up in the dnsext working group a few years ago. In the
end, I don't think anything was done, which is kind of a shame. A lot of
old protocols could benefit by "this is what is important" documents
(search the RFCs for "FTP" or "TELNET" to get some examples of protocols
with lots and lots of RFCs that make it hard to decipher).

Even worse for actual operators who may actually want to use the IETF
recommendations and not become IETF experts! 

I'll join the <[email-masked]> list as Joel suggests,
although it seems quite chatty with procedural stuff. :-/

--
Shane

On Tue, 2011-03-01 at 22:01 +1100, Mark Nottingham wrote:
> I've considered setting up a wiki page or similar to serve this purpose
> for the HTTP family of specifications. However, it's not clear what
> authority it would have, and it's not clear whether people would be
> able to readily find it.
> 
> If we can find a way to do this, and to cut through the clutter of all
> of the other information, it would be very helpful IMO. I'm not sure
> where it would start, though.
> 
> Cheers,
> 
> 
> 
>

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 1 Mar 2011 07:29:50 -0500

On Tue, Mar 01, 2011 at 01:18:12PM +0100, Shane Kerr wrote:

> end, I don't think anything was done, which is kind of a shame. 

Nothing was done for want of workers ;-) We concluded there was no
real room in official IETF channels for such a publication, but that
it would be possible for people to do this independently.

I believe Dave Crocker has been attempting to do it, with assistance
from people who know each protocol well.  I can't find it on his site
just now, however.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Bob Braden <[email-masked]>
Date: Tue, 01 Mar 2011 09:34:19 -0800

A few years ago some of us tried to interest the IETF in producing "road 
maps" for all the major protocols/protocol families.  As a worked 
example, we produced a roadmap for TCP. It seems to me that you are 
asking for more roadmaps.

Bob Braden

On 3/1/2011 4:18 AM, Shane Kerr wrote:
> I'll join the<[email-masked]>  list as Joel suggests,

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 01 Mar 2011 10:56:25 -0800

On 3/1/2011 3:01 AM, Mark Nottingham wrote:
> I've considered setting up a wiki page or similar to serve this purpose for
> the HTTP family of specifications.
...
> If we can find a way to do this, and to cut through the clutter of all of the
> other information, it would be very helpful IMO. I'm not sure where it would
> start, though.
...
>> use? There are more than 6000 RFCs, and they don't seem to be organized in
>> a useful way that I can find.

Well, this is entirely premature for the schedule I had in mind -- I had hoped 
to add one or two more example sets before exposing this widely -- but this 
thread is too timely to ignore.

If you all promise to keep in mind that it is only a /very/ rough and formative 
effort, please take a look at:

    <http://bbiw.net/trac/suites/>

I believe what it's trying to do is exactly what you are asking for.  It's in 
trac wiki form because it's intended for eventual adoption by the IETF tools 
site.  I've been pursuing the activity somewhat like I did for the Outcomes 
wiki, although this is proving to be much more effort:  getting the design right 
and adding initial data is more complicated.

If this does not match what you folks have in mind, my understanding why would 
be helpful.  If it does seem to be in the right direction, what changes would 
you like to see?

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Tony Finch <[email-masked]>
Date: Tue, 1 Mar 2011 19:59:42 +0000

On 1 Mar 2011, at 18:56, Dave CROCKER <[email-masked]> wrote:
> 
> If you all promise to keep in mind that it is only a /very/ rough and formative effort, please take a look at:
> 

There are also some groups of RFCs listed at http://www.apps.ietf.org/rfc/index.html

Tony.
--
f.anthony.n.finch  <[email-masked]>  http://dotat.at/

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 01 Mar 2011 12:01:42 -0800

On 3/1/2011 11:59 AM, Tony Finch wrote:
> On 1 Mar 2011, at 18:56, Dave CROCKER<[email-masked]>  wrote:
>>

Cool. Hadn't heard of that link before.

d/

-- 

   Dave Crocker

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 02 Mar 2011 09:43:12 +1300

On 2011-03-02 01:29, Andrew Sullivan wrote:
> real room in official IETF channels for such a publication, 

I have asserted for some years that the "Applicability Statement"
subset of the standards track, defined in RFC 2026, could perfectly well
be used for explaining how a group of RFCs fit together. There have
been various proposals for more specific methods than that which haven't
caught on, but the real problem has already been mentioned:

>>> Nothing was done for want of workers ;-)

It is a lot of work. I've done it for IETF process RFCs and even that
was a lot of work:
http://www.ietf.org/about/process-docs.html

    Brian

---

From: Joel Jaeggli <[email-masked]>
Date: Tue, 01 Mar 2011 12:49:48 -0800

> caught on, but the real problem has already been mentioned:

in v6ops ops we have documents like:

http://tools.ietf.org/id/draft-jankiewicz-v6ops-v4v6biblio-03.txt

opsec

http://tools.ietf.org/wg/opsec/draft-ietf-opsec-efforts/

---

From: Dave Cridland <[email-masked]>
Date: Tue, 01 Mar 2011 21:19:58 +0000

On Tue Mar  1 18:56:25 2011, Dave CROCKER wrote:
> If you all promise to keep in mind that it is only a /very/ rough  
> and formative effort, please take a look at:
> 
> I believe what it's trying to do is exactly what you are asking  
> for.  It's in trac wiki form because it's intended for eventual  
> adoption by the IETF tools site.  I've been pursuing the activity  
> somewhat like I did for the Outcomes wiki, although this is proving  
> to be much more effort:  getting the design right and adding  
> initial data is more complicated.

As a counter-example, you might want to look at the XSF's  
higher-level documentation:

http://xmpp.org/xmpp-protocols/xmpp-core/

I think entirely written by Peter Saint-Andre.

It does highlight a problem with such documentation actually, in that  
it's somewhat out of date in places; still, it's far better than  
nothing, I think.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 2 Mar 2011 09:45:29 +0100

On Tue, Mar 01, 2011 at 09:34:19AM -0800,
 Bob Braden <[email-masked]> wrote 
 a message of 29 lines which said:

> A few years ago some of us tried to interest the IETF in producing
> "road maps" for all the major protocols/protocol families.  As a
> worked example, we produced a roadmap for TCP. It seems to me that
> you are asking for more roadmaps.

The biggest problem with roadmaps like RFC 4614 (TCP) and RFC 6071
(IPsec) is that they are obsolete a few months after their publication
(for instance, since RFC 4614, there have been RFC 5925, RFC 5961, RFC
5681... which are all necessary for a TCP implementer).

Since RFC are never modified, they may not be the best way to navigate
into IETF standards.

---

From: Shane Kerr <[email-masked]>
Date: Wed, 02 Mar 2011 14:34:53 +0100

Bob,

I'm not sure. In my mind a "road map" tells you where something is
going:

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

I am kind of looking for where we are now, and possibly where we have
been.

--
Shane

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 2 Mar 2011 14:41:25 +0100

On Wed, Mar 02, 2011 at 02:34:53PM +0100,
 Shane Kerr <[email-masked]> wrote 
 a message of 50 lines which said:

> In my mind a "road map" tells you where something is going:

May be in english :-) but in IETFspeak, "roadmap" has already been
used several times for "list of relevant RFC on a given subject, with
comments".

See RFC 4614 and 6071 as examples.

---

From: Shane Kerr <[email-masked]>
Date: Wed, 02 Mar 2011 14:43:16 +0100

Andrew,

> it would be possible for people to do this independently.

I suppose this makes sense in the context of a single working group.
However, perhaps it makes sense for such channels to be created?

I envision two or three types of work related to coming up with such
sort of correlation activities:

     1. Decide which groupings make sense
     2. For each grouping (for example, DNS, BGP, NFS) create a document
        which serves to guide people who actually want to use RFCs in
        some way without becoming an IETF guru
     3. Some sort of ongoing maintenance

The first two types could quite easily be done by one or more normal
working groups, even if no place exists for such a working group today.
I'm not sure where the last work (care & feeding) would fit. There is
precedent for indefinite-duration working groups, both by design and
accident.

I know this stuff could be done outside of the IETF framework, but it
seems like a shame to have to outsource such a critical piece of work...
actually making RFCs useful. :)

--
Shane

---

From: Shane Kerr <[email-masked]>
Date: Wed, 02 Mar 2011 14:45:01 +0100

Joel,

> http://tools.ietf.org/id/draft-jankiewicz-v6ops-v4v6biblio-03.txt

Cool, this is actually the document I was looking for when I started
this thread - even if it doesn't have the logging recommendation draft
too. :)

--
Shane

---

From: Shane Kerr <[email-masked]>
Date: Wed, 02 Mar 2011 15:03:28 +0100

Tony, Dave,

> >   <http://bbiw.net/trac/suites/>

This seems like the kind of thing I was thinking of.

> http://www.apps.ietf.org/rfc/index.html

While this is better than nothing, it's almost the same as using the
RFC-editor search page. I mean, looking at the IMAP documents:

http://www.apps.ietf.org/rfc/ipoplist.html

Does a modern implementer really care about IMAP version 2? Maybe they
do, if it's in use commonly today, but probably not. Surely an IMAP
expert could look at that list and say, perhaps, the ACL extension is
almost never used (I have no idea if this is true, this is just an
example).

So, would RFC 1639 - FTP Operation Over Big Address Records (FOOBAR) be
included in a list of FTP documents, even though everybody actually uses
RFC 2428 (FTP Extensions for IPv6 and NATs)? I would argue "no", or
rather that there should be some editorial content letting people know
that, frankly, FOOBAR is exactly what it claims to be. ;) (And before
people mention that it's experimental, RFC 5006 - IPv6 Router
Advertisement Options for DNS Configuration - now obsoleted by RFC 6106
- was experimental for a few years and was actually probably something
that *is* worthwhile implementing.)

Sorry this is a bit ranting. I don't mean to be negative! I'm actually
hopeful that some solutions can be found.

--
Shane

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 02 Mar 2011 09:59:32 -0800

> This seems like the kind of thing I was thinking of.

Excellent.  But since it is still quite formative, the obvious question is what 
-- if anything -- you would like to see done differently with it?

The generic question is whether you can approach it with a goal of finding 
specific information and found that it was easy to obtain that information?

This divides into:

    1. The form of the wiki didn't work well enough

    2. The data in the wiki is not complete enough.

The first is strategic information.  The second is the wiki equivalent of SMOP 
(simple matter of programming), of course.

d/

-- 

   Dave Crocker

---

From: Joel Jaeggli <[email-masked]>
Date: Sun, 06 Mar 2011 18:06:10 -0800

> this thread - even if it doesn't have the logging recommendation draft

cool, there are certain limitations to documenting the documents from
within the document framework. but there's been a certain amount of
effort that ammounts to that nonetheless.