[pcap-ng-format] Procedure for registering new block type value and block-specific values such as options

Jasper Bongertz jasper at packet-foo.com
Wed Nov 21 16:36:58 UTC 2018


Tuesday, November 20, 2018, 7:40:33 AM, Guy Harris wrote:

> 5) We set up a GitHub wiki, with a page for block number values. 
> The requestor updates that page to add an otherwise-unused number
> for their block type, and then submits the pull request, updating
> the wiki entry to point to the pull request.

> (Perhaps we have a timeout so that if nothing happens in, say, six
> months, the reserved block type code is released.)

> In all three of those procedures, we could also require that the
> pull request also update the "Standardized Block Type Codes" table. 
> The pull request for the Decryption Secrets Block already has that -
> for procedure 2), the initial version would use the placeholder.

> For updates to block-specific values, such as option codes and, for
> the proposed Decryption Secrets Block, the secrets type, do we need
> to have that procedure to avoid collisions?

> My inclination is currently to go with 5).

5 sounds like a good strategy. We will need a few procedures like the one you 
mentioned for "nothing happens", or when a block type code request is refused. 
This could happen e.g. when adding a new block type is too similar to an existing
type, or the intended purpose can be realized via additional options for an existing 
block type.

> (And if we could make the pcapng spec *be* the wiki, with a way to
> generate a single page or whatever from it, that might be even cooler.)

At Sharkfest 2018 EU there was a proposal to convert the specs to Markdown to make it
easier to edit the specs, which sounds like a similar approach to me. I'm not sure how to do
that on Github to be honest, and I still struggle with the concepts of git and Github in 
general. But I plan to familiarize myself with it over the upcoming Xmas holidays :-)




More information about the pcap-ng-format mailing list