Andy,
> On Apr 12, 2023, at 1:27 PM, Andy Bierman <[email protected]> wrote: > I unclear on the "ease of use" gained by using YANG bits to define bit > positions. > IMO is would be much easier to use a protocol-specific leaf if you want to > debug > a specific protocol. An operational leaf like "raw-foo-field" is sufficient > and easy to use. Not really, and this exact issue was raised earlier in the discussion. See "more compact representation" in here and Jürgen's response: https://mailarchive.ietf.org/arch/msg/netmod/j3d3O15IYKxmtDioZC28bVDRVLg/ > The only semantics seems to be the bit position, which is already standardized > and can be represented many ways (e.g. hex-string, binary, uint32). Or... bits. (BITS in SMIv2 by comparison) The semantic being modeled here is the unexpected rather than the raw output. Our routing protocols expect things generally to be "known" if you're in an appropriate version of the protocol. Having raw output isn't needed most of the time, only for transitional cases. And if you want to do raw, you encounter the issues previously mentioned. If netmod and the YANG doctors want to provide general purpose advice for leveraging existing data types for representing arbitrary bit vectors for raw purposes... go for it. That's not my use case. That said, out of those options: - Native uintX - bit alignment, network byte ordering and other things need to be specified, but it's doable. - hex string - pick a canonicalized format, and permit it to be arbitrary length. Now the user has to do math to figure out where in the vector bit X may be, then do a bit mask on it. Simple for machines, certainly. PITA even when I'm dealing with it in gdb; I tend to do "print/t" when I get to that point. - binary? base64 is already a PITA. If the client doesn't parse it and turn it into something else a human can read, you're already having problems. ... or, bits have the facilities to display this stuff already. Do I want to use this type for raw output? No... it's noisy. It's also not my use case. -- Jeff _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
