Stephen Farrell wrote:
http://tools.ietf.org/wg/dkim/draft-ietf-dkim-ssp/
-----------------------------------------------------------------
- matches the ABNF for a "tag-list" and includes a valid "dkim" tag.
+ matches the ABNF for a "tag-list" and starts with a "dkim" tag.
-----------------------------------------------------------------
- background in Section 3.1 the checker MUST decide which degree of
+ background in Section 3.1 the checker decides which degree of
Already reported earlier, IIRC.
-----------------------------------------------------------------
- query to fetch the Named ADSP Record. If the result of this query
+ query to fetch the named ADSP Record. If the result of this query
Another occurence later, maybe s/Named/named/g (?)
-----------------------------------------------------------------
- If a query results in a "SERVFAIL" error response, the algorithm
+ Otherwise the agorithm
Already reported earlier: NXDOMAIN at this point is not different
from SERVFAIL. If that's supposed to be a subtle hint at TEMPERROR
processing for SERVFAIL maybe add an "Otherwise" covering NXDOMAIN
after the SERVFAIL blurb.
-----------------------------------------------------------------
- cases, new values are assigned only for values that have been
- documented in a published RFC that has IETF Consensus [RFC5226].
+ cases, new values are assigned only for values after IETF review
+ as specified in [RFC5226].
RFC 5226 intentionally *renamed* IETF consensus to IETF review,
this covers publication as RFC among other things.
-----------------------------------------------------------------
- Domains that intend to make active use of ADSP by publishing a
- practice other than Unknown are advised to avoid the use of
- wildcards elsewhere in their hierarchy.
Strike that, wildcards elsewhere can never overlap, or can they ?
-----------------------------------------------------------------
- Hence a domain MUST NOT publish wildcard ADSP records.
+ Hence a domain SHOULD NOT publish wildcard ADSP records.
The whole point of the "must start with dkim" discussions was to
make wildcards possible for publishers inisting on this "feature".
-----------------------------------------------------------------
All occurences of "discardable" should be replaced by a better
term, e.g., "suspicious" in old drafts was better. "Discard"
could cause losses of legit resent mails. The issue itself -
independent of its name - should be mentioned in the security
considerations.
-----------------------------------------------------------------
The terms SERVFAIL, NXDOMAIN, and NOERROR should be explained
where they are first used, e.g., NXDOMAIN (rcode=3, [RFC1035]).
Please add a normative reference to RFC 1035 for this purpose,
already reported several times.
Frank
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html