> I have no idea what a second round would be. > The pcap format needs to be published only once. > > [Qin Wu] My impression is that pcap will be the first and pcapng will derive > from it. Maybe I am wrong, I am not clear > the relation between these two.
These are independent formats that need independent documentation. No need for a sequence in publishing; both exist are are widely used. > The pcap document *could* be an independent submission. > However, the document will benefit from wide review, as it is documenting > widely spread practice, which makes the WG process more useful. > > > [Qin Wu] Just to clarify that my comment is more related to process for > publication of this work, not aim at technical content. > If this document doesn't change the control from "The Tcpdump Group" to IETF > or IESG or individual person, I feel we follow the wrong IETF registry > template. > This comment is applied to both section 8.1 and 8.2. Now you are discussing the media type registration for pcap (Section 8.1). The pcap format is only being documented, I donβt see a need to transfer control. Pcapng doesnβt seem to register a media-type name, which appears to be an omission. We can fix that in the WG process. > [Qin Wu] I thought pcapng will be progressed after pcap draft and is > replacement to pcap. Still we need to clarify the relation between two > documents. > I think JSON document evolvement (RFC4627,RFC7158,RFC8259) is the right > process for such kind of work. The cost is the time for iteration. > GrΓΌΓe, Carsten JSON is a single format that went through three RFCs just improving the description. Pcapng is a format different from pcap. Itβs a bit like IPv4 and IPv6. No need to wait with publishing IPv6 for IPv4 to be published (well, it happened that way, but that is not a consideration here). GrΓΌΓe, Carsten _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
