[wgguide] Initial comments on draft-crocker-rfc2418bis-wgguidelines-00

[Brian E Carpenter <[e-mail]>]

Hi,

I've had a first look at this draft.

What I have *not* done: I have not done a point by point comparison
with 2418. That does need to be done by somebody (I'm not volunteering).
Neither have I read the Appendices yet. However, I think the general
approach is logical and readable.

Here are my stream-of-consciousness comments:

> 1.  Introduction
> 
>    The [IETF] is

I suggest giving the Mission Statement RFC as the primary reference,
and maybe the Tao too.

>    o  Replaces general IETF tutorial material that it had with pointers
>       to independent versions

Syntax

>    Familiarity:    Besides RFC 2026, what other IETF docs are "required"
>       for the reader to have familiarity with?

A lot. See http://www.ietf.org/about/process-docs.html

>    Suspension:    Email -- " the Area Director, with the approval of the
>       IESG, MAY request that the mailing list maintainer block the
>       ability of the offending individual to post to the mailing list."
>       Is it the AD that does this?  Who really does?

I think you've missed some important RFCs out there. Specifically RFC3683,
3934 (which formally updates 2418, and was hard-won) and 4633. See
"Conduct of participants" at the above URL.

>    Wiki?    What should be moved to the Wiki or added to it?

Wikis rot. I would be careful about heavy dependency on a wiki.

> 2.2.  Deliverables
> 
>    A working group's charter specifies deliverables to be achieved.
>    (Section 7.2) These are usually documents to be published in the
>    Request for Comments series [RFC-Editor]

Specifically, in the IETF Stream, so refer to the stream definitions.
See Publication process at the above URL.

>    As a service to the community, the IETF Secretariat operates a
>    mailing list archive for working group mailing lists.

Check RFC 2026, but I think this is a requirement of the standards
process (as well as a service to the community). If not, it must become
a MUST here.

> 2.4.  Area Directors
> 
>    IETF Working Groups are administratively aggregated into "areas".
>    Each working group has a designated ("cognizant") Area Director [AD]
>    ([AD-Desc],[Areas]), to formally select chairs for the working group
>    and to provide oversight.

Also say that they lead relevant discussions in the IESG.

>    ... Chairs are always
>    accountable to the rough consensus (Section 2.8) of the working group
>    participants, as well as to the Area Director who appointed them.

No, to the AD currently providing oversight (the one who appointed them
might have moved on).

>    NOTE:    WG participants MUST conform to the requirements for
>       disclosure of conflicts of interest in [RFC2028].

That seems like a normative use of an informational reference.

> 2.8.  Rough Consensus Decision Making

Somewhere in this section, it seems like we should say that
technical correctness always trumps human feelings.

>    The
>    working group home page is located at:
> 
>             http://datatracker.ietf.org/wg/{ACRONYM}/documents/

Firstly, a better URL is the generic one
  http://datatracker.ietf.org/wg/{ACRONYM}

I could rant at length why defaulting to the /documents page
is annoying, and the 'real' home page should
http://datatracker.ietf.org/wg/{ACRONYM}/charter

Secondly, you cite a lot of URLs and my experience is that this
is dangerous in an RFC. Like wikis, they rot.

> 3.4.  Meeting Materials
> 
>    Any organized working group session (meeting) will have planning and
>    reporting material, including:
> 
>    o  Agenda
> 
>    o  Presentations
> 
>    o  Notes
> 
>    o  Transcripts (e.g., jabber logs)

1. Make it clear that this applies to face-to-face or on-line
meetings.

2. Make it clear that Agenda and Notes are mandatory.

3. I think we've lost the old text stating that meeting minutes
should be a record of decisions made and not a transcript. And
why call them notes when the correct word is minutes?

4. I think we've lost the statement that there must be an
attendance record (which is necessary for IPR disputes).

>    NOTE:    The IETF web site has related information that appears to be
>       out of date, such as [AgendaNotes].

Don't tell me, tell [e-mail] (they love it if you send them
corrected text...)

>    NOTE: The RFC series is a publication mechanism only and publication
>    does not determine the IETF status of a document.  RFCs are processed
>    through a number of independent 'streams', of which those produced
>    with IETF approval represent one.

Give references as noted above.

>    The secretarial function
>    encompasses document editing. 

No, it absolutely doesn't.

>    Most of the time the bulk of the work
>    is done by a few dedicated participants.

That comes out rather pejorative. Suggestion:

   In many working groups, the bulk of the work
   is done by a core of dedicated participants.

>    Most working groups are
>    not so fortunate.  For them, active management might be required, to
>    determine such things as the sequence of work, the design teams for
>    doing core work, issue-tracking, the approach for resolving issues,
>    and even discussion facilitation.

I find the last three words a bit euphemistic. How about "and moderation
of contentious discussions"?

> 4.2.1.  Characterizing the Effort

Suggest adding:

* Consider any effort needed for liaison within the IETF or
  with other SDOs.

>    (Task)    Given a sequence of documents, what are the subordinate
>       steps that will achieve necessary milestones?  It can help to
>       chart this explicitly in the working group Wiki.  (Section 3.2)

or the issue tracker?

