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

[Hannes Tschofenig <[e-mail]>]

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

Ciao
Hannes