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

Hannes Tschofenig <> Thu, 21 June 2012 18:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4E99E21F876A for <>; Thu, 21 Jun 2012 11:14:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.192
X-Spam-Status: No, score=-102.192 tagged_above=-999 required=5 tests=[AWL=-0.193, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dy1uA0akZvL9 for <>; Thu, 21 Jun 2012 11:14:21 -0700 (PDT)
Received: from ( []) by (Postfix) with SMTP id 0E48F21F875A for <>; Thu, 21 Jun 2012 11:14:19 -0700 (PDT)
Received: (qmail invoked by alias); 21 Jun 2012 18:14:08 -0000
Received: from (EHLO []) [] by (mp036) with SMTP; 21 Jun 2012 20:14:08 +0200
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX188r8UwD2s8K1F3ujyHT7+bhftMZ7IkWScxTcwMYf 2seio0C9DjY0CO
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Hannes Tschofenig <>
In-Reply-To: <>
Date: Thu, 21 Jun 2012 21:13:56 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Stephen Farrell <>
X-Mailer: Apple Mail (2.1084)
X-Y-GMX-Trusted: 0
Cc: "" <>
Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-urn-sub-ns-02
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 21 Jun 2012 18:14:22 -0000

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]
> (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 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., for example, asks for registration of urn:ietf:params:oauth:grant-type:saml2-bearer.