Subject: [ietf-dkim] ADSP WGLC

From: Stephen Farrell <[email-masked]>
Date: Wed, 06 Aug 2008 13:01:19 +0100

This note is to start WGLC for the ADSP document. [1]

Given its vacation time, WGLC will run for 4 weeks from
now, ending on September 3rd.

Thanks,
Stephen.

[1] http://tools.ietf.org/wg/dkim/draft-ietf-dkim-ssp/

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Frank Ellermann" <[email-masked]>
Date: Wed, 6 Aug 2008 16:02:52 +0200

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