On Fri, Apr 14, 2023 at 7:33 AM Italo Busi <Italo.Busi= 40huawei....@dmarc.ietf.org> wrote:
> 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) > > > Maybe because hexdump is over 20X more efficient on the wire than the bits proposal. Or that a special custom typedef is not needed for every leaf to represent the bit names. Or that an extra bit-name to bit-position lookup is not required. The bits type is intended for permanent bit assignments, where there is semantics associated with each bit (other than an unknown bit N set). It is not meant for temporary assignments that change the identifier over time. It is possible to change the status of a bit to "obsolete", which seems to be sufficient for the unknown-bits use-case. 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 > Andy > > > *From:* Jeffrey Haas <jh...@pfrc.org> > *Sent:* venerdì 14 aprile 2023 14:49 > *To:* Italo Busi <italo.b...@huawei.com> > *Cc:* Jason Sterne (Nokia) <jason.ste...@nokia.com>; 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> 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 >
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
