From nobody Wed Jan 6 18:54:18 2021 Return-Path: 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 6B02B3A0964; Wed, 6 Jan 2021 18:54:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.846 X-Spam-Level: X-Spam-Status: No, score=-1.846 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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=gmail.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 Azl_s8BvW3IO; Wed, 6 Jan 2021 18:54:10 -0800 (PST) Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) (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 2616F3A1290; Wed, 6 Jan 2021 18:54:10 -0800 (PST) Received: by mail-ed1-x52f.google.com with SMTP id j16so6381706edr.0; Wed, 06 Jan 2021 18:54:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ak82pQ56lqxoYEuANfvS2PGavKtZZ37xciJZHhyV7p4=; b=a8t9WdTenJ//J2Bwfzfh5EK8zGFt2zOVbpyPWftPb53cLB0u3CYzTuOi40MQ9o+i8d RWQNJeRmazwAQ7DMW0hy838aLDss8ZNRsKLTLb5Lp92QXTQIuyhocfySYf3NTdI7i3ta cM2Axv+WzYDiIBKquInXILWtf400GcgEIq/VJiikDLspkGIaVfWJPkNrfRTaMZ4YGlUv r0ltlpSkZdD4EtRmVhOcZMGtEihMKa07Pfz9bdLMy9FO3rkN/7NNVFQfQkqfzl0Bwez4 LKtYluQGUM5pu7TZVI5t+I7uhE930SafB/nFOyIaXnPACyRW0YkVsaKB8ArrO3RVgHao Ow8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ak82pQ56lqxoYEuANfvS2PGavKtZZ37xciJZHhyV7p4=; b=DeZAuFMAsTQGbHLODgCIf7Gcg18isv2+HofOkprLYm2S+rc98PS4N/T1ztxzIkGpR2 gQMJadIUEGNks6s4Wo7DxBXGYHy56IWQMhdwja/bwiFx+K2lC+GDJvki8uzQcVXkgOQs 1b2o48XtgbLJgQR4y8gYXVNf3EY45ACQqodP9S2f3as6XyTE+LF5y+HfM8L1HtqtLe1U lY4L50/VrGQ2qek3Y/QyzQLgydiGZEzIgFAU5NqJGAFCStYmvUk23CTG/MiOwAeC8Obe m1a+pdaeF6+MsvGyie3EidEEl7m5oA8Ps/1tPdUuKvIr09oNEkZePMQ77/V/MicrXOmT Zrkg== X-Gm-Message-State: AOAM5310eOA4nlL0btVxPDnXOpS8toysQ5UJzzMlZf7rM4t1a5A3rptH H+5Qh5MtBBd6EDRbPgYe8x3hNHZfFM+Ljp+ZMck= X-Google-Smtp-Source: ABdhPJwtNVVJl42XjDHRv679Rka+Dyi0XDV5zRP8zE8i6MoAVKXnDk/8k701XFE5ead2+/UWhs60YN5UNP5620KO5rE= X-Received: by 2002:aa7:dcd0:: with SMTP id w16mr41372edu.229.1609988048563; Wed, 06 Jan 2021 18:54:08 -0800 (PST) MIME-Version: 1.0 References: <160995499362.18437.16175887825588198380@ietfa.amsl.com> In-Reply-To: <160995499362.18437.16175887825588198380@ietfa.amsl.com> From: Lucas Pardue Date: Thu, 7 Jan 2021 02:53:57 +0000 Message-ID: Subject: Re: Robert Wilton's Discuss on draft-ietf-quic-transport-33: (with DISCUSS and COMMENT) To: Robert Wilton Cc: The IESG , draft-ietf-quic-transport@ietf.org, WG Chairs , QUIC WG , Lars Eggert Content-Type: multipart/alternative; boundary="000000000000ba309105b8468df0" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2021 02:54:13 -0000 --000000000000ba309105b8468df0 Content-Type: text/plain; charset="UTF-8" Hi Rob, Thanks for the review. I've captured your comments as issues on the QUIC WG GItHub repository. Links to each are provided as in-line responses. On Wed, Jan 6, 2021 at 5:43 PM Robert Wilton via Datatracker < noreply@ietf.org> wrote: > Robert Wilton has entered the following ballot position for > draft-ietf-quic-transport-33: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-quic-transport/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > With so many "Yes" votes from other ADs, I feel like I'm swimming against > the > flow by raising a discuss ... > > Firstly, I would like the thank the authors and WG on such a well written > document. I am supportive of this protocol and hope that it will be good > for > the Internet. > > However, I do have some discuss questions relating to the Spin Bit and the > ability to manage and monitor networks. I appreciate that there has > already > been a lot of (presumably heated) discussion on the spin bit, which I've > not > read or participated in, but I am concerned about the operational > manageability > aspect of QUIC. > > Firstly, I have two comments on clarifying the spin bit > behaviour/specification: > > 1) It would be helpful to clarify what the expected behaviour is for an > implementation that chooses not to support the spin-bit. Does it just > leave > the bit set as 0, or is it meant to follow the same behaviour as if > spin-bit is > supported but disabled? > https://github.com/quicwg/base-drafts/issues/4668 > > 2) This may not be discuss worthy, but some of the spin bit behaviour is > inconsistently defined between the quic transport and quic manageability > drafts. Specifically: > - The transport draft states that at least 1 in 16 connections "MUST" > disable > spinning, whereas the manageability draft states this as "recommended". > - In > the case that the spin bit is disabled, the transport draft uses > "RECOMMENDED" to use a random value for each packet, or chosen > independently > for each connection. Whereas the manageability draft uses "can" and > lists > the two options in the opposite order. > > For this review, since it is in IESG review, I've presumed that the > transport > draft has the definitive definitions and the manageability draft is > lagging. > https://github.com/quicwg/base-drafts/issues/4669 > But my two main discuss questions/comments relate to whether the spin-bit, > as > specified in quic transport, achieves its goal. I appreciate that there > are > individuals who don't think that it is required at all, conversely some > network > operators believe that they will lose vital information needed to help > manage > their networks, and presumably we are trying to find a pragmatic compromise > between these two positions. > > 1) I find it hard to understand why a server is allowed to independently > decide > whether or not to support the spin bit on a connection? Shouldn't the > client > (or administrator of the client system) that opened the connection be able > to > choose whether they want the RTT to be monitorable via the spin bit? What > is > the reasoning for allowing the server (or server administrator) to be able > to > independently be able to decide what is best for the client? > https://github.com/quicwg/base-drafts/issues/4666 > 2) In the case that the spin-bit is disabled, I don't understand the > benefit of > injecting a random spin bit value in each packet rather than always > setting it > to a per connection random value. It seems that whether or not the > randomness > is injected, it is expected to be feasible to extract the RTT for those > connections that are genuinely spinning the bit (or otherwise the spin bit > is > entirely pointless), but it just seems to make it computationally harder to > extract the signal from the noise. Perhaps the goal here is reduce the > ability > for pervasive monitoring to occur, but that feels a bit like security > through > obscurity. > https://github.com/quicwg/base-drafts/issues/4667 > Some enlightenment for these questions would be appreciated. > > Regards, > Rob > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Comments: > > 1.2. Terms and Definitions > > Frame: A unit of structured protocol information. There are multiple > frame > types, each of which carries different information. Frames are > contained in > QUIC packets. > > Perhaps indicate that a quic packet can contain multiple frames? The > terminology states that a datagram contains multiple quick packets, but it > wasn't obvious to me that a quick packet can contain multple frames. > https://github.com/quicwg/base-drafts/issues/4670 > This document uses the terms "QUIC packets", "UDP datagrams", and "IP > packets" to refer to the units of the respective protocols. That is, > one or > more QUIC packets can be encapsulated in a UDP datagram, which is in > turn > encapsulated in an IP packet. > > Frame is a widely used term in L2. Hence, it might be helpful if this > description also covered "Frames". Perhaps this would also be a helpful > place > (or an alternative place) to mention that a QUIC packet contains one or > more > QUIC frames. > https://github.com/quicwg/base-drafts/issues/4671 > 3. Stream States > > Bidirectional streams use both state machines > > Maybe clarify this to indicate that it means that both state machines are > used > at each endpoint. Otherwise, even unidirection steams use both state > machines, > one at each endpoint. > https://github.com/quicwg/base-drafts/issues/4672 > 3.2. Receiving Stream States > > Figure 3: States for Receiving Parts of Streams > > Perhaps expand "App Read RST" to "App Read RESET", since there doesn't > seem a > great reason to abbreviate it. > https://github.com/quicwg/base-drafts/issues/4673 > 3.2. Receiving Stream States > > The receiving part of a stream enters the "Recv" state when the > sending part of a bidirectional stream initiated by the endpoint > (type 0 for a client, type 1 for a server) enters the "Ready" state. > > This might be slightly clearer if the conditional predicate was moved to > the > beginning of the sentence. E.g., For bidirectional streams, ... > > https://github.com/quicwg/base-drafts/issues/4674 > 4.1. Data Flow Control > > * Stream flow control, which prevents a single stream from consuming > the > entire receive buffer for a connection by limiting the amount of data > that > can be sent on any stream > > Perhaps "on a stream" would be better than "on any stream". > https://github.com/quicwg/base-drafts/issues/4675 > 4.6. Controlling Concurrency > > An endpoint that is unable to open a new stream due to the peer's > limits > SHOULD send a STREAMS_BLOCKED frame (Section 19.14). This signal is > considered useful for debugging. An endpoint MUST NOT wait to receive > this > signal before advertising additional credit, since Iyengar & Thomson > Expires 16 June 2021 [Page 29] Internet-Draft QUIC Transport Protocol > December 2020 doing so will mean that the peer will be blocked for at > least > an entire round trip, and potentially indefinitely if the peer chooses > not > to send STREAMS_BLOCKED frames. > > By additional credit, does it sending MAX_STREAMS? If so, it might be > helpful > to clarify that. > https://github.com/quicwg/base-drafts/issues/4676 > > 5.1. Connection ID > > 5.1.1. Issuing Connection IDs > > Additional connection IDs are communicated to the peer using > NEW_CONNECTION_ID frames (Section 19.15). The sequence number on > each newly issued connection ID MUST increase by 1. The connection > ID randomly selected by the client in the Initial packet and any > connection ID provided by a Retry packet are not assigned sequence > numbers unless a server opts to retain them as its initial > connection > ID. > > I was slightly confused by the "The connection ID randomly selected by the > client". Elsewhere in section 5.1 it says that connection id allocation > are > implementation specific. Are there any constraints on how connection ids > can > be allocated (other than not repeating as already stated). E.g., could an > implementation just allocate them as integers starting at 1? Or can all > connection ids (including NEW_CONNECTION_IDs) be randomly allocated? > https://github.com/quicwg/base-drafts/issues/4677 > > 16. Variable-Length Integer Encoding > > No requirement to send integers in smallest encoding possible? E.g. > okay > to send the value 3 in an 8 byte field? > > This section doesn't indicate whether a sender is allowed to send integers > not > using the smallest possible encoding, and doesn't indicate whether a > receive is > expected to process non optimal encodings. It might be helpful to be > explicit. > https://github.com/quicwg/base-drafts/issues/4678 > 17. Packet Formats > > Version: The QUIC Version is a 32-bit field that follows the first > byte. > This field indicates the version of QUIC that is in use and determines > how > the rest of the protocol fields are interpreted. > > By "rest of the protocol fields", I had incorrectly interpreted this as > meaning > all subsequent fields described after the version field are determined > Perhaps worth clarifying - although I recall that it does become clear > elsewhere. > https://github.com/quicwg/base-drafts/issues/4679 > 17. Packet Formats > > Type-Specific Bits: The lower four bits (those with a mask of 0x0f) of > byte > 0 are type-specific > > Perhaps "packet type specific" rather than just "type-specific"? > https://github.com/quicwg/base-drafts/issues/4680 Cheers, Lucas On behalf of QUIC WG Chairs --000000000000ba309105b8468df0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi= Rob,

Thanks for the review. I've captured you= r comments as issues on the QUIC WG GItHub repository. Links to each are pr= ovided as in-line responses.

=
On Wed, Jan 6, 2021 at 5:43 PM Robert= Wilton via Datatracker <noreply@iet= f.org> wrote:
Robert Wilton has entered the following ballot position for
draft-ietf-quic-transport-33: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/s= tatement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ie= tf-quic-transport/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

With so many "Yes" votes from other ADs, I feel like I'm swim= ming against the
flow by raising a discuss ...

Firstly, I would like the thank the authors and WG on such a well written document.=C2=A0 I am=C2=A0 supportive of this protocol and hope that it wil= l be good for
the Internet.

However, I do have some discuss questions relating to the Spin Bit and the<= br> ability to manage and monitor networks.=C2=A0 I appreciate that there has a= lready
been a lot of (presumably heated) discussion on the spin bit, which I'v= e not
read or participated in, but I am concerned about the operational manageabi= lity
aspect of QUIC.

Firstly, I have two comments on clarifying the spin bit behaviour/specifica= tion:

1) It would be helpful to clarify what the expected behaviour is for an
implementation that chooses not to support the spin-bit.=C2=A0 Does it just= leave
the bit set as 0, or is it meant to follow the same behaviour as if spin-bi= t is
supported but disabled?

