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@ietf.org or iesg@ietf.org mailing lists. _______________________________________________ IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