>    Meetings can be face-to-face, such as during the thrice-annual IETF
>    Plenary Meeting, or "virtual" via teleconference or chat session.
>    Face-to-face meetings can (and often do) include provisions for
>    virtual participation to accommodate participants who cannot attend
>    in person.  See: Section 4.6, Section 4.7, Section 4.6.4.
> 

I've developed a dislike of this use of "virtual". The meeting, and the
participation, are *real* for goodness' sake. Can't we just say "on line"
or "remote"?

>    (Task)    The Chair has the responsibility for overseeing the process
>       but MAY delegate direct process management to a formally-
>       designated Facilitator.

...and MUST do so if there would otherwise be a conflict of interest.

>          Timing:    The input pertains to a topic that the working group
>             has not yet opened for discussion; or Scope The input is
>             outside of the scope of the working group charter.

That seems to be two items squashed into one.

Also, is this one missing?

Wrong: The working group quickly concludes that the input is technically incorrect.

>    IETF rough consensus does not require that all participants agree

I suggest:

   IETF rough consensus does not require that no participants disagree

to avoid the question of the silent majority. (Triple negative, I know.)

> 4.5.  Mailing List Primacy

I found the discussion of design teams out of place here - I suggest
reducing it to a forward reference to the later discussion.

>    (Task)    As a last resort and after explicit warnings, the Area
>       Director, with the approval of the IESG, MAY request that the
>       mailing list maintainer block the ability of the offending
>       individual to post to the mailing list.  (If the mailing list
>       software permits this type of operation.)  Even if this is done,
>       the individual MUST NOT be prevented from receiving messages
>       posted to the list.
> 
>    Other methods of mailing list control MAY be considered but MUST be
>    approved by the AD(s) and the IESG.

I think this has to be reviewed in the light of  RFC3683,
3934 and 4633 mentioned above.


>    When acceptable to the WG, the Chair MAY call for
>    restricted participation (but not restricted attendance!) at IETF
>    working group sessions for the purpose of achieving progress.

As written this calls up a WTF? reaction. I think it needs context,
about when discussion is bogged down because of persistent off-topic
interventions, or something.

> (Task)    All relevant documents to be discussed at a session SHOULD
>       be published and available as Internet-Drafts at least two weeks
>       before a session starts, so that working group participants have
>       adequate time to review all documents.

How about a similar task for all meeting materials to be posted
a day in advance, for the convenience of remote participants?

>    1.   An individual or a group has something for the WG to discuss and
>         publishes a document on the topic as an individual I-D
> 
>    2.   WG adopts the document as a WG work item, per section 2 of
>         [RFC7221]

Mention draft naming conventions here?

>    6.   The Working Group, through the chairs or the shepherd, make a
>         recommendation to the to the Area Director that a standards
>         action be approved regarding the document [RFC 2026]
> 
>    7.   Area Director reviews the document to determine if the standards
>         action should proceed; this review may include an external
>         review, per [RFC2026]

Delete the word "standards" twice - this also applies to Informational
and Experimental documents.

At the end of the list:

Note that during steps 8 through 11, in addition to review and comments
by anyone, several reviews by organized review teams may occur.

(Task) The shepherd must ensure that all review comments are dealt
with appropriately, with any substantive technical changes being referred
to the WG as a whole. Any substantive technical changes proposed after
IESG review, up to the moment of RFC publication, must also be referred
to the WG as a whole.

>       The output
>       of a design team always MUST be subject to approval, rejection or
>       modification by the WG as a whole.

Add:
There is no presumption in advance that it will be accepted.

>  these are typically summarizations of
>       discussions, rather than detailed 'minutes'.  [I-D-Jscribe]

s/minutes/transcripts/

> 7.1.4.  Charter review & approval
> 
>    Proposed working groups often include technically competent
>    participants ...
...
>    At the discretion of the Area Director, approval of a new WG MAY be
>    withheld in the absence of sufficient Adviser resources.

This material seems like a separate topic that deserves its own
subsection "Technical Advisor" or something.
(Nit: The IETF site uses Advisor, not Adviser)

At the very end of 7.1.4. Charter review & approval, I suggest

Working group chairs are announced with the charter. Note that
the chairs might or might not be the original proponents of the
work or the BOF chairs (if any). The Area Director will appoint
chairs that he or she considers to be the best people for the
job, and it may be preferable for the technical experts to focus
on technical contributions rather than on chairing duties.

>    The copy of the message to the IESG Secretariat is to ensure that the
>    request gets recorded by the Secretariat so that they can monitor the
>    progress of the document through the process.

This is left-over text that the tracker makes redundant.

>    Unless returned by the IESG to the WG for further development,
>    progressing of the document is then the responsibility of the IESG.

The shepherd is supposed to be in the loop too.

>    After IESG approval, responsibility for final disposition is the
>    joint responsibility of the RFC Editor, the WG Chair and the Document
>    Writer.

s/WG Chair/shepherd/ I think. The shepherd may or may not be a WG chair.
You probably need a reference for shepherding - RFC 4858.

One question: the header says "Updates: 2026"? In what respect? I didn't
notice anything specific.

That's it for now.

   Brian