Subject: Gen-ART Telechat review of draft-ietf-appsawg-rfc5451bis-09

From: "Peter Yee" <[email-masked]>
Date: Sun, 7 Jul 2013 22:38:53 -0700

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

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 8 Jul 2013 00:13:23 -0700

Hi Peter, thanks for the review.  Comments inline:

> DomainKeys defined" to "pre-standard DomainKeys-defined".

This doesn't seem to work.  The sentence is basically "SPF defined X and
DomainKeys defined Y."  "defined" is a verb, not an adjective, so I don't
think the hyphen is appropriate.

> trustedness, then the MUA shouldn't be checking it anywhere else, right?

At the time the work on RFC5451 was originally done, here were some
implementations of a plugin API that were not able to prepend trace header
fields, and could only append them.  Moreover, an MUA or other agent might
be configured to trust A-R fields added in more than one place (e.g., a
trusted filter), so trusting only the top-most one would limit that
possibility.

> essentially ignore) the header be made by the MUA?

Good point.  I'll add a note about this.

> how about using a new RRType in the DNS?

That's certainly one option to solve that problem. However, I'd prefer not
to suggest new mechanisms that haven't been deployed yet.

I'll post the rest in a -10 revision after the telechat, or if directed to
do so sooner.

Thanks again,
-MSK

---

From: "Peter Yee" <[email-masked]>
Date: Mon, 8 Jul 2013 00:21:42 -0700

Murray,

                Quick response!  My replies are found below.

                Thanks.

                                -Peter

From: Murray S. Kucherawy [mailto:[email-masked]] 
Sent: Monday, July 08, 2013 12:13 AM
To: Peter Yee
Cc: [email-masked]; General Area Review
Team; ietf
Subject: Re: Gen-ART Telechat review of draft-ietf-appsawg-rfc5451bis-09

Hmm.  Yup, I misread that.  Just ignore the hyphen part of the comment.

Fair enough.

Thanks again,

-MSK

---

From: Jari Arkko <[email-masked]>
Date: Wed, 10 Jul 2013 23:24:40 +0300

Peter,

Thank you very much for your detailed review. And Murray, thanks for taking into account the comments. FWIW, I plan to ballot No-Objection for this draft based on the Gen-ART review (and my own far less detailed review).

Jari