single QUIC packet.  If it does not, then older ranges (those with the smallest packet numbers) are omitted. <del> ack-tracking and ack-limiting describe an exemplary approach for determining what packets to acknowledge in each ACK frame.  Though the goal of these algorithms is to generate an acknowledgment for every packet that is processed, it is still possible for acknowledgments to be lost.  A sender cannot expect to receive an acknowledgment for every packet that the receiver processes. 13.2.4. When a packet containing an ACK frame is sent, the largest acknowledged in that frame may be saved.  When a packet containing an ACK frame is acknowledged, the receiver can stop acknowledging packets less than or equal to the largest acknowledged in the sent ACK frame. In cases without ACK frame loss, this algorithm allows for a minimum of 1 RTT of reordering.  In cases with ACK frame loss and reordering, this approach does not guarantee that every acknowledgement is seen by the sender before it is no longer included in the ACK frame. Packets could be received out of order and all subsequent ACK frames containing them could be lost.  In this case, the loss recovery algorithm could cause spurious retransmissions, but the sender will continue making forward progress. 13.2.5. </del> A receiver limits the number of ACK Ranges (ack-ranges) it remembers and sends in ACK frames, both to limit the size of ACK frames and to avoid resource exhaustion.  After receiving acknowledgments for an ACK frame, the receiver SHOULD stop tracking those acknowledged ACK <del> Ranges. </del> <ins> Ranges.  Senders can expect acknowledgements for most packets, but QUIC does not guarantee receipt of an acknowledgment for every packet that the receiver processes. </ins> It is possible that retaining many ACK Ranges could cause an ACK frame to become too large.  A receiver can discard unacknowledged ACK


value than what was included in a previous ACK frame could cause ECN to be unnecessarily disabled; see ecn-validation. <ins> ack-tracking describes an exemplary approach for determining what packets to acknowledge in each ACK frame.  Though the goal of this algorithm is to generate an acknowledgment for every packet that is processed, it is still possible for acknowledgments to be lost. 13.2.4. When a packet containing an ACK frame is sent, the largest acknowledged in that frame may be saved.  When a packet containing an ACK frame is acknowledged, the receiver can stop acknowledging packets less than or equal to the largest acknowledged in the sent ACK frame. </ins> A receiver that sends only non-ack-eliciting packets, such as ACK frames, might not receive an acknowledgement for a long period of time.  This could cause the receiver to maintain state for a large


send a PING or other small ack-eliciting frame occasionally, such as once per round trip, to elicit an ACK from the peer. <del> A receiver MUST NOT send an ack-eliciting frame in all packets that would otherwise be non-ack-eliciting, to avoid an infinite feedback loop of acknowledgements. </del> <ins> In cases without ACK frame loss, this algorithm allows for a minimum of 1 RTT of reordering.  In cases with ACK frame loss and reordering, this approach does not guarantee that every acknowledgement is seen by the sender before it is no longer included in the ACK frame. Packets could be received out of order and all subsequent ACK frames containing them could be lost.  In this case, the loss recovery algorithm could cause spurious retransmissions, but the sender will continue making forward progress. </ins> <del> 13.2.6. </del> <ins> 13.2.5. </ins> An endpoint measures the delays intentionally introduced between the time the packet with the largest packet number is received and the


packets, the ACK Delay field in acknowledgements for those packet types SHOULD be set to 0. <del> 13.2.7. </del> <ins> 13.2.6. </ins> ACK frames MUST only be carried in a packet that has the same packet number space as the packet being acknowledged; see packet-protected.


Note that the same limitation applies to other data sent by the server protected by the 1-RTT keys. <del> 13.2.8. </del> <ins> 13.2.7. </ins> Packets containing PADDING frames are considered to be in flight for congestion control purposes QUIC-RECOVERY.  Packets containing only


connection ID. If the spin bit is enabled for the connection, the endpoint maintains <del> a spin value and sets the spin bit in the short header to the currently stored value when a packet with a short header is sent out. The spin value is initialized to 0 in the endpoint at connection start.  Each endpoint also remembers the highest packet number seen from its peer on the connection. When a server receives a short header packet that increments the highest packet number seen by the server from the client, it sets the spin value to be equal to the spin bit in the received packet. When a client receives a short header packet that increments the highest packet number seen by the client from the server, it sets the spin value to the inverse of the spin bit in the received packet. An endpoint resets its spin value to zero when sending the first packet of a given connection with a new connection ID.  This reduces the risk that transient spin bit state can be used to link flows across connection migration or ID change. </del> <ins> a spin value for each network path and sets the spin bit in the short header to the currently stored value when a packet with a short header is sent on that path.  The spin value is initialized to 0 in the endpoint for each network path.  Each endpoint also remembers the highest packet number seen from its peer on each path. When a server receives a short header packet that increases the highest packet number seen by the server from the client on a given network path, it sets the spin value for that path to be equal to the spin bit in the received packet. When a client receives a short header packet that increases the highest packet number seen by the client from the server on a given network path, it sets the spin value for that path to the inverse of the spin bit in the received packet. An endpoint resets the spin value for a network path to zero when changing the connection ID being used on that network path. </ins> With this mechanism, the server reflects the spin value received, while the client 'spins' it after one RTT.  On-path observers can


path via the attacker.  This places the attacker on path, giving it the ability to observe or drop all subsequent packets. <del> Unlike the attack described in on-path-spoofing, the attacker can ensure that the new path is successfully validated. </del> This style of attack relies on the attacker using a path that is approximately as fast as the direct path between endpoints.  The attack is more reliable if relatively few packets are sent or if


assumed to be implicitly reset. After sending a CONNECTION_CLOSE frame, an endpoint immediately <del> enters the closing state. </del> <ins> enters the closing state; see closing.  After receiving a CONNECTION_CLOSE frame, endpoints enter the draining state; see draining. </ins> <del> During the closing period, an endpoint that sends a CONNECTION_CLOSE frame SHOULD respond to any incoming packet that can be decrypted with another packet containing a CONNECTION_CLOSE frame.  Such an endpoint SHOULD limit the number of packets it generates containing a CONNECTION_CLOSE frame.  For instance, an endpoint could wait for a </del> <ins> An immediate close can be used after an application protocol has arranged to close a connection.  This might be after the application protocol negotiates a graceful shutdown.  The application protocol can exchange messages that are needed for both application endpoints to agree that the connection can be closed, after which the application requests that QUIC close the connection.  When QUIC consequently closes the connection, a CONNECTION_CLOSE frame with an application-supplied error code will be used to signal closure to the peer. The closing and draining connection states exist to ensure that connections close cleanly and that delayed or reordered packets are properly discarded.  These states SHOULD persist for at least three times the current Probe Timeout (PTO) interval as defined in QUIC- RECOVERY. Disposing of connection state prior to exiting the closing or draining state could cause could result in an endpoint generating a stateless reset unnecessarily when it receives a late-arriving packet.  Endpoints that have some alternative means to ensure that late-arriving packets do not induce a response, such as those that are able to close the UDP socket, MAY end these states earlier to allow for faster resource recovery.  Servers that retain an open socket for accepting new connections SHOULD NOT end the closing or draining states early. Once its closing or draining state ends, an endpoint SHOULD discard all connection state.  The endpoint MAY send a stateless reset in response to any further incoming packets belonging to this connection. 10.2.1. An endpoint enters the closing state after initiating an immediate close. In the closing state, an endpoint retains only enough information to generate a packet containing a CONNECTION_CLOSE frame and to identify packets as belonging to the connection.  An endpoint in the closing state sends a packet containing a CONNECTION_CLOSE frame in response to any incoming packet that it attributes to the connection. An endpoint SHOULD limit the rate at which it generates packets in the closing state.  For instance, an endpoint could wait for a </ins> progressively increasing number of received packets or amount of time <del> before responding to a received packet. An endpoint is allowed to drop the packet protection keys when entering the closing period (draining) and send a packet containing a CONNECTION_CLOSE in response to any UDP datagram that is received. However, an endpoint without the packet protection keys cannot identify and discard invalid packets.  To avoid creating an unwitting amplification attack, such endpoints MUST limit the cumulative size of packets containing a CONNECTION_CLOSE frame to 3 times the cumulative size of the packets that cause those packets to be sent. To minimize the state that an endpoint maintains for a closing connection, endpoints MAY send the exact same packet. </del> <ins> before responding to received packets. An endpoint's selected connection ID and the QUIC version are sufficient information to identify packets for a closing connection; the endpoint MAY discard all other connection state.  An endpoint that is closing is not required to process any received frame.  An endpoint MAY retain packet protection keys for incoming packets to allow it to read and process a CONNECTION_CLOSE frame. An endpoint MAY drop packet protection keys when entering the closing state and send a packet containing a CONNECTION_CLOSE frame in response to any UDP datagram that is received.  However, an endpoint that discards packet protection keys cannot identify and discard invalid packets.  To avoid being used for an amplication attack, such endpoints MUST limit the cumulative size of packets it sends to three times the cumulative size of the packets that are received and attributed to the connection.  To minimize the state that an endpoint maintains for a closing connection, endpoints MAY send the exact same packet in response to any received packet. </ins> Allowing retransmission of a closing packet is an exception to the requirement that a new packet number be used for each packet in


