Gen-art review of draft-hartman-mailinglist-experiment-01.txt

[Elwyn Davies <[e-mail]>]

I was selected as General Area Review Team reviewer for this specification
(for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Document: draft-hartman-mailinglist-experiment-01.txt
Intended Status: Experimental (RFC3933 Process Experiment)
Shepherding AD: Brian Carpenter
Review Trigger: IETF Last Call ending 15 March 2006

Summary:
[Note: This is the first time that I have done a Process Experiment 
review and I will have to stretch the usual review criteria a bit.  
Basically I believe I should be looking for internal self-consistency, 
consistency with associated processes and likelihood of damage to the 
functioning of the IETF.]

I will disregard all matters of the appropriateness or otherwise of the 
timing of this experiment vis-a-vis any discussion of ongoing PR 
actions. This review will only consider the merits of the proposal itself.

I think this draft is NOT currently in a suitable state to produce a 
well-defined experiment.  The main reason for this conclusion is that 
the experiment consists of enabling a meta-mechanism and suggesting 
something the IESG might possibly do with this power rather than 
explicitly stating that this is what the IESG should put in place.  My 
reading of s7.2 of the IESG Charter [RFC3710] is that the IESG has the 
power to do this sort of thing already anyway.  Were the suggested 
mechanisms eventually adopted, I would have some qualms about the 
possibility of indefinite bans being possible without allowing a wider 
(possibly IETF as opposed to IESG) consensus, but that point is 
currently moot as the actual proposals that would be put in place are 
not specified by this document.

[Aside: Posting policies will need to start covering wikis and issue 
trackers in the immediate future!]

Review:

s1:
I think that this section of the last paragraph of s1 
overstates/mis-states what this document actually does:
>
> This memo is an RFC 3933[RFC3933] experiment to provide
>    the community with additional mechanisms to manage its mailing lists
>    while the community decides what mailing list guidelines are
>    appropriate.  IN particular this experiment creates a level of
>    sanction between RFC 3934 and RFC 3683 for working group lists and
>    creates sanctions other than RFC 3683 for non-working-group lists.
>
In practice all that s4 mandates is:
>
> During the
>    experiment period, the IESG MAY approve  other methods of mailing
>    list control besides those outlined in RFC 3683 and RFC 3934 to be
>    used on a specified set of IETF mailing lists.
>
i.e., it enables a meta-mechanism.  s4 then goes on to suggest some 
things the IESG *might* adopt (second half of para 1 and all of para 2 
of s4) and the procedures that it must go through to get them adopted.  
The result of this is (in the first instance) merely the provision to 
allow the IESG to decide to do something.  I don't think this 
constitutes a well-formed experiment.

s3:  The section
>
>    ... and
>    any mailing list hosted on any site or system operated by the IASA or
>    otherwise on behalf of the IETF.
>
still leaves considerable scope for discussion of whether some mailing 
lists associated with IETF stuff would be covered.  In particular I am 
thinking of pre-BOF lists and auxiliary WG mailing lists which are not 
hosted on IETF controlled systems but are discussing IETF related stuff.

s3: The following sentence 'Mailing lists listed at 
https://datatracker.ietf.org/public/nwg_list.cgi are explicitly included 
in this definition.'  has been specifically crafted to catch some of the 
lists where there are currently problems even though these lists are not 
actually hosted on IETF controlled systems.  Although I am not aware of 
any specific problems, there could be potential legal minefields in the 
IETF attempting to manage (especially retrospectively) posting rights on 
mailing lists which are not hosted on IETF hardware.  Some existing WG 
mailing lists are also not hosted on IETF hardware.

s4: Para 2 talks about 'managers' of lists.  This term has not been 
defined - in particular non-WG lists only have administrators (aka 
owners in some cases).

s4, next to last para: The piece about last calls appears to confuse 
last calls relating to the specification of procedures and last calls 
relating to specific PR-actions (as mandated by  RFC3683 but not 
required by RFC2418).  The initial part of the para appears to be 
talking about the  definition of the powers and procedures which the 
IESG takes and decides to follow but this metamorphoses into 
consideration of individual 'procedures' taken under the resulting 
procedures.. too many 'procedures'!  In my view the Last Call which has 
provoked this review really ought to be arriving at consensus on the 
additional procedures currently 'suggested' in the second half of para 1 
and in para 2 of s4 of this document, and the next to last para of s4 
should just state that any actions taken under these procedures don't 
need to be IETF Last Call'ed:  One could then argue about whether this 
was appropriate for (for example) indefinite bans (presumably the higher 
hurdle in RFC3683 as compared with RFC2418/3634 was adopted because of 
some concerns such as this).  As it stands, the sanctions under these 
powers could exceed those allowed by RFC3683 - admittedly not in the 
scope of the experiment but if permanently adopted.


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