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

Steve Lhomme <slhomme@matroska.org> Sun, 03 October 2021 06:12 UTC

Return-Path: <slhomme@matroska.org>
X-Original-To: cellar@ietfa.amsl.com
Delivered-To: cellar@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2DED3A0AE8 for <cellar@ietfa.amsl.com>; Sat, 2 Oct 2021 23:12:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=matroska-org.20210112.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ICJL3oh4J2kz for <cellar@ietfa.amsl.com>; Sat, 2 Oct 2021 23:12:29 -0700 (PDT)
Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D178F3A083E for <cellar@ietf.org>; Sat, 2 Oct 2021 23:12:28 -0700 (PDT)
Received: by mail-wr1-x433.google.com with SMTP id d6so23671236wrc.11 for <cellar@ietf.org>; Sat, 02 Oct 2021 23:12:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20210112.gappssmtp.com; s=20210112; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=9gO6e+MD/jFLO5cYzyNVZd+2qEXIB6655T3Ng6VpZjM=; b=a80KYzc/01VtQLb3xoHedG4Mze+gXTkAgqmmxnw7O9ThA2gcCqasLEnNQTELxizMcG 4TRgVflI2WKNtePPvZEYXDbNHYSa+17WxcIf60HW+nJbH7h3OqKobd7MximnJTm34EFm V6zkE00Uk51ZC0A+Hnm15a6xPMmFIacenRh7FGM48/ERKUc5WH20b/U1VyujtMrObf2V tWsbwtl29Yc5u/9FSCeeR8ofO38ZTO2JBnruyrxlBp58iH2N7O9nroYCm512Qp9n5RjW HWGc+6VbjhDCWwJO4OrOF41KVlX00VI3c/m0CQbFW7HSd3bBYDHqUTRXtBGzWbTAwqep 9c9w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=9gO6e+MD/jFLO5cYzyNVZd+2qEXIB6655T3Ng6VpZjM=; b=CvUN2/NyRNHJFIJRcEwF6J1ACsbw3CPM/zT7AUTv0g8lrjGWQbNaZEsyFmBSMLoqE+ cRRRv18hFGLVVJqwzHiLi8MaDaKqLfIrsvPyzjMQHSiFB7XI+BNiwDeCdvrHvFPoE/p1 ZfOfLjutmO5Q/MRBtNDSMYyaCmbgSV3MDuaCdclApQ2gxN5/NR5h6+7vvHYqW++rBlIN m/lEVInKkX/46koEOiPIGpseXPE6Q+ZcP4W2j1HjV/Msy3sjKIXlwKcbLCmp2/iQGHyY W9Hgc/1+DFMIwLv265OaaNdupG1D9C/D7ao0PocgwDkoHuSL5hdNdpUEP9pkAYWV6XUu eHSQ==
X-Gm-Message-State: AOAM533WQC4ZO30LkmPBKBb1SYoIo8ZUNIO8S6oy9v4OIrW2TYzJXJKq hF3jcsn1k3uynIKm3WQx440xZYi+6V/NDA==
X-Google-Smtp-Source: ABdhPJyh1Jworw3zl7jzkSfl+siIAeDZRdP/Hq7iXthIR4SzYA5pt3P0MloxhYZIaWyGUf0+ZqP0jw==
X-Received: by 2002:adf:b1d4:: with SMTP id r20mr4938112wra.308.1633241546637; Sat, 02 Oct 2021 23:12:26 -0700 (PDT)
Received: from ?IPv6:2a01:cb0c:20:e900:252a:5ff6:a0aa:a37c? (2a01cb0c0020e900252a5ff6a0aaa37c.ipv6.abo.wanadoo.fr. [2a01:cb0c:20:e900:252a:5ff6:a0aa:a37c]) by smtp.gmail.com with ESMTPSA id w23sm13115873wmi.6.2021.10.02.23.12.26 for <cellar@ietf.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 02 Oct 2021 23:12:26 -0700 (PDT)
To: cellar@ietf.org
References: <RT-Ticket-1186419@icann.org> <21576.1609796505@localhost> <rt-4.4.3-459-1609897035-36.1186419-37-0@icann.org> <10969.1632857380@localhost>
From: Steve Lhomme <slhomme@matroska.org>
Message-ID: <b2d1f19d-2ce9-c762-47bb-54e7ddd4fb50@matroska.org>
Date: Sun, 3 Oct 2021 08:12:26 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0
MIME-Version: 1.0
In-Reply-To: <10969.1632857380@localhost>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/cellar/8Ehtazzp53N2PO-95MHC5ULZnxc>
Subject: Re: [Cellar] recap large initial registry tables for gharris-opsawg-pcap..
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Codec Encoding for LossLess Archiving and Realtime transmission <cellar.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cellar>, <mailto:cellar-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cellar/>
List-Post: <mailto:cellar@ietf.org>
List-Help: <mailto:cellar-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cellar>, <mailto:cellar-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 03 Oct 2021 06:12:34 -0000

On 2021-09-28 21:29, Michael Richardson wrote:
> 
> 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:

Sounds good. I created an issue to work on this
https://github.com/ietf-wg-cellar/matroska-specification/issues/568

> <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 <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
>             Sandelman Software Works Inc, Ottawa and Worldwide
> 
> 
> 
> 
> 
> _______________________________________________
> Cellar mailing list
> Cellar@ietf.org
> https://www.ietf.org/mailman/listinfo/cellar
>