expected to be relevant for a closed connection.  Retransmitting the final packet requires less state. <del> New packets from unverified addresses could be used to create an amplification attack; see address-validation.  To avoid this, endpoints MUST either limit transmission of CONNECTION_CLOSE frames to validated addresses or drop packets without response if the response would be more than three times larger than the received packet. After receiving a CONNECTION_CLOSE frame, endpoints enter the draining state.  An endpoint that receives a CONNECTION_CLOSE frame MAY send a single packet containing a CONNECTION_CLOSE frame before entering the draining state, using a CONNECTION_CLOSE frame and a NO_ERROR code if appropriate.  An endpoint MUST NOT send further packets, which could result in a constant exchange of CONNECTION_CLOSE frames until the closing period on either peer ended. </del> <ins> While in the closing state, an endpoint could receive packets from a new source address, possibly indicating a connection migration; see migration.  An endpoint in the closing state MUST either discard packets received from an unvalidated address or limit the cumulative size of packets it sends to an unvalidated address to three times the size of packets it receives from that address. </ins> <del> An immediate close can be used after an application protocol has arranged to close a connection.  This might be after the application protocols negotiates a graceful shutdown.  The application protocol exchanges whatever messages that are needed to cause both endpoints to agree to close the connection, after which the application requests that the connection be closed.  When the application closes the connection, a CONNECTION_CLOSE frame with an appropriate error code will be used to signal closure. 10.2.1. </del> <ins> An endpoint is not expected to handle key updates when it is closing (Section 6 of QUIC-TLS).  A key update might prevent the endpoint from moving from the closing state to the draining state, as the endpoint will not be able to process subsequently received packets, but it otherwise has no impact. 10.2.2. The draining state is entered once an endpoint receives a CONNECTION_CLOSE frame, which indicates that its peer is closing or draining.  While otherwise identical to the closing state, an endpoint in the draining state MUST NOT send any packets.  Retaining packet protection keys is unnecessary once a connection is in the draining state. An endpoint that receives a CONNECTION_CLOSE frame MAY send a single packet containing a CONNECTION_CLOSE frame before entering the draining state, using a NO_ERROR code if appropriate.  An endpoint MUST NOT send further packets.  Doing so could result in a constant exchange of CONNECTION_CLOSE frames until one of the endpoints exits the closing state. An endpoint MAY enter the draining state from the closing state if it receives a CONNECTION_CLOSE frame, which indicates that the peer is also closing or draining.  In this case, the draining state SHOULD end when the closing state would have ended.  In other words, the endpoint uses the same end time, but ceases transmission of any packets on this connection. 10.2.3. </ins> When sending CONNECTION_CLOSE, the goal is to ensure that the peer will process the frame.  Generally, this means sending the frame in a


of broken connections where only very small packets are sent; such failures might only be detected by other means, such as timers. <del> 10.4. The closing and draining connection states exist to ensure that connections close cleanly and that delayed or reordered packets are properly discarded.  These states SHOULD persist for at least three times the current Probe Timeout (PTO) interval as defined in QUIC- RECOVERY. An endpoint enters a closing period after initiating an immediate close; immediate-close.  While closing, an endpoint MUST NOT send packets unless they contain a CONNECTION_CLOSE frame; see immediate- close for details.  An endpoint retains only enough information to generate a packet containing a CONNECTION_CLOSE frame and to identify packets as belonging to the connection.  The endpoint's selected connection ID and the QUIC version are sufficient information to identify packets for a closing connection; an endpoint can discard all other connection state.  An endpoint MAY retain packet protection keys for incoming packets to allow it to read and process a CONNECTION_CLOSE frame. The draining state is entered once an endpoint receives a signal that its peer is closing or draining.  While otherwise identical to the closing state, an endpoint in the draining state MUST NOT send any packets.  Retaining packet protection keys is unnecessary once a connection is in the draining state. An endpoint MAY transition from the closing period to the draining period if it receives a CONNECTION_CLOSE frame or stateless reset, both of which indicate that the peer is also closing or draining. The draining period SHOULD end when the closing period would have ended.  In other words, the endpoint can use the same end time, but cease retransmission of the closing packet. Disposing of connection state prior to the end of the closing or draining period could cause delayed or reordered packets to generate an unnecessary stateless reset.  Endpoints that have some alternative means to ensure that late-arriving packets on the connection do not induce a response, such as those that are able to close the UDP socket, MAY use an abbreviated draining period to allow for faster resource recovery.  Servers that retain an open socket for accepting new connections SHOULD NOT exit the closing or draining period early. Once the closing or draining period has ended, an endpoint SHOULD discard all connection state.  This results in new packets on the connection being handled generically.  For instance, an endpoint MAY send a stateless reset in response to any further incoming packets. The draining and closing periods do not apply when a stateless reset (stateless-reset) is sent. An endpoint is not expected to handle key updates when it is closing or draining.  A key update might prevent the endpoint from moving from the closing state to draining, but it otherwise has no impact. While in the closing period, an endpoint could receive packets from a new source address, indicating a connection migration; migration.  An endpoint in the closing state MUST strictly limit the number of packets it sends to this new address until the address is validated; see migrate-validate.  A server in the closing state MAY instead choose to discard packets received from a new source address. </del> 11. An endpoint that detects an error SHOULD signal the existence of that


semantics and encodings for any version-specific field.  In particular, different packet protection keys might be used for different versions.  Servers that do not support a particular version <del> are unlikely to be able to decrypt the payload of the packet. Servers SHOULD NOT attempt to decode or decrypt a packet from an unknown version, but instead send a Version Negotiation packet, provided that the packet is sufficiently long. </del> <ins> are unlikely to be able to decrypt the payload of the packet or properly interpret the result.  Servers SHOULD respond with a Version Negotiation packet, provided that the datagram is sufficiently long. </ins> Packets with a supported version, or no version field, are matched to a connection using the connection ID or - for packets with zero-


between a specific local address and a specific peer address, where an address is the two-tuple of IP address and port. <del> Path validation tests that packets can be both sent to (PATH_CHALLENGE) and received from (PATH_RESPONSE) a peer on the path.  Importantly, it validates that the packets received from the migrating endpoint do not carry a spoofed source address. </del> <ins> Path validation tests that packets sent on a path to a peer are received by that peer.  Path validation is used to ensure that packets received from a migrating peer do not carry a spoofed source address. Path validation does not validate that a peer can send in the return direction.  The peer performs independent validation of the return path. </ins> Path validation can be used at any time by either endpoint.  For instance, an endpoint might check that a peer is still in possession


8.3. To initiate path validation, an endpoint sends a PATH_CHALLENGE frame <del> containing a random payload on the path to be validated. </del> <ins> containing an unpredictable payload on the path to be validated. </ins> An endpoint MAY send multiple PATH_CHALLENGE frames to guard against packet loss.  However, an endpoint SHOULD NOT send multiple


On receiving a PATH_CHALLENGE frame, an endpoint MUST respond by echoing the data contained in the PATH_CHALLENGE frame in a <del> PATH_RESPONSE frame.  An endpoint MUST NOT delay transmission of a packet containing a PATH_RESPONSE frame unless constrained by congestion control. </del> <ins> PATH_RESPONSE frame.  A PATH_RESPONSE frame does not need to be sent on the network path where the PATH_CHALLENGE was received; a PATH_RESPONSE can be sent on any network path.  An endpoint MUST NOT delay transmission of a packet containing a PATH_RESPONSE frame unless constrained by congestion control. </ins> An endpoint MUST NOT send more than one PATH_RESPONSE frame in response to one PATH_CHALLENGE frame; see retransmission-of-


8.5. <del> A new address is considered valid when a PATH_RESPONSE frame is received that contains the data that was sent in a previous PATH_CHALLENGE frame.  Receipt of an acknowledgment for a packet containing a PATH_CHALLENGE frame is not adequate validation, since the acknowledgment can be spoofed by a malicious peer. </del> <ins> Path validation succeeds when a PATH_RESPONSE frame is received that contains the data that was sent in a previous PATH_CHALLENGE frame. This validates the path on which the PATH_CHALLENGE was sent. Receipt of an acknowledgment for a packet containing a PATH_CHALLENGE frame is not adequate validation, since the acknowledgment can be spoofed by a malicious peer. </ins> 8.6.


initial timeout (that is, 2*kInitialRtt) as defined in QUIC-RECOVERY is RECOMMENDED.  That is: <ins> This timeout allows for multiple PTOs to expire prior to failing path validation, so that loss of a single PATH_CHALLENGE or PATH_RESPONSE frame does not cause path validation failure. </ins> Note that the endpoint might receive packets containing other frames on the new path, but a PATH_RESPONSE frame with appropriate data is required for path validation to succeed.


To avoid excessively small idle timeout periods, endpoints MUST increase the idle timeout period to be at least three times the <del> current Probe Timeout (PTO). </del> <ins> current Probe Timeout (PTO).  This allows for multiple PTOs to expire prior to idle timeout, ensuring the idle timeout does not expire as a result of a single packet loss. </ins> 10.1.1.


sequence 7b bd decodes to 15293; and the single byte 25 decodes to 37 (as does the two byte sequence 40 25). <del> Versions (versions) and error codes (error-codes) are described using integers, but do not use this encoding. </del> <ins> Versions (versions) and packet numbers sent in the header (packet- encoding) are described using integers, but do not use this encoding. </ins> 17.


If the packet is from a new encryption level, it is saved for later processing by TLS.  Once TLS moves to receiving from this <del> encryption level, saved data can be provided to TLS.  When providing data from any new encryption level to TLS, if there is data from a previous encryption level that TLS has not consumed, this MUST be treated as a connection error of type PROTOCOL_VIOLATION. </del> <ins> encryption level, saved data can be provided to TLS.  When TLS provides keys for a higher encryption level, if there is data from a previous encryption level that TLS has not consumed, this MUST be treated as a connection error of type PROTOCOL_VIOLATION. </ins> Each time that TLS is provided with new data, new handshake bytes are requested from TLS.  TLS might not provide any bytes if the handshake


expiration, as TCP does with Tail Loss Probes (RACK) and a Retransmission Timeout (RFC5681). <ins> Larger values of kPersistentCongestionThreshold cause the sender to become less responsive to persistent congestion in the network, which can result in aggressive sending into a congested network.  Too small a value can result in a sender declaring persistent congestion unnecessarily, resulting in reduced throughput for the sender. </ins> The RECOMMENDED value for kPersistentCongestionThreshold is 3, which <del> is approximately equivalent to two TLPs before an RTO in TCP. </del> <ins> results in behavior that is approximately equivalent to a TCP sender declaring an RTO after two TLPs. </ins> This design does not use consecutive PTO events to establish persistent congestion, since application patterns impact PTO


The total length of time over which consecutive PTOs expire is limited by the idle timeout. <del> The probe timer MUST NOT be set if the time threshold (time- threshold) loss detection timer is set.  The time threshold loss detection timer is expected to both expire earlier than the PTO and be less likely to spuriously retransmit data. </del> <ins> The PTO timer MUST NOT be set if a timer is set for time threshold loss detection; see time-threshold.  A timer that is set for time threshold loss detection will expire earlier than the PTO timer in most cases and is less likely to spuriously retransmit data. </ins> 6.2.2.


