> On Sep 5, 2023, at 16:25, Jeffrey Haas <jh...@pfrc.org> wrote:
>
> Acee,
>
>
>> On Sep 5, 2023, at 12:42 PM, Acee Lindem <acee.i...@gmail.com> wrote:
>>
>> What I’d thought about for this requirement is an optional read-only leaf
>> containing the hex representation of only the unknown bits. This would be
>> simpler to model and would be fully backward compatible.
>>
>> For example:
>>
>> leaf unknown-flags {
>> type yang:hex-string;
>> description
>> "When a bit is exchanged in the Graceful Restart Flags
>> field that is unknown to this module, the hexadecimal
>> representation of flags field is returned with the unknown
>> bit(s).";
>> reference
>> "RFC 4724: Graceful Restart Mechanism for BGP, Section
>> 3.";
>> }
>
> I'm not sure why this variant is particularly nicer than a set of bits in a
> bit vector that themselves do not have any backward-incompatible changes.
>
> If I have, e.g. "unknown-3" and "unknown-4" as the options in the unknown
> field, and then next rev comes along and defines 3 and the "known" bit gets
> defined, deprecating unknown-3 is clear signaling that it's gone away.
>
> Part of the complaint in this thread is bit-3's contents "move" around. The
> same would be true for the contents of a unknown field in a different non-bit
> format: e.g. hex, uint, or binary.
The advantage is that the initial modeling is simpler (especially with lots of
reserved bits) and an augmentation adding a definition of a bit that was
previously defined doesn’t need to deprecate anything.
Acee
>
> -- Jeff
>
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
