On 5/3/2014 4:35 PM, Jim Fenton wrote: > On 05/01/2014 11:43 AM, Dave Crocker wrote: >> On 5/1/2014 1:36 PM, Jim Fenton wrote: >>> I'd like to understand the relationship of RFC 4846, which is >>> Informational, with RFC 5792/BCP 92 here. The latter gives IESG 5 >>> options for review of independent submissions for conflicts with the >>> IETF standards process, such as: >>> >>> 5. The IESG has concluded that this document extends an IETF protocol >>> in a way that requires IETF review and should therefore not be >>> published without IETF review and IESG approval. >> Since DMARC does not extend any existing IETF protocol, how is that >> reference useful here? > > I was citing one of the five options IESG has. For brevity I chose not > to cite all five (everyone can find them in RFC 5742, not 5792 which was > a typo). > > But since you bring it up, DMARC does alter (extend) SMTP, for example > by its recommendation in Section 10.1 that messages containing a single > RFC5322.From with multiple entities be rejected. It might be argued > that's not a significant limitation, but that's what the IETF review is > all about. This confuses advice about policies for /use/ of a protocol, versus /specification/ of the protocol itself. "Extending" means modifying the protocol. Changing the bits over the wire; changing semantics of the bits. Bits over the wire is the usual IETF definition of 'protocol'. The SMTP specification makes no attempt to give comprehensive guidance about receiver policies for rejecting or accepting mail. Nor should it. The DMARC draft does not alter the bits over the wire. John Levine's example of DMARC defining additional response codes is somewhat more interesting, though I'd still class it as pretty minor, since its not changing any major reply values. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net