Skip to main content

Appeal against IESG blocking DISCUSS on draft-klensin-rfc2821bis (John C Klensin; 2008-06-13) - 2008-06-13
Response - 2008-07-07

* To: john-ietf at jck.com, ietf-smtp at imc.org
* Subject: Response to appeal from John Klensin dated 13-Jun-2008
* From: IESG Secretary <iesg-secretary at ietf.org>
* Date: Mon, 7 Jul 2008 10:00:01 -0700 (PDT)
* Cc: ietf-announce at ietf.org

The IESG received an appeal from John Klensin dated June 13, 2008.
This is a response to that appeal.

  1. The appeal asked for the IESG to approve RFC2821bis. (The
    wording was that "the blocking DISCUSS must be removed" but that's a
    detail of determining IESG consensus to approve a document.) The
    IESG came to consensus that the use of non-example domain names
    should not prevent publication of RFC2821bis, even though the IESG
    finds this practice can cause harm. The arguments made in public
    list discussion of the appeal have been a factor in the IESG being
    able to come to consensus on this point.

The IESG believes the appeal has surfaced several important issues
with respect to the use of non-example names in IETF stream RFCs.
First, current IESG practice goes beyond the explicit requirements in
BCP 32. An IESG Statement that documents and explains this practice
is being developed to ensure transparency and avoid late surprises in
the publication process. Second, given that the non-example domain
names are already published in RFC 2821, and some were used with
permission, the possibility of harm to the Internet is less clear
than with new specifications. Community input is needed with respect
to the application of this policy to revision of specifications.

  1. The appeal asked for the IESG to clarify its DISCUSS
    terminology. The IESG agrees that all DISCUSS positions are
    blocking for as long as that position exists. But it is normal, and
    indeed encouraged, to establish a dialog between the holder of the
    DISCUSS, the document shepherd (see RFC 4858), the authors, the
    working group, and the sponsoring AD. In some cases such dialog
    results in clearing the DISCUSS without changes to the document, such
    as when additional information convinces the AD that there actually
    is no significant issue. In other cases the parties should come to an
    understanding on how the DISCUSS can be resolved. In its May 2008
    retreat, the IESG talked about the DISCUSS resolution process. One of
    the items that was felt important in improving this process was that
    the role of the shepherds should be more central than it currently is.

  2. The appeal asked the IESG to "prohibit the use of a blocking
    DISCUSS on a specification for any editorial or other non-technical
    reason unless the requirement is clearly documented". The IESG
    Statement "DISCUSS Criteria in IESG Review" is consistent in spirit
    with this request, noting that stylistic issues and pedantic
    corrections are not appropriate for a DISCUSS. (See http://
    www.ietf.org/IESG/STATEMENTS/discuss-criteria.html) However, several
    ADs felt that the issue was technical, not stylistic, thus the IESG
    as a whole did not have consensus that the issue was non-technical in
    this case. Further, the IESG notes that the recommendations
    regarding use of non-example domains are documented in section 6 of
    the ID-Checklist (version 1.7).

The IESG is granted certain authority by RFC 2026 and the published
BCP revisions of that RFC. The current IESG unanimously believes
that the IESG member(s) who entered a discuss position on this
document over this issue were acting within the authority granted
them by these rules. An appeal is not an appropriate mechanism to
revise the rules. Forming IETF consensus on a BCP that revises the
rules is the appropriate mechanism.

  1. The appeal asked the IESG to "explicitly recognize that the
    interests of the IETF and the Internet community are served by
    encouraging the advancement of documents in maturity level on the
    standards track.". The IESG explicitly recognizes this. However,
    the IESG does not agree that the interests of the IETF and Internet
    community are always served by prohibiting changes when documents
    advance.

In addition to the remedies suggested in the appeal, the IESG is
considering other improvements in transparency of its actions. The
IESG continues to welcome feedback from the community on its
procedures. Comments may be directed to the ietf@ietf.org or
iesg@ietf.org mailing lists.