ietf
[Top] [All Lists]

Re: Last Call: <draft-ietf-spfbis-4408bis-19.txt> (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard

2013-08-29 11:32:23


--On Wednesday, August 28, 2013 07:21 -0700 Dave Crocker
<dhc(_at_)dcrocker(_dot_)net> wrote:

RFC 5507 primarily raises three concerns about TXT records:

RFC 5507 is irrelevant to consideration of the SPFbis draft.

Really.

RFC 5507 concerns approaches to design.  However the SPFbis
draft is not designing a new capability.  It is documenting a
mechanism that has existed for quite a long time, is very
widely deployed, and has become an essential part of Internet
Mail's operational infrastructure that works to counter abuse.
...

Dave.

I may be violating my promise to myself to stay out of
SPF-specific issues, but this does not seem to me to be an
SPF-specific issue.  I suggest to you that the notions of IETF
change control and consensus of the IETF community are very
important to the integrity of how the IETF does things.  The
question of where and how the IETF adds value comes in there
too.  If some group --whether an IETF WG or some external
committee or body-- comes to the IETF and says "we have this
protocol, it is well-tested and well-deployed, and we think  the
community would benefit from the IETF publishing its
description" that is great, we publish as Informational RFC (or
the ISE does), and everyone is happy.   If that group can get
IETF community consensus for the idea that the spec should get a
gold star, someone writes an Applicability Statement that points
to the other document and says "Recommended", we push any
quibbles about downrefs out of the way, and we move on.

However, it seems to me that, for anything that is proposed to
be a normal standards track document, the community necessarily
ought to be able to take at least one whack at it on IETF LC.
That "one whack" principle suggests that one cannot say "this
was developed and deployed elsewhere and is being published as
Experimental" (which is what, IIR, was one thing that happened
in the discussion of 4408) and then say "now the design quality
of SPF is not a relevant consideration because it has been
considered elsewhere and widely deployed".  If the IETF doesn't
get a chance to evaluate design quality and even, if
appropriate, to consider the tradeoffs between letting a
possibly-odious specification be standardized and causing a fork
between deployed-SPF and IETF-SPF, then the IETF's statements
about what its standards mean become meaningless (at least in
this particular type of case).

Now I think it is perfectly reasonable to say, as you nearly did
later in your note, that SPF-as-documented-in-4408bis is
sufficiently deployed and would be sufficiently hard to change
that the community should swallow its design preferences and
standardize the thing.  One can debate that position, but it is
at least a reasonable position to take.    Modulo some quibbles,
it probably the position I'd take at this point if I were
willing to take a position, but it is different from saying
"can't discuss the design choices".

Things would also be very different if the present question
involved updating or replacing an existing Proposed Standard.
If design decisions were made in that earlier version (and that
went through IETF LC and got consensus), I think it would be
perfectly reasonable to say "the IETF community looked at that
before and it is now too late".  You've done that before, I've
done it before, and I don't think anyone who isn't prepared to
explain why, substantively and in terms of deployment, it isn't
too late should be able to object.  

But, in the absence of demonstrated and documented IETF
consensus --independent of WG consensus, implementation
consensus, deployment consensus, silent majority consensus, or
any other type of claim about broader community consensus-- I
don't think one can exclude a discussion of a specification's
relationship to various design considerations, if only because
"that may be deployed but the IETF should not endorse it in that
form by standardizing it" or even "if the community that is
advocating this won't allow design issues to be discussed, then
there is no IETF value-added and the IETF should decline to
standardize on that basis" have got to be possible IETF
community responses.

To consider RFC 5507 with respect to SPFbis is to treat the
current draft as a matter of new work, which it isn't.

No, it is to treat the current draft as a matter of work that
the IETF is being asked to standardize for the first time...
which, as far as I can tell, it is.

I think those distinctions about standardization (including the
value-added and change control ones) and what can reasonably be
raised on IETF LC are important to the IETF, even for those who
agree with you (entirely or in part) about what should happen
with this particular specification at this particular point.

YMMD.

best,
   john

<Prev in Thread] Current Thread [Next in Thread>