comments on draft-rja-mail-lists-00.txt

[Keith Moore <moore@cs.utk.edu>]

I hadn't seen this until today.

In general I'm supportive of having a standard for IETF WG mailing 
lists - I drafted a similar document myself many years ago that
died due to lack of support.

But I have some issues with the current version of this document.

> 4.1 Message Content
> 
>          Postings to IETF mailing lists MUST focus  on  architectural,
>    standards,  or  technical  content  that advances the progress of the
>    Working Group towards fulfilling  its  charter.   Postings  that  are
>    primarily  of  a  political,  (non-technical) philosophical, or legal
>    nature SHOULD NOT be made to IETF mailing lists.  Postings  that  use
>    foul  language  or  attack  people  (as  different from criticising a
>    particular idea on technical grounds) are  always  inappropriate  and
>    SHOULD NOT be made to IETF lists.

I think these criteria need a lot of refinement.  The MUST is too 
restrictive and too narrow, and the SHOULD NOT criteria are too vague.
Input of a political, legal, or philosophical nature are often valuable 
to a WG in its deliberations.  And there needs to be room for at least
some input which doesn't "advance the progress" of a WG (as the WG
defines it) but rather objects to the course that it the WG is taking - 
while still not permitting denial of service attacks.

here's my stab at rewriting this:

   Postings to IETF WG mailing lists SHOULD be intended to advance the 
   progress of the WG as defined by its charter, to contribute to a discussion 
   of future WG directions, or to provide reasoned arguments as to why the 
   WG should alter or abandon its current course.  Most postings SHOULD 
   generally be technical or architectural in nature, or regarding WG
   process issues, and directly related to the WG's current efforts as 
   defined by the charter and the chair.  Postings of a political, legal, 
   or (non-technical) philosophical nature MAY on occasion be useful,
   but extended discussion of such topics SHOULD be avoided.  

   Postings  that  use foul  language  or  attack  people  (as  different 
   from criticising a particular idea on technical grounds) are  always  
   inappropriate and SHOULD NOT be made to IETF lists.  Complaints about
   disruptive behavior of particular individuals within the group should be 
   made to the individuals themselves (via private mail), and if that is not 
   effective, to the WG chair (again via private mail).


>           Postings to IETF lists MUST be made using  real  identifiable
>   names   and   email   addresses,  rather  than  obfuscating  aliases.

I don't think we can or should restrict what email addresses people use,
since many provider-assigned email addresses could be regarded as
"obfuscating".  And I'm doubtful that it's a good idea to exclude anonymous
input.  If someone wants to provide useful input anonymously in order to
avoid backlash from their employer, we should accept such input without
hesitation. 

I would rewrite this as follows:

    Postings to IETF lists SHOULD be made using real identifiable names,
    rather than obfuscating aliases.  Anonymous or pseudonymous input
    MAY be occasionally provided when necessary, but SHOULD be clearly
    labelled as such rather than as coming from a ficticious person.  

    Originator email addresses (From, Sender header fields) on postings 
    SHOULD be stable, used exclusively by the individual posting the 
    message, and suitable for replies. 

>  Participants ought not use their employer affiliation for  marketing,
>  neither  should  they  disguise  their  employer  affiliation in IETF
>  activities.

Mumble. If participants are obeying the rules, their employer is irrelevant.
Folks who are expressing their best personal engineering opinions should
be free to omit their employers.  However, I have seen a case where a 
chair failed to disclose that he was doing consulting work for a party
that had a strong interest in a particular outcome of the WG - and this
tainted the WG's work.

IETF doesn't have any requirements to state employer affiliation as a
condition of WG participation, and this document isn't the place to
impose such requirements.  Nor do I think we can or should require
IETF participants to use employers' email addresses, particularly when
we also expect them to represent their own best technical engineering
judgement, rather than the interests of their employers, when participating
in IETF.  That could put them in a conflict of interest that would prevent
their ethical participation in IETF>  So I think it would be better to omit 
this sentence.

One other point about message content - it has become fashionable in
recent years to append notices to messages that "this message contains
privileged content and you may not disclose it, etc."  IMHO such notices 
are not appropriate for content sent to IETF mailing lists, because IETF
requires that such input be freely redistributable.  Folks who wish to 
participate in IETF SHOULD NOT use mail systems that append such notices.

