Here is an example of a LINKTYPE that would be very difficult to explain if it weren't in the context of a pcap/pcapng file.
If this goes into a new document, then would it have a normative?
informative? reference to... pcap and pcapng?
I was assuming that pcap and pcapng would wind up with normative references
to each other, and wind up going through the RFC editor queue together.
Maybe we can eliminate all of the pcap->pcapng normative references.
LINKTYPE_USB_LINUX_MMAPPED 220
USB packets, beginning with a Linux USB header, as specified by the
struct usbmon_packet in the Documentation/usb/usbmon.txt file in the
Linux source tree. All 64 bytes of the header are present. All fields
in the header are in host byte order. When performing a live capture,
the host byte order is the byte order of the machine on which the
packets are captured. When READING A PCAP FILE, the byte order is the
byte order for THE FILE, as specified by the FILE'S MAGIC NUMBER;
when reading a pcapng file, the byte order is the byte order for the
section of the pcapng file, as specified by the Section Header
Block. For isochronous transfers, the ndesc field specifies the
number of isochronous descriptors that follow.
--
Michael Richardson <mcr+i...@sandelman.ca> . o O ( IPv6 IΓΈT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
