Tom, On Wed, Dec 08, 2021 at 04:24:27PM +0000, t petch wrote: > On 08/12/2021 12:58, Jeffrey Haas wrote: > >>The IANA Considerations are now a nonsense; I think that IANA need > >>consulting on what they want to do about whatever happens and > >>9127-bis revising accordingly. > > > >Issue #9 has been opened to track this. I believe this is mostly a simle > >matter of requesting IANA to update the previous registrations to point to > >the RFC-to-be. > > Wrong! > > RFC9127 set up an IANA-maintained module and provided the initial > entries and handed control over to IANA. That is done, dusted, > finished with. You cannot provide initial entries again, they are > there in IANA. You cannot provide the instructions - they have > already been given to IANA.
This is for iana-bfd-types, which we're not touching. Dropping it out of the 9127-bis draft text is certainly the easy fix here. As I think through what I think you're highlighting as the consequences here, it seems like you're leading toward the idea that a full re-issue is not the proper idea to address the issue we're discussing. > There is nothing to be changed as a result of what is currently > proposed in 9127-bis; the IANA registry, the instructions about it > change not a whit so this I-D must do nothing. A helpful note > explaining why section 2.11 has been removed (as it must be) and an > IANA Considerations saying that this I-D, unlike RFC9127, makes no > change to the IANA-maintained module (as indeed it cannot as it is > IANA-maintained!). It is all very simple and logical. If we were doing a re-issue of the existing modules in the same RFC, requesting IANA to update the various registries that refer to the owning RFC would likely be appropriate. That said, where I think you're leading the discussion is that the simplest fix may be to simply re-issue the ietf-bfd-types module since that's our only change? -- Jeff
