On Thursday, March 01, 2012 07:14:20 PM Murray S. Kucherawy wrote:
-----Original Message-----
From: ietf-bounces(_at_)ietf(_dot_)org
[mailto:ietf-bounces(_at_)ietf(_dot_)org] On Behalf Of
SM Sent: Wednesday, February 29, 2012 10:27 PM
To: ietf(_at_)ietf(_dot_)org
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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf