OAuth 2.0 Dynamic Client Registration Protocol
draft-ietf-oauth-dyn-reg-30

Section 2:

The software_version "SHOULD change on any update identified with the same software_id" --why not MUST? What happens if this doesn't happen?

"Extensions and profiles MAY expand this list.." -- That seems more like a statement of fact than a normative requirement.

3.2.1:

client_id "SHOULD NOT be currently valid for any other registered client": Why not MUST? What happens if it is valid for another client? 

4.1 and 4.2 allow the designated expert to accept preliminary registrations if they are confident a spec will be published. Shouldn't this follow the normal processes for preliminary registrations? Is there a way to walk back registrations if the spec isn't published after all?

section 5:

4th paragraph after bullet list: "... authorization server needs to take steps to
   mitigate this risk...":  Other statements like this have been normative. Is there a reason this one is not?

2nd paragraph from end: "... treat the new registration as being suspect": ... and do what?

I support Stephen's DISCUSS point #1.

My previous DISCUSS point (1) is below. That has been 
handled via new text in section 5 (on p27). I do wonder
though if you ought also say a bit about, or point at a
reference describing, the possible bad outcomes if 
one of these URLs  goes bad. The new text I think 
assumes that the developer will get how bad that can 
be, but I'm not sure if they would or not. 

(1) General: there are many URIs sent to the AS from the
client here. Nothing prevents the client messing about with
the content served from those later, after registration. What
mechanism holds clients accountable for such misbehaviours?
(Examples, logo_uri, tos_uri, policy_uri, jwks_uri) Section 5
does say that the AS "SHOULD check" but does not say what
"checking" means, nor what to do if the check fails.  I think
a bit more security considerations-like text here, reflecting
what is (or ought;-) actually be done would be good. Do you
agree?


--- OLD COMMENTS, I didn't check if they'd been handled

- s2, software_version: what is the impact if the s/w is
updated twice a day, every day?

- 3.2.1 - why is the response status 201? That may be correct,
but seems to subtle if so to only state in an exmaple.

- s5, last para - "be very particular" is not good spec
language - what do you actually mean that can be implemented?

- thanks for section 6 - it's great to see thought being
devoted to these issues.

- Did the secdir review [1] get a response? And I think I
quite agree with Charlie's point#2 about versions.

   [1] https://www.ietf.org/mail-archive/web/secdir/current/msg05519.html