On 08/12/2021 17:47, Jeffrey Haas wrote:
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?
Well, no. I thought about that and because RFC9127 has seven modules
and five of them import bfd-types then that is five import statements
that should be changed to point to RFC XXXX, not RFC9127, five modules
that if
not updated will mislead in that the message will then be that these five
modules have not been tested with 9127-bis, only with RFC9127; that is
what the reference statement on the import means and I doubt if we can
guess what tooling does what with that information in the wild (and
since this has been hanging around for several years, there may be many
who have proceeded on the basis of the I-D that led to RFC9127).
So my take is that those five modules need to be updated and 9127-bis is
the place to do so.
iana-bfd-types by contrast is done and dusted, handed over to IANA
and further IETF intervention can only confuse IMHO. So in 9127-bis, s.2.11
should be retained, to keep the section numbering consistent, but should say
"RFC9127 contained the initial values for the IANA-Maintained module
iana-bfd-types in this section. This module is now under the control of
IANA. The current version of the module may be obtained from the IANA
website."
Likewise
"5.1 RFC9127 created an IANA-maintained module iana-bfd-types which is
now maintained by IANA; details of how this module is updated can be
found on
the IANA website. IANA is not requested to take any action with respect
to this module. The reference for this module on the IANA website
remains RFC9127"
s.5 remove the two entries for iana-bfd-types; update the others to
point to 9127-bis or 'XXXX' as I keep saying.
Normally, when an RFC creates a module for IANA to maintain, then plenty
of people go on accessing the RFC because ... Here we have a rare
opportunity to keep them on the straight and narrow by removing the
module from 9127-bis making them go look where they should have looked
in the first place.
Tom Petch
-- Jeff .
