Date: 2005-08-26 10:45
From: Andrew Newton <andy(_at_)hxr(_dot_)us>
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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf