Thanks Stephen, I'll try and get all that done soon.
On Wed, Jun 20, 2012 at 10:41 AM, Stephen Farrell <stephen.farr...@cs.tcd.ie> 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 >> <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
