I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>
Please resolve these comments along with any other Last Call comments you
may receive.
Document: draft-ietf-appsawg-rfc5451bis-09
Reviewer: Peter Yee
Review Date: July-01-2013
IETF LC End Date: June-27-2013
IESG Telechat date: July-11-2013
Summary: This draft is basically ready for publication as a Standards Track
RFC, but has nits that should be fixed before publication. [Ready with nits]
This draft defines a message header for conveying message authentication
outcomes from various, existing email authentication standards. The draft
is well-written with numerous worked out examples.
Major issues:
Minor issues:
Nits:
Page 4, Introduction, 5th paragraph: append a comma after "published".
Page 5, 2nd paragraph after bullet item, 1st sentence: change "pre-standards
DomainKeys defined" to "pre-standard DomainKeys-defined".
Page 6, 2nd paragraph, last sentence: change "their data center" to "its
data center".
Page 6, section 1.3, 2nd sentence: change "encapsualted" to "encapsulated".
Page 7, section 1.5.2, 1st paragraph after bullet points, 2nd sentence: add
commas after "agents" and "authorization)". Also change "ensures" to
"ensure".
Page 14, section 2.5, 4th sentence: insert ", but" between "document" and
"intended".
Page 17, Section 2.5.5: amend "Authorhized" to "Authorized".
Page 19, 2nd full paragraph, 2nd sentence: "finite" is probably not the best
word to use here. Perhaps "not unduly taxing to the DNS infrastructure"
would work better?
Page 19, section 4, title: change "A" to "a".
Page 19, section 4, 1st paragraph, second sentence: change "THe" to "The".
Page 20, 2nd full paragraph, 1st sentence: append a comma after "applied".
Page 20, 5th full paragraph, 3rd sentence: insert "placement" between "This"
and "allows".
Page 20, 5th full paragraph, 3rd sentence: regarding whether the field can
be "trusted": why would the MUA check the field in any other location than
prior to the top-most trace field? If the location is the source of
trustedness, then the MUA shouldn't be checking it anywhere else, right?
Page 22, first full paragraph, 1st sentence: replace "which" with "that".
Page 22, 3rd full paragraph: "this" is an ambiguous reference. Maybe use
"these topics" or "these issues" if you mean everything in the section?
Page 23, 1st paragraph, last sentence: for clarity, consider inserting "the
header field originating from" between "removing" and "all".
Page 23, 4th paragraph: as the MTA (implied to be an MTA within the ADMD)
is not the end consumer of the information and the MUA might understand a
later version of the header, shouldn't the decision to remove (or
essentially ignore) the header be made by the MUA?
Page 31, section 8.4, 2nd sentence: change "need" to "needs".
Page 32, section 8.6, 3rd sentence: regarding keeping the list "current",
how about using a new RRType in the DNS?
Page 39, section C.4: the "Received" header would make it look like the
message is going from example.net to example.com, but the "To" and "From"
headers show the opposite to be the case.
Page 39, section C.4: the same issue strikes the paragraph immediately
following Example 4. The "sending DNS" name is what appears for the
authserv-id, not the "receiving DNS" name. A simple swap of the "To" and
"From" header values would rectify the situation.
Page 43, 2nd paragraph, 2nd sentence: change "that" to "whom".
Page 44, item 1, 2nd sentence: delete the "s" in "rejections".
Page 44, item 3, 1st sentence: append a comma after "header".
Page 45, item 5, 3rd sentence: change "vs" to "vs." and append a comma
after "intertia".
-Peter Yee