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

From: Stephen Farrell <[email-masked]>
Date: Wed, 20 Jun 2012 13:26:21 +0100

Hi,

Many thanks for a nice short document!

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?

   [1] http://www.iana.org/assignments/params/params.xml

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

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

(4) Isn't the template missing the reference to the RFC or
other specification that defines the URN?

(5) I don't get section 3, sorry;-) Can you give an example of
a class:id pair that'd be registered? Asking IANA to generate
the id part seems odd.

nits:

s3: s/generally referred/generally known/

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.

Cheers,
Stephen.

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 20 Jun 2012 06:40:03 -0600

>    [1] http://www.iana.org/assignments/params/params.xml

I think you're right that standards-track makes sense here.

> be ok?  No trying to push you one way or the other, I just

Expert review seems fine; lighter processes are better here. If folks
really want a spec, I'd prefer Specification Required to RFC Required or
IETF Review.

> a class:id pair that'd be registered? Asking IANA to generate

It's also not clear to me what is meant by "The token URI that
identifies the registered component."

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Mike Jones <[email-masked]>
Date: Wed, 20 Jun 2012 16:14:05 +0000

I agree that this should be standards track.

I agree that RFC Required is severe overkill.  Specification required or expert review would be fine.

I believe that we should delete the "please assign" functionality and require the registration to include the URN.  The defining specification should contain the URI to be registered.

I also agree that we need the "Specification document(s)" section of the template.  Authors, possibly see http://tools.ietf.org/html/draft-ietf-oauth-v2-28#section-11.1.1 for example wording to use.

The template is also missing the standard "Change controller" section.

Per your question (5) Stephen, possibly see the registrations in http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-12#section-6.  Authors, maybe using one of these as an example would help?

				-- Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Peter Saint-Andre
Sent: Wednesday, June 20, 2012 5:40 AM
To: Stephen Farrell
Cc: [email-masked]
Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-urn-sub-ns-02

On 6/20/12 6:26 AM, Stephen Farrell wrote:
> 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?
> 

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

Expert review seems fine; lighter processes are better here. If folks really want a spec, I'd prefer Specification Required to RFC Required or IETF Review.

> (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;-)
> 
> (4) Isn't the template missing the reference to the RFC or other 
> specification that defines the URN?
> 
> (5) I don't get section 3, sorry;-) Can you give an example of a 
> class:id pair that'd be registered? Asking IANA to generate the id 
> part seems odd.

It's also not clear to me what is meant by "The token URI that identifies the registered component."

Peter

--
Peter Saint-Andre
https://stpeter.im/

_______________________________________________
OAuth mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 20 Jun 2012 17:18:14 +0100

> Per your question (5) Stephen, possibly see the registrations in http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-12#section-6.  Authors, maybe using one of these as an example would help?

Thanks Mike, that answers the question. I can't see
IANA picking that id part but we can ask if the WG
want to ask.

S.

---

From: Brian Campbell <[email-masked]>
Date: Wed, 20 Jun 2012 10:26:03 -0600

Thanks Stephen (also Peter) for the review and feedback. Responses are inline.

> Many thanks for a nice short document!

If only they could all be so short right? :)

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

> be ok?  No trying to push you one way or the other, I just

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?

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

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

> 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

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/

> s3: s/generally referred/generally known/

Will do.

> for the use of these URNs, before you go making one up.

Is just referencing it sufficient?

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 20 Jun 2012 17:41:02 +0100

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.

---

From: Brian Campbell <[email-masked]>
Date: Wed, 20 Jun 2012 12:13:02 -0600

Thanks Stephen,

I'll try and get all that done soon.

---

From: Barry Leiba <[email-masked]>
Date: Wed, 20 Jun 2012 14:34:52 -0400

I'd like to see the new version, since there appear to be a bunch of
changes, but first here are some issues that I don't think have been
brought up yet:

The URN registration stuff seems very incompletely baked.  The title
of 5.1 correctly says it's registering a sub-namespace, but the text
incorrectly says that it's creating a registry.  Perhaps IANA will
understand, but I think you need to do this in two parts.  The first
part would register the "oauth" sub-namespace, and the second would
create a new registry for the things that go into it.

Now, as to what goes into it: What is "class"?  Is there meant to be a
registry of classes?  Is that what section 5.1 is trying to create
(which should be done in a new section 5.2)?  What initial values are
registered there?

Barry

---

From: Brian Campbell <[email-masked]>
Date: Wed, 20 Jun 2012 14:36:16 -0600

After looking at the text again, I think you're right Barry.  It's a
bit confusing as the establishment of the sub-namespace and the
registry for it go somewhat hand in hand. But I agree that it's not
well baked and I'm in the process of reworking it to try and address
your concerns as well as the things Stephen, Mike and Peter have
brought up.

The new version will be substantially different (in its from and text
but not its intent) from -02 and I would really appreciate another
review when I get that published (hopefully soon).

Thanks,
Brian

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 21 Jun 2012 21:13:56 +0300

Hi Stephen, 

thanks for the review comments. ;

> standards track. Did I miss something?
Standards Track is OK. 

> be ok?  No trying to push you one way or the other, I just

That's a good question. 

There are a few documents in the OAuth WG that define new sub-namespaces under urn:ietf:params:oauth. 

It would be good to get the policy for creating new extensions inline with what the registry demands. 

So, for example if I look at the extension policy for 'grant-types' of http://datatracker.ietf.org/doc/draft-ietf-oauth-v2/ says 'Specification Required'. 

On the other hand OAuth core has an interesting policy here since specification required is not enough but it has to be followed by a call for review on some IETF mailing list. 

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.

> consistent. (Or else I've misread something;-)

Of course it is nice to keep the overhead low to define new extensions but the consequence then is that some of these extensions will have very dubious quality.  As an example of this have a look at the EAP methods. 

So, I am curious where to hit the right level of process here to find the sweetspot between low overhead and high quality specifications. 

> other specification that defines the URN?

Not sure what you mean. 

> a class:id pair that'd be registered? Asking IANA to generate

http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-12, for example, asks for registration of urn:ietf:params:oauth:grant-type:saml2-bearer.

Ciao
Hannes

---

From: Barry Leiba <[email-masked]>
Date: Thu, 21 Jun 2012 14:29:37 -0400

>> standards track. Did I miss something?

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

>> be ok?  No trying to push you one way or the other, I just
...
> 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

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 21 Jun 2012 21:44:40 +0300

Hi Barry, 

let me describe what we are trying to do here:

1.) This document creates a new URN with urn:ietf:params:oauth. 
There are procedures for creating new entries under urn:ietf:params, as described in RFC 3553, and we have them in the document. 

2.) We provide guidance on how others then define new sub-registries under urn:ietf:params:oauth. 
Class refers to concepts like 'grant-type'. 

This document does not create these sub-registries. Instead, it only provides guidance for doing that and leaves it to other documents, such as to the bearer document. 

[Note: We should have created these child registries in the document ourselves as well.]

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 21 Jun 2012 21:48:22 +0300

Hi Barry, 

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

> they often come back and bite on the ass the very people who picked

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. 

Ciao
Hannes

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 21 Jun 2012 20:27:02 +0100

On 21 Jun 2012, at 19:29, Barry Leiba <[email-masked]> wrote:

> Yeah, I'm not sure Standards Track is needed.  

On this bit: I personally don't care, except that we don't have to do it twice because someone later on thinks the opposite and wins that argument, which I'd rather not have at all  (My one-track mind:-) Doing the 4 week last call means once is enough. But I'm ok with whatever the WG want.

S

> Other than "Other

---

From: Barry Leiba <[email-masked]>
Date: Thu, 21 Jun 2012 15:31:06 -0400

> On this bit: I personally don't care, except that we don't have to do it twice
> because someone later on thinks the opposite and wins that argument, which
> I'd rather not have at all  (My one-track mind:-) Doing the 4 week last call means
> once is enough. But I'm ok with whatever the WG want.

Well, it's not a 4-week LC, but a 2-week one.  Anyway, yes, I see your
point, and I've done that with other documents.  Better to make it
Standards Track for now, note in the shepherd writeup that
Informational is probably OK, and let the IESG decide.

b

---

From: Mike Jones <[email-masked]>
Date: Thu, 21 Jun 2012 19:49:12 +0000

I'd argue that the registration regime chosen should be flexible enough to permit OASIS or OpenID specs to use it. Otherwise, as someone else pointed, people will work around the limitation by using unregistered values - which helps no one.

-- Mike

________________________________
From: Barry Leiba
Sent: 6/21/2012 12:31 PM
To: Stephen Farrell
Cc: [email-masked]
Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-urn-sub-ns-02

b

---

From: Brian Campbell <[email-masked]>
Date: Thu, 21 Jun 2012 14:22:28 -0600

I agree there but does that have anything to do with the track of this
doc (standards vs info)? Isn't that defined in the doc itself? i.e.

"The registration procedure for new entries requires a request in the
   form of the following template and is subject to Expert Review per
   RFC 5226 [RFC5226]."

