search

IETF-OPSAWG-WG / draft-ietf-opsawg-pcap

PCAP next generation file format specification
Other
264 stars 59 forks source link

Possible cleanup #100

Closed tuexen closed 3 years ago

tuexen commented 3 years ago

I think this makes the text clearer. But I'm not sure if it is a way to go.

mcr commented 3 years ago

Guy Harris notifications@github.com wrote:

Alternatively, we could do

  • values from 0 to 32767, except for values from 147 to 162, are marked as Specification Required;
  • values from 32768 to 65000 are marked as First-Come First-Served;
  • values from 147 to 162, and from 65000 to 65535 are marked as Private Use.

This is much clearer. I'll use that.

mcr commented 3 years ago

Guy Harris notifications@github.com wrote:

@@ -295,6 +291,8 @@ DLT values are associated with specific operation system captures, and are opera |LINKTYPE_SCCP|142|SS7 Control Part, ITU-T Q.711/Q.712/Q.713/Q.714 |LINKTYPE_DOCSIS|143|DOCSIS MAC frames, DOCSIS 3.1 |LINKTYPE_LINUX_IRDA|144|Linux-IrDA packets w/LINKTYPE_LINUX_IRDA header +|LINKTYPE_PRIVATE_USE_1|147|For private use

There aren't 2 private use values, there are 16 private use values, 147 to 162, so they'd be LINKTYPE_PRIVATE_USE_1 (LINKTYPE_USER1) through LINKTYPE_PRIVATE_USE_16 (LINKTYPE_USER16).

The last revision does not list that entry at all. I felt that giving away ~500 at the end of the range should accomodate pretty much all sorts of experiments. If we ever get close (at ~10/year it would be a long time), then the 65535+PEN thing should work great. In PCAPNG, we could also just have a new packet header.

-- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [

guyharris commented 3 years ago

This is much clearer. I'll use that.

Or

tuexen commented 3 years ago

On 23. Dec 2020, at 01:54, Michael Richardson notifications@github.com wrote:

Guy Harris notifications@github.com wrote:

Alternatively, we could do

  • values from 0 to 32767, except for values from 147 to 162, are marked as Specification Required;
  • values from 32768 to 65000 are marked as First-Come First-Served;
  • values from 147 to 162, and from 65000 to 65535 are marked as Private Use.

This is much clearer. I'll use that. I would vote for just putting 147 to 162 in the initial allocation table and have only the first two rules. That means that IANA has only to deal with two ranges.

Best regards Michael

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

mcr commented 3 years ago

Michael Tüxen notifications@github.com wrote:

Guy Harris notifications@github.com wrote:

Alternatively, we could do

  • values from 0 to 32767, except for values from 147 to 162, are marked as Specification Required;
  • values from 32768 to 65000 are marked as First-Come First-Served;
  • values from 147 to 162, and from 65000 to 65535 are marked as Private Use.

This is much clearer. I'll use that. I would vote for just putting 147 to 162 in the initial allocation table and have only the first two rules. That means that IANA has only to deal with two ranges.

I don't have a strong opinion about table vs not, or the "except..." text. I wanted to list 147->162 this way so that people reading would see what choices they have.

-- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [

tuexen commented 3 years ago

On 23. Dec 2020, at 14:26, Michael Richardson notifications@github.com wrote:

Michael Tüxen notifications@github.com wrote:

Guy Harris notifications@github.com wrote:

Alternatively, we could do

  • values from 0 to 32767, except for values from 147 to 162, are marked as Specification Required;
  • values from 32768 to 65000 are marked as First-Come First-Served;
  • values from 147 to 162, and from 65000 to 65535 are marked as Private Use.

This is much clearer. I'll use that. I would vote for just putting 147 to 162 in the initial allocation table and have only the first two rules. That means that IANA has only to deal with two ranges.

I don't have a strong opinion about table vs not, or the "except..." text. I wanted to list 147->162 this way so that people reading would see what choices they have. If I would be a developer looking for a number I can take, I would scroll through header files to find something for private use. Maybe look at the table available from IANA, but not in the IANA section.

So I would suggest:

I you want to draw the attention to such values, put some text in the main part of the document, not only in the IANA section.

If you agree, I can update my pull request.

Best regards Michael

-- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

mcr commented 3 years ago

Michael Tüxen notifications@github.com wrote:

I don't have a strong opinion about table vs not, or the "except..." text. I wanted to list 147->162 this way so that people reading would see what choices they have.

If I would be a developer looking for a number I can take, I would scroll through header files to find something for private use. Maybe look at the table available from IANA, but not in the IANA section.

So I would suggest:

  • add the entries to the table.
  • take them out of the IANA consoderations

okay, so the 147->162 are already listed in the header/source. They are also in the tables on tcpdump.org, and I would expect them to be visible in the IANA table...

> I you want to draw the attention to such values, put some text in the main
> part of the document, not only in the IANA section.

> If you agree, I can update my pull request.

I think we already merged it, and further adapted. More text welcome!

I guess we also need some emails to the chairs.

-- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [

guyharris commented 3 years ago

Given that the link-layer types are used in both pcap and pcapng, should there be a third I-D that just lists the link-layer types, to which both the pcap and pcapng I-Ds refer? A number of protocols aren't handled by a single RFC, they have multiple RFCs.

tuexen commented 3 years ago

On 23. Dec 2020, at 20:47, Guy Harris notifications@github.com wrote:

Given that the link-layer types are used in both pcap and pcapng, should there be a third I-D that just lists the link-layer types, to which both the pcap and pcapng I-Ds refer? A number of protocols aren't handled by a single RFC, they have multiple RFCs. I think it is a valid approach for the first document using some values to define the corresponding registry.

I like the approach of getting out the pcap spec first introducing the link layer type registry and then having the pcapng spec using it and defining the registries for the blocks and so on.

Best regards Michael

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

mcr commented 3 years ago

Guy Harris notifications@github.com wrote:

Given that the link-layer types are used in both pcap and pcapng, should there be a third I-D that just lists the link-layer types, to which both the pcap and pcapng I-Ds refer? A number of protocols aren't handled by a single RFC, they have multiple RFCs.

yes, that's a reasonable refactor.... in a world where the IESG wasn't so heavy-weight and liked more documents rather than bigger documents that might make sense.

I think that it will take a few months to get pcapng through. Look at the conversation in November in the "lets adopt it" thread from Toerless and others who want to redo the entire thing. So if we put it into pcapng, then pcap would just stall.

-- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [

tuexen commented 3 years ago

Guy Harris notifications@github.com wrote: Given that the link-layer types are used in both pcap and pcapng, should there be a third I-D that just lists the link-layer types, to which both the pcap and pcapng I-Ds refer? A number of protocols aren't handled by a single RFC, they have multiple RFCs. yes, that's a reasonable refactor.... in a world where the IESG wasn't so heavy-weight and liked more documents rather than bigger documents that might make sense. I think that it will take a few months to get pcapng through. Look at the conversation in November in the "lets adopt it" thread from Toerless and others who want to redo the entire thing. So if we put it into pcapng, then pcap would just stall. …

Guy Harris notifications@github.com wrote: Given that the link-layer types are used in both pcap and pcapng, should there be a third I-D that just lists the link-layer types, to which both the pcap and pcapng I-Ds refer? A number of protocols aren't handled by a single RFC, they have multiple RFCs. yes, that's a reasonable refactor.... in a world where the IESG wasn't so heavy-weight and liked more documents rather than bigger documents that might make sense. I think that it will take a few months to get pcapng through. Look at the conversation in November in the "lets adopt it" thread from Toerless and others who want to redo the entire thing. So if we put it into pcapng, then pcap would just stall. …

I would suggest to finish the work on the pcap specification, which includes the IANA registry for the link layer types.

We should also decide first, which Registration Policy is the right one. Then deal with the IETF procedural issues. Let me ask the question: Do we really want Specification Required. I'm not sure if the current assignments really have specs. I would vote for expert review. Since there needs to be text to describe the expert review anyway (also for spec required), we could request some sort of description. I think this way it was handled in the past. Or am I wrong?

mcr commented 3 years ago

I would suggest to finish the work on the pcap specification, which includes the IANA registry for the link layer types.

Agreed. May I also suggest we do this on the opsawg list, because doing it there means getting more attention from the chairs :-)

We should also decide first, which Registration Policy is the right one. Then deal with the IETF procedural issues. Let me ask the question: Do we really want Specification Required. I'm not sure if the current assignments really have specs. I would vote for expert review. Since there needs to be text to describe the expert review anyway (also for spec required), we could request some sort of description. I think this way it was handled in the past. Or am I wrong?

Hi, Specification Required actually implies Designated Experts (aka "expert review"). So, we have on the tcpdump-workers, essentially run things as expert review, and asked/begged for a Specification, but we haven't insisted upon it. So I'm trying to keep a similar policy. Guy has mostly been that expert, with Dennis and I asking questions around the edges.
Often in github issues where someone does a pull request. I think that we can probably adapt the IANA process into github Issues as in almost all cases we'll want to put it into libpcap as well.

If we were to DROP Specification Required, then we could go via ISE. But, I've had a bunch of back and forth with Adrian Farrel (the ISE), and he would like to see us exhaust all other avenues first. So I would tentatively say we go until Jan.31 or so.