Matt Thanks for the great review. As Kathleen mentioned, there are some other changes we have to make that will push the draft back. Never-the-less I will take into account all the reviewer comments in the next draft.
All your comments seem very reasonable to me. Thanks, Phil > On Dec 17, 2015, at 04:02, Kathleen Moriarty > <[email protected]> wrote: > > Hi Matt, > > Thank you for your review! The editors will take these comments into > consideration and discuss any updates. I'll note that the draft was > pulled from the telechat and will likely not go through last call > again until sometime around Buenos Aires due to some other changes > that came up. You may see this one again. > > Thanks, > Kathleen > > On Wed, Dec 16, 2015 at 9:28 PM, Matt Miller (mamille2) > <[email protected]> wrote: >> I am the assigned Gen-ART reviewer for this draft. The General Area >> Review Team (Gen-ART) reviews all IETF documents being processed >> by the IESG for the IETF Chair. Please treat these comments just >> like any other last call comments. >> >> For more information, please see the FAQ at >> >> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. >> >> Document: draft-ietf-oauth-pop-architecture-07 >> Reviewer: Matthew A. Miller >> Review Date: 2015-12-16 >> IETF LC End Date: 2015-12-15 >> IESG Telechat date: 2015-12-17 >> >> Summary: Almost ready. >> >> I have several editorial nits, but also a couple of minor concerns that >> I think would improve this document's readability. >> >> I note that idnits complained about the lack of RFC 2119 boilerplate; >> however, I think the text actually used in this document is most >> appropriate and still conveys the intent. The idnits also complained >> about a reference to an obsolete RFC 5849; however, this reference >> appears to be intentional and necessary. >> >> ----- >> >> Major issues: >> >> Nnne. >> >> Minor issues: >> >> 1. In Section 1. Introduction, the last paragraph makes it seem the >> document isn't organized properly. It implies an order to read the >> document that is not reflected in the outline: >> >> * Section 1 >> * Section 2 >> * Section 3 >> * Section 4 >> * Section 6 >> * Section 7 >> * Section 5 >> >> Simply re-ording the document I think causes bigger problems. While >> the intro hints at the order to read, it makes more sense to me in >> the order it actually is. Ultimately, for me the problem arises with >> the word "concludes". It might simply be enough to change the last >> participle from ", and concludes with a requirements list in Section 5." >> to ", and lists requirements in Section 5." >> >> 2. In several places, terms of art are used that have not been defined >> in this document: "resource server", "protected resource", etc. I >> think it would help if Section 2. indicated where these terms are >> defined or discussed, which is RFC 6749. >> >> >> Nits/editorial comments: >> >> * The reference to draft-ietf-oauth-proof-of-possession-08 should be >> updated to its latest version, although I expect RFC Editor will >> resolve this before publication. >> >> * The reference to RFC 4347 should be updated to 6347; there's no clear >> requirement for the older document. >> >> * In Section 3.1 Preventing Access Token Re-Use by the Resource Server, >> "with other resource server" should be either "with another resource >> server" or "with other resource servers". >> >> * In Section 3.2 TLS and DTLS Channel Binding Support, "entity entity" >> should be "entity". >> >> * In section 3.4 Offering Application Layer End-to-End Security, The >> last sentence of the last paragraph seems out of place. It seems it >> would be better as the penultimate sentence of the previous paragraph. >> >> * In section 4. Security and Privacy Threats under "Token >> manufacture/modification", "causing resource server" should be "causing >> the resource server". >> >> * Also in Section 4. Security and Privacy Threats under "Token >> manufacture/modification", the normative language here seems out of >> place. It seems to me that 'may' conveys just as much as 'MAY' for >> how it is used here. >> >> * In Section 5. Requirements under "Prevent the Domino Effect", >> "Resource Server" is capitalized differently than all previous uses, >> but it doesn't seem to be a different use. I suggest changing it to >> "resource server". >> >> * In Section 6.3. Key Confirmation, uses the term "privacy key" where >> I believe the common nomenclature is "private key". >> >> * In Section 7. Client and Authorization Server Interaction, I find >> most of the figures a little hard to follow. While I appreciate the >> attempt to go beyond strict perpendicularity, I find it distracting >> from the information it is trying to convey. >> >> * In Section 7.1 Symmetric Keys, I think the "three ways for >> communicating this session key" would benefit having bullets or >> outline numbers. >> >> * In Section 10. Acknowledgements, the second paragraph discusses an >> appendix that borrows content from another document, but there is no >> appendix in this draft. Is this text still relevant? >> >> >> -- >> - m&m >> >> Matt Miller >> Cisco Systems, Inc. > > > > -- > > Best regards, > Kathleen _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
