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