On Tue, Jun 13, 2023 at 05:54:40PM +0000, Joe Clarke (jclarke) wrote: > > - I prefer to have non-backwards compatible changes marked and > > explained in the modules instead of relying on some schema > > comparison algorithm. > > > > [JMC] IMHO, the algorithm is useful in addition to any per-module notation > > as the tooling can provide a clear, consolidated report of the overall > > compatibility. > > > > Sure, years ago I implemented smidiff, but then assuming that every > reader has the proper tools is likely wrong. And while tools can spot > differences, they lack the ability to give explanations or advice how > to adapt to changes. NBC changes deserve to be documented where they > take place. Tooling can spot missing documentation. > > [JMC] We have per-module notation, and we discussed general per-node tags > (though they were moved to schema comparison as you point out). Part of this > oscillation is due to changes in feedback over time, and I am unclear the > best path forward on this issue. Myself, personally, I would be okay > bringing back the per-node tags as I agree with your point above. >
The module revision derives from the changes, hence hiding the changes behind a module revision label and suggesting tools to find the details is really backwards. It is relatively pointless whether a module is at revision a.b.c or d.e.f, as long as the definitions imported and used from that module have no NBC changes, the module revision label does not matter for this particular import. If Rob's story is true that NBC changes are rare, then marking them where they occur seems the simplest and most effective solution. /js -- Jürgen Schönwälder Constructor University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <https://constructor.university/> _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
