On Thursday, March 01, 2012 07:14:20 PM Murray S. Kucherawy wrote: > > -----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? Replied seprately. I think it should stay as it is. > > "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. Done in my local copy > > 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". Done in my local copy > > "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. Done in my local copy. > 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. Replied separately. I think it should stay the way it is. > 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. I agree I should add the reference to 5321. Is informative sufficient (I don't think any detailed understand of Mail From or EHLO/HELO is necessary to implement this spec). I can see the construction is awkward, but I'm not sure how to make it better. I'd appreciate suggestions. On Thursday, March 01, 2012 04:01:20 PM Barry Leiba wrote: > >> "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? > > I suggest, "The field might still be in use, but its use is discouraged." Done in my local copy. Scott K _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf