However, the use case is covered by two points: 1. Don't emit the "unknown" node when you know everything. 2. Encodings that make you "hunt for the bit" are a PITA. If bit-31 is the only new one in a 32-bit vector, you have to know that's the thing to look for if it's in any format other than bits. xx-yy-zz-q1 - we care about the 1 here and have to "know" to ignore xx-yy-zz-q.
Never mind that my actual example comes from an RFC where the bit vector is a nybble and hex-string requires a full octet of representation. -- Jeff > On Apr 17, 2023, at 9:40 AM, Jason Sterne (Nokia) <[email protected]> > wrote: > > That could be one approach, but note that the final step (your last sentence) > would still be NBC. > > From: Rob Wilton (rwilton) <[email protected]> > Sent: Monday, April 17, 2023 9:36 AM > To: Jason Sterne (Nokia) <[email protected]>; Italo Busi > <[email protected]>; Jeffrey Haas <[email protected]> > Cc: [email protected] > Subject: RE: [netmod] Unknown bits - backwards compatibility > > > CAUTION: This is an external email. Please be very careful when clicking > links or opening attachments. See the URL nok.it/ext for additional > information. > > > Hi Jason, > > Yes, I was thinking that you would always return the raw value and the bits > encoded value, but perhaps a server could optionally elide the raw value when > it knows that it can be fully represented by the bits value. > > Regards, > Rob > > > > From: Jason Sterne (Nokia) <[email protected] > <mailto:[email protected]>> > Sent: 17 April 2023 14:05 > To: Rob Wilton (rwilton) <[email protected] <mailto:[email protected]>>; > Italo Busi <[email protected] <mailto:[email protected]>>; Jeffrey > Haas <[email protected] <mailto:[email protected]>> > Cc: [email protected] <mailto:[email protected]> > Subject: RE: [netmod] Unknown bits - backwards compatibility > > Rob & Italo – are you proposing that the “raw-bits” are all always returned > (whether they are known or not)? > Jason > > From: netmod <[email protected] <mailto:[email protected]>> On > Behalf Of Rob Wilton (rwilton) > Sent: Monday, April 17, 2023 7:43 AM > To: Italo Busi <[email protected] > <mailto:[email protected]>>; Jeffrey Haas > <[email protected] <mailto:[email protected]>> > Cc: [email protected] <mailto:[email protected]> > Subject: Re: [netmod] Unknown bits - backwards compatibility > > > CAUTION: This is an external email. Please be very careful when clicking > links or opening attachments. See the URL nok.it/ext for additional > information. > > > 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 <[email protected] <mailto:[email protected]>> On > Behalf Of Italo Busi > Sent: 14 April 2023 15:33 > To: Jeffrey Haas <[email protected] <mailto:[email protected]>> > Cc: [email protected] <mailto:[email protected]> > 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 <[email protected] <mailto:[email protected]>> > Sent: venerdì 14 aprile 2023 14:49 > To: Italo Busi <[email protected] <mailto:[email protected]>> > Cc: Jason Sterne (Nokia) <[email protected] > <mailto:[email protected]>>; [email protected] <mailto:[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
