On Thu, Apr 13, 2023 at 1:27 PM Jeffrey Haas <[email protected]> wrote:
> > > On Apr 13, 2023, at 3:59 PM, Andy Bierman <[email protected]> wrote: > It is somewhat strange to model "unknown-bits" as if it was a property of > the data model. > Protocols generally have version detection or rules (e.g. receiver MUST > ignore reserved bits). > > > Repeating my question to Acee... did you read the draft? This isn't a > theoretical use case. > > > > The semantics of the leaf could easily be unknown bits instead of a raw > field. > The (subjective) issue is whichYANG representation of a set of bits is > best to use. > > typedef unknown-bits { > type bits { > bit bit-0 { > position 0; > > [...] > > Perhaps some people prefer "bit-0 bit-1 bit-2 bit-3 bit-4 bit-5 bit-6 bit-7" > over "ff". > > It seems rather subjective to debate which is easier for everybody to use. > > > And yet, here you are stating an opinion. > > My opinion on this matter stems from the use case being mostly known and > assigned bits and a small number of unknown bits and a desire to not to > have to make my model users go fishing for the exceptions. > The typedef provides no semantics other than which bits are set in a bit string. There are other ways to do that and all of them are valid usage of YANG. I do not see how either encoding above requires "fishing" any more than the other. > RFC 7950 is quite clear about MUST NOT change the bit position or bit > identifier after a module is published. > > > > And yet, we're here because the current design of YANG doesn't handle this > unknown case well. > > Changing the identifier breaks XML and JSON encoding of bits, so that is why it says MUST NOT do this in RFC 7950. > Note that this proposal provides stable assignments in each of the known > and unknown leafs. Nothing changes in a version incompatible fashion for > the types. > > -- Jeff > > Andy
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
