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

[Brian Campbell <[e-mail]>]

Thanks Stephen,

I'll try and get all that done soon.

On Wed, Jun 20, 2012 at 10:41 AM, Stephen Farrell
<[e-mail]> wrote:
>
> Hi Brian,
>
> That all looks fine.
>
> I'd say start from the expert review text from the oauth base
> IANA considerations if that's what you think the WG want. Posting
> that to the list for checking would seem worthwhile, its common
> to need a minor tweak or two.
>
> I'm ok with having or not having the reference to oauth
> base security considerations - whatever you prefer.
>
> I'll mark this as revised I-D needed.
>
> Soon's that's out I'll start IETF LC.
>
> Thanks,
> S.
>
>
> On 06/20/2012 05:26 PM, Brian Campbell wrote:
>> Thanks Stephen (also Peter) for the review and feedback. Responses are inline.
>>
>> On Wed, Jun 20, 2012 at 6:26 AM, Stephen Farrell
>> <[e-mail]> wrote:
>>>
>>> Hi,
>>>
>>> Many thanks for a nice short document!
>>
>> If only they could all be so short right? :)
>>
>>> I've a few questions though and suspect that a quick re-spin
>>> might be needed, but let's see what the wg think about 'em
>>> first.
>>>
>>> (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?
>>
>> I'm pretty sure that was just an oversight when using some boilerplate
>> xml to get the document started. I agree with you and Peter that
>> standards track makes more sense and I've updated my local copy of the
>> source to reflect that.
>>
>>>
>>> (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.
>>
>> Again I agree with you and Peter - lighter is preferred.  Though
>> Hannes wrote the original text for this so I'd ask that he please
>> speak up if there was some reason to require RFC here that we aren't
>> aware of.
>>
>> Can you help me with the proper text for this? Is it sufficient to
>> drop the "NOTE: in  order for a URN of this type to be assigned, the
>> item being registered MUST be documented in a RFC" text from the 1st
>> paragraph of §3 and change "New entries to the registry are
>> Specification Required" to "New entries to the registry require expert
>> review" in §5.1?
>>
>>
>>> (3) If answer to (2) is yes: Section 5.1 says "Specification
>>> Required" but section 3 said "RFC Required" and those differ.
>>> For example, an OASIS spec would not be ok if you say RFC
>>> required. I don't know if you care, but you need to be
>>> consistent. (Or else I've misread something;-)
>>
>> Having chaired an OASIS TC for 2 years I probably should care :)  See
>> the previous comment/question about relaxing this.  Expert review
>> seems good or maybe Specification Required but not RFC Required.
>> Regardless, your are right, it should at very least be consistent :)
>>
>>> (4) Isn't the template missing the reference to the RFC or
>>> other specification that defines the URN?
>>
>> I believe the "Description" portion of the template was intended to
>> capture that. Or that's how it's kinds been used by specs that use it
>> anyway. Should we add a "Specification document(s):" to the template?
>>
>>> (5) I don't get section 3, sorry;-) Can you give an example of
>>> a class:id pair that'd be registered?
>>
>> http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-12#section-6
>> and http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-00#section-6
>> are real examples that *hopefully* do the registration correctly.
>>
>> Do you think I should add an example registration directly to
>> draft-ietf-oauth-urn-sub-ns?
>>
>>> Asking IANA to generate
>>> the id part seems odd.
>>
>> Agreed. The "please assign" text should probably be removed. It's
>> really up to the defining spec to say what the class and id are/
>>
>>> nits:
>>>
>>> s3: s/generally referred/generally known/
>>
>> Will do.
>>
>>> s4: Might be worth pointing at the security considerations
>>> section of draft-ietf-oauth-v2? I'd say that text would be
>>> good to have read to know about the security considerations
>>> for the use of these URNs, before you go making one up.
>>
>> Is just referencing it sufficient?
>>
>>