-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
William Leibzon wrote:
Wayne Schlitt wrote:
Now would be a good time to decide whether you want to file an IAB
appeal or not. There isn't much use in having the RFC editor do stuff
if we are just going to go into another 3-6 month delay.
I think it would be good to hear from the community at large on this
issue now and this can then be used by SPF Council when making a final
decision on it (...).
I already said I would abstain from the vote as a council member, but of
course I do have an opinion on the "v=spf1 re-use" appeal:
I am still absolutely convinced that the appeal is technically justified.
The Sender-ID spec sanctions the misinterpretation of already published
v=spf1 records. The owners of those records might find that their records
cause unexpected loss of mail, which would not normally have been the case
with a pure MAILFROM interpretation. This might make them abandon their
records or weaken them from "-all" to "?all". And as Frank said, the IESG
appeal was also useful to document our strict opposition against the abuse
of v=spf1 records, even though the appeal didn't succeed.
Now the question is what an escalation of the appeal to the IAB could
possibly benefit us. The IAB cannot modify IESG decisions or make their
own decisions, all they can do is _undo_ IESG decisions. Since we have
_not_ appealed to the IESG about their decision not to publish draft-
schlitt-spf-classic as a "Proposed Standard", appealing to the IAB cannot
turn draft-schlitt-spf-classic into a "Proposed Standard". All an appeal
to the IAB can achieve is to stop the Sender-ID spec from being published
as-is as an "Experimental RFC".
Again, I think that would be technically justified. But there are other
issues we need to consider. For one, appealing to the IAB could
practically (if not formally) delay the publication of SPFv1 as an RFC
even further. Having a published RFC, and be it an "Experimental" one,
would however be useful for convincing MTA authors and OS distros to
finally include SPF support in their official distributions. And having
an "Experimental" RFC _soon_ could improve our position for claiming
implementation and deployment experience when submitting SPFv2.1/v3 for
"Proposed Standard" status in a year or so.
Besides, there are more solutions for overcoming the SPF/S-ID conflict than
just trying to block the S-ID specs from gaining RFC status (which might
not work at all in the first place). Gladly, several people here think
that creating a SPFv2.1/v3 would be useful. In my opinion there's much
more value in that than just any new features (such as new dkim, pgp, or
smime mechanisms) -- it could make "spf2.0" and "v=spf1" obsolete in a
year or two and thus resolve the conflict. And it could be a better
candidate for a "Proposed Standard" RFC than "draft-schlitt-spf-classic"
was due to the conflict with S-ID.
It may be noteworthy, however, that escalating the appeal to the IAB
wouldn't exactly stop us from proceeding with SPFv2.1/v3 now. I think it
would be helpful, though, to have an "Experimental" RFC soon to cleanly
base the new SPF version on.
Now on to more specific comments:
Terry Fielder wrote:
I think we should proceed with an appeal, unless
1) the consensus is that there will be no more FUD to try and kill SPF
(whether or not in the effort to promote some other protocol).
AND
2) the appeal has a reasonable chance for success
AND
3) the delay it entails is not deemed to have likelihood of being
detrimental to SPF
To deal with FUD from MS (mostly), the obvious solution is to do better PR
ourselves. And of course I really don't have the slightest idea how the
IAB people would judge the appeal, just like I didn't with the IESG
people.
Dotzero wrote:
I believe that an appeal should go forward. My reasons are as follows:
[...]
3) SPF has everything to gain and SID has everything to lose by a
continued open and public debate. Conversely, SID has everything to
gain (regardless of the merits of the approach) at this point by
continuing to co-opt spf=v1 records without the SPF folks showing some
backbone. [...] Every additional spf=v1 record published is a draw for
SPF and SID. Every v2 record is a win for SID/MS. That is a recipe for an
SPF loss in the marketplace. [...]
I don't think we should conceive this as a race between SPF and Sender-ID.
Those two are not mutually exclusive, at least not from a wider, more
general POV. I'd even go as far as saying that an SPFv2.1/v3 _should_
support the PRA in an _optional_ manner (that does not require implemen-
tors to acquire an S-ID/PRA license in order to be compliant with the
spec). IOW, embrace and extend reversed.
Frank Ellermann wrote:
Wayne Schlitt wrote:
I don't think we gained much by the appeal, and we have lost a lot of
time.
Strongly disagree. Having them on public record is already a very good
thing. I've often used the URLs of the IESG appeals directory or of my
HTML version of Julian's mail in discussions.
Without that it would be very difficult to fight Doug's verdict "SPF is
defunct because of the PRA re-use" (or similar).
I absolutely agree with Frank's assessment regarding the appeal to the
_IESG_. As for another appeal to the IAB, see above.
Mark Kramer wrote:
When the first appeal occured, I was in favor of it. I think the word
"hindsight" captures exactly my current reservations for going down the
same path again. It was not wrong for us to try. [...] I think that,
without 'material' changes in the field, expecting a different outcome,
just for the sake of it, probably will be a waste of time.
Just for the record, there _would_ be a material change: we would be
appealing to the IAB, not to the IESG. The very fact that the IAB can
undo decisions of the IESG shows that the IAB is not their a puppet.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
iD8DBQFD17IIwL7PKlBZWjsRAmyEAJ0YR1D8sFlV2Ls7rCdf7U/VhT+MkACgjpXi
gfCSI9EcmbGp0MjhCLt6h1A=
=yGAZ
-----END PGP SIGNATURE-----
-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com