> Date: 2005-08-26 10:45 > From: Andrew Newton <andy@xxxxxx> > >> If this is the source of the conflict, then BOTH experiments should > >> not use the v=spf1 records. > >> > >> -andy > >> > > > > The stated goal of draft-schlitt-spf-classic is to document SPF, > > basically as it was before the IETF got involved. Yes, the IETF is > > calling it an experiment, which I don't agree with. It is documenting > > an existing, well established, protocol. > > > > > > Are you saying that the IETF shouldn't publish an RFC that documents > > SPF? > > I stated that the SPF and Sender ID experiments should not use the > v=spf1 records to avoid conflict. I did not state that the IETF > should not publish an Experimental RFC about SPF. > > But since you brought this up: if you (the author of the document) do > not consider this to be an experiment, then perhaps the IETF should > not publish SPF as an Experimental RFC. This is an important point; the SPF-classic draft was announced to the ietf-822 and ietf-smtp mailing lists where there was some discussion on that very point. While the ID-tracker state indicated intended status of Experimental, the author stated that he was "very reluctant to debate" issues of controversy with the technical specification, and that his goal was to "document a de-facto standard" [his words]. Both of which would seem to indicate an Informational document, rather than any other category (at least with no apparent mechanism to get to Historic except via the Standards Track -- more below). However, in the same announcement, the author also stated his intent to "ask the IESG to consider it for a Proposed Standard status". That conflicts with the ID-tracker state indication and with the stated goal and reluctance to discuss technical shortcomings, and with text in the draft itself which conflicted with BCP 9 procedures. The conflicts in those statements were discussed, copying the IESG. While I agree with the principle that the IESG should not be running concurrent experiments that conflict with one another, there is another principle; the IESG should not be running experiments that are harmful to the Internet, especially when the harm is to those who choose not to participate in the experiment(s). As noted in http://www.imc.org/ietf-smtp/mail-archive/msg01872.html SPF is doubly harmful to the Internet (affecting those who do not explicitly choose to participate); in fairness it should be noted that many of the same considerations also apply to Sender-ID and other similar schemes, however SPF appears to be unique at this time in having the distinction of being more thoroughly adopted by spammers (to lend an air of legitimacy to their missives) than by non-spammers. Because of the harm caused to Internet users who travel, which in turn is due to conflation by many such schemes between sending and receipt of (delivery notification) messages and further conflating the receiving mailboxes with sending IP addresses coupled with the inability of most users to alter the relevant DNS records, neither of the schemes being discussed should have been approved as experiments as written. The IESG should examine both of these schemes -- as well as any others that might be under consideration -- as a result of this appeal. The Historic category of published RFCs can be used for documents which specify a protocol or technology which is known to be harmful to the Internet. However, RFC 2026 appears to have no provision for getting to Historic except via the Standards Track, and we would not want to approve a specification with known technical omissions, harmful provisions, unresolved design choices, and which is not well-understood or suitable for further development as a Proposed Standard solely for the purpose of subsequently moving it to Historic. Perhaps we need another category, or at least a path to Historic that doesn't go via the Standards Track. That is a matter that the IETF should consider, but it seems to be outside of the scope of NEWTRK and other WGs, and concerns have been raised elsewhere of the IESG acting as "judge and jury" on procedural matters that affect IESG standards actions. Probably the topic should be discussed on the IETF discussion list, but preferably with a change of subject from the current appeal discussion. _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf