ietf
[Top] [All Lists]

RE: Last Call: <draft-ietf-marf-spf-reporting-08.txt> (SPF Authentication Failure Reporting using the Abuse Report Format) to Proposed Standard

2012-03-01 13:15:04
-----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?

   "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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>