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

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

I am not against this draft. I am just thinking whether Independent submission stream process is a better choice for this document in the first round when WG and IESG have no change control to this work.
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.

-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_msdnORHMUY3kbyCV6dbG
> 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 08:34:56 +0200

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.

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

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.

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

Grüße, Carsten

---

From: Guy Harris <[email-masked]>
Date: Tue, 26 Oct 2021 00:00:26 -0700

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

Currently:

	draft-gharris-opsawg-pcap-02 contains its own list of values for the LinkType field in the file header;

	draft-tuexen-opsawg-pcapng-02 points to https://www.tcpdump.org/linktypes.html for the LinkTYpe field in the Interface Description Block.

Note that those two sets must be *the exact same sets*, so, by the time these become RFCs, either one should point to the other, or both should point to a common location, such as an IETF registry.

If we go for "one should point to the other", e.g. the pcapng spec points to the pcap spec, then the one that is pointed to must be published first.

If we go for "both should point to a common location", the common location must be established first; if that involves publishing a spec that lists the LINKTYPE_ values, e.g. by extracting that list from the pcap spec and putting it into a separate spec, and having the registry point to that spec, the same way that the registry for Snoop link types:

	https://www.iana.org/assignments/snoop-datalink-types/snoop-datalink-types.xhtml#snoop-datalink-types-2

points to one or more RFCs for various link-layer types, then the initial spec with the link-layer types would have to be published at the same time as, or before, the pcap and pcapng specs are published.

I would vote for "both should point to a common location" so that neither the pcap nor the pcapng spec says "there is *the* list of link-layer types" - it points to a registry, and as more types are added to the registry, more specs can be published define them.

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 26 Oct 2021 09:17:50 +0200

> I would vote for "both should point to a common location" so that neither the pcap nor the pcapng spec says "there is *the* list of link-layer types" - it points to a registry, and as more types ar…

Indeed, and running such a registry is exactly what IANA is good at.

One way to do this would be to jump-start the process by a short document establishing this registry, with a defined registration policy.
(We’d probably need to be able to point out candidates for the designated experts that will implement this policy to make this approach palatable to IESG.)

This registry could (and should) be established before the two main documents are completed, as the protocols that use the registry are in use and could immediately benefit from the existence of the registry.

Grüße, Carsten

---

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

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 in the
    > first round when WG and IESG have no change control to this work.  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.

The ISE stream is not permitted to create the pcap link_type registry that we
need, with the desired IANA Considerations.

See https://www.ietf.org/archive/id/draft-gharris-opsawg-pcap-02.html#name-linktype-registry

We had this conversation a year ago, I think.

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

---

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

Guy Harris <[email-masked]> wrote:
    > I would vote for "both should point to a common location" so that
    > neither the pcap nor the pcapng spec says "there is *the* list of
    > link-layer types" - it points to a registry, and as more types are
    > added to the registry, more specs can be published define them.

That "common location" has to be created.
That's being done by the pcap document.
(It could be done by a third document, but that seems wasteful)

Pcapng would never have to point to pcap: it would always point at the IANA
registry.  It does have to wait for the registry to exist.

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 26 Oct 2021 15:49:07 +0200

> (It could be done by a third document, but that seems wasteful)

It seems appropriate to have a third document.
I don’t see the waste, only process improvement.

Grüße, Carsten

---

From: Michael Richardson <[email-masked]>
Date: Tue, 26 Oct 2021 13:46:01 -0400

> I don’t see the waste, only process improvement.

I'm not convinced that the IESG review of the document won't take months.
But, if the WG would like to go that way, I will prepare the document.

---

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

Here is an example of a LINKTYPE that would be very difficult to explain if
it weren't in the context of a pcap/pcapng file.

If this goes into a new document, then would it have a normative?
informative? reference to... pcap and pcapng?

I was assuming that pcap and pcapng would wind up with normative references
to each other, and wind up going through the RFC editor queue together.

Maybe we can eliminate all of the pcap->pcapng normative references.

LINKTYPE_USB_LINUX_MMAPPED	220
	USB packets, beginning with a Linux USB header, as specified by the
	struct usbmon_packet in the Documentation/usb/usbmon.txt file in the
	Linux source tree. All 64 bytes of the header are present. All fields
	in the header are in host byte order. When performing a live capture,
	the host byte order is the byte order of the machine on which the
	packets are captured. When READING A PCAP FILE, the byte order is the
	byte order for THE FILE, as specified by the FILE'S MAGIC NUMBER;
	when reading a pcapng file, the byte order is the byte order for the
	section of the pcapng file, as specified by the Section Header
	Block. For isochronous transfers, the ndesc field specifies the
	number of isochronous descriptors that follow.

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 26 Oct 2021 23:14:20 +0200

> On 26. Oct 2021, at 20:57, Michael Richardson <[email-masked]> wrote:
> 
> 

…
> 	struct usbmon_packet in the Documentation/usb/usbmon.txt file in the
…

Whether that is a good registry entry is for the designated expert (DE) to decide, not for the IESG.

The third document would establish the registry and maybe provide a few entries so the IESG has some examples to look at.

Loading that registry is then done via IANA and the DE.
If the policy is “specification required”, the existing I-D + a filled in web form at iana.org may be all that is needed to do that.

> to each other, and wind up going through the RFC editor queue together.

I hope we can avoid that.

> Maybe we can eliminate all of the pcap->pcapng normative references.

Yes, please!

(Having a normative reference to a HISTORIC document is a bit weird, anyway.)

Grüße, Carsten

---

From: Guy Harris <[email-masked]>
Date: Tue, 26 Oct 2021 15:12:52 -0700

> 	number of isochronous descriptors that follow.

So, currently, the pcap file refers to pcapng.

Perhaps the link-layer-types spec should, at the beginning, say something such as

	Some link-layer types contain data written in "host byte order".  The specifications for file formats using these link-layer types indicates how the host byte order for the portion of a file in which a packet is written is determined.

so that it can cover pcap, pcapng, and any other formats that might in the future, use these link-layer types.

Then the pcap and pcapng specs should indicate that the byte order of the framing data (such as record lengths, link-layer type values, etc.) is also used for packets where the link-layer type includes data in "host byte order".

---

From: Michael Richardson <[email-masked]>
Date: Wed, 27 Oct 2021 17:06:24 -0400

> to decide, not for the IESG.

The document in question would have to establish the history of the entries.
The IESG will ask questions about this part.  It will happen.

    > The third document would establish the registry and maybe provide a few
    > entries so the IESG has some examples to look at.

Not a few entries, all of the history of them.

    > Loading that registry is then done via IANA and the DE.

No, that's now how it's worked in the past, and now what IANA told me.

    > (Having a normative reference to a HISTORIC document is a bit weird, anyway.)

I don't see why.

anyway, if the WG wants to go this way, then I'd ask the chairs to judge.

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 28 Oct 2021 02:02:00 +0200

> The document in question would have to establish the history of the entries.

Why are you saying this?
(Maybe I don’t parse this right.)

> The IESG will ask questions about this part.  It will happen.

Sure, I’ve seen the IESG ask questions before.
I think they will be quite sympathetic that we are doing most of the entries outside of IETF consensus to reduce their workload.

> Not a few entries, all of the history of them.

What I’m trying to say is that this doesn’t have to be done in the IETF consensus document.

> No, that's now how it's worked in the past, and now what IANA told me.

Can’t parse.  Which of the “now” are “not” maybe?

The way I have proposed is exactly how a registry is run.

Grüße, Carsten