Subject: Re: [OPSAWG] 🔔 WG Adoption Call for draft-gharris-opsawg-pcap-02

From: Qin Wu <[email-masked]>
Date: Tue, 26 Oct 2021 09:00:07 +0000

-----邮件原件-----
发件人: Carsten Bormann [mailto:[email-masked]] 
发送时间: 2021年10月26日 14:35
收件人: Qin Wu <[email-masked]>
抄送: [email-masked]
主题: Re: [OPSAWG] 🔔 WG Adoption Call for draft-gharris-opsawg-pcap-02

Hi Qin,

On 26. Oct 2021, at 03:43, Qin Wu <[email-masked]> wrote:
> 
> I am not against this draft. I am just thinking whether Independent 
> submission stream process is a better choice for this document

I’m not sure which “this document” you are discussing here, as Michael asked about both pcap and pcapng.
Let’s assume you are talking about pcap.

[Qin Wu] Yes and no, related to both, I think.

> in the first round when WG and IESG have no change control to this work.

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.

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.
That is why I feel Independent stream process is a better choice, but I also realized that Independent stream process doesn't provide IETF registry for new link type or new media type.
That is the tricking point.

Yes, WG process provides benefit for wide review, I am wondering what technical content change we can make for this document? 
I feel what we can do is cosmetic change. In addition what Directorate in each area can do about it? Maybe genart review has no issues.

> Upon this work get published as RFC (https://www.rfc-editor.org/about/independent/), bisdocument can go through WG submission process, if my understanding is correct.

No document here has to wait for any other document to be published.

[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

> 
> -Qin
> -----邮件原件-----
> 发件人: Michael Richardson [mailto:[email-masked]]
> 发送时间: 2021年10月26日 0:28
> 收件人: [email-masked]
> 抄送: [email-masked]; Toerless Eckert <[email-masked]>; Qin Wu 
> <[email-masked]>; Carsten Bormann <[email-masked]>; 
> [email-masked]; 
> [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> 主题: Re: [OPSAWG] 🔔 WG Adoption Call for draft-gharris-opsawg-pcap-02
> 
> On 2021-10-20 12:40 p.m., Michael Richardson wrote:
>> On 2021-10-04 4:00 p.m., Henk Birkholz wrote:
>>> Dear OPSAWG members,
>>> 
>>> this starts a call for Working Group Adoption of
>>> 
>>>> https://datatracker.ietf.org/doc/html/draft-gharris-opsawg-pcap-02
>>> 
>>> ending on Monday, October 18th.
>> 
>> https://mailarchive.ietf.org/arch/msg/opsawg/4Cvm_msdnORHMUY3kbyCV6db
>> G yI is a very long thread about adoption from November 2020.
>> 
>> There were many suggestions at the time from many people on the CC.
>> 
>> It would be great if you could comment on the current plan.
>> 
> 
> A number of you spoke up last week about pcapng in this thread.
> Can you clarify if your support was for the pcapng only document, or for both pcap and pcapng?
>

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 26 Oct 2021 11:30:48 +0200

> 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.

> 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.

> I think JSON document evolvement (RFC4627,RFC7158,RFC8259) is the right process for such kind of work. The cost is the time for iteration.

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

---

From: Michael Richardson <[email-masked]>
Date: Tue, 26 Oct 2021 09:57:44 -0400

> It’s a bit like IPv4 and IPv6.

And like IPv4 and IPv6, which happen to share TCP and UDP and therefore a
port number registry... pcap and pcapng share a linktype registry.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide