The Tao of IETF - A Novice's Guide to the Internet Engineering Task Force
draft-hoffman-taobis-08

[Ballot comment]
I have two comments on Section 10.1, IETF liaisons with other SDOs

First, it currently says that some of the liaison tasks fall on
the IAB and some on IESG. But the actual formal responsibility
is on the IAB to manage the liaison relationships. So the
text should be corrected.

But that relates to my other comment. Perhaps you could
add something that emphasizes the IETF's preference for
taking issues directly to the WGs; WG members, chairs,
ADs, etc. all have a role in the actual joint work,
and the formal liaison discussions are there to just
support that.

[Ballot comment]
Section 2., para. 1:

>    The original version of this document, published in 1994, was written
>    by Gary Malkin.  His knowledge of the IETF, insights, and unmatched
>    writing style set the standard for this later revision, and his
>    contributions to the current draft are also much appreciated.  Paul
>    Hoffman wrote significant portions of this revision and provided
>    encouragement, expertise, and much-needed guidance.  Other
>    contributors include Brian Carpenter, Scott Bradner, Michael Patton,
>    Donald E. Eastlake III, Tony Hansen, the IETF Secretariat, members of
>    the User Services Working Group, and members of the PESCI design
>    team.

        Nit: Section usually located towards the end.

Section 3.2.2., para. 11:

>    Transport (TSV)        Special services for special packets

        Nit: We should really come up with something better for TSV :-)

[Ballot comment]
The document says:

  The IESG ratifies or corrects the output from the
  IETF's Working Groups, gets WGs started and finished, and makes sure
  that non-WG drafts that are about to become RFCs are correct.


I think "ratifies or corrects" would be better put as "reviews and advances".

[Ballot comment]
Trivial detail that you have probably already thought of ... Can you get commitment to make the URLs in the document be stable over the long term?

[Ballot comment]
Section 7 has the following title:
  >
  > ** New to the IETF and Coming to a Meeting? STOP HERE! (Temporarily)
  > **
  >
  I undertand the point, but the stars should be removed to avoid
  line wrap.

  A better title for Section 8.1 is "Getting a Document Published".  I
  think this is better because it includes discussion about documents
  that are not on the standards track.

  Section 8.4.5: s/everyone agrees to abide by/everyone agrees to follow/

[Ballot discuss]
Section 8.3.1:

  o  When you think you are finished with the draft process and are
      ready to request that the draft become an RFC, you should
      definitely read "Checklist for Internet-Drafts (IDs) Submitted for
      RFC Publication," http://www.ietf.org/ID-Checklist.html, a list of
      common "nits" that have been known to stop documents in the IESG.
      In fact, you should probably read that document well before you
      are finished, so that you don't have to make a bunch of last-
      minute changes.  There is a very useful checking tool at
      http://tools.ietf.org/tools/idnits/idnits.pyht.

This needs to be rewritten as submission of a draft these days basically require it to pass ID-nits. It might be worth splitting this bullet into two parts. On about submission needing to meet ID-nits. And a second about going forward and the need to revisit the ID-checklist. I would recommend that any one trying to post a draft needs to run idnits on it to verify that it passes.

Section 8.3.2:

You are welcome to suggest
  names; however, it is up to the Internet Drafts editor (and, if it is
  an official WG draft, the WG chair) to come up with the filename.  If
  you follow the naming guidelines given at
  http://www.ietf.org/ietf/1id-guidelines.txt, chances are quite good
  that your suggested filename will be fine.

This section is very confusing as it talks about the "Internet Drafts editor", while it previously talked about the author. To my knowledge it is the author that are responsible for the name. The secretariat may protest against bad or conflicting names but nothing more. Please clarify what is meant.

Section 8.4, last paragraph:

A few years after a document has been a Draft Standard, it can become
  an Internet Standard, also known as "full standard."

This is not in accordance with RFc 2026, see section 6.2:

  A specification shall remain at the Draft Standard level for at least
  four (4) months, or until at least one IETF meeting has occurred,
  whichever comes later.

Please rephrase the sentence.

[Ballot discuss]
The role of WG Chairs is significantly expanded from what RFC3160 says.  I can speak authoritatively for Apps Area but I suspect that other areas have a larger role too.  A chair's role is also :

- To determine consensus on some issues (in addition to what's mentioned already, determining consensus around publishing whole documents)
- To keep WG charter up-to-date
- To exercise technical judgement (to be personally responsible for a
document being complete, allowing interoperability, etc)
- To shepherd document through Last Call and IESG Evaluation, or at a
minimum to aid communication with external reviewers of WG documents
- To schedule meetings, publish agendas and minutes
- To exercise adult supervision of mailing lists
- To choose document editors for WG drafts

I consider some of this stuff quite important, because when I was a WG chair, I was accussed of having technical opinions when I reviewed WG documents, and told that my job was just to submit to IESG!

[Ballot discuss]
The role of WG Chairs is significantly expanded from what RFC3160 says.  I can speak authoritatively for Apps Area but I suspect that other areas have a larger role too.  A chair's role is also :

- To determine consensus on some issues (in addition to what's mentioned already, determining consensus around publishing whole documents)
- To keep WG charter up-to-date
- To exercise technical judgement (to be personally responsible for a
document being complete, allowing interoperability, etc)
- To shepherd document through Last Call and IESG Evaluation, or at a
minimum to aid communication with external reviewers of WG documents
- To schedule meetings, publish agendas and minutes
- To exercise adult supervision of mailing lists
- To choose document editors for WG drafts

I consider some of this stuff quite important, because when I was a WG chair, I was accussed of having technical opinions when I reviewed WG documents, and told that my job was just to submit to IESG!