Re: New RFCs for 1) pcap file format and 2) rpcapd protocol?

[Eliot Lear <lear () ofcourseimright com>]

This very much depends on how stable you wish the spec to be.  If you
want to to be entirely osified, I recommend actual RFCs.  Otherwise,
perhaps a renamed team like "pcap-format" (or whatever the people on the
team want to call it)?

Eliot

On 21.03.20 22:15, Guy Harris wrote:
> There should probably be RFC-style specifications for 1) the pcap file format and 2) the rpcapd protocol used for 
> remote capturing.
>
> 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.
>
> The options I see are:
>
>       1) add them as repositories to the pcapng team;
>
>       2) add them as repositories to the the-tcpdump-group team;
>
>       3) give them each their own teams.
>
> I see pcapng - and the pcap file format and rpcapd protocol - as not being directly tied to libpcap.  *Historically*, 
> pcap originated as the format that libpcap read and wrote, and rpcap was a protocol initially implemented in the 
> WinPcap derivative of libpcap, but:
>
>       1) pcapng arose independently, and one of the earliest implementations was in Wireshark (where the internal 
> APIs were easier to change; libpcap's support currently works through the existing API, but that hides a lot of the 
> capabilities of pcapng);
>
>       2) code other than libpcap code reads and writes pcap files (including, but not limited to, Wireshark's code);
>
>       3) some devices either implement an rpcap server or could perhaps usefully do so, and they might have reasons 
> to have independent implementations rather than basing their implementations on libpcap's rpcapd.
>
> So I'm not inclined to go with option 2) - and if we do go with option 2), whatever arguments are offered for that 
> would probably apply to pcapng as well, so it would, in that case, make sense to move the pcapng repository to that 
> team as well.
>
> 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.
> ___________________________________________________________________________
> Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
> Archives:    https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>              mailto:wireshark-dev-request () wireshark org?subject=unsubscribe

Attachment: signature.asc
Description: OpenPGP digital signature

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe