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

Stephen Farrell <> Thu, 21 June 2012 19:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DFF8621F8542 for <>; Thu, 21 Jun 2012 12:27:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -101.751
X-Spam-Status: No, score=-101.751 tagged_above=-999 required=5 tests=[AWL=-0.548, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JMXvrRpyQYAJ for <>; Thu, 21 Jun 2012 12:27:06 -0700 (PDT)
Received: from ( [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by (Postfix) with ESMTP id 8784721F85CE for <>; Thu, 21 Jun 2012 12:27:04 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 26650171C1E; Thu, 21 Jun 2012 20:27:04 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; h=date :subject:from:x-mailer:message-id:content-type :content-transfer-encoding:mime-version:in-reply-to:references :received:received:x-virus-scanned; s=cs; t=1340306823; bh=MLbeV oOdf1TUcrgq7WFhHX0Q3GCj7v+6qh6r+GQ5sHQ=; b=W0LF62jzvspXVgIpDbALG N4TMdRUTF6b1jMDfMzJGA6NKGgraiRchSAIYB2P6+MwFmCdK+aNJoZjCMzZwC2W/ RnpWTcEXBvel9Y+w9pwD4P5foBoioL4IYef6ctq88L9ibN6lgFddOBxXgp5Sq0ST CYcG5lOIIjq8ukhvSHR5lujQJKnybz5KuP+yG8vekCZug23C4CjiqjH2QadXEZ7Q YyO4itVfdoX+7itkT9Z7JfUQuI5wVArtxQI9P5T3TnLgzel1qeikXnO4BvTiiyu/ 9h/wAsf4zeUF5nx8Ps5EduBDnWWf1jEJbN1hXZL24JkNw6VmMA7zUxf3SW4pUHq8 g==
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10027) with ESMTP id DAKJBwkg7cPA; Thu, 21 Jun 2012 20:27:03 +0100 (IST)
Received: from [] (unknown []) by (Postfix) with ESMTPSA id 114D617147E; Thu, 21 Jun 2012 20:27:03 +0100 (IST)
References: <> <> <>
In-Reply-To: <>
Mime-Version: 1.0 (1.0)
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="us-ascii"
Message-Id: <>
X-Mailer: iPhone Mail (9B206)
From: Stephen Farrell <>
Date: Thu, 21 Jun 2012 20:27:02 +0100
To: Barry Leiba <>
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 19:27:07 -0000

On 21 Jun 2012, at 19:29, Barry Leiba <> wrote:

>>> (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.
> Stephen:
> Yeah, I'm not sure Standards Track is needed.  

On this bit: I personally don't care, except that we don't have to do it twice because someone later on thinks the opposite and wins that argument, which I'd rather not have at all  (My one-track mind:-) Doing the 4 week last call means once is enough. But I'm ok with whatever the WG want.


> Other than "Other
> documents like it are Standards Track," explain why Informational
> doesn't work.  Is there some procedural reason that these IANA actions
> can't be done with an Informational document?  Is there any
> expectation that this will be reviewed and modified and progress along
> any sort of track at all?  Certainly, this doesn't define any sort of
> "standard" that I can see.
> Informational documents in the IETF Stream *do* have "IETF Consensus".
>>> (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.
> ...
>> 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.
> Hannes:
> I'm going to really push hard on this point: the goal is *NOT* to make
> all the registration policies the same, and I will resist that
> strongly.  The *goal* is to use for each registry a registration
> policy that makes sense for *that* registry.  That means that you
> (well, someone) need to tell me why *this* registry needs the
> strictness that you pick for it.  What will the harm be in leaving it
> to Expert Review, and letting the designated expert decide how much
> documentation to require?  And remember, you can document guidelines
> for the designated expert.  For that matter, what will the *harm* be
> in simply letting it be First Come First Served?
> We have far too many too-strict registration policies in effect, and
> they often come back and bite on the ass the very people who picked
> the policies.
>> So, I am curious where to hit the right level of process here to find the sweetspot
>> between low overhead and high quality specifications.
> You also need to consider whether poorly documented and unused
> extensions really cause any *harm*.  If some bozo writes a bad spec
> for a stupid idea, and no one implements it because the spec is bad
> and the idea is stupid, so what?  On the other hand, if some big
> company decides it's too much trouble to follow IETF procedures and
> chooses not to register their extension, but everyone winds up using
> it because they're big and it's necessary, what was the point of
> making the registration hard?
> That's the real balance we have to look at.
> Barry