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

Brian Campbell <> Wed, 20 June 2012 16:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6B51921F8713 for <>; Wed, 20 Jun 2012 09:26:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.677
X-Spam-Status: No, score=-5.677 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QK865Fa+uCH0 for <>; Wed, 20 Jun 2012 09:26:35 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 7C32B21F8711 for <>; Wed, 20 Jun 2012 09:26:35 -0700 (PDT)
Received: from ([]) (using TLSv1) by ([]) with SMTP ID; Wed, 20 Jun 2012 09:26:35 PDT
Received: by qcsu28 with SMTP id u28so5539340qcs.22 for <>; Wed, 20 Jun 2012 09:26:34 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=I0cwl+QUHBqBb5xVI2Pv3h55CtJbFk1nIdVMMrjmmDA=; b=d0dH6c1nUBrBqKOSgkcDTkquKt/dn7rbIAhUcA61MEMEw4aOxeZ3Tvwr1llvdEFw08 m5dUd3/hsjhTwUB4Nnknlxrvu+1RU7Yh4ve5Qd/BJdshDX1p0zPp1R9PEihO3LBkyEkt cMfwh3QtPYcF/OqxuB/bCV1ggmGOh0oxFth1vTXUus5Z3970tL9pPrR40HzaZVq39siR VJf+TcE5G8Rbm6PYNwHW4LY0isbTeDkJSfUQx8G0VzY6dQyDdseyY5wbfdz+RWy9jWBZ l41iPajJEEDjjJdCf8mS+Dzln0jEDTIT4nZXzZpESXg6XFfV0WprsFInjU1ETKdy3wLn 82LQ==
Received: by with SMTP id gq1mr42339368qab.54.1340209594028; Wed, 20 Jun 2012 09:26:34 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 20 Jun 2012 09:26:03 -0700 (PDT)
In-Reply-To: <>
References: <>
From: Brian Campbell <>
Date: Wed, 20 Jun 2012 10:26:03 -0600
Message-ID: <>
To: Stephen Farrell <>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQn6w2s2rPb46rfFlXuYQ5apzmXa/QFzw7K0Mn4nea/kIg5H0KZ25HOAr2N95MUzzjYBMqCx
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:26:36 -0000

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?
are real examples that *hopefully* do the registration correctly.

Do you think I should add an example registration directly to

> 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?