Italo, > On Apr 14, 2023, at 10:32 AM, Italo Busi <[email protected]> wrote: > I also agree with you concerns with hexdump, but parsing has some issues when > something is unknown (these are the issues that have triggered your draft and > this discussion), although I also agree with you that the unknown is for > ‘exception cases’ > > That’s why I would prefer: > A YANG leaf of type bits to report known bits (after parsing) which will > cover “most circumstances” > Another YANG leaf of type hex-string for the ‘exception cases’ (or for those > who really loves hexdump)
What do you think goes into such hex-strings? And why is that different than raw format? > There is a similar issue when reporting a protocol field representing an > enumeration. If the received value is known, it would be better to report a > string/identity name associated with the recived value but when the value is > unknown it is only possible to report the hexdump of the field Partial agreement here. This overlaps the desire to have bits be able to print things by default. Please see the github entry Kent referenced earlier. -- Jeff
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
