Re: [OAUTH-WG] AD review of draft-ietf-oauth-urn-sub-ns-02

[Hannes Tschofenig <[e-mail]>]

Hi Stephen, 

thanks for the review comments. ;

On Jun 20, 2012, at 3:26 PM, Stephen Farrell wrote:

> 
> Hi,
> 
> Many thanks for a nice short document!
> 
> I've a few questions though and suspect that a quick re-spin
> might be needed, but let's see what the wg think about 'em
> first.
> 
> (1) Why Informational? Everything else at that level seems to
> be specified in a standards track or BCP level RFC, and IETF
> Consensus is required. [1] I think you have to do this as
> standards track. Did I miss something?
> 
Standards Track is OK. 

>   [1] http://www.iana.org/assignments/params/params.xml
> 
> (2) Do you *really* want RFC or specification required for all
> registrations?  I don't care, but there is a trend away from
> that at the moment since its been found to discourage
> registrations in a lot of cases. Perhaps expert review would
> be ok?  No trying to push you one way or the other, I just
> wanted to check.

That's a good question. 

There are a few documents in the OAuth WG that define new sub-namespaces under urn:ietf:params:oauth. 

It would be good to get the policy for creating new extensions inline with what the registry demands. 

So, for example if I look at the extension policy for 'grant-types' of http://datatracker.ietf.org/doc/draft-ietf-oauth-v2/ says 'Specification Required'. 

On the other hand OAuth core has an interesting policy here since specification required is not enough but it has to be followed by a call for review on some IETF mailing list. 

If the goal is to get this document inline with what our existing documents say then 'Specification Required' would be the right policy here as well.

> 
> (3) If answer to (2) is yes: Section 5.1 says "Specification
> Required" but section 3 said "RFC Required" and those differ.
> For example, an OASIS spec would not be ok if you say RFC
> required. I don't know if you care, but you need to be
> consistent. (Or else I've misread something;-)

Of course it is nice to keep the overhead low to define new extensions but the consequence then is that some of these extensions will have very dubious quality.  As an example of this have a look at the EAP methods. 

So, I am curious where to hit the right level of process here to find the sweetspot between low overhead and high quality specifications. 


> 
> (4) Isn't the template missing the reference to the RFC or
> other specification that defines the URN?

Not sure what you mean. 

> 
> (5) I don't get section 3, sorry;-) Can you give an example of
> a class:id pair that'd be registered? Asking IANA to generate
> the id part seems odd.

http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-12, for example, asks for registration of urn:ietf:params:oauth:grant-type:saml2-bearer.

Ciao
Hannes