Re: Trouble with Sender Authentication

--nextPart1586324.igG0JjTTqU
Content-Type: text/plain;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Douglas Otis wrote:
> In Dusseldorf, Julian and Ming received *constructive* recommendations to
> allow record scoping, but this was ignored and became the basis for
> Julian's ignored complaint made to the IESG.

Sorry to barge in on this particular topic (which is mostly unrelated to=20
the issues raised by K.J. Petrie or the alleged DoS issue), but this ain't=
=20
correct.  The v=3Dspf1/pra re-use issue was indeed discussed at the MAAWG=20
meeting in D=C3=BCsseldorf.  I'm not sure what you mean when you say that
"allowing record scoping" was proposed, but what was actually proposed were=
=20
two different things (depending on whom I talked to):

 A. Accept the v=3Dspf1/pra re-use and start promoting v=3Dspf1 as having a
    different meaning than what had been defined back in 2003.

 B. Abandon v=3Dspf1 entirely in favor of spf2.0 (or some completely
    different) scheme in order to avoid the misinterpretation of v=3Dspf1
    records for PRA purposes.

At that point (2005-06), materially changing the definition of v=3Dspf1 was=
=20
out of the question as SPFv1 (and many, many records) had existed=20
essentially unchanged since at least early 2004.  And agreeing to jump=20
ship towards spf2.0 (Microsoft's Sender ID) was out of the question, too,=20
due to the idiotic patent issue which many just could not simply ignore.

(Now Microsoft seems to have seen the light after all and has subjected=20
their patent to their Open Specification Promise, which might make the=20
issue go away.  I'll leave it up to Debian, the ASF, or others to decide=20
whether spf2.0 AKA Sender ID is now free-software compatible.)

And finally, the appeal to the IESG was not "ignored".  It was rejected. =20
The reason being that the IESG did not want to take sides in the conflict=20
and change the Sender ID I-D or even bar it from publication as an RFC.
On a technical level, the IESG even confirmed in their response[1] to the=20
appeal that they "have found merit in [the] technical concerns".

When people discuss past matters as delicate as those above, I do expect=20
some accuracy.  Otherwise the truth will fall through the cracks and=20
disappear all too easily.=20

References:
 1. http://www.ietf.org/IESG/APPEALS/appeal-response-julian-mehnle.txt


--nextPart1586324.igG0JjTTqU
Content-Type: application/pgp-signature

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

iD8DBQBFT8FywL7PKlBZWjsRAuJCAKCqXXfZSnHx5if/B0qR2Y3+F52UOgCgn+1J
nuowrA4kKgqeczLPjlMckU0=
=DkNm
-----END PGP SIGNATURE-----

--nextPart1586324.igG0JjTTqU--