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

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4DB0721F8718 for <>; Thu, 21 Jun 2012 11:48:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.487
X-Spam-Status: No, score=-102.487 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XP30txHMW+VU for <>; Thu, 21 Jun 2012 11:48:27 -0700 (PDT)
Received: from ( []) by (Postfix) with SMTP id 396BE21F8726 for <>; Thu, 21 Jun 2012 11:48:26 -0700 (PDT)
Received: (qmail invoked by alias); 21 Jun 2012 18:48:25 -0000
Received: from (EHLO []) [] by (mp027) with SMTP; 21 Jun 2012 20:48:25 +0200
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX1+N2YdXbLWNnQvfSi/dodRCukxFJvhpHqmlmJ84b3 c+yXlwNLmgbbtn
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:48:22 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <>
To: Barry Leiba <>
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:48:28 -0000

Hi Barry, 

On Jun 21, 2012, at 9:29 PM, 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.  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".

On our status call on Monday you explained me that both types of documents have IETF last calls these days. 
Hence, I wonder whether there is any practical difference? 

>>> (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.

I made a mistake here and responded too quickly. I will respond to that issue in my mail to Mike since it very much relates to an issue he raised. 

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