3.1.Provide DNS Privacy

DoT[RFC7858] defines how to mitigate some of the issues described in "DNSPrivacy Considerations"[RFC9076] by specifying how to transmit DNS messagesover TLS. The "Usage Profiles for DNS over TLS and DNS over DTLS"[RFC8310]specify Strict and Opportunistic usage profiles for DoT including how stubresolvers can authenticate recursive resolvers.¶

QUIC connection setup includes the negotiation of security parameters usingTLS, as specified in "Using TLS to Secure QUIC"[RFC9001],enabling encryption of the QUIC transport. Transmitting DNS messages over QUICwill provide essentially the same privacy protections as DoT[RFC7858]including Strict and Opportunistic usage profiles[RFC8310]. Furtherdiscussion on this is provided inSection 7.¶

3.2.Design for Minimum Latency

QUIC is specifically designed to reduce protocol-induced delays, with featuressuch as:¶

1. Support for 0-RTT data during session resumption.¶
2. Support for advanced packet-loss recovery procedures as specified in"QUIC Loss Detection and Congestion Control"[RFC9002].¶
3. Mitigation of head-of-line blocking by allowing paralleldelivery of data on multiple streams.¶

This mapping of DNS to QUIC will take advantage of these features inthree ways:¶

1. Optional support for sending 0-RTT data during session resumption(the security and privacy implications of this are discussedin later sections).¶
2. Long-lived QUIC connections over which multiple DNS transactionsare performed,generating the sustained traffic required to benefit fromadvanced recovery features.¶
3. Mapping of each DNS Query/Response transaction to a separate stream,to mitigate head-of-line blocking. This enables servers to respondto queries "out of order". It also enables clients to processresponses as soon as they arrive, without having to wait for in-order delivery of responses previously posted by the server.¶

These considerations are reflected in the mapping of DNS trafficto QUIC streams inSection 4.2.¶

3.3.Middlebox Considerations

Using QUIC might allow a protocol to disguise its purpose from devices on thenetwork path using encryption and traffic analysis resistance techniques likepadding, traffic pacing, and traffic shaping. This specification does notinclude any measures that are designed to avoid such classification;the padding mechanisms defined inSection 5.4 are intended to obfuscate the specificrecords contained in DNS queries and responses, but not the fact that this is DNS traffic.Consequently, firewalls and other middleboxes mightbe able to distinguish DoQ from other protocols that use QUIC, like HTTP, andapply different treatment.¶

The lack of measures in this specification to avoid protocol classification is not an endorsement of such practices.¶

3.4.No Server-Initiated Transactions

As stated inSection 1, this document does not specify support forserver-initiated transactions within established DoQ connections. That is, onlythe initiator of the DoQ connection may send queries over the connection.¶

DSO does support server-initiated transactions within existing connections.However, DoQ as defined here does not meet the criteria for an applicabletransport for DSO because it does not guarantee in-order delivery of messages;seeSection 4.2 of [RFC8490].¶

4.1.Connection Establishment

DoQ connections are established as described in the QUIC transportspecification[RFC9000]. During connection establishment, DoQ support isindicated by selecting the Application-Layer Protocol Negotiation (ALPN) token "doq" in the crypto handshake.¶

4.2.Stream Mapping and Usage

The mapping of DNS traffic over QUIC streams takes advantage of the QUIC streamfeatures detailed inSection 2 of [RFC9000], the QUIC transport specification.¶

DNS query/response traffic[RFC1034][RFC1035]follows a simple pattern in which the client sends a query, and theserver provides one or more responses (multiple responses can occur in zonetransfers).¶

The mapping specified here requires that the client select a separate QUICstream for each query. The server then uses the same stream to provide all theresponse messages for that query. In order for multiple responses to beparsed, a 2-octet length field is used in exactly the same way as the 2-octetlength field defined for DNS over TCP[RFC1035]. The practical result of thisis that the content of each QUIC stream is exactly the same as the content of aTCP connection that would manage exactly one query.¶

All DNS messages (queries and responses) sent over DoQ connectionsMUST beencoded as a 2-octet length field followed by the message content as specifiedin[RFC1035].¶

The clientMUST select the next available client-initiated bidirectional streamfor each subsequent query on a QUIC connection, in conformance with the QUICtransport specification[RFC9000]. Packet losses and other network events mightcause queries to arrive in a different order. ServersSHOULD process queriesas they arrive, as not doing so would cause unnecessary delays.¶

The clientMUST send the DNS query over the selected stream andMUST indicatethrough the STREAM FIN mechanism that no further data will be sent on thatstream.¶

The serverMUST send the response(s) on the same stream andMUST indicate, afterthe last response, through the STREAM FIN mechanism that no further data will besent on that stream.¶

Therefore, a single DNS transaction consumes a single bidirectional client-initiated stream.This means that the client's first query occurs on QUIC stream 0, the second on4, and so on (seeSection 2.1 of [RFC9000]).¶

ServersMAY defer processing of a query until the STREAM FIN has been indicatedon the stream selected by the client.¶

Servers and clientsMAY monitor the numberof "dangling" streams. These are open streams where the following events have not occurred after implementation-defined timeouts:¶

• the expected queries or responses have not been received or,¶
• the expected queries or responses have been received but not the STREAM FIN¶

ImplementationsMAY impose a limit on the number of such dangling streams. If limits are encountered, implementationsMAY close the connection.¶

4.3.DoQ Error Codes

The following error codes are defined for use when abruptly terminating streams,for use as application protocol error codes whenaborting reading of streams, or for immediately closing connections:¶

DOQ_NO_ERROR (0x0):

No error. This is used when the connection or stream needs to be closed, butthere is no error to signal.¶

DOQ_INTERNAL_ERROR (0x1):

The DoQ implementation encountered an internal error and is incapable ofpursuing the transaction or the connection.¶

DOQ_PROTOCOL_ERROR (0x2):

The DoQ implementation encountered a protocol error and is forcibly abortingthe connection.¶

DOQ_REQUEST_CANCELLED (0x3):

A DoQ client uses this to signal that it wants to cancel anoutstanding transaction.¶

DOQ_EXCESSIVE_LOAD (0x4):

A DoQ implementation uses this to signal when closing a connection due to excessive load.¶

DOQ_UNSPECIFIED_ERROR (0x5):

A DoQ implementation uses this in the absence of a more specific error code.¶

DOQ_ERROR_RESERVED (0xd098ea5e):

An alternative error code used for tests.¶

SeeSection 8.4 for details on registering new error codes.¶

4.4.Connection Management

Section 10 of [RFC9000], the QUIC transport specification, specifies thatconnections can be closed in three ways:¶

• idle timeout¶
• immediate close¶
• stateless reset¶

Clients and servers implementing DoQSHOULD negotiate use of the idle timeout.Closing on idle timeout is done without any packet exchange, which minimizesprotocol overhead. PerSection 10.1 of [RFC9000], the QUIC transport specification, theeffective value of the idle timeout is computed as the minimum of the valuesadvertised by the two endpoints. Practical considerations on setting the idletimeout are discussed inSection 5.5.2.¶

ClientsSHOULD monitor the idle time incurred on their connection to theserver, defined by the time spent since the last packet from the server hasbeen received. When a client prepares to send a new DNS query to the server, itSHOULD check whether the idle time is sufficiently lower than the idle timer. If itis, the clientSHOULD send the DNS query over the existing connection. If not,the clientSHOULD establish a new connection and send the query over thatconnection.¶

ClientsMAY discard their connections to the server before the idle timeoutexpires. A client that has outstanding queriesSHOULD close the connectionexplicitly using QUIC's CONNECTION_CLOSE mechanism and the DoQ error codeDOQ_NO_ERROR.¶

Clients and serversMAY close the connection for a variety of otherreasons, indicated using QUIC's CONNECTION_CLOSE. Client and serversthat send packets over a connection discarded by their peer mightreceive a stateless reset indication. If a connection fails, all thein-progress transactions on that connectionMUST be abandoned.¶

4.5.Session Resumption and 0-RTT

A clientMAY take advantage of the session resumption and 0-RTT mechanisms supported byQUIC transport[RFC9000] and QUIC TLS[RFC9001] if the server supports them.ClientsSHOULD considerpotential privacy issues associated with session resumption before deciding to usethis mechanism and specifically evaluate the trade-offs presented in the various sections of this document. The privacy issues are detailed in Sections7.1and7.2,and the implementation considerations are discussed inSection 5.5.3.¶

The 0-RTT mechanismMUST NOT be used to send DNS requests that are not"replayable" transactions. In this specification, only transactions that havean OPCODE of QUERY or NOTIFY are considered replayable; therefore, other OPCODESMUST NOTbe sent in 0-RTT data. SeeAppendix A for a detailed discussion of why NOTIFY isincluded here.¶

ServersMAY support session resumption, andMAY do that with or without supporting0-RTT, using the mechanisms described inSection 4.6.1 of [RFC9001].Servers supporting 0-RTTMUST NOT immediately processnon-replayable transactions received in 0-RTT data but insteadMUST adopt one of the following behaviors:¶

• Queue the offending transaction and only process it after the QUIC handshakehas been completed, as defined inSection 4.1.1 of [RFC9001].¶
• Reply to the offending transaction with a response code REFUSED andan Extended DNS Error Code (EDE) "Too Early" using the extended RCODEmechanisms defined in[RFC6891] and the extended DNS errors defined in[RFC8914]; seeSection 8.3.¶
• Close the connection with the error code DOQ_PROTOCOL_ERROR.¶

4.6.Message Sizes

DoQ queries and responses are sent on QUIC streams, which in theory can carryup to 2⁶² bytes. However, DNS messages are restricted in practice to a maximumsize of 65535 bytes. This maximum size is enforced by the use of a 2-octetmessage length field in DNS over TCP[RFC1035] and DoT[RFC7858], and by the definition of the "application/dns-message" for DoH[RFC8484]. DoQ enforces the same restriction.¶

The Extension Mechanisms for DNS (EDNS(0))[RFC6891] allow peers to specify theUDP message size. This parameter is ignored by DoQ. DoQ implementations alwaysassume that the maximum message size is 65535 bytes.¶

5.1.Authentication

For the stub to recursive scenario, the authentication requirementsare the same as described in DoT[RFC7858] and "Usage Profiles for DNS overTLS and DNS over DTLS"[RFC8310].[RFC8932] states that DNS privacyservicesSHOULD provide credentials that clients can use to authenticate theserver. Given this, and to align with the authentication model for DoH, DoQ stubsSHOULD use a Strict usage profile. Client authentication for the encryptedstub to recursive scenario is not described in any DNS RFC.¶

For zone transfer, the authentication requirements are the same as described in[RFC9103].¶

For the recursive to authoritative scenario, authenticationrequirements are unspecified at the time of writing and are the subject ofongoing work in the DPRIVE WG.¶

5.2.Fallback to Other Protocols on Connection Failure

If the establishment of the DoQ connection fails, clientsMAY attempt tofall back to DoT and then potentially cleartext, as specified in DoT[RFC7858] and "Usage Profiles for DNS over TLS and DNS over DTLS"[RFC8310], depending on their usage profile.¶

DNS clientsSHOULD remember server IP addresses that don't support DoQ.Mobile clients might also remember the lack of DoQ support bygiven IP addresses on a per-context basis (e.g., per network or provisioning domain).¶

Timeouts, connection refusals, and QUIC handshake failures are indicatorsthat a server does not support DoQ. ClientsSHOULD NOT attempt DoQ queries to aserver that does not support DoQ for a reasonable period (such as one hour perserver). DNS clients following an out-of-band key-pinned usage profile[RFC7858]MAY be more aggressive about retrying after DoQ connection failures.¶

5.3.Address Validation

Section 8 of [RFC9000], the QUIC transport specification, defines AddressValidation procedures to avoid servers being used in address amplificationattacks. DoQ implementationsMUST conform to this specification, which limitsthe worst-case amplification to a factor 3.¶

DoQ implementationsSHOULD consider configuring servers to use the AddressValidation using Retry Packets procedure defined inSection 8.1.2 of [RFC9000], the QUICtransport specification. This procedure imposes a 1-RTT delay forverifying the return routability of the source address of a client, similar tothe DNS Cookies mechanism[RFC7873].¶

DoQ implementations that configure Address Validation using Retry PacketsSHOULD implement the Address Validation for Future Connections proceduredefined inSection 8.1.3 of [RFC9000], the QUIC transport specification.This defines how servers can send NEW_TOKEN frames to clients after the clientaddress is validated in order to avoid the 1-RTT penalty during subsequentconnections by the client from the same address.¶

5.4.Padding

ImplementationsMUST protect against the traffic analysis attacks described inSection 7.5 by the judicious injection of padding. Thiscould be done either by padding individual DNS messages using theEDNS(0) Padding Option[RFC7830] or by padding QUIC packets (seeSection 19.1 of [RFC9000]).¶

In theory, padding at the QUIC packet level could result in better performance for the equivalentprotection, because the amount of padding can take into account non-DNS framessuch as acknowledgements or flow control updates, and also because QUIC packetscan carry multiple DNS messages. However, applications can only control theamount of padding in QUIC packets if the implementation of QUIC exposes adequate APIs. This leadsto the following recommendations:¶

• If the implementation of QUIC exposes APIs to set a padding policy,DoQSHOULD use that API to align the packet length to a small set offixed sizes.¶
• If padding at the QUIC packet level is not available or not used,DoQMUST ensure that all DNS queries and responses are padded toa small set of fixed sizes, using the EDNS(0) padding extension as specifiedin[RFC7830].¶

Implementations might choose not to use a QUIC API for padding if it issignificantly simpler to reuse existing DNS message padding logic that isapplied to other encrypted transports.¶

In the absence of a standard policy for padding sizes, implementationsSHOULDfollow the recommendations of the Experimental status "Padding Policies forExtension Mechanisms for DNS (EDNS(0))"[RFC8467]. While Experimental,these recommendations are referenced because they are implemented and deployedfor DoT and provide a way for implementations to be fully compliant with thisspecification.¶

5.5.Connection Handling

"DNS Transport over TCP - Implementation Requirements"[RFC7766] providesupdated guidance on DNS over TCP, some of which is applicable to DoQ. This section provides similar advice on connection handling for DoQ.¶

5.6.Processing Queries in Parallel

As specified inSection 7 of [RFC7766] "DNS Transport over TCP - ImplementationRequirements", resolvers areRECOMMENDED to support the preparingof responses in parallel and sending them out of order. In DoQ, they do that bysending responses on their specific stream as soon as possible, without waitingfor availability of responses for previously opened streams.¶

5.7.Zone Transfer

[RFC9103] specifies zone transfer over TLS (XoT)and includes updates to[RFC1995] (IXFR),[RFC5936] (AXFR), and[RFC7766]. Considerations relating to the reuse of XoT connectionsdescribed there apply analogously to zone transfers performed using DoQconnections. One reason for reiterating such specific guidance is thelack of effective connection reuse in existing TCP/TLS zone transferimplementations today. The following recommendations apply:¶

• DoQ serversMUST be able to handle multiple concurrent IXFR requests on asingle QUIC connection.¶
• DoQ serversMUST be able to handle multiple concurrent AXFR requests on asingle QUIC connection.¶

• DoQ implementationsSHOULD¶

  • use the same QUIC connection for both AXFR and IXFR requests to the sameprimary¶
  • send those requests in parallel as soon as they are queued, i.e., do not waitfor a response before sending the next query on the connection(this is analogous to pipelining requests on a TCP/TLS connection)¶
  • send the response(s) for each request as soon as they are available, i.e.,response streamsMAY be sent intermingled¶

5.8.Flow Control Mechanisms

Servers and clients manage flow control using the mechanisms defined inSection 4 of [RFC9000]. These mechanisms allow clients and servers to specifyhow many streams can be created, how much data can be sent on a stream,and how much data can be sent on the union of all streams. For DoQ,controlling how many streams are created allows servers to control how manynew requests the client can send on a given connection.¶

Flow control exists to protect endpoint resources.For servers, global and per-stream flow control limits control how much data can be sent byclients. The same mechanismsallow clients to control how much data can be sent by servers.Values that are too small will unnecessarily limit performance.Values that are too large might expose endpoints to overload or memory exhaustion.Implementations or deployments will need to adjust flow control limits tobalance these concerns. In particular, zone transfer implementations will need to controlthese limits carefully to ensure both large and concurrent zone transfers are well managed.¶

Initial values of parameters control how many requests and how much data can besent by clients and servers at the beginning of the connection. These valuesare specified in transport parameters exchanged during the connection handshake.The parameter values received in the initial connection also control how many requests andhow much data can be sent by clients using 0-RTT data in a resumed connection.Using too small values of these initial parameters would restrict theusefulness of allowing 0-RTT data.¶

7.1.Privacy Issues with 0-RTT data

The 0-RTT data can be replayed by adversaries. That data may trigger queries bya recursive resolver to authoritative resolvers. Adversaries may be able topick a time at which the recursive resolver outgoing traffic is observable andthus find out what name was queried for in the 0-RTT data.¶

This risk is in fact a subset of the general problem of observing the behaviorof the recursive resolver discussed in "DNS Privacy Considerations"[RFC9076]. The attack is partially mitigated by reducing the observabilityof this traffic. The mandatory replay protection mechanisms inTLS 1.3[RFC8446] limit but do not eliminate the risk of replay.0-RTT packets can only be replayed within a narrow window,which is only wide enough to account for variations in clock skew and network transmission.¶

The recommendation for TLS 1.3[RFC8446] is that the capability to use 0-RTTdata should be turned off by default and only enabled if the user clearlyunderstands the associated risks. In the case of DoQ, allowing 0-RTT dataprovides significant performance gains, and there is a concern that arecommendation to not use it would simply be ignored. Instead, a set ofpractical recommendations is provided in Sections4.5 and5.5.3.¶

The specifications inSection 4.5 block the most obviousrisks of replay attacks, as they only allow for transactions that willnot change the long-term state of the server.¶

The attacks described above apply to the stub resolver to recursive resolver scenario, but similar attacks might be envisaged in therecursive resolver to authoritative resolver scenario, and thesame mitigations apply.¶

7.2.Privacy Issues with Session Resumption

The QUIC session resumption mechanism reduces the cost of re-establishing sessionsand enables 0-RTT data. There is a linkability issue associated with sessionresumption, if the same resumption token is used several times. Attackers on pathbetween client and server could observe repeated usage of the token anduse that to track the client over time or over multiple locations.¶

The session resumption mechanism allows servers to correlate the resumed sessionswith the initial sessions and thus to track the client. This creates a virtuallong duration session. The series of queries in that session can be used by theserver to identify the client. Servers can most probably do that already ifthe client address remains constant, but session resumption tickets also enabletracking after changes of the client's address.¶

The recommendations inSection 5.5.3 are designed tomitigate these risks. Using session tickets only once mitigatesthe risk of tracking by third parties. Refusing to resume a session if addresseschange mitigates the incremental risk of tracking by the server (but the risk oftracking by IP address remains).¶

The privacy trade-offs here may be context specific. Stub resolvers will have a strongmotivation to prefer privacy over latency since they often change location. However,recursive resolvers that use a small set of static IP addresses are more likely to prefer the reducedlatency provided by session resumption and may consider this a valid reason to useresumption tickets even if the IP address changed between sessions.¶

Encrypted zone transfer ([RFC9103]) explicitly doesnot attempt to hide the identity of the parties involved in the transfer; at thesame time, such transfers are not particularly latency sensitive. This means thatapplications supporting zone transfers may decide to apply the sameprotections as stub to recursive applications.¶

7.3.Privacy Issues with Address Validation Tokens

QUIC specifies address validation mechanisms inSection 8 of [RFC9000]. Useof an address validation token allows QUIC servers to avoid an extra RTT fornew connections. Address validation tokens are typically tied to an IP address.QUIC clients normally only use these tokens when setting up a new connectionfrom a previously used address. However, clients are not always aware that theyare using a new address. This could be due to NAT, or because the client doesnot have an API available to check if the IP address has changed (which can bequite often for IPv6). There is a linkability risk if clients mistakenly useaddress validation tokens after unknowingly moving to a new location.¶

The recommendations inSection 5.5.3 mitigatesthis risk by tying the usage of the NEW_TOKEN to that of session resumption,though this recommendation does not cover the case where the client is unawareof the address change.¶

7.4.Privacy Issues with Long Duration Sessions

A potential alternative to session resumption is the use of long duration sessions:if a session remains open for a long time, new queries can be sent without incurringconnection establishment delays. It is worth pointing out that the two solutions havesimilar privacy characteristics. Session resumption may allow servers to keep trackof the IP addresses of clients, but long duration sessions have the same effect.¶

In particular, a DoQ implementation might take advantage of the connection migrationfeatures of QUIC to maintain a session even if the client's connectivity changes,for example, if the client migrates from a Wi-Fi connection to a cellular networkconnection and then to another Wi-Fi connection. The server would beable to track the client location by monitoring the succession of IP addressesused by the long duration connection.¶

The recommendation inSection 5.5.4 mitigatesthe privacy concerns related to long duration sessions using multiple client addresses.¶

7.5.Traffic Analysis

Even though QUIC packets are encrypted, adversaries can gain information fromobserving packet lengths, in both queries and responses, as well as packettiming. Many DNS requests are emitted by web browsers. Loading a specific webpage may require resolving dozens of DNS names. If an application adopts asimple mapping of one query or response per packet, or "one QUIC STREAM frameper packet", then the succession of packet lengths may provide enoughinformation to identify the requested site.¶

