On Thu, Apr 13, 2023 at 12:17 PM Jeffrey Haas <jh...@pfrc.org> wrote:
> Andy, > > > > On Apr 12, 2023, at 1:27 PM, Andy Bierman <a...@yumaworks.com> 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. > It is somewhat strange to model "unknown-bits" as if it was a property of the data model. Protocols generally have version detection or rules (e.g. receiver MUST ignore reserved bits). The semantics of the leaf could easily be unknown bits instead of a raw field. The (subjective) issue is whichYANG representation of a set of bits is best to use. typedef unknown-bits { type bits { bit bit-0 { position 0; description "Bit 0 is unknown."; } bit bit-1 { position 1; description "Bit 1 is unknown."; } // .... bit bit-63 { position 63; description "Bit 63 is unknown."; } } } Perhaps some people prefer "bit-0 bit-1 bit-2 bit-3 bit-4 bit-5 bit-6 bit-7" over "ff". It seems rather subjective to debate which is easier for everybody to use. RFC 7950 is quite clear about MUST NOT change the bit position or bit identifier after a module is published. Andy > 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 netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
