Tom, I think we're going too deep into the weeds here for the BFD list in terms of the impact of this piece of the discussion. I'd suggest continuing it on the thread started with the yang doctors. Once there is consensus on it, we can take it back here as actions for suggested updates to the BFD document.
On Fri, Dec 10, 2021 at 04:47:05PM +0000, t petch wrote: > 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. I have only your words to go on. When you use phrases like "guess what tooling does with that information in the wild", it's reasonable to think you have a strong concern. You finish by saying we had five modules that "need to be updated". It's not clear why - hence asking the broader audience what their own interpretation of the rules are. > 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. That was my take on the issue. But that lead me to question why we had need to update the other modules simply to update the reference. > 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. I don't know that is the case. It is a valid, but perverse option to have support for the new feature and still deviate away the nodes. Deviating away the nodes when the feature is not supported is likely still valid. I don't find anything in the definition in RFC 7950 ยง7.20.3 that specifies interaction with if-feature. I believe the reasonable expectations are: 1. If you implement solely RFC 9127, and you don't support the per-client configuration nodes, your implementation can deal with this solely by issuing deviations on the importing modules. This is where we had started this exercise some years ago. 2. If you implement what comes after RFC 9127, regardless of whether you get a new copy of the full non-IANA maintained module set or an update to just the ietf-bfd-types module, you don't need the deviations if you don't need the feature. The shipping vendor would remove the deviations as part of their bundle. The implication you're trying to raise is that it's impossible to update a module that is cited in a specific RFC without implying scarily that Things May Break. I don't think that's the intent. > 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. How is this any different than an IANA maintained module where the intent is stuff is added as the protocol is maintained? If your implementation pulls in a new version of the impacted module, your implementation has a need to deal with the impacts. For operational state, this isn't an issue because it'd not start using a new value without changes. For configuration state, the implementor had better make sure that they either support changes that result from using that new version or issue the appropriate deviation. -- Jeff
