Italo's suggest was also how I was thinking of this. We could define a convention for how the "raw" leaf should be named relative to the bits decoded leaf, and also what type the "raw" leaf should use. E.g., in the case where the length of the bits field is known (e.g., it is defined/constrained by a protocol spec), then it could just use a uint8 - through uint64 as appropriate, otherwise I would have thought that binary would be appropriate underlying type.
As new bits get defined then the bits type would get updated, but the "raw" leaf wouldn't need to change. Hence a draft could: * Define a convention for naming the "raw value" leaves to be used in conjunction with the decodable bits types leaves. * Define typedefs that wrap (uint8 - uint64, and binary) to indicate the semantics as representing undecoded bits. * Define a convention for decoding/displaying the new types (perhaps in conjunction with the decoded bits type leaf). Regards, Rob // As a contributor. From: netmod <netmod-boun...@ietf.org> On Behalf Of Italo Busi Sent: 14 April 2023 15:33 To: Jeffrey Haas <jh...@pfrc.org> Cc: netmod@ietf.org Subject: Re: [netmod] Unknown bits - backwards compatibility Hi Jeff, I agree with you on the preference for hex-string versus binary in YANG 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) 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 Italo From: Jeffrey Haas <jh...@pfrc.org<mailto:jh...@pfrc.org>> Sent: venerdì 14 aprile 2023 14:49 To: Italo Busi <italo.b...@huawei.com<mailto:italo.b...@huawei.com>> Cc: Jason Sterne (Nokia) <jason.ste...@nokia.com<mailto:jason.ste...@nokia.com>>; netmod@ietf.org<mailto:netmod@ietf.org> Subject: Re: [netmod] Unknown bits - backwards compatibility Italo, On Apr 14, 2023, at 4:04 AM, Italo Busi <italo.b...@huawei.com<mailto:italo.b...@huawei.com>> wrote: If the need is to report the value of a received protocol field for debugging/troubleshooting purposes, I am wondering why not using a binary type instead of a bits type or, better, a YANG leaf of bits type for the known bits and another YANG leaf of binary type for all known/unknown bits Type binary isn't generically helpful. The implementation has to do something with the base64 stream it gets. If it's just going to dump it in hex format, you might as well just say that and use hex-string. The use case here is most bits are known and these are exception cases. Ideally in most circumstances, the leaf containing the unknowns is absent. Perhaps a bit of personal context: "Hey, Jeff... why not just get a hexdump of the packet?" "I've spent 20+ years looking at different tools' dumps of bits of BGP PDU and I'm sick of it. The code knows how to parse out fields, let it do that work." -- Jeff (who keeps expecting this conversation to devolve to a proposal for netconf streaming tcpdump)
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