certain that it has not processed another packet with the same packet number from the same packet number space.  Duplicate suppression MUST happen after removing packet protection for the reasons described in <del> Section 9.3 of QUIC-TLS. </del> <ins> Section 9.5 of QUIC-TLS. </ins> Endpoints that track all individual packets for the purposes of detecting duplicates are at risk of accumulating excessive state.


both packet and header protection as a connection error of type PROTOCOL_VIOLATION.  Discarding such a packet after only removing header protection can expose the endpoint to attacks; see <del> Section 9.3 of QUIC-TLS. </del> <ins> Section 9.5 of QUIC-TLS. </ins> In packet types that contain a Packet Number field, the least significant two bits (those with a mask of 0x03) of byte 0 contain


and header protection, as a connection error of type PROTOCOL_VIOLATION.  Discarding such a packet after only removing header protection can expose the endpoint to attacks; see <del> Section 9.3 of QUIC-TLS. </del> <ins> Section 9.5 of QUIC-TLS. </ins> The next bit (0x04) of byte 0 indicates the key phase, which allows a recipient of a packet to identify the packet protection


has received this parameter SHOULD NOT send an HTTP message header that exceeds the indicated size, as the peer will likely refuse to process it.  However, an HTTP message can traverse one or more <del> intermediaries (see Section 3.7 of SEMANTICS) before reaching the origin server.  Because this limit is applied separately by each </del> <ins> intermediaries before reaching the origin server; see Section 3.7 of SEMANTICS.  Because this limit is applied separately by each </ins> implementation which processes the message, messages below this limit are not guaranteed to be accepted.


If a stream is canceled after receiving a complete response, the client MAY ignore the cancellation and use the response.  However, if a stream is cancelled after receiving a partial response, the <del> response SHOULD NOT be used.  Only idempotent actions (such as GET, PUT, or DELETE) can be safely retried; a client SHOULD NOT </del> <ins> response SHOULD NOT be used.  Only idempotent actions such as GET, PUT, or DELETE can be safely retried; a client SHOULD NOT </ins> automatically retry a request with a non-idempotent method unless it <del> has some means to know that the request semantics are actually idempotent, regardless of the method, or some means to detect that the original request was never applied.  See Section 8.2.2 of SEMANTICS for more details. </del> <ins> has some means to know that the request semantics are idempotent independent of the method or some means to detect that the original request was never applied.  See Section 8.2.2 of SEMANTICS for more details. </ins> 4.1.3.


negotiating-connection-ids describes the use of this field in more detail. <ins> The remainder of the packet, if any, is type-specific. </ins> In this version of QUIC, the following packet types with the long header are defined:


distrustful entities control requests or responses that are placed onto a single HTTP/3 connection.  If the shared QPACK compressor permits one entity to add entries to the dynamic table, and the other <del> to access those entries, then the state of the table can be learned. </del> <ins> to access those entries to encode chosen field lines, then the attacker can learn the state of the table by observing the length of the encoded output. </ins> Having requests or responses from mutually distrustful entities occurs when an intermediary either:


1. <del> QUIC is a new multiplexed and secure transport protocol atop UDP, specified in QUIC-TRANSPORT.  This document describes congestion control and loss recovery for QUIC.  Mechanisms described in this document follow the spirit of existing TCP congestion control and loss recovery mechanisms, described in RFCs, various Internet-drafts, or academic papers, and also those prevalent in TCP implementations. </del> <ins> QUIC is a secure general-purpose transport protocol, described in QUIC-TRANSPORT).  This document describes loss detection and congestion control mechanisms for QUIC. </ins> 2.


4.2. TCP conflates transmission order at the sender with delivery order at <del> the receiver, which results in retransmissions of the same data carrying the same sequence number, and consequently leads to "retransmission ambiguity".  QUIC separates the two.  QUIC uses a packet number to indicate transmission order.  Application data is sent in one or more streams and delivery order is determined by stream offsets encoded within STREAM frames. </del> <ins> the receiver, resulting in the retransmission ambiguity problem (RETRANSMISSION).  QUIC separates transmission order from delivery order: packet numbers indicate transmission order, and delivery order is determined by the stream offsets in STREAM frames. </ins> QUIC's packet number is strictly increasing within a packet number space, and directly encodes transmission order.  A higher packet


The initial contents of this registry are shown in iana-tp-table. <del> Additionally, each value of the format "31 * N + 27" for integer values of N (that is, 27, 58, 89, ...) are reserved and MUST NOT be assigned by IANA. </del> <ins> Each value of the format "31 * N + 27" for integer values of N (that is, 27, 58, 89, ...) are reserved; these values MUST NOT be assigned by IANA and MUST NOT appear in the listing of assigned values. </ins> 22.3.


The entries in iana-frame-table are registered by this document. <del> Additionally, each code of the format "0x1f * N + 0x21" for non- negative integer values of N (that is, 0x21, 0x40, ..., through 0x3FFFFFFFFFFFFFFE) MUST NOT be assigned by IANA. </del> <ins> Each code of the format "0x1f * N + 0x21" for non-negative integer values of N (that is, 0x21, 0x40, ..., through 0x3FFFFFFFFFFFFFFE) MUST NOT be assigned by IANA and MUST NOT appear in the listing of assigned values. </ins> 11.2.2.


The entries in iana-setting-table are registered by this document. <del> Additionally, each code of the format "0x1f * N + 0x21" for non- negative integer values of N (that is, 0x21, 0x40, ..., through 0x3ffffffffffffffe) MUST NOT be assigned by IANA. </del> <ins> Each code of the format "0x1f * N + 0x21" for non-negative integer values of N (that is, 0x21, 0x40, ..., through 0x3ffffffffffffffe) MUST NOT be assigned by IANA and MUST NOT appear in the listing of assigned values. </ins> 11.2.3.


Specification Required policy to avoid collisions with HTTP/2 error codes. <del> Additionally, each code of the format "0x1f * N + 0x21" for non- negative integer values of N (that is, 0x21, 0x40, ..., through 0x3ffffffffffffffe) MUST NOT be assigned by IANA. </del> <ins> Each code of the format "0x1f * N + 0x21" for non-negative integer values of N (that is, 0x21, 0x40, ..., through 0x3ffffffffffffffe) MUST NOT be assigned by IANA and MUST NOT appear in the listing of assigned values. </ins> 11.2.4.


The entries in the following table are registered by this document. <del> Additionally, each code of the format "0x1f * N + 0x21" for non- negative integer values of N (that is, 0x21, 0x40, ..., through 0x3ffffffffffffffe) MUST NOT be assigned by IANA. </del> <ins> Each code of the format "0x1f * N + 0x21" for non-negative integer values of N (that is, 0x21, 0x40, ..., through 0x3ffffffffffffffe) MUST NOT be assigned by IANA and MUST NOT appear in the listing of assigned values. </ins>


QUIC carries TLS handshake data in CRYPTO frames, each of which consists of a contiguous block of handshake data identified by an offset and length.  Those frames are packaged into QUIC packets and <del> encrypted under the current TLS encryption level.  As with TLS over TCP, once TLS handshake data has been delivered to QUIC, it is QUIC's </del> <ins> encrypted under the current encryption level.  As with TLS over TCP, once TLS handshake data has been delivered to QUIC, it is QUIC's </ins> responsibility to deliver it reliably.  Each chunk of data that is produced by TLS is associated with the set of keys that TLS is currently using.  If QUIC needs to retransmit that data, it MUST use the same keys even if TLS has already updated to newer keys. <del> One important difference between TLS records (used with TCP) and QUIC CRYPTO frames is that in QUIC multiple frames may appear in the same QUIC packet as long as they are associated with the same packet number space.  For instance, an endpoint can bundle a Handshake message and an ACK for some Handshake data into the same packet. </del> <ins> Each encryption level corresponds to a packet number space.  The packet number space that is used determines the semantics of frames. </ins> Some frames are prohibited in different packet number spaces; see Section 12.5 of QUIC-TRANSPORT.


exchange-summary shows the multiple packets that form a single "flight" of messages being processed individually, to show what <del> incoming messages trigger different actions.  New handshake messages are requested after incoming packets have been processed.  This process varies based on the structure of endpoint implementations and the order in which packets arrive; this is intended to illustrate the steps involved in a single handshake exchange. </del> <ins> incoming messages trigger different actions.  This shows multiple "Get Handshake" invocations to retrieve handshake messages at different encryption levels.  New handshake messages are requested after incoming packets have been processed. exchange-summary shows one possible structure for a simple handshake exchange.  The exact process varies based on the structure of endpoint implementations and the order in which packets arrive. Implementations could use a different number of operations or execute them in other orders. </ins> 4.2.


ClientHello message in their first Initial packet. The TLS implementation does not need to ensure that the ClientHello <del> is sufficiently large.  QUIC PADDING frames are added to increase the size of the packet as necessary. </del> <ins> is large enough to meet the requirements for QUIC packets.  QUIC PADDING frames are added to increase the size of the packet as necessary; see Section 14.1 of QUIC-TRANSPORT. </ins> 4.4.


that supports this extension if the extension is received when the transport is not QUIC. <ins> Negotiating the quic_transport_parameters extension causes the EndOfEarlyData to be removed; see remove-eoed. </ins> 8.3. The TLS EndOfEarlyData message is not used with QUIC.  QUIC does not


4. <del> Packet diagrams in this document use a format defined in QUIC- TRANSPORT to illustrate the order and size of fields. </del> <ins> The format of packets is described using the notation defined in this section.  This notation is the same as that used in QUIC-TRANSPORT. </ins> Complex fields are named and then followed by a list of fields surrounded by a pair of matching braces.  Each field in this list is


defined in Section 6 of TLS13. A TLS alert is converted into a QUIC connection error.  The <del> AlertDescription value is added to 0x100 to produce a QUIC error code from the range reserved for CRYPTO_ERROR.  The resulting value is sent in a QUIC CONNECTION_CLOSE frame of type 0x1c. </del> <ins> AlertDescription value is added to 0x0100 to produce a QUIC error code from the range reserved for CRYPTO_ERROR.  The resulting value is sent in a QUIC CONNECTION_CLOSE frame of type 0x1c. </ins> QUIC is only able to convey an alert level of "fatal".  In TLS 1.3, the only existing uses for the "warning" level are to signal


