On Fri May 20 2005 16:15, wayne wrote:
There is a new I-D for the SPF email anti-forgery system available for
review. This draft tries to document the current practices of the
~1,000,000[1]
[remainder of marketing blurb elided]
See: http://www.ietf.org/internet-drafts/draft-schlitt-spf-classic-01.txt
The ID-tracker says that the intended status -- which is nowhere mentioned
in the draft itself -- is Experimental.
It is entirely inappropriate to mention it in the draft. The final status of
the draft is determined by the IESG; the status in the datatracker (and
eventually in the last call) is the status believed to be appropriate by the
submitter/WG. (I have seen documents last called as informational moved to
experimental and vice versa. I've also seen documents last called for standards
track approved as informational or experimental.)
Experimental RFCs typically
define a specification which is part of a research or development effort,
not "document [...] current practices" -- that would be an Informational
RFC (or for non-protocol issues, a BCP RFC). In either case, there may
be problems with the draft's use of BCP 14 imperatives and other keywords.
I've heard this argument before. I do not buy it, and in the past the IESG has
not bought it either. These terms are a specification tool, nothing more and
nothing less. Nothing about their use or non-use has anything to do with the
status of a document. For example, an informational document describing some
non-IETF protocol might be much clearer for having used MUST/SHOULD/MAY. Why
should we deny such a document access to this terms?
It is possible to use the terms inappropriately, of course. But this has
nothing to do with document status.
Experimental in particular would seem inappropriate for another reason
noted in the IESG comments; viz. that the draft attempts to document a
version which has apparently been superseded. Moreover, the message to
which this is in response claims a different intended status (see below).
IMO it is appropriate if the intent is to gain experience with the
specification and eventually, if experience proves positive, move it onto the
standards track. If, OTOH, the intent is to document something that's in use
but nonstandard and there's no intention to ever place it on the standards
track, informational is the appropriate status.
The real question for this particular document is how the determination of it's
worthiness of an eventual move to the standards track is going to be made,
regardless of the status it receives now.
Discussions about this, and previous, drafts have been taking place on
the spf-discuss(_at_)v2(_dot_)listbox(_dot_)com mailing list. To subscribe
or read
the archives, see http://spf.pobox.com/mailinglist.html
While I have been reading this mailing list for many months and will
note any comments posted here, sending email to the spf-discuss list
or to me personally is probably better than flooding this list.
The draft notes "The SPF project DOES NOT expect the IESG to review
this version. Instead, a two week pseudo last call will be put out
to collect any final changes. After that, a new I-D will be
submitted with the expectation of an IESG review.".
This statement is a best superfluous. The IESG generally only reviews drafts it
has been reqested to review in one way or another. And while some documents can
go to the IESG without an IETF last call (not standards-track ones, of course),
IMO it would be entirely inappropriate for this one to. It is also entirely
possible that multiple revisions will be needed prior to handing it off
to the IESG.
I have copied
the IESG mailing list so that the IESG can be kept informed of the
discussion -- if the intent is as stated not to subject the draft to
further public review in view of the IESG, then it would at least seem
appropriate to have suggested that copies of comments should be sent
to the IESG list.
Regardless of the intention, whether or not there's a last call for further
public review is up to the IESG. The IESG can, and often does, request last
calls for informational or experimental documents. I think this is one that
definitely deserves a four week last call.
If the intent is in fact to change the intended
status from Experimental (I-D tracker) to Standards Track (as stated
by the author in the predecessor of this message; see below), then
the IESG may wish to initiate a New Last Call of at least 4 weeks
duration in accordance with the procedures for an individual
submission for Standards Track status as outlined in RFC 2026 (BCP 9).
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.
Use of the word "standard" is going to cause problems for either
Informational or Experimental status.
Well, the term was "de-facto standard" not "standard". I don't like the term
much either and IMO it is inappropriate to say this, especially if the intent
is for this to eventually wind up as a standards-track document.
OTOH, an organization where a document labelled "draft standard" has higher
status than one labelled "proposed standard" has little to complain about when
it comes to terminology...
I note that the document uses
the term standard in several places, including:
o the IPR boilerplate, which is probably inappropriate for a draft or
RFC intended for Experimental or Informational status, or one that
has been moved to Historic status. I realize that the boilerplate
is not the author's handiwork, and that authors currently have zero
latitude to correct such errors in boilerplate according to recent
IETF Secretariat policy. I mention it to bring the issue to the
attention of the IESG, which may choose to consider the problem.
I agree the term should be "specification" or "document" or something similar
rather than "standard". However, I also think the costs of correcting this FAR
outweight any potential benefit. At most this should be noted for correction
should there be cause to change the boilerplate to correct some more serious
problem at some point in the (hopefully distant) future.
o in the BCP 90-derived registration template. "Standard" status would
be inappropriate for an Experimental RFC, or for one which provides
Informational documentation of an obsoleted or otherwise undesirable
mechanism. In the case of an Experimental RFC, the registration
should probably be in the Provisional, rather than Permanent registry,
and the status per BCP 90 section 4.2.1 should reflect the actual
intended status corresponding to the draft's publication, viz.
"experimental" or "informational", both of which are explicitly
provided for in BCP 90 section 4.2.1. That section also provides for
"obsoleted" and "deprecated", which may be appropriate in accordance
with issues registered in IESG comments and as discussed herein.
Given the liklihood that this proposal, regardless of its final disposition,
will remain deployed for the forseeable future, I'm inclined to think
the registration should be permanent, not provisional.
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.
On the contrary, I believe the IESG should have the benefit of
community input on such matters, as that may help to gauge community
consensus on relevant issues. In particular, I concur with at least
parts of the noted issues regarding "abuses" of and/or "concerns with"
DNS as it pertains to the draft. Public discussion in plain view of
the IESG may also raise issues of concern which had not been previously
brought to the IESG's attention.
Agreed. If this is to become an IETF specification it needs to be discussed
on an IETF list.
SPF does not directly change RFC2821 or add any extentions to SMTP.
Indeed, one of the IESG comments suggests that a more appropriate
mechanism might have been to use such an extension.
Which would make this much harder to deploy.
...
I'm not going to rehash the whole "MAIL FROM is not the sender" argument - I'm
frankly tired of doing so. Suffice it to say that this draft needs to document
the shortcomings fully and completely, as Bruce suggests. I will also add,
however, that Bruce and others who are less tired of this particular discussion
than I am would do well to suggest specific text to add or change rather than
running around this particular track for the Nth time.
Ned