![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
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 Ietf at ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.