=C2=A0

2) This may not be discuss worthy, but some of the spin bit behaviour is inconsistently defined between the quic transport and quic manageability drafts.=C2=A0 Specifically:
=C2=A0 - The transport draft states that at least 1 in 16 connections "= ;MUST" disable
=C2=A0 spinning, whereas the manageability draft states this as "recom= mended". - In
=C2=A0 the case that the spin bit is disabled, the transport draft uses
=C2=A0 "RECOMMENDED" to use a random value for each packet, or ch= osen independently
=C2=A0 for each connection.=C2=A0 Whereas the manageability draft uses &quo= t;can" and lists
=C2=A0 the two options in the opposite order.

=C2=A0 For this review, since it is in IESG review, I've presumed that = the transport
=C2=A0 draft has the definitive definitions and the manageability draft is = lagging.



But my two main discuss questions/comments relate to whether the spin-bit, = as
specified in quic transport, achieves its goal.=C2=A0 I appreciate that the= re are
individuals who don't think that it is required at all, conversely some= network
operators believe that they will lose vital information needed to help mana= ge
their networks, and presumably we are trying to find a pragmatic compromise=
between these two positions.

1) I find it hard to understand why a server is allowed to independently de= cide
whether or not to support the spin bit on a connection?=C2=A0 Shouldn't= the client
(or administrator of the client system) that opened the connection be able = to
choose whether they want the RTT to be monitorable via the spin bit?=C2=A0 = What is
the reasoning for allowing the server (or server administrator) to be able = to
independently be able to decide what is best for the client?

