> On Apr 14, 2023, at 10:55 AM, Jürgen Schönwälder > <[email protected]> wrote: > > On Fri, Apr 14, 2023 at 08:48:39AM -0400, Jeffrey Haas wrote: >> >> -- Jeff (who keeps expecting this conversation to devolve to a proposal for >> netconf streaming tcpdump) >> > > So let me help with that.
I should have avoided typing this. :-) > The allocation of unused bits is probably > the most basic protocol extension you can think of. So what do we do > if a protocol engine receives messages of unknown message type? To > expose the details of the unknown message, we indeed need a proposal > for streaming pcap data over netconf. And in case things are messed up > internally by the software, perhaps also an associated memory dump > protocol to aid with software debugging? A flavor of this is present in OSPF's modeling for its raw types. But in such cases, you're getting a full dump of the element. This isn't my use case. This is a known syntactically valid bit vector. There's no need for a full-packet dump as your first line of debugging. As a very new operator at a small tier-3 ISP, my first introduction to PDU decoding was turning on hexdump tracing for Livingston Portmaster CHAP and ISDN sessions. I have no desire for this to be the default way we push people to model their debugging experiences for data that is largely known. When things have truly gone to hell, raw packets are helpful. Perhaps a different effort for enabling exception debugging is a worthy netconf extension. -- Jeff _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
