> On Apr 13, 2023, at 3:59 PM, Andy Bierman <a...@yumaworks.com> 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.
>
> 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.
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
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