QUIC permits the use of a generic code in place of a specific error code; see Section 11 of QUIC-TRANSPORT.  For TLS alerts, this includes replacing any alert with a generic alert, such as <del> handshake_failure (0x128 in QUIC).  Endpoints MAY use a generic error code to avoid possibly exposing confidential information. </del> <ins> handshake_failure (0x0128 in QUIC).  Endpoints MAY use a generic error code to avoid possibly exposing confidential information. </ins> 4.9.


on KeyUpdate messages sent using 1-RTT encryption keys.  Endpoints MUST NOT send a TLS KeyUpdate message.  Endpoints MUST treat the receipt of a TLS KeyUpdate message as a connection error of type <del> 0x10a, equivalent to a fatal TLS alert of unexpected_message; see </del> <ins> 0x010a, equivalent to a fatal TLS alert of unexpected_message; see </ins> tls-errors. ex-key-update shows a key update process, where the initial set of


When using ALPN, endpoints MUST immediately close a connection (see Section 10.2 of QUIC-TRANSPORT) with a no_application_protocol TLS <del> alert (QUIC error code 0x178; see tls-errors) if an application </del> <ins> alert (QUIC error code 0x0178; see tls-errors) if an application </ins> protocol is not negotiated.  While ALPN only specifies that servers <del> use this alert, QUIC clients MUST use error 0x178 to terminate a </del> <ins> use this alert, QUIC clients MUST use error 0x0178 to terminate a </ins> connection when ALPN negotiation fails. An application protocol MAY restrict the QUIC versions that it can operate over.  Servers MUST select an application protocol compatible with the QUIC version that the client has selected.  The server MUST treat the inability to select a compatible application protocol as a <del> connection error of type 0x178 (no_application_protocol).  Similarly, a client MUST treat the selection of an incompatible application protocol by a server as a connection error of type 0x178. </del> <ins> connection error of type 0x0178 (no_application_protocol). Similarly, a client MUST treat the selection of an incompatible application protocol by a server as a connection error of type 0x0178. </ins> 8.2.


MUST send the quic_transport_parameters extension; endpoints that receive ClientHello or EncryptedExtensions messages without the quic_transport_parameters extension MUST close the connection with an <del> error of type 0x16d (equivalent to a fatal TLS missing_extension </del> <ins> error of type 0x016d (equivalent to a fatal TLS missing_extension </ins> alert, see tls-errors). Transport parameters become available prior to the completion of the


Contains additional ranges of packets that are alternately not acknowledged (Gap) and acknowledged (ACK Range); see ack-ranges. <del> The three ECN Counts; see ack-ecn-counts. </del> <ins> The three ECN counts; see ack-ecn-counts. </ins> 19.3.1.


The ACK frame uses the least significant bit of the type value (that is, type 0x03) to indicate ECN feedback and report receipt of QUIC packets with associated ECN codepoints of ECT(0), ECT(1), or ECN-CE <del> in the packet's IP header.  ECN Counts are only present when the ACK </del> <ins> in the packet's IP header.  ECN counts are only present when the ACK </ins> frame type is 0x03. When present, there are three ECN counts, as shown in ecn-count- format. <del> The three ECN Counts are: </del> <ins> The ECN count fields are: </ins> A variable-length integer representing the total number of packets received with the ECT(0) codepoint in the packet number space of


"HTTP fields"; see Sections RFC9110 and RFC9110 of RFC9110.  For a listing of registered HTTP fields, see the "Hypertext Transfer Protocol (HTTP) Field Name Registry" maintained at <del> <https://www.iana.org/assignments/http-fields/>. </del> <ins> <https://www.iana.org/assignments/http-fields/>.  Like HTTP/2, HTTP/3 has additional considerations related to the use of characters in field names, the Connection header field, and pseudo-header fields. </ins> Field names are strings containing a subset of ASCII characters. Properties of HTTP field names and values are discussed in more <del> detail in RFC9110.  As in HTTP/2, characters in field names MUST be converted to lowercase prior to their encoding.  A request or response containing uppercase characters in field names MUST be treated as . </del> <ins> detail in RFC9110.  Characters in field names MUST be converted to lowercase prior to their encoding.  A request or response containing uppercase characters in field names MUST be treated as . </ins> <del> Like HTTP/2, HTTP/3 does not use the Connection header field to indicate connection-specific fields; in this protocol, connection- specific metadata is conveyed by other means.  An endpoint MUST NOT generate an HTTP/3 field section containing connection-specific fields; any message containing connection-specific fields MUST be treated as . </del> <ins> HTTP/3 does not use the Connection header field to indicate connection-specific fields; in this protocol, connection-specific metadata is conveyed by other means.  An endpoint MUST NOT generate an HTTP/3 field section containing connection-specific fields; any message containing connection-specific fields MUST be treated as . </ins> The only exception to this is the TE header field, which MAY be present in an HTTP/3 request header; when it is, it MUST NOT contain


7.2.5. The frame (type=0x05) is used to carry a promised request header <del> section from server to client on a , as in HTTP/2. </del> <ins> section from server to client on a . </ins> The payload consists of:


The QUIC transport protocol (QUIC-TRANSPORT) is designed to support HTTP semantics, and its design subsumes many of the features of <del> HTTP/2 (RFC7540).  HTTP/2 uses HPACK (RFC7541) for compression of the header and trailer sections.  If HPACK were used for HTTP/3 (HTTP3), it would induce head-of-line blocking for field sections due to built-in assumptions of a total ordering across frames on all </del> <ins> HTTP/2 (RFC9113).  HTTP/2 uses HPACK (RFC7541) for compression of the header and trailer sections.  If HPACK were used for HTTP/3 (RFC9114), it would induce head-of-line blocking for field sections due to built-in assumptions of a total ordering across frames on all </ins> streams. QPACK reuses core concepts from HPACK, but is redesigned to allow


fields; this document uses "fields" for generality. A name-value pair sent as part of an HTTP field section.  See <del> Sections 6.3 and 6.5 of SEMANTICS. </del> <ins> Sections 6.3 and 6.5 of RFC9110. </ins> Data associated with a field name, composed from all field line values with that field name in that section, concatenated together


8. This document makes multiple registrations in the registries defined <del> by HTTP3.  The allocations created by this document are all assigned permanent status and list a change controller of the IETF and a contact of the HTTP working group (ietf-http-wg@w3.org). </del> <ins> by RFC9114.  The allocations created by this document are all assigned permanent status and list a change controller of the IETF and a contact of the HTTP working group (ietf-http-wg@w3.org). </ins> 8.1. This document specifies two settings.  The entries in the following table are registered in the "HTTP/3 Settings" registry established in <del> HTTP3. </del> <ins> RFC9114. </ins> For formatting reasons, the setting names here are abbreviated by removing the 'SETTINGS_' prefix.


This document specifies two stream types.  The entries in the following table are registered in the "HTTP/3 Stream Types" registry <del> established in HTTP3. </del> <ins> established in RFC9114. </ins> 8.3. This document specifies three error codes.  The entries in the following table are registered in the "HTTP/3 Error Codes" registry <del> established in HTTP3. </del> <ins> established in RFC9114. </ins>


integer value (represented as a variable-length integer) that represents the maximum size of a DATAGRAM frame (including the frame type, length, and payload) the endpoint is willing to receive, in <del> bytes.  An endpoint that includes this parameter supports the DATAGRAM frame types and is willing to receive such frames on this connection.  Endpoints MUST NOT send DATAGRAM frames until they have received the max_datagram_frame_size transport parameter.  Endpoints MUST NOT send DATAGRAM frames of size strictly larger than the value of max_datagram_frame_size the endpoint has received from its peer. An endpoint that receives a DATAGRAM frame when it has not sent the max_datagram_frame_size transport parameter MUST terminate the connection with error PROTOCOL_VIOLATION.  An endpoint that receives a DATAGRAM frame that is strictly larger than the value it sent in its max_datagram_frame_size transport parameter MUST terminate the connection with error PROTOCOL_VIOLATION.  Endpoints that wish to use DATAGRAM frames need to ensure they send a max_datagram_frame_size value sufficient to allow their peer to use them.  It is RECOMMENDED to send the value 65535 in the max_datagram_frame_size transport parameter as that indicates to the peer that this endpoint will accept any DATAGRAM frame that fits inside a QUIC packet. </del> <ins> bytes. The default for this parameter is 0, which indicates that the endpoint does not support DATAGRAM frames.  A value greater than 0 indicates that the endpoint supports the DATAGRAM frame types and is willing to receive such frames on this connection. An endpoint MUST NOT send DATAGRAM frames until it has received the max_datagram_frame_size transport parameter with a non-zero value. An endpoint MUST NOT send DATAGRAM frames that are larger than the max_datagram_frame_size value it has received from its peer.  An endpoint that receives a DATAGRAM frame when it has not indicated support via the transport parameter MUST terminate the connection with an error of type PROTOCOL_VIOLATION.  Similarly, an endpoint that receives a DATAGRAM frame that is larger than the value it sent in its max_datagram_frame_size transport parameter MUST terminate the connection with an error of type PROTOCOL_VIOLATION. For most uses of DATAGRAM frames, it is RECOMMENDED to send a value of 65535 in the max_datagram_frame_size transport parameter to indicate that this endpoint will accept any DATAGRAM frame that fits inside a QUIC packet. </ins> The max_datagram_frame_size transport parameter is a unidirectional limit and indication of support of DATAGRAM frames.  Application


max_datagram_frame_size <del> Indicates that the connection should enable support for unreliable DATAGRAM frames.  An endpoint that advertises this transport parameter can receive datagrams frames from the other endpoint, up to and including the length in bytes provided in the transport parameter. </del> <ins> A non-zero value indicates that the endpoint supports receiving unreliable DATAGRAM frames.  An endpoint that advertises this transport parameter can receive DATAGRAM frames from the other endpoint, up to and including the length in bytes provided in the transport parameter.  The default value is 0. </ins> This document also registers a new value in the QUIC Frame Type registry:


This document defines two new DATAGRAM QUIC frame types, which carry application data without requiring retransmissions. <ins> Note that DATAGRAM frames are only meant for unreliable transmissions.  Reliable transmission is already supported by QUIC via STREAM frames. </ins> Discussion of this work is encouraged to happen on the QUIC IETF mailing list quic@ietf.org [3] or on the GitHub repository which contains the draft: https://github.com/quicwg/datagram [4].


7. <ins> 7.1. </ins> This document registers a new value in the QUIC Transport Parameter <del> Registry: </del> <ins> Registry maintained at <https://www.iana.org/assignments/quic/ quic.xhtml#quic-transport>. </ins> <del> 0x0020 (if this document is approved) </del> <ins> 0x20 (if this document is approved) </ins> max_datagram_frame_size <del> A non-zero value indicates that the endpoint supports receiving unreliable DATAGRAM frames.  An endpoint that advertises this transport parameter can receive DATAGRAM frames from the other endpoint, up to and including the length in bytes provided in the transport parameter.  The default value is 0. </del> <ins> permanent This document </ins> <del> This document also registers a new value in the QUIC Frame Type registry: </del> <ins> 7.2. This document registers two new values in the QUIC Frame Type registry maintained at <https://www.iana.org/assignments/quic/ quic.xhtml#quic-frame-types>. </ins> 0x30 and 0x31 (if this document is approved) DATAGRAM <del> Unreliable application data </del> <ins> permanent This document </ins> 8.


extension parameters: To avoid clashes, implementers SHOULD prefix unregistered parameters <del> with an "x-<vendor>" identifier, e.g. "x-acme-policy", "x-acme- burst".  While it is useful to define a clear syntax and semantics even for custom parameters, it is important to note that user agents are not required to process quota policy information. </del> <ins> with a vendor identifier, e.g. "acme-policy", "acme-burst".  While it is useful to define a clear syntax and semantics even for custom parameters, it is important to note that user agents are not required to process quota policy information. </ins> 2.2.


references.  Like all search criteria, on a resource lookup it can match the target reference of the resource link itself, but also the registration resource of the endpoint that registered it, or any <del> group resource that endpoint is contained in. </del> <ins> group resource that endpoint is contained in.  Queries for resource link targets MUST be in absolute form and are matched against a resolved link target.  Queries for groups and endpoints SHOULD be expressed in path-absolute form if possible and MUST be expressed in absolute form otherwise; the RD SHOULD recognize either. </ins> Clients that are interested in a lookup result repeatedly or continuously can use mechanisms like ETag caching, resource


This document registers one new ND option type under the sub-registry "IPv6 Neighbor Discovery Option Formats": <del> Resource Directory address Option (38) </del> <ins> Resource Directory Address Option (38) </ins> 9.3.


references) and are matched against a resolved link target.  Queries for endpoints SHOULD be expressed in path-absolute form if possible and MUST be expressed in URI form otherwise; the RD SHOULD recognize <del> either. </del> <ins> either.  The "anchor" attribute is usable for resource lookups, and, if queried, MUST be for in URI form as well. </ins> Endpoints that are interested in a lookup result repeatedly or continuously can use mechanisms like ETag caching, resource


