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

[Barry Leiba <[e-mail]>]

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

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