> 4.3 List Moderation

I would suggest an alternative to either self-moderation or full moderation -
hybrid moderation, where postings from subscribers or previously
approved posters are assumed to be valid, and postings from others
are subject to human moderation.

> 4.3.1 Self-Moderation

This section is by far the most problematic of the entire document.

IMNSHO, self-moderation is NOT appropriate for IETF mailing lists
unless the moderation policy is to approve non-subscriber postings 
that are on-topic. 

Many WGs operate in a vacuum, with a narrow focus, and little awareness of 
how their decisions might affect other WGs, existing practice, or existing 
applications.  Occasional input from non-subscribers, or occasional discussions 
involving more than one WG or mailing list, can be immensely valuable at addressing 
this problem.  It's also quite reasonable for non members to respond to Last 
Call notices and proposed charter changes by sending mail to the WG's mailing list.

For WGs that have employed it (usually in violation of the rules, and 
without prior approval from IESG) self-moderation has imposed a considerable 
barrier to such input.  I have seen many of my own non-subscriber contributions 
discarded, bounced, or ignored.  On those occasions when a notice that the message 
was not fowarded to the list has been provided, such notices have in my experience 
often been terse, vague, or even abusive.  The steps that are necessary to get a 
message posted to the WG list have varied widely from one list to another, with widely 
varying results.  

Some list software provides for a list of non-subscribers who are permitted to post, 
but multiple exchanges of messages, with delays sometimes measuring in hours, and 
multiple context switches, have often been required to get added to this list of addresses.  
When such messages were posted to the list by the moderator, the headers of the message 
were often altered so that replies would not go back to the author of the message.  

Finally, WG participants that subscribe to lists using subaddresses (like 
moore+xxx@cs.utk.edu) so that their mail will arrive pre-sorted into its
correct folder, should not be required to change their From addresses
every time they post a message to that list. Nor, when it is desirable 
to cross-post to multiple lists, should participants using subaddresses
be required to post the same message separately to each list, with different
return addresses.

self-moderation is neither necessary nor justifiable.  a far more reasonable
strategy is to allow contributions from subscribers (or approved posters)
to be forwarded to the list automatically, and to perform "full moderation"
on contributions from non-subscribers.  and some kinds of messages - e.g. those
with invalid reply addresses or executable attachments - can be silently 
discarded, further reducing the burden on the moderator.

if a moderator claims he/she does not have time to review the few messages
that arrive from non-subscribers, another moderator should be found, rather
than using this as an excuse to close the list to input from outsiders.

when moderators do forward messages to the list, they need to ensure that
all message headers, including received headers, arrive as received from
the original poster - as an original message, not a forwarded message,
and with the poster's return address, not the moderator's return address.

> 4.4 Languages & Character Sets 

I agree with the sentiment, but I think it will be difficult to make this stick.
Too few folks have control over what charset their UAs generate.

> 4.5.1 Preferred Mail Format

I'm entirely in agreement with the restrictions on attachment types.

> 4.5.2 Mail Attachments (General)

I would say that any attachment MUST have a proper MIME content-type label,
and not expect that the recipient will be able to interpret the filename extension.

> 4.6 Vacation Messages

this is too vague.  I would say:

automatic responses SHOULD be sent only to the return-path or SMTP MAIL FROM address, 
rather than to the From address.  They MUST NOT be sent to TO/CC addresses.

automatic responses SHOULD NOT be sent for any message in which the recipient
address does not appear in the To, Cc, or Bcc header field of the subject message.

regarding Precedence headers: "MAY or MAY NOT" is vague because "MAY NOT" is
ambiguous.  I would just say "MAY"; this implies that omitting the Precedence
header is also reasonable.

It is NOT appropriate to use Sender as a tag for mail sorting, nor for lists to
modify or add this header field from that supplied by the original poster.
Sender is intended to identify the acutal sender of the original message
when there are multiple From addresses or when the From address is different
than the identity of the person who sent the message.  For the list to mung
Sender is to lose valuable information.

--

Finally - as many aspects of this document are technical, I think it would be
appropriate to discuss this document on the ietf-822@imc.org mailing list,
in addition to any process discussion that takes place.

Keith