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.";
}
Or some variant.
Thanks,
Acee
> On Sep 5, 2023, at 10:54, Jeffrey Haas <jh...@pfrc.org> wrote:
>
> Italo,
>
>
>> On Sep 5, 2023, at 10:28 AM, Italo Busi <italo.b...@huawei.com> wrote:
>> Thinking further, you are right that hex-dumping a field works well only
>> when the "the semantics of the field were always clear: bits, but some are
>> unassigned/reserved"
>>
>> IMHO, if you are interested to diagnose also RESERVED fields with no clear
>> semantic, the best option would be to hex-dump the whole packet/message
>
> IMNSHO, end users will be cursing models that require you to tcpdump the YANG
> for many years to come.
>
> I have some small hope that we'll eventually end up with a mechanism that
> permits such diagnostic nodes to be easily excluded from default views.
> We're not there yet.
>
>> In order to keep the semantics, it is possible to prefix the name of the
>> YANG leaf carrying the hex-dump of the reserved field with the RFC number
>> where the reserved field is defined (e.g., rfcxxx-foo).
>
> I think this is a reasonable proposal.
>
> -- Jeff
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
