-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Lo and behold! Something happened!
See their response in the attached text file.
Julian.
- ---------- Forwarded Message ----------
Subject: Re: Appeal: Publication of draft-lyon-senderid-core-01 in conflict
with referenced draft-schlitt-spf-classic-02
Date: Thursday, 8. December 2005 10:47
From: Brian E Carpenter <brc(_at_)zurich(_dot_)ibm(_dot_)com>
To: Julian Mehnle <julian(_at_)mehnle(_dot_)net>
Julian,
The attached response is on its way through the formal channel.
This ends the IESG appeal process.
Sorry this took so long.
Brian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
iD8DBQFDmBMpwL7PKlBZWjsRArs7AJ92Zi1G+XkyihKG3Gcno6tUq46bCgCfc5yC
YQk7rJKCGsM6VGsfptz17e0=
=m62H
-----END PGP SIGNATURE-----
The IESG has reviewed Julian Mehnle's appeal against the approval of
draft-lyon-senderid-core-01 (see
http://www.ietf.org/IESG/APPEALS/appeal-draft-lyon-senderid-core for the
full text of the appeal).
Firstly we recall that the Sender ID drafts, and the SPF draft,
were approved for publication as Experimental RFCs and not approved
for the Standards track. The bar is lower for Experimental RFCs.
The assertion of the appeal is that the Sender ID experiment will use DNS
records also used by the SPF experiment in a way that overloads their
meaning. Specifically, the appeal asserts that in some circumstances, a
message sent by a participant in the SPF experiment will be labeled as
suspicious by a system participating in the Sender ID experiment, and
therefore may not be delivered to recipients participating in the Sender ID
experiment, or may be delivered but discarded upon receipt. The relief
sought is a change in the text draft-lyon-senderid-core-01 that specifies
this interpretation.
The IESG has reviewed the contents of the appeal and subsequent email
discussions, and while we have found merit in Julian Mehnle's technical
concerns, we will not change our decision to publish the draft as
an Experimental RFC without change to its technical content.
The IESG did consider this conflict in its original discussions, and that is
one of the reasons why we crafted the original IESG note to be included in
these documents, which highlights that there are concerns about using these
mechanisms in tandem. It is quite clear that this conflict would not be
acceptable for a standards track specification. The original IESG note
reads as follows:
"The following documents (draft-schlitt-spf-classic, draft-katz-submitter,
draft-lyon-senderid-core, draft-lyon-senderid-pra) are published
simultaneously as Experimental RFCs, although there is no general technical
consensus and efforts to reconcile the two approaches have failed. As such
these documents have not received full IETF review and are published "AS-IS"
to document the different approaches as they were considered in the MARID
working group.
"The IESG takes no position about which approach is to be preferred and
cautions the reader that there are serious open issues for each approach and
concerns about using them in tandem. The IESG believes that documenting the
different approaches does less harm than not documenting them.
"The community is invited to observe the success or failure of the two
approaches during the two years following publication, in order that a
community consensus can be reached in the future."
The IESG continues to believe that it is important to document these
efforts, as they are being used already, and we note that Julian Mehnle did
not request that we withdraw publication of these documents; instead he
requested that we modify draft-lyon-senderid-core to address the conflict.
However, his proposed modification amounted to a substantive technical
change. The IESG did not consider this an appropriate action to take in
this case. Instead, we have decided to add the following text to
the IESG Note. This note will be added to all four documents listed above:
"Note that the Sender ID experiment may use DNS records which may have been
created for the current SPF experiment or earlier versions in this set of
experiments. Depending on the content of the record, this may mean that
Sender-ID heuristics would be applied incorrectly to a message. Depending on
the actions associated by the recipient with those heuristics, the message
may not be delivered or may be discarded on receipt.
Participants relying on Sender ID experiment DNS records are warned that
they may lose valid messages in this set of circumstances. Participants
publishing SPF experiment DNS records should consider the advice given in
section 3.4 of RFC XXXX (draft-lyon-senderid-core) and may wish to publish
both v=spf1 and v=spf2.0 records to avoid the conflict."
We thank Julian Mehnle for bringing this issue to our attention, and we hope
that this augmented IESG note will address his concerns.