<= br>

2) In the case that the spin-bit is disabled, I don't understand the be= nefit of
injecting a random spin bit value in each packet rather than always setting= it
to a per connection random value.=C2=A0 It seems that whether or not the ra= ndomness
is injected, it is expected to be feasible to extract the RTT for those
connections that are genuinely spinning the bit (or otherwise the spin bit = is
entirely pointless), but it just seems to make it computationally harder to=
extract the signal from the noise.=C2=A0 Perhaps the goal here is reduce th= e ability
for pervasive monitoring to occur, but that feels a bit like security throu= gh
obscurity.



Some enlightenment for these questions would be appreciated.

Regards,
Rob


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Comments:

=C2=A0 =C2=A0 1.2.=C2=A0 Terms and Definitions

=C2=A0 =C2=A0 Frame: A unit of structured protocol information. There are m= ultiple frame
=C2=A0 =C2=A0 types, each of which carries different information. Frames ar= e contained in
=C2=A0 =C2=A0 QUIC packets.

Perhaps indicate that a quic packet can contain multiple frames?=C2=A0 The<= br> terminology states that a datagram contains multiple quick packets, but it<= br> wasn't obvious to me that a quick packet can contain multple frames.

https://github.com/quicwg/base-drafts/issues/4670<= /div>


=C2=A0 =C2=A0 This document uses the terms "QUIC packets", "= UDP datagrams", and "IP
=C2=A0 =C2=A0 packets" to refer to the units of the respective protoco= ls. That is, one or
=C2=A0 =C2=A0 more QUIC packets can be encapsulated in a UDP datagram, whic= h is in turn
=C2=A0 =C2=A0 encapsulated in an IP packet.

