Folks,The IESG has reviewed the draft prior to publication and come back with several requested edits, a few of which were considered as blockers. Only one of the issues was actually technical; the rest were just language and reference adjustments.
Attached is the proposed version 19 of the draft which addresses these concerns and should in theory be the one that gets published (subject to the RFC Editor's office making last-minute adjustments). Please have a look at it before I send it off.
If you want to see side-by-side differences instead of the entire thing, have a look at:
http://www.blackops.org/~msk/a-r/draft-kucherawy-sender-auth-header-19-from-18.diff.htmlAssuming no giant problems are raised after these edits, I'll send it off to the IESG in a week or so. Please review them when you get a moment and reply to the list with any comments you may have about these edits or any new issues that have arisen.
In summary, here's what changed:o One of the blocking complaints was what appeared to be a normative down-reference to SPF. Normative down-references to experimental RFCs (RFC4408, SPF, is experimental) in standards-track documents are not permitted. Initially I argued that the SPF reference in question (in Section 3 of this draft) was informative only, but I see the point of the complaint: this draft failed to specify the limit on the number of queries while RFC4408 did. This revision brings the restriction into the normative language it offers and references SPF as an example implementation. Also on the topic of reverse DNS issues, the prior work of the DNSOP working group in this area has now been taken into account, including the addition of a small subsection to "Security Considerations". The specific DNS reply codes are also included in the "iprev" result descriptions. Finally, the "softfail" case for "iprev" was removed as it was not substantively different from the other cases.
o The other blocking complaint was the ambiguous use of the word "domain", sometimes to refer to a DNS domain name and sometimes to refer to the more abstract idea of an administrative management domain. Being explicit about each such reference in the revised text appears to have resolved this issue.
o An appendix was added which provides some discussion about the scope and models which this work presumes (i.e. what's generally implemented).
o A number of minor rewording issues were addressed. o Some references to other RFCs (i.e. section numbers) were corrected.o A tweak to the ABNF was done to enable references to this work by future documents to be less ambiguous (i.e. "header" becomes "authres-header").
o The result table is more explicit about omitting those parts of the "ptype.propspec=value" construction which were not actually authenticated.
Happy holidays! -MSK
draft-kucherawy-sender-auth-header-19.txt
Description: Text document
_______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html