registration if it were not to be used in lookup or attributes, but would make a bad parameter for lookup, because a resource lookup with an "if" query parameter could ambiguously filter by the registered <del> endpoint property or the RFC6690 target attribute).  It is expected that the registry will receive between 5 and 50 registrations in total over the next years. </del> <ins> endpoint property or the RFC6690 target attribute). </ins> 9.3.1.


the same properties for operations on the registration resource. Registrants that are prepared to pick a different identifier when <del> their initial attempt at registration is unauthorized should pick an </del> <ins> their initial attempt (or attempts, in the unlikely case of two subsequent collisions) at registration is unauthorized should pick an </ins> identifier at least twice as long as the expected number of registrants; registrants without such a recovery options should pick significantly longer endpoint names (e.g. using UUID URNs RFC4122).


Minor editorial fixes in response to Gen-ART review. <ins> Random EP names: Point that multiple collisions are possible but unlikely. (For background, in the first round of attempts there's a good chance that one of the random IDs will collide due to the birthday paradox; the likelyhood for a second (or even third) collision in a row is way below that because only the colliding node(s) will retry). </ins> changes from -24 to -25 Large rework of section 7 (Security policies)


the complete LwM2M model to a summary of how RD is used in there, with a reference to the current specification. <ins> impl-info: Add note about the type being WIP </ins> changes from -24 to -25 Large rework of section 7 (Security policies)


4. <del> Several mechanisms can be employed for discovering the RD, including assuming a default location (e.g. on an Edge Router in a LoWPAN), assigning an anycast address to the RD, using DHCP, or discovering the RD using .well-known/core and hyperlinks as specified in CoRE Link Format RFC6690.  Endpoints that want to contact a Resource Directory (RD) can obtain candidate IP addresses of RD servers dependent on the operational conditions.  It is assumed that the nodes looking for a Resource Directory are connected to a Border Router (6LBR).  Given the various existing network installation procedures, the 6LBR is either connected or disconnected from the Internet and its services like DHCP and DNS.  Two conditions are separately considered: (1) Internet services present, and (2) no Internet services present. When no Internet services are present, the following techniques are used (in random order): Sending a Multicast to [ff02::1]/.well-known/core with ?rt=core.rd*. The receiving RDs will answer the query. The Authoritative Border Router Option (ABRO) present in the Router Advertisements (RA), contains the address of the border router. Assuming that an RD is located at the 6LBR.  Confirmation can be obtained by sending a Unicast to [6LBR]/.well-known/core with ?rt=core.rd*. Address of 6LBR is obtained from ABRO. The 6LBR can send the Resource Directory Address Option (RDAO) during neighbour Discovery containing one or more RD addresses, as explained in The installation manager can decide to preconfigure an ANYCAST address with as destination the interface of the RDs.  Clients send a discovery message to the predefined RD anycast address. Each target network environment in which some of these preconfigured nodes are to be brought up is then configured with a route for this anycast address that leads to an appropriate RD. Instead of using an ANYCAST address, a multicast address can be preconfigured.  All RD directory servers need to configure one of their interfaces with this multicast address. After installation of mDNS on all nodes, mDNS can be queried for the IP-address of RD. When Internet services are present, the techniques cited above are still valid.  Using standard techniques to obtain the addresses of DNS or DHCP servers, the RD can be discovered in the following way: Using a DNSSD query to return the Resource Records (RR) describing </del> <ins> A device coming up may want to find one or more resource directories to make itself known with. The device may be pre-configured to exercise specific mechanisms for finding the resource directory: It may be configured with a specific IP address for the RD.  That IP address may also be an anycast address, allowing the network to forward RD requests to an RD that is topologically close; each target network environment in which some of these preconfigured nodes are to be brought up is then configured with a route for this anycast address that leads to an appropriate RD.  (Instead of using an anycast address, a multicast address can also be preconfigured.  The RD directory servers then need to configure one of their interfaces with this multicast address.) It may be configured with a DNS name for the RD and a resource- record type to look up under this name; it can find a DNS server to perform the lookup using the usual mechanisms for finding DNS servers. It may be configured to use a service discovery mechanism such as DNS-SD RFC6763.  The present specification suggests configuring </ins> the service with name rd._sub._coap._udp, preferably within the <del> domain of the querying nodes. Using DHCPv6 with options to be defined. Assisting the 9 techniques above, requires manual intervention or may be done automatically. Manual management: IP address of RD is present in each node. ANYCAST address or Multicast address of RD is present in each node [see 5,6]. 6LBR receives IP address of RD for distribution via RDAO [see 4]. RD address is configured in DHCP [see 9]. DNS is configured with Resource Record specifying address of RD service [see 8]. Automatic management Multicasting to all nodes to return IP address [see 1]. Querying mDNS to receive IP address [see 7]. 6LBR contains RD service [see 2, 3]. As some of these RD addresses are just (more or less educated) guesses, endpoints MUST make use of any error messages to very strictly rate-limit requests to candidate IP addresses that don't work out.  For example, an ICMP Destination Unreachable message (and, in particular, the port unreachable code for this message) may indicate the lack of a CoAP server on the candidate host, or a CoAP error response code such as 4.05 "Method Not Allowed" may indicate unwillingness of a CoAP server to act as a directory server. </del> <ins> domain of the querying nodes.  [_1] For cases where the device is not specifically configured with a way to find a resource directory, the network may want to provide a suitable default. If the address configuration of the network is performed via SLAAC, this is provided by the RDAO option rdao. If the address configuration of the network is performed via DHCP, this could be provided via a DHCP option (no such option is defined at the time of writing). Finally, if neither the device nor the network offer any specific configuration, the device may want to employ heuristics to find a suitable resource directory. The present specification does not fully define these heuristics, but suggests a number of candidates: In a 6LoWPAN, just assume the Edge Router (6LBR) can act as a resource directory (using the ABRO option to find that RFC6775). Confirmation can be obtained by sending a Unicast to coap://[6LBR]/.well-known/core?rt=core.rd*`. In a network that supports multicast well, discovering the RD using a multicast query for /.well-known/core as specified in CoRE Link Format RFC6690: Sending a Multicast GET to "coap://[ff02::1]/.well-known/core?rt=core.rd*".  RDs within the multicast scope will answer the query. As some of the RD addresses obtained by the methods listed here are just (more or less educated) guesses, endpoints MUST make use of any error messages to very strictly rate-limit requests to candidate IP addresses that don't work out.  For example, an ICMP Destination Unreachable message (and, in particular, the port unreachable code for this message) may indicate the lack of a CoAP server on the candidate host, or a CoAP error response code such as 4.05 "Method Not Allowed" may indicate unwillingness of a CoAP server to act as a directory server. </ins> 4.1.


Changed the lookup interface to accept endpoint and Domain as query string parameters to control the scope of a lookup. <ins> Editorial Comments [_1] cabo: What is _sub here? </ins>


POST <del> {+rd}{?ep,d,et,lt,con,extra-attrs*} </del> <ins> {+rd}{?ep,d,lt,con,extra-attrs*} </ins>


parameter is elided, the RD MAY associate the endpoint with a configured default domain. <del> Endpoint Type (optional).  The semantic type of the endpoint. This parameter SHOULD be less than 63 bytes. </del> Lifetime (optional).  Lifetime of the registration in seconds. Range of 60-4294967295.  If no lifetime is included in the initial registration, a default value of 86400 (24 hours)


the link-format payload to register. The endpoint MUST include the endpoint name and MAY include the <del> registration parameters d, lt, et and extra-attrs, in the POST request as per registration.  The context of the registration is taken from the requesting server's URI. </del> <ins> registration parameters d, lt and extra-attrs, in the POST request as per registration.  The context of the registration is taken from the requesting server's URI. </ins> The endpoints MUST be deleted after the expiration of their lifetime. Additional operations cannot be executed because no registration


Endpoint and group lookups result in links to the selected registration resource and group resources.  Endpoint registration resources are annotated with their endpoint names (ep), domains (d, <del> if present), context (con), endpoint type (et, if present) and lifetime (lt, if present).  Additional endpoint attributes are added as link attributes to their endpoint link unless their specification says otherwise.  Group resources are annotated with their group names (gp), domain (d, if present) and multicast address (con, if present). </del> <ins> if present), context (con) and lifetime (lt, if present).  Additional endpoint attributes are added as link attributes to their endpoint link unless their specification says otherwise.  Group resources are annotated with their group names (gp), domain (d, if present) and multicast address (con, if present). </ins> While Endpoint Lookup does expose the registration resources, the RD does not need to make them accessible to clients.  Clients SHOULD NOT


