Re: IAB Response to the Appeal from Julian Mehnle
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 To any who reply to this thread: please, please trim the list of recipients to remove any of the following addresses, unless you explicitly want to address them: * iab@iab.org * iesg@ietf.org * [EMAIL PROTECTED] Keith Moore wrote: > when editing documents that purport to describe existing practices and > protocols, there is often a conflict between documenting existing > practice and describing desirable practice (or undesirable practice). > this conflict results in confusion of goals, and one possible result is > that the document describes neither existing practice nor desirable > practice. > > in resolving the conflict it is sometimes useful to separate the two > efforts: > > - describe existing practice, warts and all > - describe what is believed to be good or bad about the existing > practice I agree. But please note that there was no "existing practice" of re-using "v=spf1" records for the checking of the PRA identity or any other non- envelope identities when Microsoft first submitted the Sender ID drafts to the IESG after the demise of the MARID WG. See my IESG appeal (included in the IAB appeal[1]) for details on the history of Sender ID's re-use of "v=spf1". Please do not spread urban legends. Julian. References: 1. http://www.iab.org/appeals/2006-02-08-mehnle-appeal.html -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFEBzeswL7PKlBZWjsRAqBmAJ9AdDrgJmu57uoKLxESZDVnLK1yVwCgrQM0 Rm1xWFooLP/oOhQ45xXBTMY= =1M5G -END PGP SIGNATURE- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [spf-discuss] IAB Response to the Appeal from Julian Mehnle
when editing documents that purport to describe existing practices and protocols, there is often a conflict between documenting existing practice and describing desirable practice (or undesirable practice). this conflict results in confusion of goals, and one possible result is that the document describes neither existing practice nor desirable practice. in resolving the conflict it is sometimes useful to separate the two efforts: - describe existing practice, warts and all - describe what is believed to be good or bad about the existing practice this doesn't have to be done in separate documents but the efforts should be separate so that each effort can have a clear focus. once there is an understanding about what is good and/or bad about existing practice, notes or footnotes can be added to the description of existing practice to inform the reader of these annotations. if there's not consensus about what is good or bad about existing practice, it may be useful to document the lack of consensus. Keith p.s. I am personally of the opinion that SPF in all but a few corner cases is harmful to the interoperability of Internet mail, so I'm very keen to have those limitations documented. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [spf-discuss] IAB Response to the Appeal from Julian Mehnle
On 02/03/06, Leslie Daigle <[EMAIL PROTECTED]> 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: <> <> 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 mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
IAB Response to the Appeal from Julian Mehnle
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 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." Mr. Mehnle appealed the approval of draft-lyon-senderid-core on the grounds that the proposed protocols were incompatible and that the IESG should rewrite draft-lyon-senderid-core to assume the SPF classic interpretation unless a new-style record was present. The IESG rejected his appeal on the grounds that it involved a technical change to the document but added the following strengthened note: "Note that the Sender ID experiment may use DNS records which may have been created for the current SPF experiment or earlier versions in this set of experiments. Depending on the content of the record, this may mean that Sender-ID heuristics would be applied incorrectly to a message. Depending on the actions associated by the recipient with those heuristics, the message may not be delivered or may be discarded on receipt. Participants relying on Sender ID experiment DNS records are warned that they may lose valid messages in this set of circumstances. Participants publishing SPF experiment DNS records should consider the advice given in section 3.4 of RFC (draft-lyon-senderid-core) and may wish to publish both v=spf1 and spf2.0 records to avoid the conflict." Mr. Mehnle appealed to the IAB, reiterating his original issue and raising the following process issue: Finally, the IESG's approval of conflicting experiments could be seen as a failure in following the standards process[9], which in section 4.2.1, "Experimental", requires "verification that there has been adequate coordination with the standards process", which would by analogy not only mean coordination with standards track RFCs but also with other experimental RFCs. 3. Discussion The process issue that Mr. Mehnle raises is rooted in RFC 2026, Section 4.2.1: The "Experimental" designation typically denotes a specification that is part of some research or development effort. Such a specification is published for the general information of the Internet technical community and as an archival record of the work, subject only to editorial considerations and to verification that there has been adequate coordination with the standards process (see below). An Experimental specification may be the output of an organized Internet research effort (e.g., a Research Group of the IRTF), an IETF Working Group, or it may be an individual contribution. On the basis of this text, the IAB concludes that the IESG's approval of draft-lyon-senderid-core does not constitute an endorsement of this technology but simply a publication for the "general information of the Internet technical community". With respect to the issue of adequate coordination, Section 4.2.3 reads (in part): If (a) the IESG recommends that the document be brought within the IETF and progressed within the IETF context, but the author declines to do so, or (b) the IESG considers that the document proposes something that conflicts with, or is actually inimical to, an established IETF effort, the document may still be published as an Experimental or Informational RFC. In these cases, however, the IESG may insert appropriate "disclaimer" text into the RFC either in or immediately following the "Status of this Memo" section in order to make the circumstances of its publication clear to readers. The IAB con
