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
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf