Hi Mike, On Wed, Oct 2, 2024 at 11:01 PM Michael Jones <[email protected]> wrote:
> ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > I concur strongly enough with John Scudder's comment about the IANA > registry > that I'd like to discuss it. Moreover, Section 4 of BCP 26 says: > > [...] Newly minted policies, > including ones that combine the elements of procedures associated > with these terms in novel ways, may be used if none of these policies > are suitable; it will help the review process if an explanation is > included as to why that is the case. > > Is that explanation available anywhere? I think John's right, this is a > peculiar loophole, and it would be helpful to know why the WG thinks this > is > necessary. There's already a debate in progress about whether an I-D > (which > expires) is viable in a Specification Required registry, and we're about to > charter a WG to revise BCP 26, so this is actually quite topical. > > Mike> The explanation for the OAuth registration language is that we want > to give authors of specifications proposing to register OAuth parameters > the benefit of review by designated experts *before* the spec is completely > done, so that if problems are found, they can iterate and fix them before > making their specifications final. I've been in many situations, both as > the party registering and as the Designated Expert, where this pre-final > review was priceless and resulted in improvements in the specification. > I'd be open to different (possibly more standard) language that still > achieves this possibility. > > Mike> For what it's worth, remember too that this language was written > before RFC 8126 was. If there's a more modern equivalent you can suggest, > I'm all for it. > Irrespective of that BCP's timeline, I always prefer to err on the side of explaining too much versus too little when doing something procedurally unusual. In this case, I think the explanation you gave here is simple and would be beneficial to include, especially since future authors might take it as an example of the minimum you need to get some kind of custom policy through IESG Evaluation. I would encourage such a sentence or two to be added here. My main concern with the policy as written is that there's a possible leak: If the DE approves something because she is relatively certain a registration is going to happen, but then for some reason that process is never completed, we're left with a dangling registration. What might we do for this registry in such a situation? Should a DE be further empowered to deregister something if this condition were to arise? It would be nice to plug this hole. I'll clear my DISCUSS now, since the discussion happened, but I'd encourage consideration of some review of these two points with Deb, and I'm happy to continue the conversation too if necessary. ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > [...] > In Section 2.1, second paragraph, the RECOMMENDED and SHOULD seem bare to > me. > Why would we allow anything other than what's specified, especially since > BCP > 47 prescribes a particular behavior? > > Mike> This is exactly the same language as used for OAuth Client metadata > at https://www.rfc-editor.org/rfc/rfc7591.html#section-2.2. Since this > spec is entering the same OAuth ecosystem, I'm reluctant to make it > different in any way. > > Mike> I look forward to hearing back from you, particularly about the IANA > registration goals and language. > Well, that's unfortunate. But this part was only a COMMENT. -MSK
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