that the registry will receive between 5 and 50 registrations in total over the next years. <ins> 9.4. The Endpoint Type parameter is described as follows: An endpoint registering at an RD can describe itself with endpoint types, similar to how resources are described with Resource Types in RFC6690.  An endpoint type is expressed as a string, which can be either a URI or one of the values defined in the Endpoint Type subregistry; it SHOULD be shorter than 63 bytes.  Endpoint types can be passed in the "et" query parameter as part of extra-attrs at the Registration step, are shown on endpoint lookups using the "et" target attribute, and can be filtered for using "et" as a search criterion in resource and endpoint lookup.  Multiple endpoint types are given as separate query parameters or link attributes. Note that Endpoint Type differs from Resource Type in that it uses multiple attributes rather than space separated values.  As a result, Resource Directory implementations automatically support correct filtering in the lookup interfaces from the rules for unknown endpoint attributes. This specification establishes a new sub-registry under "CoRE Parameters" called "Endpoint Type".  The registry properties (required policy, requirements, template) are identical to those of the Resource Type parameters in RFC6690.  The registry is initially empty. </ins> 10. Two examples are presented: a Lighting Installation example in lt-ex


RD registration URI (mandatory).  This is the location of the RD, as obtained from discovery. <del> Endpoint name (mandatory).  The endpoint name is an identifier that MUST be unique within a domain.  The maximum length of this parameter is 63 bytes. </del> <ins> Endpoint name (mostly mandatory).  The endpoint name is an identifier that MUST be unique within a domain.  The maximum length of this parameter is 63 bytes.  If the RD is configured to recognize the endpoint (eg. based on its security context), the endpoint can elide the endpoint name, and assign one based on the configuration. </ins> Domain (optional).  The domain to which this endpoint belongs. The maximum length of this parameter is 63 bytes.  When this


requests at the requesting server's default discovery URI to obtain the link-format payload to register. <del> The endpoint MUST include the endpoint name and MAY include the registration parameters d, lt and extra-attrs, in the POST request as per registration.  The context of the registration is taken from the requesting server's URI. </del> <ins> The endpoint includes the same registration parameters in the POST request as it would per registration.  The context of the registration is taken from the requesting server's URI. </ins> The endpoints MUST be deleted after the expiration of their lifetime. Additional operations cannot be executed because no registration


Internet Backbone: If a censor controls the gateways into a region, they can filter undesirable traffic that is traveling into and out of the region by sniffing and mirroring at the relevant <del> exchange points.  Censorship at this point-of-control is most </del> <ins> exchange points.  Censorship at this point of control is most </ins> effective at controlling the flow of information between a region and the rest of the Internet, but is ineffective at identifying content traveling between the users within a region. Internet Service Providers: Internet Service Providers are perhaps <del> the most natural point-of-control.  They have a benefit of being </del> <ins> the most natural point of control.  They have a benefit of being </ins> easily enumerable by a censor paired with the ability to identify the regional and international traffic of all their users.  The censor's filtration mechanisms can be placed on an ISP via


than potentially excluding content, users, or uses of their service. <ins> Certificate Authorities: Authorities that issue cryptographically secured resources can be a significant point of control. Certificate Authorities that issue certificates to domain holders for TLS/HTTPS or Regional/Local Internet Registries that issue Route Origination Authorizations to BGP operators can be forced to issue rogue certificates that may allow compromises in confidentiatlity guarantees - allowing censorship software to engage in identification and interference where not possible before - or integrity degrees - allowing, for example, adversarial routing of traffic. </ins> At all levels of the network hierarchy, the filtration mechanisms used to detect undesirable traffic are essentially the same: a censor sniffs transmitting packets and identifies undesirable content, and


domain all other DNS servers will be unable to properly forward and cache the site.  Domain name registration is only really a risk where undesirable content is hosted on TLD controlled by the censoring <del> country, such as .cn or .ru Anderson-2011. </del> <ins> country, such as .cn or .ru Anderson-2011 or where legal processes in countries like the United States result in domain name seizures and/ or DNS redirection by the government Kopel-2013. </ins> 6.3.


possible, and that when relative URIs are used, they include the full path (e.g., "/types/123"). <ins> The type URI can also be a non-resolvable URI.  For example, the tag URI scheme RFC4151 can be used to uniquely identify problem types: Non-resolvable URIs ought not be used when there is some future possibility that it might become desireable to do so.  For example, if the URI above were used in an API and later a tool was adopted that resolves type URIs to discover information about the error, taking advantage of that capability would require switching to a resolvable URI, thereby creating a new identity for the problem type and thus introducing a breaking change. </ins> 3.1.2. The "status" member is a JSON number indicating the HTTP status code


Changed the registry policy to: <del> Updated the "Reference" to also refer to this document. </del> <ins> Updated the "Reference" to refer to this document instead of RFC8447. </ins> See expert-pool for additional information about the designated expert pool.


Add a "Recommended" column with the contents as listed below. This table has been generated by marking Standards Track RFCs as <del> "Y" and all others as "N".  The "Recommended" column is assigned a value of "N" unless explicitly requested, and adding a value with a "Recommended" value of "Y" requires Standards Action RFC8126. IESG Approval is REQUIRED for a Y->N transition. </del> <ins> "Y", "truncated_hmac" (4) and "connection_id (deprecated)" (53) as "D", and all others as "N".  The "Recommended" column is assigned a value of "N" unless explicitly requested, and adding a value with a "Recommended" value of "Y" requires Standards Action RFC8126.  IESG Approval is REQUIRED for a Y->N, Y->D, and D->Y|N transitions. </ins> IANA [SHALL update/has added] the following notes: The extensions added by I-D.ietf-tls-rfc8446bis are omitted from the <del> above table; additionally, token_binding is omitted, since RFC8472 specifies the value of the "Recommended" column as for this extension. </del> <ins> above table.  Likewise, extensions defined after RFC8447 are also not listed in the table as those RFCs specify the value of the extension's "Recommended"; extensions points defined after RFC8447 include token_binding, compress_certificate, record_size_limit, pwd_protect, pwd_clear, password_salt, ticket_pinning, tls_cert_with_extern_psk, delegated_credentials, supported_ekt_ciphers, connection_id, external_id_hash, external_session_id, quic_transport_parameters, ticket_request, and dnssec_chain. </ins> I-D.ietf-tls-rfc8446bis also uses the TLS ExtensionType Values registry originally created in RFC4366.  The following text is from


gateway to convert between the signaling on the web side to the SIP signaling may be needed. <del> When a new codec is specified, and the SDP for the new codec is specified in the MMUSIC WG, no other standardization should be required for it to be possible to use that in the web browsers. Adding new codecs which might have new SDP parameters should not change the APIs between the browser and Javascript application. As soon as the browsers support the new codecs, old applications written before the codecs were specified should automatically be able to use the new codecs where appropriate with no changes to the JS applications. </del> <ins> When an SDP for a new codec is specified, no other standardization should be required for it to be possible to use that in the web browsers.  Adding new codecs which might have new SDP parameters should not change the APIs between the browser and Javascript application.  As soon as the browsers support the new codecs, old applications written before the codecs were specified should automatically be able to use the new codecs where appropriate with no changes to the JS applications. </ins> The particular choices made for WebRTC, and their implications for the API offered by a browser implementing WebRTC, are described in I-


elements described. TCP RFC0793.  This is used for HTTP/WebSockets, as well as for <del> TURN/SSL and ICE-TCP. </del> <ins> TURN/TLS and ICE-TCP. </ins> For both protocols, IPv4 and IPv6 support is assumed.


This specification does not assume that the implementation will have access to ICMP or raw IP. <ins> The following protocols may be used, but can be implemented by a WebRTC endpoint, and are therefore not defined as "system-provided interfaces": TURN - Traversal Using Relays Around NAT, STUN - Session Traversal Utilities for NAT, ICE - Interactive Connectivity Establishment, RFC5245 TLS - Trasnsport Layer Security, DTLS - Datagram Transport Layer Security, RFC6347. </ins> 3.2. Web applications running in a WebRTC browser MUST be able to utilize


The WebRTC implementation MAY support accessing the Internet through an HTTP proxy.  If it does so, it MUST support the "connect" header <del> as specified in I-D.ietf-httpbis-tunnel-protocol. </del> <ins> as specified in I-D.ietf-httpbis-tunnel-protocol, and proxy authentication as described in Section 4.3.6 of RFC7231 and RFC7235 MUST also be supported. </ins> 3.5.


4. <del> This section describes a typical RTCWeb session and shows how the </del> <ins> This section describes a typical WebRTC session and shows how the </ins> various security elements interact and what guarantees are provided to the user.  The example in this section is a "best case" scenario in which we provide the maximal amount of user authentication and


the calling service via HTTPS and so know the origin with some level of confidence.  They also have accounts with some identity provider. This sort of identity service is becoming increasingly common in the <del> Web environment in technologies such (BrowserID, Federated Google Login, Facebook Connect, OAuth, OpenID, WebFinger), and is often provided as a side effect service of a user's ordinary accounts with some service.  In this example, we show Alice and Bob using a </del> <ins> Web environment (with technologies such as BrowserID, Federated Google Login, Facebook Connect, OAuth, OpenID, WebFinger), and is often provided as a side effect service of a user's ordinary accounts with some service.  In this example, we show Alice and Bob using a </ins> separate identity service, though the identity service may be the same entity as the calling service or there may be no identity service at all.


freshness", i.e., allowing Alice to verify that Bob is still prepared to receive her communications so that Alice does not continue to send large traffic volumes to entities which went abruptly offline.  ICE <del> specifies periodic STUN keepalizes but only if media is not flowing. Because the consent issue is more difficult here, we require RTCWeb </del> <ins> specifies periodic STUN keepalives but only if media is not flowing. Because the consent issue is more difficult here, we require WebRTC </ins> implementations to periodically send keepalives.  As described in Section 5.3, these keepalives MUST be based on the consent freshness mechanism specified in I-D.muthu-behave-consent-freshness.  If a


NOT be permitted to control the local ufrag and password, though it of course knows it. <del> While continuing consent is required, that ICE RFC5245; Section 10 keepalives STUN Binding Indications are one-way and therefore not sufficient.  The current WG consensus is to use ICE Binding Requests for continuing consent freshness.  ICE already requires that implementations respond to such requests, so this approach is maximally compatible.  A separate document will profile the ICE timers to be used; see I-D.muthu-behave-consent-freshness. </del> <ins> While continuing consent is required, the ICE RFC5245; Section 10 keepalives use STUN Binding Indications which are one-way and therefore not sufficient.  The current WG consensus is to use ICE Binding Requests for continuing consent freshness.  ICE already requires that implementations respond to such requests, so this approach is maximally compatible.  A separate document will profile the ICE timers to be used; see I-D.muthu-behave-consent-freshness. </ins> 5.4.


5.6. In a number of cases, it is desirable for the endpoint (i.e., the <del> browser) to be able to directly identity the endpoint on the other side without trusting only the signaling service to which they are </del> <ins> browser) to be able to directly identify the endpoint on the other side without trusting the signaling service to which they are </ins> connected.  For instance, users may be making a call via a federated system where they wish to get direct authentication of the other side.  Alternately, they may be making a call on a site which they


identity on a site they do trust (such as a social network.) Recently, a number of Web-based identity technologies (OAuth, <del> BrowserID, Facebook Connect), etc. have been developed.  While the </del> <ins> BrowserID, Facebook Connect etc.) have been developed.  While the </ins> details vary, what these technologies share is that they have a Web- based (i.e., HTTP/HTTPS) identity provider which attests to your identity.  For instance, if I have an account at example.org, I could


The precise information from the signaling message that must be cryptographically bound to the user's identity and a mechanism for <del> carrying assertions in JSEP messages. sec.jsep-binding </del> <ins> carrying assertions in JSEP messages.  This is specified in sec.jsep-binding. </ins> The interface to the IdP. sec.protocol-details specifies a specific protocol mechanism which allows the use of any identity


The specific IdP protocol which the IdP is using.  This is a completely opaque IdP-specific string, but allows an IdP to <del> implement two protocols in parallel.  This value may be the empty string. </del> <ins> implement multiple protocols in parallel.  This value may be the empty string. </ins> Each IdP MUST serve its initial entry page (i.e., the one loaded by the IdP proxy) from a RFC5785.  The well-known URI for an IdP proxy


who have not implemented WebRTC at all, WebRTC implementations need to be more careful. <del> Consider the case of a call center which accepts calls via RTCWeb. </del> <ins> Consider the case of a call center which accepts calls via WebRTC. </ins> An attacker proxies the call center's front-end and arranges for multiple clients to initiate calls to the call center.  Note that this requires user consent in many cases but because the data channel


6.4.1. Fundamentally, the IdP proxy is just a piece of HTML and JS loaded by <del> the browser, so nothing stops a Web attacker o from creating their own IFRAME, loading the IdP proxy HTML/JS, and requesting a signature.  In order to prevent this attack, we require that all signatures be tied to a specific origin ("rtcweb://...") which cannot be produced by content JavaScript.  Thus, while an attacker can instantiate the IdP proxy, they cannot send messages from an appropriate origin and so cannot create acceptable assertions.  I.e., the assertion request must have come from the browser.  This origin check is enforced on the relying party side, not on the authenticating party side.  The reason for this is to take the burden of knowing which origins are valid off of the IdP, thus making this mechanism extensible to other applications besides WebRTC.  The IdP simply needs to gather the origin information (from the posted message) and attach it to the assertion. </del> <ins> the browser, so nothing stops a Web attacker from creating their own IFRAME, loading the IdP proxy HTML/JS, and requesting a signature. In order to prevent this attack, we require that all signatures be tied to a specific origin ("rtcweb://...") which cannot be produced by content JavaScript.  Thus, while an attacker can instantiate the IdP proxy, they cannot send messages from an appropriate origin and so cannot create acceptable assertions.  I.e., the assertion request must have come from the browser.  This origin check is enforced on the relying party side, not on the authenticating party side.  The reason for this is to take the burden of knowing which origins are valid off of the IdP, thus making this mechanism extensible to other applications besides WebRTC.  The IdP simply needs to gather the origin information (from the posted message) and attach it to the assertion. </ins> Note that although this origin check is enforced on the RP side and not at the IdP, it is absolutely imperative that it be done.  The


Abstract <del> The Real-Time Communications on the Web (RTCWEB) working group is tasked with standardizing protocols for enabling real-time communications within user-agents using web technologies (commonly called "WebRTC").  This document defines the security architecture for WebRTC. </del> <ins> This document defines the security architecture for WebRTC, a protocol suite intended for use with real-time applications that can be deployed in browsers - "real time communication on the Web". </ins> 1.


All SenML Records in a Pack MUST have the same version number.  This is typically done by adding a Base Version field to only the first <del> Record in the Pack. </del> <ins> Record in the Pack, or by using the default value. </ins> Systems reading one of the objects MUST check for the Version field. If this value is a version number larger than the version which the


4.5.2. If the Record has no Unit, the Base Unit is used as the Unit.  Having <del> no Unit and no Base Unit is allowed. </del> <ins> no Unit and no Base Unit is allowed; any information that may be required about units applicable to the value then needs to be provided by the application context. </ins> 4.5.3.


9.2. In addition to the SenML Fragment Identifiers described above, with <del> the XML and EXI SenML formats also the syntax defined in </del> <ins> the XML and EXI SenML formats also the syntax defined in the XPointer element() Scheme XPointerElement of the XPointer Framework </ins> XPointerFramework can be used.  (This is required by RFC7303 for media types using the "+xml" structured syntax suffix.  SenML allows this for the EXI formats as well for consistency.)


Some devices have accurate time while others do not so SenML supports absolute and relative times.  Time is represented in floating point <del> as seconds.  Values greater than zero represent an absolute time relative to the Unix epoch (1970-01-01T00:00Z in UTC time) and the time is counted same way as the Portable Operating System Interface (POSIX) "seconds since the epoch" TIME_T.  Values of 0 or less represent a relative time in the past from the current time.  A simple sensor with no absolute wall clock time might take a </del> <ins> as seconds.  Values greater than or equal to 2*28 represent an absolute time relative to the Unix epoch.  Values less than 2*28 represent time relative to the current time. A simple sensor with no absolute wall clock time might take a </ins> measurement every second, batch up 60 of them, and then send the batch to a server.  It would include the relative time each measurement was made compared to the time the batch was sent in each


All comparisons of text strings are performed byte-by-byte (and therefore necessarily case-sensitive). <ins> Where arithmetic is used, this specification uses the notation familiar from the programming language C, except that the operator "**" stands for exponentiation. </ins> 4. Each SenML Pack carries a single array that represents a set of


If either the Base Time or Time value is missing, the missing field is considered to have a value of zero.  The Base Time and Time values <del> are added together to get the time of measurement.  A time of zero indicates that the sensor does not know the absolute time and the measurement was made roughly "now".  A negative value is used to indicate seconds in the past from roughly "now".  A positive value is used to indicate the number of seconds, excluding leap seconds, since the start of the year 1970 in UTC. </del> <ins> are added together to get the time of measurement. Values less than 268,435,456 (2*28) represent time relative to the current time.  That is, a time of zero indicates that the sensor does not know the absolute time and the measurement was made roughly "now".  A negative value indicates seconds in the past from roughly "now".  Positive values up to 2*28 indicate seconds in the future from "now".  Positive values can be used, e.g., for actuation use when the desired change should happen in the future but the sender or the receiver does not have accurate time available. Values greater than or equal to 2*28 represent an absolute time relative to the Unix epoch (1970-01-01T00:00Z in UTC time) and the time is counted same way as the Portable Operating System Interface (POSIX) "seconds since the epoch" . Therefore the smallest absolute time value that can be expressed (2*TIME_T28) is 1978-07-04 21:24:16 UTC. Because time values up to 2*28 are used for presenting time relative to "now" and Time and Base Time are added together, care must be taken to ensure that the sum does not inadvertently reach 2*28 (i.e., absolute time) when relative time was intended to be used. </ins> Obviously, "now"-referenced SenML records are only useful within a specific communication context (e.g., based on information on when


A base value is added to the value found in an entry, similar to Base Time. <ins> A base sum is added to the sum found in an entry, similar to Base Time. </ins> Version number of media type format.  This attribute is an optional positive integer and defaults to 5 if not present.  [RFC Editor: change the default value to 10 when this specification is


Base Unit is allowed. Value of the entry.  Optional if a Sum value is present, otherwise <del> required.  Values are represented using three basic data types, Floating point numbers ("v" field for "Value"), Booleans ("vb" for "Boolean Value"), Strings ("vs" for "String Value") and Binary Data ("vd" for "Data Value") .  Exactly one of these four fields MUST appear unless there is Sum field in which case it is allowed to have no Value field or to have "v" field. </del> <ins> required.  Values are represented using basic data types.  This specification defines floating point numbers ("v" field for "Value"), booleans ("vb" for "Boolean Value"), strings ("vs" for "String Value") and binary data ("vd" for "Data Value").  Exactly one value field MUST appear unless there is Sum field in which case it is allowed to have no Value field. </ins> Integrated sum of the values over time.  Optional.  This attribute is in the units specified in the Unit value multiplied by seconds.


attributes to provide better information about the statistical properties of the measurement. <del> A SenML object is referred to as "expanded" if it does not contain any base values and has no relative times. </del> 4.4. <ins> Sometimes it is useful to be able to refer to a defined normalized format for SenML records.  This normalized format tends to get used for big data applications and intermediate forms when converting to other formats. A SenML Record is referred to as "resolved" if it does not contain any base values and has no relative times, but the the base values of the SenML Pack (if any) are applied to the Record.  That is, name and base name are concatenated, base time is added to the time of the Record, if Record did not contain Unit the Base Unit is applied to the record, etc.  In addition the records need to be in chronological order. TODO add example 4.5. </ins> SenML is designed to carry the minimum dynamic information about measurements, and for efficiency reasons does not carry significant static meta-data about the device, object or sensors.  Instead, it is


attributes to provide better information about the statistical properties of the measurement. <del> A SenML object is referred to as "expanded" if it does not contain any base values and has no relative times. </del> 4.4. <ins> Sometimes it is useful to be able to refer to a defined normalized format for SenML records.  This normalized format tends to get used for big data applications and intermediate forms when converting to other formats. A SenML Record is referred to as "resolved" if it does not contain any base values and has no relative times, but the the base values of the SenML Pack (if any) are applied to the Record.  That is, name and base name are concatenated, base time is added to the time of the Record, if Record did not contain Unit the Base Unit is applied to the record, etc.  In addition the records need to be in chronological order.  An example of this is show in resolved-ex. 4.5. </ins> SenML is designed to carry the minimum dynamic information about measurements, and for efficiency reasons does not carry significant static meta-data about the device, object or sensors.  Instead, it is


5.1. <del> TODO - Add example with string, data, boolean, and base value </del> 5.1.1. The following shows a temperature reading taken approximately "now"


5.1.4. <ins> The following shows the example from the previos section show in resolved format. 5.1.5. The following example shows a sensor that returns different data types. 5.1.6. </ins> The following example shows how to query one device that can provide multiple measurements.  The example assumes that a client has fetched information from a device at 2001:db8::2 by performing a GET


Characters in the String Value are encoded using a definite length text string (type 3).  Octets in the Data Value are encoded using <del> a definite length byte string (type 2) . </del> <ins> a definite length byte string (type 2). </ins> <del> For compactness, the CBOR representation uses integers for the map keys defined in tbl-cbor-labels.  This table is conclusive, i.e., there is no intention to define any additional integer map keys; any extensions will use string map keys.  This allows translators converting between CBOR and JSON representations to convert also all future labels without needing to update implementations. </del> <ins> For compactness, the CBOR representation uses integers for the labels, as defined in tbl-cbor-labels.  This table is conclusive, i.e., there is no intention to define any additional integer map keys; any extensions will use string map keys.  This allows translators converting between CBOR and JSON representations to convert also all future labels without needing to update implementations. </ins> For streaming SensML in CBOR representation, the array containing <del> the records SHOULD be an CBOR indefinite length array while for non streaming SenML, a definite length array MUST be used. </del> <ins> the records SHOULD be a CBOR indefinite length array while for non-streaming SenML, a definite length array MUST be used. </ins> The following example shows a dump of the CBOR example for the same sensor measurement as in co-ex.


The compressed form, using the byte alignment option of EXI, for the above XML is the following: <del> A small temperature sensor devices that only generates this one EXI </del> <ins> A small temperature sensor device that only generates this one EXI </ins> file does not really need an full EXI implementation.  It can simply hard code the output replacing the 1-wire device ID starting at byte 0x20 and going to byte 0x2F with it's device ID, and replacing the


first record is at position 1.  A range of records can be selected by giving the first and the last record number separated by a '-' character.  Instead of the second number, the '*' character can be <del> used to indicate the last Senml Record in the Pack.  A set of records </del> <ins> used to indicate the last SenML Record in the Pack.  A set of records </ins> can also be selected using a comma separated list of record positions or ranges. (We use the term "selecting a record" for identifying it as part of the fragment, not in the sense of isolating it from the Pack -- the record still needs to be interpreted as part of the Pack, e.g., using <del> the base values defined in record 1.) </del> <ins> the base values defined in earlier records) </ins> 9.1.


Extensions that add a label that is intended for use with EXI need to create a new XSD Schema that includes all the labels in the IANA <del> registry then allocate a new EXI schemaId value.  Moving to the next letter in the alphabet is the suggested way to create the new value for the EXI schemaId.  Any labels with previously blank ID values SHOULD be updated in the IANA table to have their ID set to this new schemaId value. </del> <ins> registry and then allocate a new EXI schemaId value.  Moving to the next letter in the alphabet is the suggested way to create the new value for the EXI schemaId.  Any labels with previously blank ID values SHOULD be updated in the IANA table to have their ID set to this new schemaId value. </ins> Extensions that are mandatory to understand to correctly process the Pack MUST have a label name that ends with the '_' character.


2. The design goal is to be able to send simple sensor measurements in <del> small packets on mesh networks from large numbers of constrained devices.  Keeping the total size of payload under 80 bytes makes this easy to use on a wireless mesh network.  It is always difficult to define what small code is, but there is a desire to be able to implement this in roughly 1 KB of flash on a 8 bit microprocessor. Experience with power meters and other large scale deployments has indicated that the solution needs to support allowing multiple measurements to be batched into a single HTTP or CoAP request.  This "batch" upload capability allows the server side to efficiently support a large number of devices.  It also conveniently supports batch transfers from proxies and storage devices, even in situations where the sensor itself sends just a single data item at a time.  The multiple measurements could be from multiple related sensors or from the same sensor but at different times. </del> <ins> small packets from large numbers of constrained devices.  Keeping the total size of payload small makes it easy to use SenML also in constrained networks, e.g., in a 6LoWPAN RFC4944.  It is always difficult to define what small code is, but there is a desire to be able to implement this in roughly 1 KB of flash on a 8 bit microprocessor.  Experience with power meters and other large scale deployments has indicated that the solution needs to support allowing multiple measurements to be batched into a single HTTP or CoAP request.  This "batch" upload capability allows the server side to efficiently support a large number of devices.  It also conveniently supports batch transfers from proxies and storage devices, even in situations where the sensor itself sends just a single data item at a time.  The multiple measurements could be from multiple related sensors or from the same sensor but at different times. </ins> The basic design is an array with a series of measurements.  The following example shows two measurements made at different times.


fields to provide better information about the statistical properties of the measurement. <ins> In summary, the structure of a SenML record is laid out to support a single measurement per record.  If multiple data values are measured at the same time (e.g., air pressure and altitude), they are best kept as separate records linked through their Time value; this is even true where one of the data values is more "meta" than others (e.g., describes a condition that influences other measurements at the same time). </ins> 4.4. Sometimes it is useful to be able to refer to a defined normalized


as mile, foot, light year are not allowed.  For most cases, the SI unit is preferred. <ins> (Note that some amount of judgement will be required here, as even SI itself is not entirely consistent in this respect.  For instance, for temperature ISO-80000-5 defines a quantity, item 5-1 (thermodynamic temperature), and a corresponding unit 5-1.a (Kelvin), and then goes ahead to define another quantity right besides that, item 5-2 ("Celsius temperature"), and the corresponding unit 5-2.a (degree Celsius).  The latter quantity is defined such that it gives the thermodynamic temperature as a delta from T0 = 275.15 K.  ISO 80000-5 is defining both units side by side, and not really expressing a preference.  This level of recognition of the alternative unit degree Celsius is the reason why Celsius temperatures exceptionally seem acceptable in the SenML units list alongside Kelvin.) </ins> Symbol names that could be easily confused with existing common units or units combined with prefixes should be avoided.  For example, selecting a unit name of "mph" to indicate something that


does not lose any information from the JSON value.  EXI uses the XML types. <del> New entries can be added to the registration by Expert Review as defined in RFC8126.  Experts should exercise their own good judgment but need to consider that shorter labels should have more strict review. </del> <ins> New entries can be added to the registration by either Expert Review or IESG Approval as defined in RFC8126.  Experts should exercise their own good judgment but need to consider that shorter labels should have more strict review.  New entries should not be made that counteract the advice at the end of considerations. </ins> All new SenML labels that have "base" semantics (see senml-base) MUST start with character 'b'.  Regular labels MUST NOT start with that


encryption IV.  The frame counter must be unique and monodically increasing to avoid IV reuse. <del> The frame counter itself can be encoded in a variable length format to decrease the overhead, the following encoding schema is used The first byte in the header is fixed and contains the header metadata S 1 bit Signature flag, indicates the payload contains a signature of set. Reserved (4 bits) Reserved bits LEN (3 bits) The length of the CTR fields in bytes. CTR (Variable length) Frame counter up to 8 bytes long </del> <ins> As each sender will use their own key for encryption, so the SFrame header will include the key id to allow the receiver to identify the key that needs to be used for decrypting. Both the frame counter and the key id are encoded in a variable length format to decrease the overhead, so the first byte in the Sframe header is fixed and contains the header metadata with the following format: Signature flag (S): 1 bit This field indicates the payload contains a signature of set.  Counter Length (LEN): 3 bits This field indicates the length of the CTR fields in bytes.  Extended Key Id Flag (X): 1 bit Indicates if the key field contains the key id or the key length. Key or Key Length: 3 bits This field containts the key id (KID) if the X flag is set to 0, or the key length (KLEN) if set to 1. If X flag is 0 then the KID is in the range of 0-7 and the frame counter (CTR) is found in the next LEN bytes: Key id (KID): 3 bits The key id (0-7).  Frame counter (CTR): (Variable length) Frame counter value up to 8 bytes long. if X flag is 1 then KLEN is the length of the key (KID), that is found after the SFrame header metadata byte.  After the key id (KID), the frame counter (CTR) will be found in the next LEN bytes: 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+----------------------+------------- ---------+ |S|LEN |1|KLEN | KID... (length=KLEN) | CTR... (length=LEN) | +-+-+-+-+-+-+-+-+----------------------+----------------------+ Key length (KLEN): 3 bits The key length in bytes.  Key id (KID): (Variable length) The key id value up to 8 bytes long.  Frame counter (CTR): (Variable length) Frame counter value up to 8 bytes long. </ins> 3.2.


3- Authentication key to authenticate the encrypted frame and the media metadata <del> The IV is 128 bits long and calculated from the SRC and CTR field of the Frame header: </del> <ins> The IV is 128 bits long and calculated from the CTR field of the Frame header: </ins> 3.2.2.