Just to be clear, IANA raising the issue to the IESG is described in Section 5.3 of RFC 8126, which would be the default expectations if an individual document/registry did not give other instructions.
-Ben On Thu, Oct 31, 2019 at 12:13:58AM +0000, Mike Jones wrote: > I'm in the process of creating -10, which addresses the IESG comments other > than Mirja's. I'm reluctant to change the registration instructions, as they > are currently identical to those for CWTs (and many other specifications > going back to at least RFC 6749, modulo the name of the mailing list). That > said, if the IESG *really* wants to change the party to appeal to in the case > of non-action from the Designated Experts from the IESG to IANA, I'm amenable > to also making that change tomorrow, immediately following the telechat, so > we can send the spec on to the RFC Editor. Let me know what you decide. > > Thanks again, > -- Mike > > -----Original Message----- > From: Barry Leiba <[email protected]> > Sent: Monday, October 28, 2019 2:00 PM > To: Mike Jones <[email protected]> > Cc: Mirja Kuehlewind <[email protected]>; Benjamin Kaduk <[email protected]>; > Roman D. Danyliw <[email protected]>; [email protected]; The IESG > <[email protected]>; [email protected]; [email protected] > Subject: Re: [Ace] Mirja Kühlewind's No Objection on > draft-ietf-ace-cwt-proof-of-possession-09: (with COMMENT) > > The issue isn't using a mailing list. The issue is the instructions to IANA > about how to do management and tracking, stuff that they do just fine without > working groups trying -- will all good intentions -- to tell them how. > > The fact that there are a lot of RFCs that do it just says that working > groups do this frequently, and most ADs don't notice or don't care. And the > reality is that IANA will manage the registration process how they do it, > accommodating reasonable special instructions when they can. The point is > that documents shouldn't be giving special instructions unless there really > is something special needed for a particular reason. > > Barry > > On Mon, Oct 28, 2019 at 12:19 PM Mike Jones <[email protected]> > wrote: > > > > The practice of using a mailing list for registration requests to enable > > public visibility of them goes back at least to .well-known URI > > registrations > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc5785&data=02%7C01%7CMichael.Jones%40microsoft.com%7C085270914a0b42e5007908d75be9e2ea%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637078932422930532&sdata=bwglng9A7A8OGaV4vicvLAAcd%2FqcK7Q%2Fv9cnywn8fDo%3D&reserved=0 > > by Mark Nottingham in April 2010. OAuth 2.0 followed this practice in RFC > > 6749, as did the JOSE specs and JWT in RFCs 7515-19. The rest is history, > > as they say. > > > > -- Mike > > > > -----Original Message----- > > From: Mirja Kuehlewind <[email protected]> > > Sent: Monday, October 28, 2019 8:54 AM > > To: Benjamin Kaduk <[email protected]> > > Cc: Barry Leiba <[email protected]>; Roman D. Danyliw > > <[email protected]>; [email protected]; The IESG <[email protected]>; > > [email protected]; [email protected] > > Subject: Re: [Ace] Mirja Kühlewind's No Objection on > > draft-ietf-ace-cwt-proof-of-possession-09: (with COMMENT) > > > > These are all quite recents examples, so maybe the procedures are changing > > at the moment. I guess we as the IESG should be aware and figure out what > > the right procedure actually should be here. > > > > > On 28. Oct 2019, at 16:31, Benjamin Kaduk <[email protected]> wrote: > > > > > > On Fri, Oct 25, 2019 at 12:31:42PM -0400, Barry Leiba wrote: > > >> Yeh, it's very common for authors to try to tell IANA how to handle > > >> registrations, and I often push back on that as inappropriate. > > >> There are certainly special conditions that IANA should be told > > >> about, but this is standard work-flow management stuff that ought > > >> to be left to IANA. I do think it should be changed before this is > > >> published, probably just removing that last sentence. > > > > > > While I'm not opposed to normalizing on a default procedure, I think > > > the authors were just trying to follow existing examples. > > > > > > RFC 7519: > > > > > > Values are registered on a Specification Required [RFC5226] basis > > > after a three-week review period on the [email protected] > > > mailing list, on the advice of one or more Designated Experts. > > > However, to allow for the allocation of values prior to publication, > > > the Designated Experts may approve registration once they are > > > satisfied that such a specification will be published. > > > > > > Registration requests sent to the mailing list for review should use > > > an appropriate subject (e.g., "Request to register claim: example"). > > > > > > Within the review period, the Designated Experts will either approve > > > or deny the registration request, communicating this decision to the > > > review list and IANA. Denials should include an explanation and, if > > > applicable, suggestions as to how to make the request successful. > > > Registration requests that are undetermined for a period longer than > > > 21 days can be brought to the IESG's attention (using the > > > [email protected] mailing list) for resolution. > > > > > > RFC 8414: > > > > > > Values are registered on a Specification Required [RFC8126] basis > > > after a two-week review period on the [email protected] > > > mailing list, on the advice of one or more Designated Experts. > > > However, to allow for the allocation of values prior to publication, > > > the Designated Experts may approve registration once they are > > > satisfied that such a specification will be published. > > > > > > Registration requests sent to the mailing list for review should use > > > an appropriate subject (e.g., "Request to register OAuth > > > Authorization Server Metadata: example"). > > > > > > Within the review period, the Designated Experts will either approve > > > or deny the registration request, communicating this decision to the > > > review list and IANA. Denials should include an explanation and, if > > > applicable, suggestions as to how to make the request successful. > > > Registration requests that are undetermined for a period longer than > > > 21 days can be brought to the IESG's attention (using the > > > [email protected] mailing list) for resolution. > > > > > > RFC 8447: > > > > > > Specification Required [RFC8126] registry requests are registered > > > after a three-week review period on the <[email protected]> > > > mailing list, on the advice of one or more designated experts. > > > However, to allow for the allocation of values prior to publication, > > > the designated experts may approve registration once they are > > > satisfied that such a specification will be published. > > > > > > Registration requests sent to the mailing list for review SHOULD use > > > an appropriate subject (e.g., "Request to register value in TLS bar > > > registry"). > > > > > > Within the review period, the designated experts will either approve > > > or deny the registration request, communicating this decision to the > > > review list and IANA. Denials SHOULD include an explanation and, if > > > applicable, suggestions as to how to make the request successful. > > > Registration requests that are undetermined for a period longer than > > > 21 days can be brought to the IESG's attention (using the > > > <[email protected]> mailing list) for resolution. > > > > > > [I stopped looking here] > > > > > > So if we're going to change things around, maybe we should issue an > > > IESG statement. > > > > > > -Ben > > > > > > > > _______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
