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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]