I've noticed that you've posted draft-ietf-dmarc-arc-protocol-08, so
some of the issues identified below might no longer be relevant:
1) The new abstract doesn't even use the word "email". This needs to be
fixed, because otherwise it is not possible to determine that this is
related to email or DKIM from reading the abstract.
The current abstract:
The Authenticated Received Chain (ARC) protocol creates a mechanism
whereby a series of handlers of a message can conduct authentication
suggestion to insert "email" before "message" above.
of a message as it passes among them on the way to its destination,
and record the status of that authentication at each step along the
handling path, for use by the final recipient in making choices about
the disposition of the message.
It might also make sense to mention DKIM and DMARC (a la original text).
So I suggest to add back the following sentence from -06:
Changes in the message that might break DKIM can be
identified through the ARC set of header fields.
But otherwise the new Abstract text is an improvement as far as people
not familiar with ARC are concerned.
2) I liked "Primary Design Criteria" (section 2.1) from -06. Maybe add
it back as an Appendix? It is not important for new readers, but might
be of interest to more advanced readers.
3) In 5.1, first para now reads:
The ARC-Authentication-Results header field is defined. It is
syntactically and semantically identical to an Authentication-Results
header field [RFC7601] (A-R), as is the mechanism by which it is
constructed, with the following exception:
I think the statement "syntactically and semantically identical" is
incorrect, because the value is prefixed with "i=<N>". I think this
needs to be reworded. And adding ABNF here would resolve any remaining
confusion.
The instance identifier MUST be separated from the rest of the
Authentication-Results value contents with a semi-colon (';', 0x3b).
"Instance" is separated by ";", but its syntax in section 4 already
includes terminating ";". I think you need to clarify that only one ";"
is separating instance from the rest. Or alternatively just remove this
sentence.
4) In 5.3.2, first paragraph: I don't think saying that ARC-Seal is
"encryption" is correct, I think you should use the word "signature"
here.
5). In 6, step 4.7 (I think it is 4.6 in -08): mentioning here what
happens on failure to retrieve data from DNS would be good. A forward
reference to Section 9.3 is probably sufficient here.
6). In 9.5 (I think it is 9.6 in -08): should the document formally
register the "arc" Authentication-Results method in the IANA
Considerations?
7) I am being very confused by whether subsections of 9.5 (9.6) talk
about XML reporting or Authentication-Results header field. Section 9.5
seems to be very clear that you are talking about
Authentication-Results, but subsections seem to talk about XML reporting
format.
I couldn't understand 9.5.1 without reading 9.5.2. I think you should
add tag names (e.g. "ams") somewhere in 9.5.1.
Best Regards,
Alexey
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
