Subject: Re: Appeal: Publication of draft-lyon-senderid-core-01 in conflict with referenced draft-schlitt-spf-classic-02

From: Bruce Lilly <[email-masked]>
Date: Sun, 28 Aug 2005 11:26:46 -0400

>  Date: 2005-08-26 10:45
>  From: Andrew Newton <[email-masked]>

> >> 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: "C. M. Heard" <[email-masked]>
Date: Sun, 28 Aug 2005 11:45:44 -0700 (PDT)

On Sun, 28 Aug 2005, Bruce Lilly wrote:
> Historic except via the Standards Track [...]

What makes you say that?  It sure isn't what I read from RFC 2026.  It
says this in Section 4.2.4:

   A specification that has been superseded by a more recent
   specification or is for any other reason considered to be obsolete is
   assigned to the "Historic" level.  (Purists have suggested that the
   word should be "Historical"; however, at this point the use of
   "Historic" is historical.)

Seems to me that the proviso "is for any other reason considered to be
obsolete" could reasonably be construed to cover the initial publication
of an obsolete specification.  It's certainly true that the most common
way to get to Historic is to start on the standards track and then get
retired, but I see nothing in RFC 2026 that says (or even implies) that
this is the only way.

//cmh

---

From: wayne <[email-masked]>
Date: Mon, 29 Aug 2005 00:05:19 -0500

In <[email-masked]> Bruce Lilly <[email-masked]> writes:

> was to "document a de-facto standard" [his words].

What I said both times I submitted the spf-classic I-D for review by
various IETF mailing lists was, in full:

   I realize that the whole subject of SPF (and similar systems) has a
   certain amount of controversy to it, but for the purposes of this
   draft, I am very reluctant to try debate these issues.  The goal is to
   document a de-facto standard.  Debates about better techniques, why
   SPF is evil, etc. are probably best discussed on things like the IRTF
   ASRG list, SPAM-L, the NANAE newsgroup, or on spf-discuss on a
   separate thread/subject.

(See http://www.imc.org/ietf-smtp/mail-archive/msg01404.html and
http://www.imc.org/ietf-smtp/mail-archive/msg01870.html)

There were quite a few technical errors that were corrected because of
the reviews in ietf-822, ietf-smtp and the dnsext lists.  I even made
an editorial change to the draft because Bruce didn't think that one
RECOMMENDED item applied to only those domain owners that chose to
participate in SPF.

My intent was to simply not cause the various mailing lists to be
flooded with off-topic discussions, especially those that have had a
history of never being resolved.

-wayne

---

From: Scott W Brim <[email-masked]>
Date: Mon, 29 Aug 2005 09:26:05 +0200

I would appreciate not hearing the same arguments again and again.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 29 Aug 2005 13:54:43 +0200

I request that people who want to discuss technical issues and proposals,
rather than the narrow issue of the appeal itself, please drop
[email-masked] from their messages or change the subject to a relevant
technical topic.

Thanks

    Brian Carpenter