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.
2. 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.
3. 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.
4. 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(_at_)ietf(_dot_)org or
iesg(_at_)ietf(_dot_)org mailing lists.