Frame is a widely used term in L2.=C2=A0 Hence, it might be helpful if this=
description also covered "Frames".=C2=A0 Perhaps this would also = be a helpful place
(or an alternative place) to mention that a QUIC packet contains one or mor= e
QUIC frames.



=C2=A0 =C2=A0 3.=C2=A0 Stream States

=C2=A0 =C2=A0 Bidirectional streams use both state machines

Maybe clarify this to indicate that it means that both state machines are u= sed
at each endpoint.=C2=A0 Otherwise, even unidirection steams use both state = machines,
one at each endpoint.



=C2=A0 =C2=A0 3.2.=C2=A0 Receiving Stream States

=C2=A0 =C2=A0 Figure 3: States for Receiving Parts of Streams

Perhaps expand "App Read RST" to "App Read RESET", sinc= e there doesn't seem a
great reason to abbreviate it.



=C2=A0 =C2=A0 3.2.=C2=A0 Receiving Stream States

=C2=A0 =C2=A0 The receiving part of a stream enters the "Recv" st= ate when the
=C2=A0 =C2=A0 sending part of a bidirectional stream initiated by the endpo= int
=C2=A0 =C2=A0 (type 0 for a client, type 1 for a server) enters the "R= eady" state.

This might be slightly clearer if the conditional predicate was moved to th= e
beginning of the sentence.=C2=A0 E.g., For bidirectional streams, ...

