ietf
[Top] [All Lists]

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

2006-05-02 06:03:11
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
iesg(_at_)ietf(_dot_)org or ietf(_at_)ietf(_dot_)org 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 proceedings(_at_)ietf(_dot_)org(_dot_)
- 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 ietf(_at_)ietf(_dot_)org, 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
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>
  • Re: Last Call: 'The Tao of IETF - A Novice's Guide to the Internet Engineering Task Force' to Informational RFC, Pekka Savola <=