Subject: IAB Response to the Appeal from Julian Mehnle

From: Leslie Daigle <[email-masked]>
Date: Thu, 02 Mar 2006 05:44:01 -0500

On February 8, 2006, The IAB received an appeal from Julian Mehnle
appealing the IESG decision to publish draft-lyon-senderid-core as an
Experimental RFC. According to the procedures in Section 6.5.2 of RFC
2026, the IAB has reviewed the situation and issues the following
response.

1. Summary of IAB Response

The appeal is denied and the IESG's decision is upheld.

2. Background

After the termination of the MARID WG, the IESG approved both
draft-schlitt-spf-classic-02 and draft-lyon-senderid-core as
Experimental RFCs. Both RFCs were to bear the following note:

      "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."

Mr. Mehnle appealed the approval of draft-lyon-senderid-core on the
grounds that the proposed protocols were incompatible and that the IESG
should rewrite draft-lyon-senderid-core to assume the SPF classic
interpretation unless a new-style record was present. The IESG rejected
his appeal on the grounds that it involved a technical change to the
document but added the following strengthened note:

     "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
     spf2.0 records to avoid the conflict."

Mr. Mehnle appealed to the IAB, reiterating his original issue and raising
the following process issue:

     Finally, the IESG's approval of conflicting experiments could be seen
     as a failure in following the standards process[9], which in section
     4.2.1, "Experimental", requires "verification that there has been
     adequate coordination with the standards process", which would by
     analogy not only mean coordination with standards track RFCs but also
     with other experimental RFCs.

3. Discussion

The process issue that Mr. Mehnle raises is rooted in RFC 2026,
Section 4.2.1:

    The "Experimental" designation typically denotes a specification that
    is part of some research or development effort.  Such a specification
    is published for the general information of the Internet technical
    community and as an archival record of the work, subject only to
    editorial considerations and to verification that there has been
    adequate coordination with the standards process (see below).  An
    Experimental specification may be the output of an organized Internet
    research effort (e.g., a Research Group of the IRTF), an IETF Working
    Group, or it may be an individual contribution.

On the basis of this text, the IAB concludes that the IESG's approval of
draft-lyon-senderid-core does not constitute an endorsement of this
technology but simply a publication for the "general information of
the Internet technical community". With respect to the issue of
adequate coordination, Section 4.2.3 reads (in part):

    If (a) the IESG recommends that the document be brought within the
    IETF and progressed within the IETF context, but the author declines
    to do so, or (b) the IESG considers that the document proposes
    something that conflicts with, or is actually inimical to, an
    established IETF effort, the document may still be published as an
    Experimental or Informational RFC.  In these cases, however, the IESG
    may insert appropriate "disclaimer" text into the RFC either in or
    immediately following the "Status of this Memo" section in order to
    make the circumstances of its publication clear to readers.

The IAB concludes that this paragraph explicitly permits the
publication of work that conflicts with existing IETF standards work,
provided that it bears an appropriate disclaimer. In this case, the
IESG provided a substantial disclaimer. Without determining whether or
not this experimental document actually conflicts, we conclude that
the disclaimer added by the IESG would in any event be sufficient to
allow the publication of this document as Experimental.

4. IAB Conclusion

On the basis of the available record and the IESG's response, the
IAB concludes that the IESG gave due consideration to the technical
issues raised by Mr. Mehnle and reached a decision according to
the process specified by RFC 2026. We therefore conclude that
the appeal should be denied and the original IESG decision upheld.

Note: IAB voting member Bernard Aboba recused himself from the
discussion and decision of this appeal.

Leslie Daigle,
for the IAB.

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

---

From: Leslie Daigle <[email-masked]>
Date: Thu, 02 Mar 2006 05:44:01 -0500

2. Background

3. Discussion

4. IAB Conclusion

Leslie Daigle,
for the IAB.

---

From: "Constantine A. Murenin" <[email-masked]>
Date: Thu, 2 Mar 2006 12:44:59 +0000

>       considered in the MARID working group.

The problem is that they ARE NOT published AS-IS to document the
different approaches as they were considered (and _documented_) in the
MARID working group. This IESG statement clearly violates the reality,
just look at what was presented in the appeal:

<<The conflict arose only after the IESG asked for individual draft
submissions from the SPF and Sender ID authors and
draft-lyon-senderid-core-00 was submitted (which for the first time
included the re-interpretation of "v=spf1" records for the PRA
identity). Accepting such a submission despite the prior consensus of
the MARID WG[5] (which was closed afterwards) that "v=spf1" should not
be used for checking of PRA clearly violates the ultimate goal of
producing reliable standards.>>

<<It is also worth noting that at the time the MARID WG was closed,
the then-current Sender ID specification
draft-ietf-marid-protocol-03[18] did not include the re-use of
"v=spf1" records for PRA checking. This was only introduced in the
individual submission draft-lyon-senderid-core-00 [19] in October
2004. Also did Microsoft's record generation wizards generate only
"v=spf2.0/pra" records until the end of October[20,21], when they
began generating only "v=spf1" records.>>

I have not heard anyone question this issue with Sender ID that was
once again raised in the IAB appeal. Do you thus find it ethical and
professional to publish these RFCs with the note that does not reflect
the documented reality of the MARID WG?

If any note is to be included in the RFCs, it should be the one from
the appeal.

Cheers,
Constantine.

---

From: Keith Moore <[email-masked]>
Date: Thu, 2 Mar 2006 12:29:02 -0500

when editing documents that purport to describe existing practices and
protocols, there is often a conflict between documenting existing
practice and describing desirable practice (or undesirable practice).
this conflict results in confusion of goals, and one possible result is
that the document describes neither existing practice nor desirable
practice.

in resolving the conflict it is sometimes useful to separate the two
efforts:

- describe existing practice, warts and all
- describe what is believed to be good or bad about the existing
practice

this doesn't have to be done in separate documents but the efforts
should be separate so that each effort can have a clear focus.  once 
there is an understanding about what is good and/or bad about existing
practice, notes or footnotes can be added to the description of
existing practice to inform the reader of these annotations.  

if there's not consensus about what is good or bad about existing
practice, it may be useful to document the lack of consensus.

Keith

p.s. I am personally of the opinion that SPF in all but a few corner
cases is harmful to the interoperability of Internet mail, so I'm very
keen to have those limitations documented.

---

From: Julian Mehnle <[email-masked]>
Date: Thu, 2 Mar 2006 18:21:31 +0000

To any who reply to this thread: please, please trim the list of recipients 
to remove any of the following addresses, unless you explicitly want to 
address them:
  * [email-masked]
  * [email-masked]
  * [email-masked]

> - describe what is believed to be good or bad about the existing

I agree.  But please note that there was no "existing practice" of re-using 
"v=spf1" records for the checking of the PRA identity or any other non- 
envelope identities when Microsoft first submitted the Sender ID drafts to 
the IESG after the demise of the MARID WG.  See my IESG appeal (included 
in the IAB appeal[1]) for details on the history of Sender ID's re-use of 
"v=spf1".

Please do not spread urban legends.

Julian.

References:
 1. http://www.iab.org/appeals/2006-02-08-mehnle-appeal.html