=C2=A0
=C2=A0
https://github.com/quicwg/base-drafts/issues/46= 75


=C2=A0 =C2=A0 4.6.=C2=A0 Controlling Concurrency

=C2=A0 =C2=A0 An endpoint that is unable to open a new stream due to the pe= er's limits
=C2=A0 =C2=A0 SHOULD send a STREAMS_BLOCKED frame (Section 19.14). This sig= nal is
=C2=A0 =C2=A0 considered useful for debugging. An endpoint MUST NOT wait to= receive this
=C2=A0 =C2=A0 signal before advertising additional credit, since Iyengar &a= mp; Thomson
=C2=A0 =C2=A0 Expires 16 June 2021 [Page 29] Internet-Draft QUIC Transport = Protocol
=C2=A0 =C2=A0 December 2020 doing so will mean that the peer will be blocke= d for at least
=C2=A0 =C2=A0 an entire round trip, and potentially indefinitely if the pee= r chooses not
=C2=A0 =C2=A0 to send STREAMS_BLOCKED frames.

By additional credit, does it sending MAX_STREAMS?=C2=A0 If so, it might be= helpful
to clarify that.


=C2=A0 =C2=A0 5.1.=C2=A0 Connection ID

=C2=A0 =C2=A0 5.1.1.=C2=A0 Issuing Connection IDs

=C2=A0 =C2=A0 =C2=A0 =C2=A0Additional connection IDs are communicated to th= e peer using
=C2=A0 =C2=A0 =C2=A0 =C2=A0NEW_CONNECTION_ID frames (Section 19.15).=C2=A0 = The sequence number on
=C2=A0 =C2=A0 =C2=A0 =C2=A0each newly issued connection ID MUST increase by= 1.=C2=A0 The connection
=C2=A0 =C2=A0 =C2=A0 =C2=A0ID randomly selected by the client in the Initia= l packet and any
=C2=A0 =C2=A0 =C2=A0 =C2=A0connection ID provided by a Retry packet are not= assigned sequence
=C2=A0 =C2=A0 =C2=A0 =C2=A0numbers unless a server opts to retain them as i= ts initial connection
=C2=A0 =C2=A0 =C2=A0 =C2=A0ID.

I was slightly confused by the "The connection ID randomly selected by= the
client".=C2=A0 Elsewhere in section 5.1 it says that connection id all= ocation are
implementation specific.=C2=A0 Are there any constraints on how connection = ids can
be allocated (other than not repeating as already stated).=C2=A0 E.g., coul= d an
implementation just allocate them as integers starting at 1?=C2=A0 Or can a= ll
connection ids (including NEW_CONNECTION_IDs) be randomly allocated?


=C2=A0 =C2=A0 16. Variable-Length Integer Encoding

=C2=A0 =C2=A0 No requirement to send integers in smallest encoding possible= ?=C2=A0 E.g. okay
=C2=A0 =C2=A0 to send the value 3 in an 8 byte field?

This section doesn't indicate whether a sender is allowed to send integ= ers not
using the smallest possible encoding, and doesn't indicate whether a re= ceive is
expected to process non optimal encodings.=C2=A0 It might be helpful to be = explicit.




=C2=A0 =C2=A0 17.=C2=A0 Packet Formats

=C2=A0 =C2=A0 Version: The QUIC Version is a 32-bit field that follows the = first byte.
=C2=A0 =C2=A0 This field indicates the version of QUIC that is in use and d= etermines how
=C2=A0 =C2=A0 the rest of the protocol fields are interpreted.

By "rest of the protocol fields", I had incorrectly interpreted t= his as meaning
all subsequent fields described after the version field are determined=C2= =A0
Perhaps worth clarifying - although I recall that it does become clear
elsewhere.



=C2=A0 =C2=A0 17.=C2=A0 Packet Formats

=C2=A0 =C2=A0 Type-Specific Bits: The lower four bits (those with a mask of= 0x0f) of byte
=C2=A0 =C2=A0 0 are type-specific

Perhaps "packet type specific" rather than just "type-specif= ic"?


Cheers,
Lucas
On behalf of QUIC = WG Chairs
--000000000000ba309105b8468df0--