On Wednesday, February 29, 2012 10:26:41 PM SM wrote: > At 16:46 29-02-2012, The IESG wrote: > >The IESG has received a request from the Messaging Abuse Reporting Format > >WG (marf) to consider the following document: > >- 'SPF Authentication Failure Reporting using the Abuse Report Format' > > > > <draft-ietf-marf-spf-reporting-08.txt> as a Proposed Standard > > > >The IESG plans to make a decision in the next few weeks, and solicits > >final comments on this action. Please send substantive comments to the > >ietf@xxxxxxxx mailing lists by 2012-03-14. Exceptionally, comments may be > > [snip] > > >Note that this document has a downward normative reference: This > >document makes a normative reference to SPF (RFC4408), which is > >Experimental. > The MARF charter [1] does not contain any mention of "SPF > Authentication Failure Reporting using the Abuse Report Format" as a > deliverable. There is no mention of SPF in the charter. > > According to the Abstract Section of this document: > > "This memo presents extensions to the Abuse Reporting Format (ARF), > and Sender Policy Framework (SPF) specifications to allow for > detailed reporting of message authentication failures in an on-demand > fashion." > > This extends a specification on which there hasn't been any > conclusion yet. I note that there is a downward normative reference > to RFC 4408. During discussions about RFC 4408, on which I don't > have any opinion up to now, there have been comments about: > > (i) The specification not being sufficiently clear. > > (ii) A compelling case that there is, indeed, an error in RFC4408. > > (iii) Interoperability problems in the protocol due to DNS > "incompatibility". > > I suggest that the IETF waits for a migration or co-existence > document which discusses about the non-standards track protocol on > which there is a downward reference. I'll limit my response to these aspects of your comment, since they are the most important to resolve. I'll leave it to the MARF chairs to explain their view of how this is related to the charter. This draft is, however, related to draft-ietf-marf- authfailure-report, which is already through last call and approved by the IESG. It includes SPF specifics (although it doesn't require a normative reference to RFC 4408, so there's no downref issue with it), so I think that in the context of authentication failure reporting this is already established to be in scope. All the current draft does is provide an optional mechanism to make the desire for such reports discoverable. This draft does not depend on any elements of RFC 4408 that are under review in SPFbis (in fact, it's not possible in the current scope of the SPFbis charter to change any of them), so the risk that the ongoing work in SPFbis will affect this body of work is nil. I don't think it's efficient at all to put this draft on hold and revive it later for non-technical reasons. Scott K _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf