The IESG has reviewed William Leibzon's appeal against the approval of draft-lyon-senderid-core-01 (see http://www.ietf.org/IESG/APPEALS/appeal2-draft-lyon-senderid.txt for the full text of the appeal). Firstly we recall that the Sender ID drafts, and the SPF draft, were approved for publication as Experimental RFCs and not approved for the Standards track. The bar is lower for Experimental RFCs. To avoid confusion, we repeat here the text of the IESG Note to be included in each of the resulting RFCs: "The following documents (draft-schlitt-spf-classic, draft-katz-submitter, draft-lyon-senderid-core, draft-lyon-senderid-pra) are published simultaneously as Experimental RFCs, although there is no general technical consensus and efforts to reconcile the two approaches have failed. As such these documents have not received full IETF review and are published "AS-IS" to document the different approaches as they were considered in the MARID working group. "The IESG takes no position about which approach is to be preferred and cautions the reader that there are serious open issues for each approach and concerns about using them in tandem. The IESG believes that documenting the different approaches does less harm than not documenting them. "The community is invited to observe the success or failure of the two approaches during the two years following publication, in order that a community consensus can be reached in the future." We have reviewed the content of the appeal and subsequent email discussion. The appeal asserts that Sender-ID makes non-standard use of Resent- headers in a way that may affect their interpretation by both participants and non-participants in the Sender-ID experiment. The appeal requests the IESG to address this, without suggesting a specific remedy. After receiving expert advice from Chris Newman, the IESG has decided it is sufficient to add the following text to the IESG Note to be added to the four documents listed above: "Participants in the Sender-ID experiment need to be aware that the way Resent-* header fields are used will result in failure to receive legitimate email when interacting with standards-compliant systems (specifically automatic forwarders which comply with the standards by not adding Resent-* headers, and systems which comply with RFC 822 but have not yet implemented RFC 2822 Resent-* semantics). It would be inappropriate to advance Sender-ID on the standards track without resolving this interoperability problem." We thank William Leibzon for bringing this issue to our attention, and we hope that the augmented IESG note will address his concerns. _______________________________________________ IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
