Re: Last Call: 'The Tao of IETF - A Novice's Guide to the Internet Engineering Task Force' to Informational RFC

[Pekka Savola <[e-mail]>]

On Tue, 4 Apr 2006, The IESG wrote:
> - 'The Tao of IETF - A Novice's Guide to the Internet Engineering Task Force '
>   <draft-hoffman-taobis-06.txt> as an Informational RFC
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send any comments to the
> [e-mail] or [e-mail] mailing lists by 2006-05-02.

The last I looked at the TAO was about 5 years ago.  A lot of the 
document is good and very useful, but I believe a part of it needs 
(rather straightforward) reword, i.e., cutting out too operational 
text, specifically, two major issues:

1) includes too much operational detail

The document seems to have many parts which describe the operational 
system in too much detail, e.g.,
  - how IETF-lists are run using  'mailman',
  - what kind of subscribtion  message you should send and where,
  - that there are TWO sergeants-at-arms at the ietf list (just use a 
plural)
  - that the IETF registrations include a daily continental breakfast 
(in fact, Paris IETF didn't)
  - the fact that newcomer's orientation session takes 30 mins and is 
followed by a 30-min standards process orientation
  - the fact that the IETF agenda is sent on the IETF announcement list 
three times
  - the fact that every attempt is made to have a WG meet in the same 
room for each session.
  - the fact that the WG jabber rooms are at @rooms.jabber.ietf.org 
(which they aren't anymore..).
  - that interim meeting notes are sent to [e-mail].
  - idnits URL is referred to as ietf.levkowetz.com instead of 
tools.ietf.org.
  - Appendix A.2 on useful email addresses; should this point to a web 
page including these instead?

I'm not sure if this is a good idea; information like this is bound to 
change now and then.

In the case of mailing lists, isn't the "subscribe" URL at WG charter 
page sufficient?  While this may not exist for the special lists like 
[e-mail], id-announce or IETF-announce, we should create one if 
so.  Hands-on guidance at a very low level is bound to come back and 
bite us, so I think it'd make sense to keep the document at a higher 
level.

2) Section 8.4.5 describes "Patents in IETF Standards" which is good 
-- but I don't see the "Note WELL" described anywhere, and actually, I 
think that's the most important thing in the IETF about IPR for any 
newcomer (and one of the most important things in general), and should 
be spelled out loud and clear.

semi-substantial
----------------

Section 3.2.2 includes the list of current areas.  Is there a specific 
source for the area descriptions?  Many of those seem a bit lacking 
(e.g., security area is only "authentication and privacy", and 
transport area's "Special services for special packets" isn't exactly 
helpful).

Section 3.3 says that "Only the Secretariat can approve messages sent 
to the announcement list, although those messages can come from a 
variety of people." -- is this true?  I thought at least IAB/IETF 
chairs have the capability to send messages directly and/or approve 
postings (many of which occur at an hour where I doubt the secretariat 
is working).

Section 4.3 mentions that the newcomer training takes 30 mins, plus 
stds orientation.  The slot seems to be 1h45min..  Is this up-to-date?

Section 4.9 says, "Some Working Groups meet multiple times during a 
meeting and every attempt is made to have a Working Group meet in the 
same room for each session." -- is this true?

Section 5 says, "Some IETF WG mailing lists only let subscribers to 
the mailing list post to the mailing list, while others let anyone 
post." -- this would be in violation of the mailing list management 
principles, as anyone must be able to post w/o subscription but 
through moderation.  (Unfortunately, this doesn't work very well in 
practice, I've noticed that moderation doesn't happen very often if at 
all; maybe the amount of spam messages is a factor here..)

Section 6 says, "The purpose of a BOF is to make sure that a good 
charter with good milestones can be created, and that there are enough 
people willing to do the work needed in order to create standards." -- 
note that the WG's are created for other purposes than creating 
standards as well (cf. the IETF mission statement).  If you want 
examples, just look at some OPS&MGMT WGs..

Section 8.1 says that there are six kinds of RFCs, one of which is 
"Historic standards".  Note that 'Historic' is not reserved for 
_standards_.  An Info or Experimental doc can also be labeled 
historic.

Section 8.4.2 on maturity levels and references doesn't mention the 
relation of BCP to standards track normative references (i.e., it's an 
OK normative ref from any doc).  It also doesn't mention explicitly 
what a normative reference to an I-D means, but that's may be clear 
enough by implication.

Appendix C includes changes since 3160, per draft version, but 
instructs the RFC editor to remove it before publication.  Usually, 
RFCs which obsolete earlier ones are required to have a Changes 
section (without draft version numbers), so I'd suggest you summarize 
the most important changes (which shouldn't be removed) here.

editorial:
----------

  The
    quality of the IETF standards comes both from the review they get in
    the Working Groups and the review that the WG review gets from the
    ADs.

==> "the review that the WG review" ?  Something extra in there?

Section 8.3.1 referred to four documents, but there are five bullet 
points.  Maybe the last one shouldn't be a bullet point.

Section 8.4.4 should use s/IPSEC/IPsec/.


-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

_______________________________________________
Ietf mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ietf