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

[Guy Harris]

On Nov 21, 2018, at 8:36 AM, Jasper Bongertz <jasper at packet-foo.com> wrote:

> 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.

It also requires more infrastructure to be set up, so maybe going with something in the 1-4 range as an interim solution.

>> (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

Well, that's certainly a daring fireball of a proposal. :-) :-) :-) :-) :-) :-) :-)

And there's even at least one Markdown parser for which there's a backend to generate RFC 2629 XML for submission as an I-D:

	https://github.com/cabo/kramdown-rfc2629

> 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 :-)

If that's about setting up a Wiki on GitHub, see

	https://help.github.com/articles/about-github-wikis/

If it's just about converting the spec to Markdown, the link for kramdown-rfc2629 may give examples of how to format the spec in Markdown; it'd then just become draft-tuexen-opsawg-pcapng.md or something such as that.