> Begin forwarded message: > > From: "Sabrina Tanamal via RT" <[email protected]> > 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: [email protected], [email protected], [email protected], [email protected], > [email protected], [email protected], > [email protected], [email protected] > Reply-To: [email protected] > > (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) >
signature.asc
Description: Message signed with OpenPGP
