> -----Original Message----- > From: ietf-bounces@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] On Behalf Of SM > Sent: Wednesday, February 29, 2012 10:27 PM > To: ietf@xxxxxxxx > Subject: Re: Last Call: <draft-ietf-marf-spf-reporting-08.txt> (SPF > Authentication Failure Reporting using the Abuse Report Format) to > Proposed Standard As for your non-procedural concerns: > I'll avoid commenting on the technical angle. Here are some editorial > comments: > > In Section 3: > > "There exist cases in which a domain name owner employing [SPF] for > announcing sending practices may want to know when messages are > received via unauthorized routing." > > I suggest not using the term "domain name owner" to side-step the > question of domain "ownership". Would "ADMD" and an informative reference to RFC5598 be more appropriate? > "particular because a message arrived via an unauthorized route. > To generate a complete address to which the report is sent, the > verifier simply appends to this value an "@" followed by the > SPF domain per paragraph 4.1 of [SPF]." > > RFC 4408 uses the term "SPF-compliant domain". That's fine with us. > In Section 5.1: > > "New registrations or updates MUST be published in accordance with the > "Specification Required" guidelines as described in > [IANA-CONSIDERATIONS]. New registrations and updates MUST contain > the following information:" > > I suggest not using RFC 2119 key words in the IANA Considerations > section unless there are interoperability issues with IANA. We'll change "MUST" to "are to be". > "current: The field is in current use > > deprecated: The field is in current use but its use is > discouraged" > > The difference in "current use" can end up being problematic for the > designated expert. A number of registries are using this wording already and there's been no objection to date. Do you have a better suggestion? > In Section 6: > > "Security issues with respect to these reports are similar to those > found in [DSN]." > > The reference to DSN could be normative. Security Considerations are never normative, so I'm not sure I agree that this should be. > "The HELO/EHLO command SHOULD also be selected so that it > will pass [SPF] HELO checks." > > I could not understand what to do about the above recommendation. > FWIW, the command is specified in RFC 5321. That specification is not > referenced by this draft. Yes, that needs to be clarified, the reference added, and the typo in the section title needs correction. Thanks, -MSK _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf