Thanks Stephen (also Peter) for the review and feedback. Responses are inline.
On Wed, Jun 20, 2012 at 6:26 AM, Stephen Farrell <stephen.farr...@cs.tcd.ie> 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? _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
