----- Original Message -----
From: "The IESG" <iesg-secretary(_at_)ietf(_dot_)org>
To: "IETF-Announce" <ietf-announce(_at_)ietf(_dot_)org>
Sent: Saturday, October 21, 2006 12:29 AM
Subject: Last Call: 'Progressive Posting Rights Supsensions' to BCP
The IESG has received a request from an individual submitter to consider
the following document:
- 'Progressive Posting Rights Supsensions '
<draft-carpenter-rescind-3683-03.txt> as a BCP
This document abolishes the existing form of indefinite Posting
Rights Action and restores the previous option of finite posting
rights suspensions authorized by an Area Director. It obsoletes RFC
3683 and updates RFC 2418 and RFC 3934.
Publication of this document will classify RFC 3683 as historic.
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send any comments to the
iesg(_at_)ietf(_dot_)org or ietf(_at_)ietf(_dot_)org mailing lists by
During IESG evaluation, an AD raised the concern that the
consensus shown during the last call of this document might not be
strong enough to justify approval. In order to determine the strength
of the consensus, the IESG asks the community to focus on the following
questions in last call responses:
1) Do you support the proposal in section 2 of the draft to restore
the AD and IESG's ability to suspend posting rights for longer than
30 days and to approve alternative methods of mailing list control
as originally documented in RFC 2418?
Not as it is documented in this I-D; the wording is not careful enough - eg
RFC2418 spells out that direct communication should be off list; RFC3934 may
have removed this but it should reinstated to improve clarity.
2) Do you support the proposal in section 3 to rescind RFC 3683?
No; RFC3683 does not remove or modify the toolkit available, it adds a new one.
The bald statement that the present IESG have found it
'troublesome and contentious in practice'
is inadequate to justify its repeal.
3) Do you have any concerns about approving one part of the draft
without approving the other?
Yes, most definitely.
4) Do you have any other comments on the document?
Rather than patch RFC2418, that RFC should be reissued; this is a key process
for the IETF and we should not have to try and work out from multiple RFC what
the current state is.
The file can be obtained via
IETF-Announce mailing list
Ietf mailing list