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 <[email protected]> Sent: venerdì 14 aprile 2023 14:49 To: Italo Busi <[email protected]> Cc: Jason Sterne (Nokia) <[email protected]>; [email protected] Subject: Re: [netmod] Unknown bits - backwards compatibility Italo, On Apr 14, 2023, at 4:04 AM, Italo Busi <[email protected]<mailto:[email protected]>> 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 [email protected] https://www.ietf.org/mailman/listinfo/netmod
