On Nov 12, 2015, at 8:26 AM, Michael Richardson <mcr+i...@sandelman.ca> wrote:
> Guy Harris <g...@alum.mit.edu> wrote:
>
>> 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.
The idea is that each block type has its own set of options, with every set
being required to include an option numbered 0 for "end of options" and an
option numbered 1 for "UTF-8 comment string". Code to read a particular block
type handles all the options for that block type, including options 0 and 1;
the code to read option 1 is simple, it's the code to *display* it that does
most of the work, and that'd probably be different for different block types
anyway.
>>> 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.
We should probably indicate that, then, rather than just vaguely stating "An
Encryption Block is used to store encrypted data." and "Encrypted Data: data of
this block. Once decrypted, it originates other blocks."
Or perhaps we should remove it from the spec, and put something back in once
it's finalized to the point of having a block number assigned and having an
indication of what it contains and how it should be handled by readers.
>>> 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.
The Web site also stores a few specs linked to from entries in the table at
http://www.tcpdump.org/linktypes.html
for formats for which there's no spec to point to elsewhere on the Web; where
should those specs be stored?
In addition, the description column in that table has some fairly long entries,
which look longer than the sort of things that show up in IANA registries such
as
http://www.iana.org/assignments/snoop-datalink-types/snoop-datalink-types.xhtml#snoop-datalink-types-2
That table just points to RFCs, and the main RFC:
http://tools.ietf.org/html/rfc1761
just has a rather terse table:
Datalink Type:
A 32-bit (4 octet) field identifying the type of
datalink header used in the packet records that follow.
The datalink type codes are listed in the table below:
Datalink Type Code
------------- ----
IEEE 802.3 0
IEEE 802.4 Token Bus 1
IEEE 802.5 Token Ring 2
IEEE 802.6 Metro Net 3
Ethernet 4
HDLC 5
Character Synchronous 6
IBM Channel-to-Channel 7
FDDI 8
Other 9
Unassigned 10 - 4294967295
most of the entries of which are probably sufficient (i.e., they just contain a
frame for the particular LAN/MAN technology, with nothing added, subtracted, or
rearranged), but "HDLC", "Character Synchronous", and "IBM Channel-to-Channel"
are too vague to actually be useful. That might be because those DLPI types
were reserved for those purposes but never actually officially *used* for those
purposes, and thus nobody had to figure out what the format of those packets
were.
We could publish an RFC containing the current set of link-layer header types
from the tcpdump.org site, perhaps including the text from the specs stored on
tcpdump.org, and refer to that from the pcap-ng spec *and* from any pcap spec
we publish as an I-D or RFC; I'd have it give the descriptions from the
tcpdump.org site, to be a little more restrictive than the snoop spec - I'd
rather not have to throw heuristics into tcpdump or Wireshark to distinguish
between packets using one interpretation of the description of LINKTYPE_FOOBAR
and packets using another interpretation.
>> 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.
So it sounds as if we can assign a number before the RFC is issued for a new
block type/link type/option code/etc., and update the registry when an I-D is
issued or updated or an RFC is issued.
> 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"
So presumably somebody who wants a link type would go to
http://www.iana.org/form/protocol-assignment
and request one.
So does a Designated Expert for a registry get to edit whatever underlying file
or database is used to generate pages for the registry in question? I.e., what
would the Designated Expert do when adding a new block type/link
type/option/etc.? Is there a repository to which they're granted access and to
which they do a commit/push/whatever with the update? Is it a database for
which there's some Web interface to publish updates?
Or does the Designated Expert send a request to somebody at the IANA, who
updates the file/database/whatever?
I assume the actual underlying mechanism that implements the Protocol
Assignment registry pages is documented *somewhere*.
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
