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

[Julian Mehnle <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Douglas Otis wrote:
> As with any conflict, there are two parties involved.  In this case,
> the SPF group has essentially ignored potential conflicts by
> neglecting to include support for a subsequent version of the DNS
> record.  This newer record explicitly expresses the intended scope.
> At the MAAWG meeting in Dusseldorf, Julian suggested SPF developers
> would only consider use of the newer DNS record version provided
> Sender-ID abdicated use of the initial version of the record.  Sender-
> ID supports both versions.  An appeal was made for the SPF group to
> consider supporting the newer version of the record as a solution for
> avoiding this conflict.  This suggested use of the record is part of
> interim advice on the MAAWG website.  It would appear this appeal
> reflects a decisions to remain intransigent.

You are misrepresenting the SPF project's intentions.

We are still open to support "spf2.0" or even an "spf2.1" (with some of 
2.0's other issues resolved).  "Support", however, does _not_ mean to 
s/v=spf1/spf2.0/ (sort of) in draft-schlitt-spf-classic, which as the 
name implies is supposed to document the classic version of SPF.

The reason we have decided to file this appeal is to protect existing 
(legacy, if you will) "v=spf1" records from any misinterpretation sanc- 
tioned by the IETF.  Beyond that, almost everything is negotiable.

> While this conflict should be resolved, without evidence that Sender-
> ID has fallen out of favor, which the stance by the SPF group
> prohibits, the obvious solution would likely be for the SPF group to
> finally adopt the newer record version.

The declared policy of the SPF council, the project's elected leading 
group, is _not_ to bring down Sender ID (although it is probably true 
that many would like to see that happen, me not included), but to promote 
SPF and to ensure that its reputation doesn't get tarnished by the 
unnecessary misinterpretation of v1 policies by Sender ID.

The SPF council can very well see promoting a polished "spf2.0", as long 
as "v=spf1" is left alone.  It would probably not even be a point of 
contention if PRA was an _optional_ part of that specification (as it is 
now with "spf2.0", as opposed to "v=spf1", thanks to draft-lyon-senderid- 
core-01).

Julian.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDDlqJwL7PKlBZWjsRAkv9AJ9u9rE2bwGlmNZSmebNNFke80Fx+QCeMmIY
ZfO7UzZus5h0ZGYN1B9YUbc=
=e5dm
-----END PGP SIGNATURE-----

_______________________________________________
Ietf mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ietf