[C430] RFC 9000 - Re: [IANA #1196209] Protocol Action: 'QUIC: A UDP-Based Multiplexed and Secure Transport' to Proposed Standard (draft-ietf-quic-transport-34.txt)

[Sandy Ginoza <[e-mail]>]

Hi Amanda, Martin,

> On May 18, 2021, at 8:56 AM, Amanda Baber via RT <[e-mail]> wrote:
> 
> Hi Sandy,
> 
> Do the authors prefer to not include 0x1XX in the registry? I believe we would at least need a note, if not an entry. It's not clear to me whether this is a kind of reservation or a description of what can be registered.

Sorry for not closing this out; thanks for the followup.  I’m including Martin (via the c430 list) on the thread.

Martin, please verify that the XXX in Section 19.8 is intentional. 

   STREAM frames implicitly create a stream and carry stream data. The 
   Type field in the STREAM frame takes the form 0b00001XXX (or the 
   set of values from 0x08 to 0x0f).


Amanda, this was Martin's reply regarding "CRYPTO_ERROR (0x1XX)”:
https://www.rfc-editor.org/pipermail/c430/2021-May/000027.html


These are the related updates in the document:

1) Section 20.1: https://www.rfc-editor.org/authors/rfc9000.html#section-20.1

CRYPTO_ERROR (0x0100-0x01ff):  The cryptographic handshake failed. A range of 256 values is reserved for carrying error codes specific to the cryptographic handshake that is used. Codes for errors occurring when TLS is used for the cryptographic handshake are described in Section 4.8 of [QUIC-TLS].


from the diff (https://www.rfc-editor.org/authors/rfc9000-diff.html): 
   CRYPTO_ERROR (0x1XX): (0x0100-0x01ff):  The cryptographic handshake failed.  A
      range of 256 values is reserved for carrying error codes specific
      to the cryptographic handshake that is used.  Codes for errors
      occurring when TLS is used for the crypto cryptographic handshake are
      described in Section 4.8 of [QUIC-TLS].

2) Section 22.3: https://www.rfc-editor.org/authors/rfc9000.html#section-22.3

IANA has added a registry for "QUIC Transport Parameters" under a "QUIC" heading.

The "QUIC Transport Parameters" registry governs a 62-bit space. This registry follows the registration policy from Section 22.1. Permanent registrations in this registry are assigned using the Specification Required policy (Section 4.6 of [RFC8126]), except for values between 0x00 and 0x3f (in hexadecimal), inclusive, which are assigned using Standards Action or IESG Approval as defined in Sections 4.9 and 4.10 of [RFC8126].



from the diff (https://www.rfc-editor.org/authors/rfc9000-diff.html):

   IANA [SHALL add/has added] has added a registry for "QUIC Transport Parameters" under a
   "QUIC" heading.

   The "QUIC Transport Parameters" registry governs a 62-bit space.
   This registry follows the registration policy from Section 22.1.
   Permanent registrations in this registry are assigned using the
   Specification Required policy ([RFC8126]). (Section 4.6 of [RFC8126]), except for
   values between 0x00 and 0x3f (in hexadecimal), inclusive, which are
   assigned using Standards Action or IESG Approval as defined in
   Sections 4.9 and 4.10 of [RFC8126].

3) Section 22.5: https://www.rfc-editor.org/authors/rfc9000.html#table-7

The following has been added as the last row in Table 7:
22.5.  QUIC Transport Error Codes Registry
   … 
   +------+---------------------------+----------------+---------------+
   |0x0100| CRYPTO_ERROR              |TLS alert code  | Section 20    |
   |-     |                           |                |               |
   |0x01ff|                           |                |               |
   +------+---------------------------+----------------+---------------+


When you get a chance, please update the registry as needed and let us know when the action is complete.

Thanks!
Sandy 




> 
> thanks,
> Amanda
> 
> On Thu Apr 29 22:56:34 2021, amanda.baber wrote:
>> Hi Sandy,
>> 
>> On Thu Apr 29 21:46:15 2021, [e-mail] wrote:
>>> Hi Amanda,
>>> 
>>> Regarding the "QUIC Transport Error Codes“ registry:
>>> https://www.iana.org/assignments/quic/quic.xhtml#quic-transport-
>>> error-
>>> codes <https://www.iana.org/assignments/quic/quic.xhtml#quic-
>>> transport-error-codes>
>>> 
>>> 
>>> For section 20.1 <https://www.ietf.org/archive/id/draft-ietf-quic-
>>> transport-34.html#section-20.1>, does anything need to be marked on
>>> the IANA page regarding this range?  It’s not listed in the IANA
>>> Considerations section — it’s only mentioned in section 20.1.  Should
>>> anything appear in the IANA Considerations section or is this just
>>> guidance in the doc for IANA?
>>> 
>>> CRYPTO_ERROR (0x1XX):
>>> The cryptographic handshake failed. A range of 256 values is reserved
>>> for carrying error codes specific to the cryptographic handshake that
>>> is used. Codes for errors occurring when TLS is used for the crypto
>>> handshake are described in Section 4.8 of [QUIC-TLS
>>> <https://www.ietf.org/archive/id/draft-ietf-quic-transport-
>>> 34.html#QUIC-TLS>].
>> 
>> It does look like 0x100-0x1FF (or possibly 0x0100-0x01FF, or 0x01xx; I
>> think that for the HTTP/3 document they wanted padding to the byte?)
>> does need to be recorded in the registry in some form. How would they
>> want this entry filled in?
>> 
>>> Also, would you please update the capitalization of the description
>>> to
>>> match what appears in the I-D and the other items in the registry:
>>> 
>>> https://www.ietf.org/archive/id/draft-ietf-quic-transport-
>>> 34.html#iana-error-table <https://www.ietf.org/archive/id/draft-ietf-
>>> quic-transport-34.html#iana-error-table>
>>> 
>>> 
>>> IANA:
>>> 0x00    NO_ERROR        no error
>>> 
>>> 
>>> Current doc (caps was used in the original I-D):
>>> 0x00    NO_ERROR        No error
>> 
>> Done:
>> 
>> https://www.iana.org/assignments/quic/quic.xhtml#quic-transport-error-
>> codes
>> 
>> thanks,
>> Amanda
>> 
>> 
>>> Thanks!
>>> Sandy
>>> 
>>> 
>>> 
>>> 
>>>> On Feb 11, 2021, at 8:32 PM, Amanda Baber via RT <drafts-
>>>> [e-mail]> wrote:
>>>> 
>>>> RFC Editor:
>>>> 
>>>> NOTE: with the authors' permission, we've added padding to the
>>>> values
>>>> in Table 7 to match other QUIC registries (e.g. 0x00 instead of
>>>> 0x0)
>>>> and changed "Received" in that table to "received."
>>>> 
>>>> We've completed the registry actions for the following RFC-to-be:
>>>> 
>>>> draft-ietf-quic-transport-34
>>>> 
>>>> IANA has created the QUIC Versions, QUIC Transport Parameters, QUIC
>>>> Frame Types, and QUIC Transport Error Codes under the "QUIC"
>>>> heading
>>>> at
>>>> 
>>>> Please see
>>>> https://www.iana.org/assignments/quic
>>>> 
>>>> Please reply to this message to acknowledge receipt of these
>>>> actions.
>>>> 
>>>> Please let us know when an RFC number has been assigned and the
>>>> date
>>>> of publication by sending a new message to <drafts-update-
>>>> [e-mail]>.
>>>> 
>>>> Thanks,
>>>> 
>>>> Amanda Baber
>>>> Lead IANA Services Specialist
>>>> 
>