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

[Michael Richardson]

This document is intended to be Informational.
One thing that I'd like the WG to consider is whether it should go straight
to Historical.  (There is precedent)

This document needs to go through IETF consensus in order to be able to
create the IANA registries that pcapng needs.

[ps: I hate the name "pcapng", and I'd love another name. I suggest pcap20]

--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide






signature.asc
Description: PGP signature
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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

[Guy Harris]

On Oct 4, 2021, at 1:00 PM, Henk Birkholz  
wrote:

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

There's one small change that should be made to clarify the format of the last 
field in the file header - it's a field that's in the byte order of the host 
that wrote it and that, when converted to the byte order of the host that's 
*reading* it, has the link-layer type in the lower 16 bits and other 
information in the upper 16 bits.  See

https://github.com/pcapng/pcapng/issues/106

(Michael Richardson filed it based on a private email to Michael and me).

I'd also like to ask Van Jacobson and Steve McCanne whether they'd like to be 
included as the first two authors, as they're the creator of the file format 
(it's undergone some small tweaks since then, such as adding the 
nanosecond-resolution format and the reinterpretation of the upper 16 bits of 
the link-layer type, but the credit goes to them) - and to ask if they have any 
comments on it.  (I don't know if they're on OPSAWG; if so, and you notice this 
message, please speak up.)

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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

[Michael Richardson]

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

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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

[Henk Birkholz]

Dear OPSAWG members,

this email *extends* the ongoing call for Working Group Adoption on 
https://datatracker.ietf.org/doc/html/draft-gharris-opsawg-pcap-02 until 
*Sunday, October 24th*.


We did not reach a critical mass of positive replies - as a result, I'll 
grant a grace period until the end of the week. If you are interested in 
this work, please reply with your support on this list until *Sunday, 
October 24th*.



For the OPSAWG co-chairs,

Henk

On 04.10.21 22:00, 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.

As a reminder, this I-D describes the current definition of the PCAP 
format that has been the industry's de-facto packet capture format since 
the 1980s.


Please reply with your support and especially any substantive comments 
you may have.



For the OPSAWG co-chairs,

Henk


___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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

[Carsten Bormann]

On 2021-10-20, at 22:22, Henk Birkholz  wrote:
> 
> this email *extends* the ongoing call for Working Group Adoption on 
> https://datatracker.ietf.org/doc/html/draft-gharris-opsawg-pcap-02 until 
> *Sunday, October 24th*.

I believe WG time spent to get an authoritative description of this widely used 
format published as an RFC, with some of the original players being involved, 
is time spent very well.
I advocate adoption of this draft.

Grüße, Carsten

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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

[Jürgen Schönwälder]

+1

/js

On Wed, Oct 20, 2021 at 10:44:37PM +0200, Carsten Bormann wrote:
> On 2021-10-20, at 22:22, Henk Birkholz  
> wrote:
> > 
> > this email *extends* the ongoing call for Working Group Adoption on 
> > https://datatracker.ietf.org/doc/html/draft-gharris-opsawg-pcap-02 until 
> > *Sunday, October 24th*.
> 
> I believe WG time spent to get an authoritative description of this widely 
> used format published as an RFC, with some of the original players being 
> involved, is time spent very well.
> I advocate adoption of this draft.
> 
> Grüße, Carsten
> 
> ___
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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

[Eliot Lear]

+1.

On 20.10.21 22:44, Carsten Bormann wrote:

On 2021-10-20, at 22:22, Henk Birkholz  wrote:

this email *extends* the ongoing call for Working Group Adoption on 
https://datatracker.ietf.org/doc/html/draft-gharris-opsawg-pcap-02 until 
*Sunday, October 24th*.

I believe WG time spent to get an authoritative description of this widely used 
format published as an RFC, with some of the original players being involved, 
is time spent very well.
I advocate adoption of this draft.

Grüße, Carsten

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg



OpenPGP_signature
Description: OpenPGP digital signature
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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

[Michael Richardson]

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_msdnORHMUY3kbyCV6dbGyI 
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?


___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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

[Carsten Bormann]

On 2021-10-25, at 18:27, Michael Richardson  wrote:
> 
> 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_msdnORHMUY3kbyCV6dbGyI 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?

Both (if we manage not to entangle them too much, one is a very different 
effort from the other).

Grüße, Carsten

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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

[Henk Birkholz]

Dear OPSAWG members,

this email concludes the call for Working Group Adoption on 
https://datatracker.ietf.org/doc/html/draft-gharris-opsawg-pcap-02.


We received a minimal amount of positive replies, no objections, and a 
few elaborate comments.


The chairs believe this I-D is ready for adoption and for the working 
group to work on. As the response was not overwhelming, I want to 
highlight that this is an extensive document that can only progress with 
sufficient review. Please bear in mind that some steady progress is 
required.


Authors, please rename the I-D to draft-ietf-opsawg-pcap-00, keeping the 
content as is, and resubmit.



For the OPSAWG co-chairs,

Henk

On 04.10.21 22:00, 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.

As a reminder, this I-D describes the current definition of the PCAP 
format that has been the industry's de-facto packet capture format since 
the 1980s.


Please reply with your support and especially any substantive comments 
you may have.



For the OPSAWG co-chairs,

Henk

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg


___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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

[Qin Wu]

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:mcr+i...@sandelman.ca] 
发送时间: 2021年10月26日 0:28
收件人: opsawg@ietf.org
抄送: l...@cisco.com; Toerless Eckert ; Qin Wu 
; Carsten Bormann ; 
j.schoenwael...@jacobs-university.de; vladi...@lightside-instruments.com; 
war...@kumari.net; ie...@btconnect.com; a...@research.att.com
主题: 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?

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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

