Fwd: [IANA #1180853] Last Call: <draft-ietf-quic-transport-32.txt> (QUIC: A UDP-Based Multiplexed and Secure Transport) to Proposed Standard

[Lars Eggert <[e-mail]>]

> Begin forwarded message:
> 
> From: "Sabrina Tanamal via RT" <[e-mail]>
> Subject: [IANA #1180853] Last Call: <draft-ietf-quic-transport-32.txt> (QUIC: A UDP-Based Multiplexed and Secure Transport) to Proposed Standard
> Date: November 16, 2020 at 21:45:41 GMT+2
> Cc: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
> Reply-To: [e-mail]
> 
> (BEGIN IANA COMMENTS)
> 
> IESG/Authors/WG Chairs:
> 
> The IANA Functions Operator has completed its review of draft-ietf-quic-transport-32. If any part of this review is inaccurate, please let us know.
> 
> The IANA Functions Operator has questions about the actions requested in the IANA Considerations section of this document.
> 
> The IANA Functions Operator understands that, upon approval of this document, there are four actions which we must complete.
> 
> First, a new registry page will be created on the IANA Matrix located at:
> 
> https://www.iana.org/protocols
> 
> the new registry page will be titled "QUIC" and have a reference of [ RFC-to-be ].
> 
> IANA Question --> Regarding the detailed instructions in section 22.1 of the current document, it's not clear to us what information should be captured in a note. Can you provide the notes that should be added to the top of each registry?
> 
> Second, a new registry will be created on the registry page created above called the QUIC Transport Parameters registry. The new registry will be managed via the Specification Required policy as defined by RFC8126.
> 
> IANA will add a note to the registry indicating that: " each value of the format "31 * N + 27" for integer values of N (that is, 27, 58, 89, ...) are reserved."
> 
> IANA Question --> are those values to be marked as reserved in the new registry?
> 
> IANA Question --> Section 22.1.2 says, "Use of the first codepoint in a range is
> intended for use by specifications that are developed through the
> standards process [STD] and its allocation MUST be negotiated with
> IANA before use."
> 
> What does "negotiation with IANA" mean? When there's an expert, normally this would be handled by an expert, but we understand that future documents might use this guidance but apply it to registries that have other registration procedures. Does this mean that if IESG Approval were being used, or a future registry that applied this guidance were to use a registration procedure like IETF Review, which requires only an IETF-stream RFC and does not require expert review, and the registration were being requested in an informational or experimental I-D, IANA would need to be aware of this requirement and refuse to register that codepoint? We really want to know what IANA has to know vs. what the other people such as the expert have to know.
> 
> Also, does this mean that codepoints can generally be used before they've been allocated?
> 
> IANA Question --> Section 22.1.2 says, "Applications to register codepoints in QUIC registries MAY include a codepoint as part of the registration.  IANA MUST allocate the selected codepoint unless that codepoint is already assigned or the
> codepoint is the first unallocated codepoint in the registry."
> 
> What if it's the first unallocated codepoint in a range, but not in the registry?
> 
> There are initial registrations in the new registry as follows:
> 
> +=======+=====================================+=============================+
> | Value | Parameter Name | Reference |
> +=======+=====================================+=============================+
> | 0x00 | original_destination_connection_id | [ RFC-to-be Section 18.2 ] |
> +-------+-------------------------------------+-----------------------------+
> | 0x01 | max_idle_timeout | [ RFC-to-be Section 18.2 ] |
> +-------+-------------------------------------+-----------------------------+
> | 0x02 | stateless_reset_token | [ RFC-to-be Section 18.2 ] |
> +-------+-------------------------------------+-----------------------------+
> | 0x03 | max_udp_payload_size | [ RFC-to-be Section 18.2 ] |
> +-------+-------------------------------------+-----------------------------+
> | 0x04 | initial_max_data | [ RFC-to-be Section 18.2 ] |
> +-------+-------------------------------------+-----------------------------+
> | 0x05 | initial_max_stream_data_bidi_local | [ RFC-to-be Section 18.2 ] |
> +-------+-------------------------------------+-----------------------------+
> | 0x06 | initial_max_stream_data_bidi_remote | [ RFC-to-be Section 18.2 ] |
> +-------+-------------------------------------+-----------------------------+
> | 0x07 | initial_max_stream_data_uni | [ RFC-to-be Section 18.2 ] |
> +-------+-------------------------------------+-----------------------------+
> | 0x08 | initial_max_streams_bidi | [ RFC-to-be Section 18.2 ] |
> +-------+-------------------------------------+-----------------------------+
> | 0x09 | initial_max_streams_uni | [ RFC-to-be Section 18.2 ] |
> +-------+-------------------------------------+-----------------------------+
> | 0x0a | ack_delay_exponent | [ RFC-to-be Section 18.2 ] |
> +-------+-------------------------------------+-----------------------------+
> | 0x0b | max_ack_delay | [ RFC-to-be Section 18.2 ] |
> +-------+-------------------------------------+-----------------------------+
> | 0x0c | disable_active_migration | [ RFC-to-be Section 18.2 ] |
> +-------+-------------------------------------+-----------------------------+
> | 0x0d | preferred_address | [ RFC-to-be Section 18.2 ] |
> +-------+-------------------------------------+-----------------------------+
> | 0x0e | active_connection_id_limit | [ RFC-to-be Section 18.2 ] | +-------+-------------------------------------+-----------------------------+
> | 0x0f | initial_source_connection_id | [ RFC-to-be Section 18.2 ] |
> +-------+-------------------------------------+-----------------------------+
> | 0x10 | retry_source_connection_id | [ RFC-to-be Section 18.2 ] |
> +-------+-------------------------------------+-----------------------------+
> 
> Third, a new registry will be created on the QUIC registry page created above called the QUIC Frame Types registry.
> 
> The registration policy for the new registry is as follows:
> 
> 0x00 - 0x3f - Standards Action or IESG Approval
> 0x40 - 3FFFFFFFFFFFFFFF - Specification Required
> 
> There are initial registrations in the new registry as follows:
> 
> +=============+======================+=============================+
> | Type Value | Frame Type Name | Definition |
> +=============+======================+=============================+
> | 0x00 | PADDING | [ RFC-to-be Section 19.1 ] |
> +-------------+----------------------+-----------------------------+
> | 0x01 | PING | [ RFC-to-be Section 19.2 ] |
> +-------------+----------------------+-----------------------------+
> | 0x02 - 0x03 | ACK | [ RFC-to-be Section 19.3 ] |
> +-------------+----------------------+-----------------------------+
> | 0x04 | RESET_STREAM | [ RFC-to-be Section 19.4 ] |
> +-------------+----------------------+-----------------------------+
> | 0x05 | STOP_SENDING | [ RFC-to-be Section 19.5 ] |
> +-------------+----------------------+-----------------------------+
> | 0x06 | CRYPTO | [ RFC-to-be Section 19.6 ] |
> +-------------+----------------------+-----------------------------+
> | 0x07 | NEW_TOKEN | [ RFC-to-be Section 19.7 ] |
> +-------------+----------------------+-----------------------------+
> | 0x08 - 0x0f | STREAM | [ RFC-to-be Section 19.8 ] |
> +-------------+----------------------+-----------------------------+
> | 0x10 | MAX_DATA | [ RFC-to-be Section 19.9 ] |
> +-------------+----------------------+-----------------------------+
> | 0x11 | MAX_STREAM_DATA | [ RFC-to-be Section 19.10 ] |
> +-------------+----------------------+-----------------------------+
> | 0x12 - 0x13 | MAX_STREAMS | [ RFC-to-be Section 19.11 ] |
> +-------------+----------------------+---------------+
> | 0x14 | DATA_BLOCKED | [ RFC-to-be Section 19.12 ] |
> +-------------+----------------------+-----------------------------+
> | 0x15 | STREAM_DATA_BLOCKED | [ RFC-to-be Section 19.13 ] |
> +-------------+----------------------+-----------------------------+
> | 0x16 - 0x17 | STREAMS_BLOCKED | [ RFC-to-be Section 19.14 ] |
> +-------------+----------------------+-----------------------------+
> | 0x18 | NEW_CONNECTION_ID | [ RFC-to-be Section 19.15 ] |
> +-------------+----------------------+-----------------------------+
> | 0x19 | RETIRE_CONNECTION_ID | [ RFC-to-be Section 19.16 ] |
> +-------------+----------------------+-----------------------------+
> | 0x1a | PATH_CHALLENGE | [ RFC-to-be Section 19.17 ] |
> +-------------+----------------------+-----------------------------+
> | 0x1b | PATH_RESPONSE | [ RFC-to-be Section 19.18 ] |
> +-------------+----------------------+-----------------------------+
> | 0x1c - 0x1d | CONNECTION_CLOSE | [ RFC-to-be Section 19.19 ] |
> +-------------+----------------------+-----------------------------+
> | 0x1e | HANDSHAKE_DONE | [ RFC-to-be Section 19.20 ] |
> +-------------+----------------------+-----------------------------+
> 
> Fourth, a new registry will be created on the QUIC registry page created above called the QUIC Error Codes registry.
> 
> The registration policy for the new registry is as follows:
> 
> 0x00 - 0x3f - Standards Action or IESG Approval
> 0x40 - 3FFFFFFFFFFFFFFF - Specification Required
> 
> There are initial registrations in the new registry as follows:
> 
> +======+===========================+================+=============================+
> |Value | Error |Description | Specification |
> +======+===========================+================+=============================+
> |0x0 | NO_ERROR |No error | [ RFC-to-be Section 20 ] |
> +------+---------------------------+----------------+-----------------------------+
> |0x1 | INTERNAL_ERROR |Implementation | [ RFC-to-be Section 20 ] |
> | | |error | |
> +------+---------------------------+----------------+-----------------------------+
> |0x2 | CONNECTION_REFUSED |Server refuses a| [ RFC-to-be Section 20 ] |
> | | |connection | |
> +------+---------------------------+----------------+-----------------------------+
> |0x3 | FLOW_CONTROL_ERROR |Flow control | [ RFC-to-be Section 20 ] |
> | | |error | |
> +------+---------------------------+----------------+-----------------------------+
> |0x4 | STREAM_LIMIT_ERROR |Too many streams| [ RFC-to-be Section 20 ] |
> | | |opened | |
> +------+---------------------------+----------------+-----------------------------+
> |0x5 | STREAM_STATE_ERROR |Frame received | [ RFC-to-be Section 20 ] |
> | | |in invalid | |
> | | |stream state | |
> +------+---------------------------+----------------+-----------------------------+
> |0x6 | FINAL_SIZE_ERROR |Change to final | [ RFC-to-be Section 20 ] |
> | | |size | |
> +------+---------------------------+----------------+-----------------------------+
> |0x7 | FRAME_ENCODING_ERROR |Frame encoding | [ RFC-to-be Section 20 ] |
> | | |error | |
> +------+---------------------------+----------------+-----------------------------+
> |0x8 | TRANSPORT_PARAMETER_ERROR |Error in | [ RFC-to-be Section 20 ] |
> | | |transport | |
> | | |parameters | |
> +------+---------------------------+----------------+-----------------------------+
> |0x9 | CONNECTION_ID_LIMIT_ERROR |Too many | [ RFC-to-be Section 20 ] |
> | | |connection IDs | |
> | | |received | |
> +------+---------------------------+----------------+-----------------------------+
> |0xa | PROTOCOL_VIOLATION |Generic protocol| [ RFC-to-be Section 20 ] |
> | | |violation | |
> +------+---------------------------+----------------+-----------------------------+
> |0xb | INVALID_TOKEN |Invalid Token | [ RFC-to-be Section 20 ] |
> | | |Received | |
> +------+---------------------------+----------------+-----------------------------+
> |0xc | APPLICATION_ERROR |Application | [ RFC-to-be Section 20 ] |
> | | |error | |
> +------+---------------------------+----------------+-----------------------------+
> |0xd | CRYPTO_BUFFER_EXCEEDED |CRYPTO data | [ RFC-to-be Section 20 ] |
> | | |buffer | |
> | | |overflowed | |
> +------+---------------------------+----------------+-----------------------------+
> |0xe | KEY_UPDATE_ERROR |Invalid packet | [ RFC-to-be Section 20 ] |
> | | |protection | |
> | | |update | |
> +------+---------------------------+----------------+-----------------------------+
> |0xf | AEAD_LIMIT_REACHED |Excessive use of| [ RFC-to-be Section 20 ] |
> | | |packet | |
> | | |protection keys | |
> +------+---------------------------+----------------+-----------------------------+
> 
> The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.
> 
> Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.
> 
> Thank you,
> 
> Sabrina Tanamal
> Senior IANA Services Specialist
> 
> (END IANA COMMENTS)
>