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

Stephen Farrell <> Wed, 20 June 2012 16:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6C84321F8775 for <>; Wed, 20 Jun 2012 09:41:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.205
X-Spam-Status: No, score=-102.205 tagged_above=-999 required=5 tests=[AWL=-0.206, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3AXhCEDeefX2 for <>; Wed, 20 Jun 2012 09:41:04 -0700 (PDT)
Received: from ( [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by (Postfix) with ESMTP id 8630721F8770 for <>; Wed, 20 Jun 2012 09:41:03 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id EEB9D171484; Wed, 20 Jun 2012 17:41:02 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1340210462; bh=Xdj0bFLMxH3++/ gkZVMl66E0BG8FpWSrW2jOh3BKcz0=; b=wsg7cHx2cFxNTgwZ/qOBMZRSxzrFKN ZTSL31fK87htnXHVHT4CRWeqb+lTKtSc04gFL+UXkZl0Wu+RRu6Vz6IMolMlZ1c+ nghITLVftiAqQi66kzADq8SVrw93NqXme3NywGrr29HPNGij6YWiKUFU9Dm28x0+ FunIbjWapl/IrUpovEJSOBEzfpgD8ZJo13j7hAF7eeS40uziN4unK08QLmy90QMp w8LMheUWQIcoVvide8VV55z7xBeF95io7G7yi2Ej1lVo48eC6tSnmwjHaWkSs+Em wtKYXPlkL1o4yVFsREDON1yN3ajAiPUnNwPEpMGzXgbAqqvb17LpTZGQ==
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10027) with ESMTP id gndMt+btDHTk; Wed, 20 Jun 2012 17:41:02 +0100 (IST)
Received: from [IPv6:2001:770:10:203:e59b:9b9d:9813:95ed] (unknown [IPv6:2001:770:10:203:e59b:9b9d:9813:95ed]) by (Postfix) with ESMTPSA id 80DD8171482; Wed, 20 Jun 2012 17:41:02 +0100 (IST)
Message-ID: <>
Date: Wed, 20 Jun 2012 17:41:02 +0100
From: Stephen Farrell <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: Brian Campbell <>
References: <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.4.2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
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: Wed, 20 Jun 2012 16:41:05 -0000

Hi Brian,

That all looks fine.

I'd say start from the expert review text from the oauth base
IANA considerations if that's what you think the WG want. Posting
that to the list for checking would seem worthwhile, its common
to need a minor tweak or two.

I'm ok with having or not having the reference to oauth
base security considerations - whatever you prefer.

I'll mark this as revised I-D needed.

Soon's that's out I'll start IETF LC.


On 06/20/2012 05:26 PM, Brian Campbell wrote:
> Thanks Stephen (also Peter) for the review and feedback. Responses are inline.
> On Wed, Jun 20, 2012 at 6:26 AM, Stephen Farrell
> <> wrote:
>> Hi,
>> Many thanks for a nice short document!
> If only they could all be so short right? :)
>> 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?
> I'm pretty sure that was just an oversight when using some boilerplate
> xml to get the document started. I agree with you and Peter that
> standards track makes more sense and I've updated my local copy of the
> source to reflect that.
>> (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.
> Again I agree with you and Peter - lighter is preferred.  Though
> Hannes wrote the original text for this so I'd ask that he please
> speak up if there was some reason to require RFC here that we aren't
> aware of.
> Can you help me with the proper text for this? Is it sufficient to
> drop the "NOTE: in  order for a URN of this type to be assigned, the
> item being registered MUST be documented in a RFC" text from the 1st
> paragraph of §3 and change "New entries to the registry are
> Specification Required" to "New entries to the registry require expert
> review" in §5.1?
>> (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;-)
> Having chaired an OASIS TC for 2 years I probably should care :)  See
> the previous comment/question about relaxing this.  Expert review
> seems good or maybe Specification Required but not RFC Required.
> Regardless, your are right, it should at very least be consistent :)
>> (4) Isn't the template missing the reference to the RFC or
>> other specification that defines the URN?
> I believe the "Description" portion of the template was intended to
> capture that. Or that's how it's kinds been used by specs that use it
> anyway. Should we add a "Specification document(s):" to the template?
>> (5) I don't get section 3, sorry;-) Can you give an example of
>> a class:id pair that'd be registered?
> and
> are real examples that *hopefully* do the registration correctly.
> Do you think I should add an example registration directly to
> draft-ietf-oauth-urn-sub-ns?
>> Asking IANA to generate
>> the id part seems odd.
> Agreed. The "please assign" text should probably be removed. It's
> really up to the defining spec to say what the class and id are/
>> nits:
>> s3: s/generally referred/generally known/
> Will do.
>> s4: Might be worth pointing at the security considerations
>> section of draft-ietf-oauth-v2? I'd say that text would be
>> good to have read to know about the security considerations
>> for the use of these URNs, before you go making one up.
> Is just referencing it sufficient?