On Thu, Jun 21, 2012 at 1:49 PM, Mike Jones <[email-masked]> wrote:
> I'd argue that the registration regime chosen should be flexible enough to
> permit OASIS or OpenID specs to use it. Otherwise, as someone else pointed,
> people will work around the limitation by using unregistered values - which
> helps no one.
>
> -- Mike
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 23 Jun 2012 15:31:45 +0300

Hi Mike, 

the point is not that other groups, like OASIS, cannot use them. They can use the extensions. 

The question is more what process and documentation is needed to allow OASIS (and others) to define their own extensions. 

So far, OASIS had not been interested for any extension (at least from what I know). The OpenID community, to which you also belong, had defined extensions (and brought some of them to the IETF) but had been quite careful themselves to ensure proper review and documentation. 

So, if you look at the most important decision points then you have: 

1) do you want a requirement for a specification, i.e., when someone defines an extension do you want it to be documented somewhere? 

2) do you envision a review from experts (e.g., checking whether the stuff makes any sense or conflicts with some other already available extensions)? 

http://tools.ietf.org/html/rfc5226 provides a good discussion about this topic. 

If the answer to the above-listed questions is YES then you probably at least want 'Specification Required' as a policy. 

Ciao
Hannes

---

From: John Bradley <[email-masked]>
Date: Sat, 23 Jun 2012 11:35:40 -0400

I think Specification required is fine.  It allows a OIDF or OASIS spec to be used as the basis for the registration withh appropriate expert review.

John B.

Sent from my iPad

---

From: Mike Jones <[email-masked]>
Date: Sat, 23 Jun 2012 18:31:04 +0000

I agree that Specification Required would be fine.  I'd rather that there be a publicly available specification defining the URN than one potentially available only to the expert reviewers.

				-- Mike

-----Original Message-----
From: John Bradley [mailto:[email-masked]] 
Sent: Saturday, June 23, 2012 8:36 AM
To: Hannes Tschofenig
Cc: Mike Jones; [email-masked]; Barry Leiba
Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-urn-sub-ns-02

John B.

Sent from my iPad

---

From: Eran Hammer <[email-masked]>
Date: Sun, 24 Jun 2012 07:22:37 +0000

This boils down to whether the registration template can contain all the detailes required for interoperability or not. If not, you need a specification.

EH

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Mike Jones
> Sent: Saturday, June 23, 2012 11:31 AM
> To: John Bradley; Hannes Tschofenig
> Cc: Barry Leiba; [email-masked]
> I agree that Specification Required would be fine.  I'd rather that there be a
> publicly available specification defining the URN than one potentially
> available only to the expert reviewers.
> 
> 				-- Mike
> 
> I think Specification required is fine.  It allows a OIDF or OASIS spec to be
> used as the basis for the registration withh appropriate expert review.
> 
> John B.
> 
> Sent from my iPad
> 
> > The question is more what process and documentation is needed to allow
> OASIS (and others) to define their own extensions.
> >
> > So far, OASIS had not been interested for any extension (at least from
> what I know). The OpenID community, to which you also belong, had defined
> extensions (and brought some of them to the IETF) but had been quite
> careful themselves to ensure proper review and documentation.
> >
> > 1) do you want a requirement for a specification, i.e., when someone
> defines an extension do you want it to be documented somewhere?
> >
> > 2) do you envision a review from experts (e.g., checking whether the stuff
> makes any sense or conflicts with some other already available extensions)?
> >
> > If the answer to the above-listed questions is YES then you probably at
> least want 'Specification Required' as a policy.
> >
> > Ciao
> > Hannes
> >
> >
> permit OASIS or OpenID specs to use it. Otherwise, as someone else
> pointed, people will work around the limitation by using unregistered values
> - which helps no one.
> >>
> >> -- Mike
> >>
> >> From: Barry Leiba
> >> Sent: 6/21/2012 12:31 PM
> >> To: Stephen Farrell
> >> Cc: [email-masked]
> >>> On this bit: I personally don't care, except that we don't have to
> >>> do it twice because someone later on thinks the opposite and wins
> >>> that argument, which I'd rather not have at all  (My one-track
> >>> mind:-) Doing the 4 week last call means once is enough. But I'm ok with
> whatever the WG want.
> >>
> >> Well, it's not a 4-week LC, but a 2-week one.  Anyway, yes, I see
> >> your point, and I've done that with other documents.  Better to make
> >> it Standards Track for now, note in the shepherd writeup that

---

From: Brian Campbell <[email-masked]>
Date: Mon, 25 Jun 2012 12:16:18 -0600

The sentiment of the WG seems to be leaning towards Specification
Required rather than Expert Review.

Barring any objections, I'll update the draft to reflect that and
publish a new version later today.