[Carsten Bormann]

Hi Qin,

On 26. Oct 2021, at 03:43, Qin Wu  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

> 
> -Qin
> -邮件原件-
> 发件人: Michael Richardson [mailto:mcr+i...@sandelman.ca] 
> 发送时间: 2021年10月26日 0:28
> 收件人: opsawg@ietf.org
> 抄送: l...@cisco.com; Toerless Eckert ; Qin Wu 
> ; Carsten Bormann ; 
> j.schoenwael...@jacobs-university.de; vladi...@lightside-instruments.com; 
> war...@kumari.net; ie...@btconnect.com; a...@research.att.com
> 主题: 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?
> 

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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

[Guy Harris]

On Oct 25, 2021, at 11:34 PM, Carsten Bormann  wrote:

> 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.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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

[Carsten Bormann]

On 26. Oct 2021, at 09:00, Guy Harris  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.

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

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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

[Qin Wu]

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

Hi Qin,

On 26. Oct 2021, at 03:43, Qin Wu  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:mcr+i...@sandelman.ca]
> 发送时间: 2021年10月26日 0:28
> 收件人: opsawg@ietf.org
> 抄送: l...@cisco.com; Toerless Eckert ; Qin Wu 
> ; Carsten Bormann ; 
> j.schoenwael...@jacobs-university.de; 
> vladi...@lightside-instruments.com; war...@kumari.net; 
> ie...@btconnect.com; a...@research.att.com
> 主题: 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?
> 

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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

[Vladimir Vassilev]

On 25/10/2021 18.27, Michael Richardson wrote:

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_msdnORHMUY3kbyCV6dbGyI 
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?



I support both pcap and pcapng. My potential use-case is for the 
draft-vassilev-bmwg-network-interconnect-tester-07 where we might need 
alternative binary formats for reading the capture buffers in addition 
to the format specified with a YANG data model.


I am also in support of only doing minor editorial changes to the 
submitted documents during the IETF process. That said I do not think 
there is anything preventing the work group to semantically change the 
drafts once they are adopted. I just do not see a good reason for this.


/Vladimir


___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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

[Qin Wu]

-邮件原件-
发件人: Carsten Bormann [mailto:c...@tzi.org] 
发送时间: 2021年10月26日 15:18
收件人: Guy Harris 
抄送: Qin Wu ; opsawg@ietf.org
主题: Re: [OPSAWG] 🔔 WG Adoption Call for draft-gharris-opsawg-pcap-02

On 26. Oct 2021, at 09:00, Guy Harris  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.

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

[Qin] Good proposal, agree with this.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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

[Carsten Bormann]

> 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
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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

[Michael Richardson]

Qin Wu  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. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide






signature.asc
Description: PGP signature
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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

[Michael Richardson]

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

--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide






signature.asc
Description: PGP signature
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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

[Carsten Bormann]

On 26. Oct 2021, at 15:44, Michael Richardson  wrote:
> 
> That's being done by the pcap document.
> (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

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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

[Michael Richardson]

Carsten Bormann  wrote:
> Pcapng is a format different from pcap.
> 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. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide






signature.asc
Description: PGP signature
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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

[Michael Richardson]

<#secure method=pgpmime mode=sign>

Qin Wu  wrote:
cabo> One way to do this would be to jump-start the process by a short
cabo> document establishing this registry, with a defined registration
cabo> policy.

> [Qin] Good proposal, agree with this.

So the proposal, in order to avoid having to adopt pcap as an Information
document, is to adopt a third document, which is a subset of the current pcap
document.


--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide




___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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

[Michael Richardson]

Carsten Bormann  wrote:
>> That's being done by the pcap document.
>> (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.

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.

--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide






signature.asc
Description: PGP signature
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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

[Michael Richardson]

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.

--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide


signature.asc
Description: PGP signature
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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

[Carsten Bormann]

> On 26. Oct 2021, at 20:57, Michael Richardson  wrote:
> 
> 
> 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.

…
> LINKTYPE_USB_LINUX_MMAPPED220
>   USB packets, beginning with a Linux USB header, as specified by the
>   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.

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

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

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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

[Guy Harris]

On Oct 26, 2021, at 11:57 AM, Michael Richardson  wrote:

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

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".
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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

[Michael Richardson]

Carsten Bormann  wrote:
>> On 26. Oct 2021, at 20:57, Michael Richardson  
wrote:
>>
>>
>> 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.

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

> Whether that is a good registry entry is for the designated expert (DE)
> 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.

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

I don't see why.

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

--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide






signature.asc
Description: PGP signature
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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

[Carsten Bormann]

On 27. Oct 2021, at 23:06, Michael Richardson  wrote:
> 
> 
> Carsten Bormann  wrote:
>>> On 26. Oct 2021, at 20:57, Michael Richardson  wrote:
>>> 
>>> 
>>> 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.
> 
>> …
>>> 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
>> …
> 
>> Whether that is a good registry entry is for the designated expert (DE)
>> to decide, not for the IESG.
> 
> 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.

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

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

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

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

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg