Re: [Gen-art] Gen-ART LC review of draft-ietf-oauth-dyn-reg-management-09

[Justin Richer <[e-mail]>]

Peter, thanks for the review. These are all good suggestions and simple to implement. I’ve incorporated the proposed wording changes into the working copy of the document and they’ll be pushed into the next revision of the document.

Thank you,
 — Justin

> On Mar 23, 2015, at 9:02 AM, Peter Yee <[e-mail]> wrote:
> 
> 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-oauth-dyn-reg-management-09
> Reviewer: Peter Yee
> Review Date: Mar-22-2015
> IETF LC End Date: Mar-23-2015
> IESG Telechat date: TBD
> 
> Summary: This draft is ready for publication as an Experimental RFC, but
> has nits that
> should be fixed before publication. [Ready with nits]
> 
> This specification defines an OAuth client configuration endpoint that be
> can be used to manage dynamic client registration updates and the protocol
> used to interact with it.
> 
> Major issues: None
> 
> Minor issues: None
> 
> Nits: None
> 
> 
> Page 2, section 1, 1st paragraph, 1st sentence: change “at” to “with”.
> “At” makes it sound like the client identifier is a server-only object.
> 
> Page 5, step (D), change “at” to “to”.
> 
> Page 5, step (G), append “or (F)” to the sentence.
> 
> Page 5, section 2, 2nd paragraph: this paragraph is wholly subsumed by the
> Security Considerations.  Why not just put a pointer to there rather than
> duplicate the text?
> 
> Page 6, section 2.2: while not technically incorrect, I would argue that
> the update is being made to the server by the client, albeit with the
> server’s permission.  Thus I find the wording of this first sentence
> somewhat misleading.  Perhaps a rewrite would help?  I find the use of “at
> the server” in the document allows a lot of looseness that encourages
> varying interpretations of what is meant.
> 
> Page 7, 1st paragraph: remove the space in “top- level”.
> 
> Page 7, 2nd paragraph, 2nd sentence: change “client” to “updated client
> metadata fields”.  This is to make it clear the client must not include
> the forbidden fields in the updated fields it presents, but that most
> certainly items like the registration access token will be part of the
> request.
> 
> Page 12, last paragraph, last sentence: clarify disclosure of what?
> Wasn't the deprovisioning process supposed to delete or make unavailable
> the metadata?  So other than not having canceled the registration access
> token, what's to be disclosed?
> 
> Page 15, section B.1, 1st sentence: change “token” to “tokens”.
> 
> Page 15, section B.1, 2nd sentence: change “map” to “may”.
> 
> 
> 
>