On 02/03/06, Leslie Daigle <leslie@xxxxxxxxxxxxxxx> wrote: > On February 8, 2006, The IAB received an appeal from Julian Mehnle > appealing the IESG decision to publish draft-lyon-senderid-core as an > Experimental RFC. According to the procedures in Section 6.5.2 of RFC > 2026, the IAB has reviewed the situation and issues the following > response. > > 1. Summary of IAB Response > > The appeal is denied and the IESG's decision is upheld. > > > 2. Background > > After the termination of the MARID WG, the IESG approved both > draft-schlitt-spf-classic-02 and draft-lyon-senderid-core as > Experimental RFCs. Both RFCs were to bear the following note: > > "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 problem is that they ARE NOT published AS-IS to document the different approaches as they were considered (and _documented_) in the MARID working group. This IESG statement clearly violates the reality, just look at what was presented in the appeal: <<The conflict arose only after the IESG asked for individual draft submissions from the SPF and Sender ID authors and draft-lyon-senderid-core-00 was submitted (which for the first time included the re-interpretation of "v=spf1" records for the PRA identity). Accepting such a submission despite the prior consensus of the MARID WG[5] (which was closed afterwards) that "v=spf1" should not be used for checking of PRA clearly violates the ultimate goal of producing reliable standards.>> <<It is also worth noting that at the time the MARID WG was closed, the then-current Sender ID specification draft-ietf-marid-protocol-03[18] did not include the re-use of "v=spf1" records for PRA checking. This was only introduced in the individual submission draft-lyon-senderid-core-00 [19] in October 2004. Also did Microsoft's record generation wizards generate only "v=spf2.0/pra" records until the end of October[20,21], when they began generating only "v=spf1" records.>> I have not heard anyone question this issue with Sender ID that was once again raised in the IAB appeal. Do you thus find it ethical and professional to publish these RFCs with the note that does not reflect the documented reality of the MARID WG? If any note is to be included in the RFCs, it should be the one from the appeal. Cheers, Constantine. _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf