Re: [Wireshark-dev] [tcpdump-workers] New RFCs for 1) pcap file format and 2) rpcapd protocol?
Guy Harris via tcpdump-workers wrote: > It's complex, too - and I don't know whether anybody's done a CMake > version of that. > Would it make more sense to put the rpcap I-D into either 1) a separate > team and repository or 2) another repository in the pcapng group, so > that it has its own Makefile? That's my preference. One draft per repo. If you like, make those repo(s) submodules of libpcap if one wants a stronger connection between the documents and the code. signature.asc Description: PGP signature ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] [tcpdump-workers] New RFCs for 1) pcap file format and 2) rpcapd protocol?
Guy Harris via tcpdump-workers wrote: >> >>> 5) Treat rpcap as "remote procedure call for libpcap" and put it under the the-tcpdump-group team, and put pcap under the pcapng team as per the same reason as 4). >> >> Ok. > This would require the rules in the pcapng repository Makefile to be in > the libpcap Makefile.in. > Michael, would that be inconvenient to maintain? Yes, I think it would be a pain, but it could be done. I certainly would not use the complex lib/* makefile if we really wanted to do that. What about cmake side of things? signature.asc Description: PGP signature ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] [tcpdump-workers] New RFCs for 1) pcap file format and 2) rpcapd protocol?
On Apr 1, 2020, at 11:51 AM, Michael Richardson wrote: > Guy Harris via tcpdump-workers wrote: >>> 5) Treat rpcap as "remote procedure call for libpcap" and put it under the the-tcpdump-group team, and put pcap under the pcapng team as per the same reason as 4). >>> >>> Ok. > >> This would require the rules in the pcapng repository Makefile to be in >> the libpcap Makefile.in. > >> Michael, would that be inconvenient to maintain? > > Yes, I think it would be a pain, but it could be done. > I certainly would not use the complex lib/* makefile if we really wanted to > do that. What about cmake side of things? It's complex, too - and I don't know whether anybody's done a CMake version of that. Would it make more sense to put the rpcap I-D into either 1) a separate team and repository or 2) another repository in the pcapng group, so that it has its own Makefile? ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] [tcpdump-workers] New RFCs for 1) pcap file format and 2) rpcapd protocol?
On Mar 22, 2020, at 11:40 AM, Francois-Xavier Le Bail wrote: > On 22/03/2020 18:29, Guy Harris via tcpdump-workers wrote: > >> 5) Treat rpcap as "remote procedure call for libpcap" and put it under the >> the-tcpdump-group team, and put pcap under the pcapng team as per the same >> reason as 4). > > Ok. This would require the rules in the pcapng repository Makefile to be in the libpcap Makefile.in. Michael, would that be inconvenient to maintain? ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] [tcpdump-workers] New RFCs for 1) pcap file format and 2) rpcapd protocol?
On Mar 26, 2020, at 7:10 PM, Guy Harris via tcpdump-workers wrote: > (Note that its purpose is to document the *existing* format, rather than be a > source of proposed changes.) ...proposed changes to the format. I am, however, planning on proposing a mechanism for vendor-specific "custom" link-layer types, inspired by the pcapng "custom" block types and option types, for use in both pcap and pcapng. That'll be in a separate message. As with pcapng block types and options, anything of *general* use that a vendor would like multiple programs to be able to handle should probably be proposed as a part of the standard, with a register link-layer type/block number/option number. ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] [tcpdump-workers] New RFCs for 1) pcap file format and 2) rpcapd protocol?
On Mar 22, 2020, at 10:29 AM, Guy Harris via tcpdump-workers wrote: > 5) ... and put pcap under the pcapng team as per the same reason as 4). Done. It's pointed to by https://github.com/pcapng/pcapng and the XML source is at https://github.com/pcapng/pcapng/blob/master/draft-gharris-opsawg-pcap.xml Feel free to comment, add additional authors, etc.. (Note that its purpose is to document the *existing* format, rather than be a source of proposed changes.) ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] [tcpdump-workers] New RFCs for 1) pcap file format and 2) rpcapd protocol?
Michael Tuexen via tcpdump-workers wrote: >> Guy Harris via tcpdump-workers wrote: >>> Currently, on GitHub, there's a "pcapng" team: >>> https://github.com/pcapng >> >>> with one repository containing the pcapng specification, and a "the-tcpdump-group" team: >> >>> https://github.com/the-tcpdump-group >>> with repositories for libpcap, tcpdump, and the tcpdump.org Web site. >> >>> It makes sense to me to keep those specifications on a site such as >>> GitHub; GitHub comes to mind first because that's where pcapng >>> currently is. >> >>> 1) add them as repositories to the pcapng team; >> >>> 1) has the slight disadvantage that the name for the team suggests it's >>> for pcapng only; it appears that teams can be renamed: >> >> ... >> >>> Were we to rename it, I don't know what would be a good new name. >> >> I'm good with pcapng, because I also have no other suggestion. >> I would like to restart the opsawg work on an IETF specification for >> this. > I would support this. However, last time I tried this, I was not successful. > There were not very interested in defining a file format... > Maybe things have changed, but I don't know. I know that you worked hard, and it didn't happen. It is on my agenda to make this happen, and I'll hope that I can depend upon your help. With IETF107 going virtual, I will see if opsawg has time consider the document again. I will look at reposting it today. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works|IoT architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] [tcpdump-workers] New RFCs for 1) pcap file format and 2) rpcapd protocol?
On 22/03/2020 18:29, Guy Harris via tcpdump-workers wrote: > 5) Treat rpcap as "remote procedure call for libpcap" and put it under the > the-tcpdump-group team, and put pcap under the pcapng team as per the same > reason as 4). Ok. ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] [tcpdump-workers] New RFCs for 1) pcap file format and 2) rpcapd protocol?
On Mar 21, 2020, at 2:38 PM, Guy Harris via tcpdump-workers wrote: > On Mar 21, 2020, at 2:14 PM, Guy Harris via tcpdump-workers > wrote: > >> The options I see are: > > 4) add a new team for rpcap, as it's a protocol rather than a file format, > and thus only indirectly tied to pcap/pcapng, and putting the pcap format in > the pcapng team because you can't have a pcap*ng* without having had a pcap > in the first place. 5) Treat rpcap as "remote procedure call for libpcap" and put it under the the-tcpdump-group team, and put pcap under the pcapng team as per the same reason as 4). ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] [tcpdump-workers] New RFCs for 1) pcap file format and 2) rpcapd protocol?
On Mar 22, 2020, at 9:49 AM, Michael Tuexen wrote: > I would support this. However, last time I tried this, I was not successful. > There were not very interested in defining a file format... They've done so in the past: https://tools.ietf.org/html/rfc1761 (and https://tools.ietf.org/html/rfc3827) and, for non-capture-file formats: https://tools.ietf.org/html/rfc8536#section-3 ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] [tcpdump-workers] New RFCs for 1) pcap file format and 2) rpcapd protocol?
> On 21. Mar 2020, at 23:10, Michael Richardson wrote: > > > Guy Harris via tcpdump-workers wrote: >> Currently, on GitHub, there's a "pcapng" team: >> https://github.com/pcapng > >> with one repository containing the pcapng specification, and a >> "the-tcpdump-group" team: > >> https://github.com/the-tcpdump-group >> with repositories for libpcap, tcpdump, and the tcpdump.org Web site. > >> It makes sense to me to keep those specifications on a site such as >> GitHub; GitHub comes to mind first because that's where pcapng >> currently is. > >> 1) add them as repositories to the pcapng team; > >> 1) has the slight disadvantage that the name for the team suggests it's >> for pcapng only; it appears that teams can be renamed: > > ... > >> Were we to rename it, I don't know what would be a good new name. > > I'm good with pcapng, because I also have no other suggestion. > I would like to restart the opsawg work on an IETF specification for this. I would support this. However, last time I tried this, I was not successful. There were not very interested in defining a file format... Maybe things have changed, but I don't know. Best regards Michael > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > ___ > Sent via:Wireshark-dev mailing list > Archives:https://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev > mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] [tcpdump-workers] New RFCs for 1) pcap file format and 2) rpcapd protocol?
Guy Harris via tcpdump-workers wrote: > Currently, on GitHub, there's a "pcapng" team: > https://github.com/pcapng > with one repository containing the pcapng specification, and a "the-tcpdump-group" team: > https://github.com/the-tcpdump-group > with repositories for libpcap, tcpdump, and the tcpdump.org Web site. > It makes sense to me to keep those specifications on a site such as > GitHub; GitHub comes to mind first because that's where pcapng > currently is. > 1) add them as repositories to the pcapng team; > 1) has the slight disadvantage that the name for the team suggests it's > for pcapng only; it appears that teams can be renamed: ... > Were we to rename it, I don't know what would be a good new name. I'm good with pcapng, because I also have no other suggestion. I would like to restart the opsawg work on an IETF specification for this. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] [tcpdump-workers] New RFCs for 1) pcap file format and 2) rpcapd protocol?
On 21/03/2020 22:14, Guy Harris via tcpdump-workers wrote: > 1) has the slight disadvantage that the name for the team suggests it's for > pcapng only; it appears that teams can be renamed: > > > https://help.github.com/en/github/setting-up-and-managing-organizations-and-teams/renaming-a-team > > Were we to rename it, I don't know what would be a good new name. Option 1) with a rename to pcapteam or pcapXteam? ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] [tcpdump-workers] New RFCs for 1) pcap file format and 2) rpcapd protocol?
El sáb., 21 mar. 2020 18:15, Guy Harris via tcpdump-workers < tcpdump-work...@lists.tcpdump.org> escribió: > 1) has the slight disadvantage that the name for the team suggests it's > for pcapng only; it appears that teams can be renamed: > > > https://help.github.com/en/github/setting-up-and-managing-organizations-and-teams/renaming-a-team > > Were we to rename it, I don't know what would be a good new name. > I'd be careful with this option, as it may affect downstream projects, as some download links that may be used for automated download (as part of a build process) could break. If there's anything downloadable I wouldn't change the team's name unless we make sure the old links remain accessible. ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] [tcpdump-workers] New RFCs for 1) pcap file format and 2) rpcapd protocol?
On Mar 21, 2020, at 2:14 PM, Guy Harris via tcpdump-workers wrote: > The options I see are: 4) add a new team for rpcap, as it's a protocol rather than a file format, and thus only indirectly tied to pcap/pcapng, and putting the pcap format in the pcapng team because you can't have a pcap*ng* without having had a pcap in the first place. ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] [tcpdump-workers] New RFCs for 1) pcap file format and 2) rpcapd protocol?
On Mar 21, 2020, at 2:31 PM, Mario Rugiero via tcpdump-workers wrote: > El sáb., 21 mar. 2020 18:15, Guy Harris via tcpdump-workers > escribió: > >> 1) has the slight disadvantage that the name for the team suggests it's >> for pcapng only; it appears that teams can be renamed: >> >> >> https://help.github.com/en/github/setting-up-and-managing-organizations-and-teams/renaming-a-team >> >> Were we to rename it, I don't know what would be a good new name. >> > I'd be careful with this option, as it may affect downstream projects, as > some download links that may be used for automated download (as part of a > build process) could break. If there's anything downloadable I wouldn't > change the team's name unless we make sure the old links remain accessible. Its one repository contains the pcapng spec, no source code, so that particular example probably less likely to happen than would be the case for other teams. But what it would break are links to the pcapng spec on other pages. Perhaps changing the *description* of the team would suffice. ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
