[pcap-ng-format] [tcpdump-workers] comments/edits on pcapng

[Michael Richardson]

Guy Harris <guy at alum.mit.edu> wrote:
    > Well, one change that would be that drastic would be changing it from a
    > format in which each block type has its own name space for options to a
    > format in which there's a single global name space for options, and
    > thus changing the option numbers.  That change would not only mean that
    > old code would no longer be able to read the new files, it would also
    > mean that code that handles the new files would need a different code
    > path to handle the old files.

Well, I don't feel too strongly about changing this.
I would suggest that we could leave values < 256 as "local", and provide new
numbers which were globally unique as aliases.  But that still leaves code
that is needed to read old files which likely never goes away, and so what's
the point.

    >> So I think that we should simply turn this into a 4-byte int32 field.
    >> Let's just put the highest *RFC* number that must be understood in
    >> order to comprehend all the blocks present.  At approx. 3500 RFCs/10
    >> years, 32-bits will last a long long long time... We could even do
    >> this with just the Minor Version and be good until rfc65535, which
    >> might be by oh year 2265 assuming the IETF continues at it's present
    >> rate.

    > So are you suggesting that updates to the format, such as the addition
    > of new blocks, new options, new link-layer types, etc. would be done
    > with RFCs?

To the extent that they would be "standards", yes.
If someone wants to allocate a block type for their own use, that would be
fine, it would just be RFCXXXX + extension.

    > That would fit with the use of IANA registries for block types/option
    > values/link-layer header types/etc..

    >> On the Interface Description Block, (section: 4.2), the table shown
    >> should be an IANA controlled registry.

    > I.e., replace http://www.tcpdump.org/linktypes.html with an IANA
    > registry?

Yes, I think that this is reasonable.

    >> The reference to section 3.5 is initially confusing when reading.  I
    >> think that there should be a single table (in section 3.5).  I see
    >> that the Section Header Block also reuses codes used in the IDB: I
    >> think that this is a mistake, the codes in a comment block should not
    >> be context dependant.  My pull request takes care of all of them, I
    >> hope.

    > Does your pull request also bump the current major version number?

Fair point, it should do that too if we were to accept this change.

    > I don't see what the problem is with different block types having
    > different option name spaces.  Common code to handle options in all
    > block types wouldn't be that useful - that code wouldn't, for example,
    > be able to do anything useful with the interface speed option in a Name
    > Resolution Block.  (And what do you mean by a "comment block"; we don't
    > have blocks whose sole purpose is to contain comments, we have a
    > comment option that can be used in any block, the content of which is
    > solely intended for display to humans.)

Perhaps I've mis-understood how these suboptions work.

    >> On the subject of the Encryption Block.  In discussion on the list
    >> many asked if we needed it.  Let me suggest that we do, but that yes,
    >> we need more information in it.

    > Well, the first question is what sort of information would be put in
    > it.  The current spec just says it "is used to store encrypted data"
    > and says of the data in it that "Once decrypted, it originates other
    > blocks.", but it doesn't say what sort of stuff is being encrypted!
    > Lists of credit card numbers? :-)

I think that essentially, it encrypts other blocks, such as captures, etc.

    >> Now, about LinkType: I suggest that having libpcap/tcpdump continue to
    >> maintain the table is not ideal.  Instead, let's create an IANA
    >> registry for it, populate it with existing values, and make the
    >> libpcap group the Expert Review.

    > So where would the actual formats be made available?

We'd have to include a few key ones into this document, and the rest would
continue to have the rather loose references that the web site has now.

    > I don't think an RFC is required as a reference, so we wouldn't have to
    > wait for an RFC to percolate through the process before making a new
    > link-layer header type available, but that would leave open the
    > question of what to use as a reference until the RFC comes out, and if
    > you don't want www.tcpdump.org to store the description until it shows
    > up in an RFC...

So, what happens right now is that we do Expert Review.  People ask us for a
link type, and we beat on them a bit to give a slightly stable document to
point at, or at least to argue why no existing type works for them.
Then they get the number, and if we are lucky, we also have a stable link to
their format.  With IANA Expert Review, we could essentially do exactly the
same thing --- just that IANA would write down the result.

Numbers can be assigned by RFC as well, and can be assigned early, and IANA
is happy to change the reference from draft-foo-bar to RFCxyaz as the
document progresses.
But, it can also just be a link to http://www.company.com/technote/foo.html,
or it can, as it says now, say, "Used by Company XYZ for Proprietary FOO"

--
Michael Richardson <mcr+IETF at sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 481 bytes
Desc: not available
URL: <http://www.winpcap.org/pipermail/pcap-ng-format/attachments/20151112/b7431bc1/attachment.pgp>