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

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.

On Sun, Jun 24, 2012 at 1:22 AM, Eran Hammer <eran@hueniverse.com> wrote:
> 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
>
>> -----Original Message-----
>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
>> Of Mike Jones
>> Sent: Saturday, June 23, 2012 11:31 AM
>> To: John Bradley; Hannes Tschofenig
>> Cc: Barry Leiba; oauth@ietf.org
>> Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-urn-sub-ns-02
>>
>> 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:ve7jtb@ve7jtb.com]
>> Sent: Saturday, June 23, 2012 8:36 AM
>> To: Hannes Tschofenig
>> Cc: Mike Jones; oauth@ietf.org; Barry Leiba
>> Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-urn-sub-ns-02
>>
>> 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
>>
>> On 2012-06-23, at 8:31 AM, Hannes Tschofenig
>> <hannes.tschofenig@gmx.net> wrote:
>>
>> > 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
>> >
>> >
>> > On Jun 21, 2012, at 10:49 PM, Mike Jones 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: Barry Leiba
>> >> Sent: 6/21/2012 12:31 PM
>> >> To: Stephen Farrell
>> >> Cc: oauth@ietf.org
>> >> Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-urn-sub-ns-02
>> >>
>> >>>> Stephen:
>> >>>> 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.
>> >>
>> >> 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
>> >> _______________________________________________
>> >> OAuth mailing list
>> >> OAuth@ietf.org
>> >> https://www.ietf.org/mailman/listinfo/oauth
>> >>
>> >> _______________________________________________
>> >> OAuth mailing list
>> >> OAuth@ietf.org
>> >> https://www.ietf.org/mailman/listinfo/oauth
>> >
>> > _______________________________________________
>> > OAuth mailing list
>> > OAuth@ietf.org
>> > https://www.ietf.org/mailman/listinfo/oauth
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth