I read the rest of the thread. I'll have to come back to figure out if there is still any todo left. I think that I expanded PCAP in the abstract in the source on my desk. I'll get it posted before Monday's deadline; maybe today if I can.
Guy Harris <[email protected]> wrote: >> 2) The registry is missing the Change Controller column and filing that is a >> bit tricky. I believe none of the initial allocations have the IETF as the >> change controller since it comes from the tcpdump/pcap open source code. As >> such, perhaps that open source project (or the lead developer/maintainer(s) for >> it) should become the Change Controllers? > I think the intent of both of the authors is that said authors be the > Change Controllers; I can authoritatively state that's true for one of > those authors, but I'll leave it for Michael Richardson to give an > authoritative statement for the other, and to indicate whether other > tcpdump/libpcap developers should be included as Change Controllers if > they wish. I'm one of the original instigator for The TCPDUMP Group project... back in ~1997ish. Denis O now leads it. We "took over" from Van Jacobson, et al. I had patches and no place to send them. (Many IETF frequent flyers have been involved over the decades. See CREDITs..) Having Guy and I as the change controllers is appropriate. > For the "no description yet written": > Some are for link-layer types that were requested, without a > specification and with an indication that they were for internal use, > and without any known code that generates them or dissects them, and > were granted a value, such as the LINKTYPE_IBM_* values; perhaps those > values should be added to additional ranges of "reserved and will never > be assigned" values. Well, knowing to/for whom it was allocated might be useful. Some random pcap file with that type, and then someone remembers that IBM branded network analyzer sitting in a closet since 2004. >> "When the contents of the link type can contain an IPv4 or IPv6 header, then >> the octets between the beginning of the link type and the IP header needs to be >> clear." > I *think* the idea is that, *if* you can encapsulate IPv4 or IPv6 > packet in that link type, the specification should describe everything > from the beginning of the packet to the IP header", i.e. "don't leave > anything out". > I'm not sure what the purpose of that is. Michael? If the description tells you how to get to the beginning of layer-3, then it's all RFCs that point on. Many link types encapsulate something ethernet-like, so that's also enough. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] [email protected] http://www.sandelman.ca/ | ruby on rails [ -- Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
