Re: [Ext] Consensus call for qlog serialization format (issue #144)

Paul Hoffman <paul.hoffman@icann.org> Thu, 05 August 2021 17:09 UTC

Return-Path: <paul.hoffman@icann.org>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC9BB3A19E9; Thu, 5 Aug 2021 10:09:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 PepPzQMJynIs; Thu, 5 Aug 2021 10:09:39 -0700 (PDT)
Received: from ppa2.lax.icann.org (ppa2.lax.icann.org [192.0.33.77]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EB143A1967; Thu, 5 Aug 2021 10:09:39 -0700 (PDT)
Received: from MBX112-W2-CO-1.pexch112.icann.org (out.mail.icann.org [64.78.33.5]) by ppa2.lax.icann.org (8.16.0.43/8.16.0.43) with ESMTPS id 175Gfrx3018579 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 5 Aug 2021 16:41:53 GMT
Received: from MBX112-W2-CO-1.pexch112.icann.org (10.226.41.128) by MBX112-W2-CO-2.pexch112.icann.org (10.226.41.130) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.858.15; Thu, 5 Aug 2021 09:41:52 -0700
Received: from MBX112-W2-CO-1.pexch112.icann.org ([10.226.41.128]) by MBX112-W2-CO-1.pexch112.icann.org ([10.226.41.128]) with mapi id 15.02.0858.015; Thu, 5 Aug 2021 09:41:52 -0700
From: Paul Hoffman <paul.hoffman@icann.org>
To: Lucas Pardue <lucaspardue.24.7@gmail.com>
CC: QUIC WG <quic@ietf.org>, QUIC WG Chairs <quic-chairs@ietf.org>
Subject: Re: [Ext] Consensus call for qlog serialization format (issue #144)
Thread-Topic: [Ext] Consensus call for qlog serialization format (issue #144)
Thread-Index: AQHXh6GqzcTca2ik1k+IeIsm09R9Natg1OOAgAAfh4CAAAy6AIAETYKAgABJBQA=
Date: Thu, 05 Aug 2021 16:41:52 +0000
Message-ID: <CC735BD8-0AF3-4E99-BD12-78C4181C3E19@icann.org>
References: <CALGR9oZS=k8XhyfugHH6VmdMVAAj6ER8s18g5eaZqX_3hie4ig@mail.gmail.com> <46CBE180-6B80-4B29-AAE3-BABBC59A02C4@icann.org> <CALGR9obnuPNYcFh1tZanFoLE1FCRSfQ1WoEEcSL+uc_5usGNSA@mail.gmail.com> <89EE247B-A26C-4C58-863C-6C938A6BA023@icann.org> <CALGR9oa0Q=N+E3ycDMBPM6HLkeGa4anWA+taJ3f088fxbo3S4Q@mail.gmail.com>
In-Reply-To: <CALGR9oa0Q=N+E3ycDMBPM6HLkeGa4anWA+taJ3f088fxbo3S4Q@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [192.0.32.234]
x-source-routing-agent: Processed
Content-Type: multipart/signed; boundary="Apple-Mail=_DD8F6486-59D7-4BB5-B441-2E8249E4C16F"; protocol="application/pkcs7-signature"; micalg="sha-256"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-08-05_05:2021-08-05, 2021-08-05 signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/8SLgxLqvsou2VvlnRV3r0AXyG74>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Aug 2021 17:09:44 -0000

On Aug 5, 2021, at 5:20 AM, Lucas Pardue <lucaspardue.24.7@gmail.com> wrote:
> On Mon, Aug 2, 2021 at 7:38 PM Paul Hoffman <paul.hoffman@icann.org> wrote:
> 
>> On Aug 2, 2021, at 10:52 AM, Lucas Pardue <lucaspardue.24.7@gmail.com> wrote:
>> > The intention here is to determine consensus on using _a JSON_ serialization and not a completely different format.
>> 
>> The associated question, which was not asked on this thread is "should there be any serialization format chosen, or just a data definition?". I would have leaned towards that, particularly because of the thorny JSON serialization issues brought up in the draft. However, that discussion often gets too meta for folks who want to start debugging and logging now.
> 
> There's quite a large population of people already using JSON for qlog, prior to WG adoption. So far, there has been a practical benefit to an interoperable serialization format that was strongly linked to the schema definition by draft version. During the adoption call I don't recall there being suggestions for dropping serialization altogether from draft-ietf-quic-qlog-main-schema.
> 
> Wearing no hats: I think including at least one serialization format as part of the work is a useful function to drive design and development decisions. There might be a question about whether draft-ietf-quic-qlog-main-schema should include the concrete serialization or if it should be spun out to a separate document. However, I think this question is tangential to the current call.

We are having a disconnect here that is central to the question in this consensus call. The original call said:

> The feeling in the room was to keep the JSON serialization format. Noting that implementations can use their own intermediate formats and transform to and from JSON as needed, and that future documents could specify other interop formats if there is sufficient interest.
> 
> The proposed resolution for this matter is to keep the JSON serialization format as the canonical interoperable format. This email seeks to establish consensus for this. If you have comments, for or against, please respond on the issue. The call will run until EoD August 9 2021.
> 


The call asked whether the (now "a") JSON serialization format will be the canonical interoperable format. That is quite different than "including at least one serialization format". As a concrete example:

- The JSON serialization says that numbers such as packet_number may be represented as a number or a string

- The data format says that the numbers such as packet_number are uint64

If the JSON serialization format is the canonical interoperable format, and I'm writing a CBOR emitter, I would be allowed to write packet_number as a number or string because both could convert to JSON. However, if the data format is the canonical interoperable format, I would only be able to write it as a number.

Thus, it is critical for interoperability between formats to specify if the data definition is canonical, or if the JSON serialization is canonical. If the latter, there really is no need for the data definitions at all; if this choice is made, interoperability would be more likely if the data definitions were removed.

I hope this helps clarify why the WG needs to choose one or the other.

--Paul Hoffman