Gen-ART LC review of draft-ietf-oauth-dyn-reg-management-09

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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”.









[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]