Jason, On Jun 28, 2023, at 5:51 PM, Jason Sterne (Nokia) <[email protected]> wrote: > > > I’m not sure how the concerns about non-backwards-compatibility are addressed > by YANG library. Both Rob and I were proposing that one potential solution is > to always send all the bits in the 2nd leaf (even after they become “known > bits” in the first leaf).
As previously discussed in the thread, while this is a possible mechanism, it’s not the intended use case. Certainly the typedef proposed here could be used for such a case where you’re always defining the bits, but in my opinion it’d be better in such cases to simply use type “binary” to model such things. A reminder of the use case I’m trying to cover: Protocols will typically move across their lifetime from mostly “known” bits in their bit vectors/flag fields during their definition with some bits left over as reserved. Over a period of maintenance, previously unknown bits may be used. Implementations of a YANG module covering an older protocol definition using bits or identities have no way to operationally represent that version of the module’s “unknown” state. The intent is to cover two cases: Transient (from the perspective of one module version to the next) missing definitions of bits that will become known. Protocol violations where unknown bits are sent and would not be expected even in updated protocol versions. For the first case, only a few bits would typically be expected to show up from one version of the module to the next. Having an “unknown” pop up in the unknown leaf should be an easy, “Surprise!” But if it’s buried in the noise of the normal, it doesn’t stand out. Distinguishing the first from the second case is impossible from the perspective of a given version of the module. All it knows is that the bit is unknown. The operator would have to know after study that a previously unknown bit is getting signaled and should not be after researching protocol changes. But at least they get the operational prod to investigate the WTF moment. After such moments, it’s not atypical to break out tcpdump. In such cases, access to raw contents can become important. In current modeling practices, I’m of mixed opinion about always putting raw contents of packets in management data; it adds significant noise. I’d personally prefer the modeling methodologies and tooling evolve to a mode where such deep debug data were either circumstantially present (it’s not noise when you ask for it) or in a distinct debug sub-tree. — Jeff
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
