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

Barry Leiba <> Thu, 21 June 2012 18:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F3CF421F8768 for <>; Thu, 21 Jun 2012 11:29:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.932
X-Spam-Status: No, score=-102.932 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pZ9jlil1KSp9 for <>; Thu, 21 Jun 2012 11:29:39 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id BAA1921F8763 for <>; Thu, 21 Jun 2012 11:29:38 -0700 (PDT)
Received: by lbbgo11 with SMTP id go11so2735317lbb.31 for <>; Thu, 21 Jun 2012 11:29:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=dHuORRvNurQRxCk+y7FXz3gbnavaBSXLp3QYzEXVSlQ=; b=I9NaXEMtKoIKAO8hWJsRUF9O3s6AtXUpY29tXZdZfI4fLnAO0KYzb9DBDmLSreH0hW 38rtproqnxrTV+/LE4lbaZ8lo/qaiFcjBfBOJv/4WeRdU2GPro93/c/T3o3FkKpjOTt1 ON7FDyPCsPRpG47Z44N9e4lA5RQS1OI0mRgdIurPpnY0mVymzjP8zicC4KmLHTWJJqti hPqla7I+JlYCl9hh82Td8A4S/kP4ZNIAeVsq0F8e+DcWxujDpno06XfdjTWxPRvQ+WhT fNzO4zNDRcXHJaW/rGckCy/dgP/Sjkad+K8nWXUiAAR9Phn0NKvrSnq8RHJp8b+tHl5p TGsQ==
MIME-Version: 1.0
Received: by with SMTP id fs11mr27325699lab.23.1340303377596; Thu, 21 Jun 2012 11:29:37 -0700 (PDT)
Received: by with HTTP; Thu, 21 Jun 2012 11:29:37 -0700 (PDT)
In-Reply-To: <>
References: <> <>
Date: Thu, 21 Jun 2012 14:29:37 -0400
X-Google-Sender-Auth: _5htFmsu_ZmG0mRrVoP_UX4Qfa8
Message-ID: <>
From: Barry Leiba <>
To: Hannes Tschofenig <>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
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:29:40 -0000

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

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

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

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.