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

[Guy Harris]

Currently, the pcapng specification says that, to request a new block number, the request should be sent to this mailing list.

However, most of the work for specifying a new block type, and discussing the specification, can probably be done with a pull request for the spec.

How should the assignment of a block number be done?

Some possibilities:

1) The requestor sends a message to this list saying "I'm going to be proposing a block called the "Writer's Block" for pcapng; could you please reserve a block number for me?  I'll make a pull request once I get a block number.", we update the "Standardized Block Type Codes" table to mark it as reserved for their block and send a reply, and they then make a pull request, with the new code in the ASCII-art diagram for their block.  Once the discussion for the pull request reaches a consensus on the block being sufficiently well-specified and the specification being reasonable, the pull request is merged, and we then update the "Standardized Block Type Codes" table.

2) The requestor submits a pull request for their block, with "0xXXXXXXXX" as a placeholder in the ASCII-art diagram for their block.  Once the discussion for the pull request reaches a consensus on the block being sufficiently well-specified and the specification being reasonable, a comment is made assigning a block number, the requestor updates the ASCII-art diagram, the pull request is merged, and we then update the "Standardized Block Type Codes" table.

3) The requestor submits a pull request for their block, with "0xXXXXXXXX" as a placeholder in the ASCII-art diagram for their block.  Once the discussion for the pull request reaches a consensus on the block being sufficiently well-specified and the specification being reasonable, the pull request is merged, and we then update the ASCII-art diagram and "Standardized Block Type Codes" table.

4) The requestor picks a currently-unused value, where "currently-unused" includes "not requested in any pull request, either"; if it's currently requested in another pull request, we add a comment saying "sorry, somebody already wants to use that, pick another value" and it's not merged until they do.

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

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