Last Call Review of draft-ietf-oauth-revocation-07
review-ietf-oauth-revocation-07-genart-lc-romascanu-2013-04-30-00

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-revocation-07
Reviewer: Dan Romascanu
Review Date: 4/29/13
IETF LC End Date: 4/30/13
IESG Telechat date: (if known)

Summary: Almost Ready - it's a relatively simple, clear and well written
document. However there is one issue related to the IANA policy for the new
registry defined by this document which must be clarified before the document
is approved. A couple of minor issues also need clarification and fixing.

Major issues:

I have found one major issue related to the Type Hint Registry policy described
in Section 5.1.2.

> This specification establishes the OAuth Token Type Hint registry.
   Possible values of the parameter "token_type_hint" (see Section 2.1)
   are registered with a Specification Required ([RFC5226]) after a two-
   week review period on the TBD at ietf.org mailing list, on the advice of
   one or more Designated Experts.  However, to allow for the allocation
   of values prior to publication, the Designated Expert(s) may approve
   registration once they are satisfied that such a specification will
   be published.  Registration requests must be sent to the TBD at ietf.org
   mailing list for review and comment, with an appropriate subject
   (e.g., "Request for parameter: example").  Within the review period,
   the Designated Expert(s) will either approve or deny the registration
   request, communicating this decision to the review list and IANA.
   Denials should include an explanation and, if applicable, suggestions
   as to how to make the request successful.  IANA must only accept
   registry updates from the Designated Expert(s) and should direct all
   requests for registration to the review mailing list.

I find this way of applying the Specification Required policy problematic.
According to RFC 5226 '... Values and their meanings must be documented in a
permanent and readily available public specification ...'. Allowing for an
approval by the Designated Expert in the absence of a readily available public
specification based on the promise that 'such a specification will be
published' seems to be contradictory to the definition of the policy. Why not
just Expert Review?

Conditioning Specification Required policies on 'a two-week reviews period on
the TBD at ietf.org mailing list also seems contrary the spirit of RFC 5226. A
specification is a specification, it's the role of the Designated Expert to
validate for IANA the specification, he may use a mail list, expert team, or
just his own expertise, but this needs not be defined here. Mail lists are
ephemeral entities relative to the stability implied by the Specification
required policy, and of course, TBD at ietf.org is hardly acceptable at this
phase of approval.

Minor issues:

1. [RFC5226] mentioned in Section 5.1.2 is not included in the list of
references.

2. There is no indication what does the server in the case when an erroneous
token_type_hint parameter is passed. Error Response is defined in 2.1.1 for
unsupported_token_type but not for the case when for example a client sends a
hint that indicates an access_token with a revocation request for a refresh
token? Can this optional information supposed to help for quicker look-up of
the tokens by the server be used for a DoS attack by a malicious client?

Nits/editorial comments: