[Cellar] recap large initial registry tables for gharris-opsawg-pcap..

[Michael Richardson <[e-mail]>]

In a different fora, I asked:

> {Well, that's really four columns: already fixed!}
> There are 151 some entries already.
>
> 1) We wonder if IANA would prefer to receive this list in another
> form.
>    Your XML format as an appendix CODE BEGINs?
>    We likely would write code to turn the XML format into a table
>    for libpcap and wireshark...

And IANA answered:

This would be just fine, if it would make sense for you. This is our format:

<record date="yyyy-mm-dd">
<value>0</value>
<name>LINKTYPE_NULL</name>
<description>BSD loopback encapsulation</description>
<xref type="draft" data="draft-gharris-opsawg-pcap-01"/>
</record>

...

<record date="yyyy-mm-dd">
<value>147-162</value>
<name>Reserved for Private Use</name>
<description/>
<xref type="draft" data="draft-gharris-opsawg-pcap-01"/>
</record>

...

<record>
<value>290-64999</value>
<name>Unassigned</name>
<description/>
</record>

To refer to an RFC, like RFC 8126:

<xref type="rfc" data="rfc8126"/>

To refer to some other document or location, like example.com:

<xref type="uri" data="https://www.example.com"/>

The date will be the date we add the record to the registry. (In addition to
the "date" attribute, if we're asked to change some aspect of the
registration in the future, we would also add an 'updated="yyyy-mm-dd"'
attribute. It's not used if we're only updating a document reference, like
replacing a draft string with its new RFC number.)

If these entries were recorded elsewhere in the document, the RFC Editor
could remove the XML before publication, if that makes more sense. Or it
could be provided to us separately once the IESG approves the document for
publication. (We generally complete the registry actions within two weeks of
IESG approval, provided we don't have any questions at that point.)


--
Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide