[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