ImplementationsSHOULD use the mechanisms defined inSection 5.4 to mitigatethis attack.¶

8.1.Registration of a DoQ Identification String

This document creates a new registration for the identification of DoQ in the"TLS Application-Layer Protocol Negotiation (ALPN) Protocol IDs" registry[RFC7301].¶

The "doq" string identifies DoQ:¶

Protocol:

DoQ¶

Identification Sequence:

0x64 0x6F 0x71 ("doq")¶

Specification:

This document¶

8.2.Reservation of a Dedicated Port

For both TCP and UDP, port 853 is currently reserved for "DNS query-response protocol run over TLS/DTLS"[RFC7858].¶

However, the specification for DNS over DTLS (DoD)[RFC8094] is experimental, limited to stub to resolver, and noimplementations or deployments currently exist to the authors' knowledge (even thoughseveral years have passed since the specification was published).¶

This specification additionally reserves the use of UDP port 853 forDoQ. QUIC version 1 was designed to be able to coexist with other protocols onthe same port, including DTLS; seeSection 17.2 of [RFC9000]. This meansthat deployments that serve DoD and DoQ (QUIC version 1) on thesame port will be able to demultiplex the two due to the second mostsignificant bit in each UDP payload. Such deployments ought to check thesignatures of future versions or extensions (e.g.,[GREASING-QUIC])of QUIC and DTLS before deploying them to serve DNS on the same port.¶

IANA has updated the following value in the "Service Name and TransportProtocol Port Number Registry" in the System range. The registry for that rangerequires IETF Review or IESG Approval[RFC6335].¶

Service Name:

domain-s¶

Port Number:

853¶

Transport Protocol(s):

UDP¶

Assignee:

IESG¶

Contact:

IETF Chair¶

Description:

DNS query-response protocol run over DTLS or QUIC¶

Reference:

[RFC7858][RFC8094] This document¶

Additionally, IANA has updated the Description field for thecorresponding TCP port 853 allocation to be "DNS query-response protocol runover TLS" and removed[RFC8094] from the TCP allocation's Reference field for consistency and clarity.¶

8.3.Reservation of an Extended DNS Error Code: Too Early

IANA has registered the following value inthe "Extended DNS Error Codes" registry[RFC8914]:¶

INFO-CODE:

26¶

Purpose:

Too Early¶

Reference:

This document¶

8.4.DNS-over-QUIC Error Codes Registry

IANA has added a registry for "DNS-over-QUIC Error Codes" on the"Domain Name System (DNS) Parameters" web page.¶

The "DNS-over-QUIC Error Codes" registry governs a 62-bit space. This space issplit into three regions that are governed by different policies:¶

• Permanent registrations for values between 0x00 and 0x3f (in hexadecimal;inclusive), which are assigned using Standards Action or IESG Approval asdefined in Sections4.9 and4.10 of[RFC8126]¶
• Permanent registrations for values larger than 0x3f, which are assignedusing the Specification Required policy ([RFC8126])¶
• Provisional registrations for values larger than 0x3f, which require ExpertReview, as defined inSection 4.5 of [RFC8126].¶

Provisional reservations share the range of values larger than 0x3fwith some permanent registrations. This is by design to enable conversionof provisional registrations into permanent registrations without requiringchanges in deployed systems. (This design is aligned with the principlesset inSection 22 of [RFC9000].)¶

Registrations in this registryMUST include the following fields:¶

Value:

The assigned codepoint¶

Status:

"Permanent" or "Provisional"¶

Contact:

Contact details for the registrant¶

In addition, permanent registrationsMUST include:¶

Error:

A short mnemonic for the parameter¶

Specification:

A reference to a publicly available specification for the value (optional for provisional registrations)¶

Description:

A brief description of the error code semantics, whichMAY be a summary if aspecification reference is provided¶

Provisional registrations of codepoints are intended to allow for private useand experimentation with extensions to DoQ. However,provisional registrations could be reclaimed and reassigned for other purposes.In addition to the parameters listed above, provisional registrationsMUST include:¶

Date:

The date of last update to the registration¶

A request to update the date on any provisionalregistration can be made without review from the designated expert(s).¶

The initial content of this registry is shown inTable 1 and allentries share the following fields:¶

Status:

Permanent¶

Contact:

DPRIVE WG¶

Specification:

Section 4.3¶