On 09/12/2021 21:58, Jeffrey Haas wrote:
Tom,
On Thu, Dec 09, 2021 at 05:04:24PM +0000, t petch wrote:
On 08/12/2021 17:47, Jeffrey Haas wrote:
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.
I follow your argument.
I have doubts about it as a requirement rather than a nice to have.
If it is a requirement to update every single set of yang modules that
maintain a non-revision specific import statement but with a softer textual
reference, then we have a massive "shake the tree" problem for even trivial
updates.
Jeff
I think you read too much into what I say. In the general case, there
is no need to go back and update reference clauses in import statements;
they tell us what the module was then tested with and that should not be
changed unless and until e.g. more testing is done or a problem is
found. And the rules in RFC7950 should ensure that updates to an
imported module never cause a well-written importing module to fail.
This is different. The update in 9127-bis is widely needed, based on
what you have reported about deviations, and so it matters that the
other modules involved, be they bfd, pim, bgp or whatever, record the
fact that they work with the new bfd-types in 9127-bis.
So here it matters that the modules that care about the changes import
bfd-types from 'XXXX' and do not go on referencing 9127. (What happens
with RIP is interesting - I think that that RFC should never have been
published!)
By contrast, if 6991bis were to become RFCyyyy, then I would not update
a single one of the hundreds of modules that import from RFC6991 unless
and until they are updated to use some value that is in 6991bis and not
in RFC6991 at which point the reference needs updating to RFCyyyy.
Tom Petch
That shake the tree exercise is understood for by revision, and I know that
discussion is ongoing in IETF to figure out how we best resolve everything.
I'll prod the YANG doctors on this point in a separate thread offlist.
Beyond that, I acknowledge your points and effective roadmap for updating
the document as being a valid one. That said, I'm only the document
shepherd rather than an authors. Let's see if they have further inputs.
-- Jeff
.
