Question: successful ACK processing updates the keys of the KeyUpdate message sender, which is reflected in the change of epoch values. <ins> With a 128-bit key as in AES-256, rekeying 2^64 times has a high probability of key reuse within a given connection.  Note that even if the key repeats, the IV is also independently generated.  In order to provide an extra margin of security, sending implementations MUST NOT allow the epoch to exceed 2^48-1.  In order to allow this value to be changed later, receiving implementations MUST NOT enforce this rule.  If a sending implementation receives a KeyUpdate with request_update set to "update_requested", it MUST NOT send its own KeyUpdate if that would cause it to exceed these limits. </ins> 9. If the client and server have negotiated the "connection_id"

Yet another attempt to This builds on Chris's PR but just omits the epoch entirely from the AEAD nonce calculation. This is more consistent with TLS and doesn't require special case reasoning about why we only need to build in the bottom 16 bits. This relies entirely on the keys being different. Needs analysis.
This seems promising.
NAME this LGTM, but there's a conflict. Can you resolve prior to merging? NAME are you OK with the new rationale, and text that allows it to be relaxed in the future?
If I have understood and calculated correctly DTLS 1.3 limits the number of packets in a AES-GCM connection to 2^40.5 compared to 2^64 in DTLS 1.2. This is quite a severe limitation that is not mentioned explicitly. The AEAD limits in themselves are not a problem, but the combination of AEAD limits (2^24.5) and a small epoch (2^16) is a problem. I think this is major problem in some use cases of DTLS. E.g. most 3GPP 5G use cases where DTLS or DTLS/SCTP is used for semi-permanent connections (lasting years) and where the terminating the connection cause severe disturbances. I did not find any discussion about this problem (but I could easily have missed it) It is known that the limit of 2^48 packets in SRTP can be reached and 2^40.5 is significantly smaller than this... If the document was not in such a late stage, I would have suggested to increase the size of the epoch to 32 bits..... I think this and the other problems DTLS 1.3 has with semi-permanent connections has to be solved sooner than later.
NAME thanks for filing this. I hear you about the late stage, but IIRC we never represent the entire epoch on the wire in any case, so it seems like just changing it to 32 bits would be pretty easy, so why not do it now?
How do the chacha20 numbers compare to the AES-GCM ones?


Question: successful ACK processing updates the keys of the KeyUpdate message sender, which is reflected in the change of epoch values. <ins> With a 128-bit key as in AES-256, rekeying 2^64 times has a high probability of key reuse within a given connection.  Note that even if the key repeats, the IV is also independently generated.  In order to provide an extra margin of security, sending implementations MUST NOT allow the epoch to exceed 2^48-1.  In order to allow this value to be changed later, receiving implementations MUST NOT enforce this rule.  If a sending implementation receives a KeyUpdate with request_update set to "update_requested", it MUST NOT send its own KeyUpdate if that would cause it to exceed these limits. </ins> 9. If the client and server have negotiated the "connection_id"

NAME I don't think (D)TLS 1.3 puts any limits on ChaCha20 so my understanding is understanding is that the total number of packets can be protected in the current drafts is ChaCha20 2^64 (2^48 2^16) AES-GCM 2^40.5 (2^24.5 2^16) AES-GCM 2^39 (2^23 * 2^16)
NAME I am all for changing this now. I made a PR that change epoch from uint16 to uint32. As you say, it seems like a pretty easy change to do. Is uint32 the right size?
Unless you think we should do uint64. NAME NAME what would we have to do to make this change?
URL Magnus Westerlund thinks uint64 would be a safer bet.Michael Tüxen suggest to wrap the uint16 epoch instead. That might be an easier solution. I don't see a direct problem in DTLSPlaintext, ACK message, or recordsequencenumber with a uint16 epoch that is allowed to wrap like: 4, 5, ... 2^16-1, 4, 5, ... 2^16-1, 4, 5, ...
NAME NAME NAME since it's through the IESG we would need to at least raise that this change was made after they had approved it. I suspect that doing some kind of 2-week heads up to the WG/IESG that we want to make the change before landing it. But, if we do that or something more drastic that's really up to NAME
I want to point out that allowing wrapping per may not be the best solution if one considers to use the DTLS epoch as part of the input to the TLS exporter as suggested in . Then one want an input that doesn't wrap, and then to ensure that one doesn't practically run into any limits, then an uint64 would be better. An unit32 appears to be sufficient for a quite extreme use case with minimal messages size (which is one DTLS record with 4 byte user message) and high bandwidth (10 Gbps) sustained over a period of more than 5 years before the epoch would wrap.


Question: successful ACK processing updates the keys of the KeyUpdate message sender, which is reflected in the change of epoch values. <ins> With a 128-bit key as in AES-256, rekeying 2^64 times has a high probability of key reuse within a given connection.  Note that even if the key repeats, the IV is also independently generated.  In order to provide an extra margin of security, sending implementations MUST NOT allow the epoch to exceed 2^48-1.  In order to allow this value to be changed later, receiving implementations MUST NOT enforce this rule.  If a sending implementation receives a KeyUpdate with request_update set to "update_requested", it MUST NOT send its own KeyUpdate if that would cause it to exceed these limits. </ins> 9. If the client and server have negotiated the "connection_id"

However, to my understanding the full epoch value are so rarely included in transmitted DTLS messages that its size have minimal implication on the overhead that it is not worth saving 4-bytes to be certain to have eliminated any practical limitation.
I think a 2-week WGLC and notifying the IESG will suffice.
FYI. We have now run into quite many problems with the interworking of semi-permanent DTLS/SCTP connections (lasting years) and DTLS 1.3: No Diffie-Hellman rekeying No post-handshake server authentication No rekeying of the exporter_secret 2^40.5 packets limit 2 minute MSL requirement 2^38.5 byte SCTP user message size limit Our initial plan was to just replace DTLS 1.2 with DTLS 1.3, leave DTLS/SCTP as is, but as the problems keep adding up we are now startnig to consider quite big changes to DTLS/SCTP 1.3 to make this work: URL Using new DTLS connections instead of KeyUpdate could potentially address the first five, but is a significant change.
Hi, Based on the problems long-lived DTLS/SCTP had with DTLS 1.3 (as well as DTLS 1.2 without renegotiation and respecting AEAD limits) we restructured DTLS/SCTP (RFC6083bis) to use parallel connections instead of relying on renegotiation and post-handshake messages. We think this quite easily solves all the problems we had without requiring any updates of DTLS 1.3. It also makes DTLS/SCTP less dependant on version specific DTLS mechanisms. It will hopefully work without changes with any future DTLS 1.4. URL We can now firmly RECOMMEND DTLS 1.3 which I think is very important. 5G is to a large degree replacing or complementing IPsec with TLS, DTLS, and DTLS/SCTP. I will do my best to transition 3GPP to DTLS 1.3 asap. FYI, 3GPP DTLS/SCTP associations have very long lifetimes (can be years), strive for five nines (99.999%) availability and cannot be teared down without causing major disruptions.


Question: successful ACK processing updates the keys of the KeyUpdate message sender, which is reflected in the change of epoch values. <ins> With a 128-bit key as in AES-256, rekeying 2^64 times has a high probability of key reuse within a given connection.  Note that even if the key repeats, the IV is also independently generated.  In order to provide an extra margin of security, sending implementations MUST NOT allow the epoch to exceed 2^48-1.  In order to allow this value to be changed later, receiving implementations MUST NOT enforce this rule.  If a sending implementation receives a KeyUpdate with request_update set to "update_requested", it MUST NOT send its own KeyUpdate if that would cause it to exceed these limits. </ins> 9. If the client and server have negotiated the "connection_id"

With such long lifetimes we think mutual reauthentication, rekeying of the SCTP-AUTH key, and forcing attackers to dynamic key exfiltration [RFC7624] are required features. I still think should be done. 2^40.5 packets is quite limiting.
Seems OK.Thanks -- this LGTM. We'll need to do a brief consensus call given the type of change.


Question: entities that handle the data, but do not modify it (such as TURN relays). <del> It includes necessary functions for congestion control: When not to send data. </del> <ins> It includes necessary functions for congestion control, retransmission, and in-order delivery. </ins> WebRTC endpoints MUST implement the transport protocols described in I-D.ietf-rtcweb-transports.

Spencer had the following comment: I'm not sure how tutorial you want section 4 to be, but I'd at least mention appropriate retransmission and in-order delivery, in addition to congestion control, since you get that with SCTP on the data channel.


Question: "key_share" and using the "psk_dhe_ke" pre-shared key exchange mode is also important in order to limit the impact of a key compromise. When using "psk_dhe_ke", TLS 1.3 provides forward secrecy meaning <del> that key leakage does not compromise any earlier connections.  It is RECOMMMENDED to use "psk_dhe_ke" for resumption. </del> <ins> that key leakage does not compromise any earlier connections.  The "psk_dh_ke" mechanism MUST be used for resumption unless the deployment has a local requirement to allow configuration of other mechanisms. </ins> 2.1.4.

URL
I added "604800 seconds" as suggested by Oleg. Joe suggested "Perhaps both of these should be left to the TLS spec." I would agree with this.... Thanks Joe, one comment regarding item is inline below. Joseph Salowey wrote: [Oleg] Got it. Then maybe it is worth specifying 604800 seconds in the section "5.7. Resumption" also so it will be clear that the requirement in this section is the same strict as in "2.1.2. Ticket Establishment".


Question: ?1.  A Capsule-Protocol header field with a value of ?0 has the same semantics as when the header is not present.  Intermediaries MAY use this header field to allow processing of HTTP Datagrams for unknown <del> HTTP methods or unknown HTTP Upgrade Tokens. </del> <ins> HTTP Upgrade Tokens; note that this is only possible for HTTP Upgrade or Extended CONNECT. </ins> The Capsule-Protocol header field MUST NOT be sent multiple times on a message.  The Capsule-Protocol header field MUST NOT be used on

This may be answered and I just missed it. After reading I think that for HTTP/1 and HTTP/2 Datagrams (via capsules) can only be sent for new methods/upgrade tokens. But it wasn't clear to me if that same property was true for HTTP/3. For example, would it be valid to send HTTP/3 datagrams along with a GET request? If so, I think this means that for HTTP/3 a GET request could have both a body AND datagrams?
That's a very good point. If anything, we should be prescriptive about what endpoints do if they receive a datagram associated with an existing method like GET. I suspect drop or error are the most likely candidates here.
I vote for close the connection with error. The datagram has the relate to something in the request. If the request doesn't or cannot articulate a datagram use, the sender of datagram is probably broken or stupid.
Since datagrams are strongly associated with a stream, I think it'd be more consistent to make this a stream error. Regardless, folks my want an extension to GET that allows sending datagrams with it, but it makes sense to require that this extension be negotiated via headers or settings first, so the semantics of such datagrams are agreed upon beforehand. So, I'm supportive of making this a stream error, with the understanding that any extension can lift this requirement between consenting parties.
I'd prefer to make people suffer but I could live with a stream error. Like you suggest, by letting people people agree on a change of requirements, we support extension. But the default of erroring helps datagram avoid the mess othat GET with body is.
Also, I reserve the right to count the number of these failures and close the connection if it reaches my annoyance threshold
Ah yes . Sounds good, I'll write up a PR for this once the design team PRs are landed.
Sounds good to me. An extension could just as easily lift a connection error requirement as it could a stream error requirement in case that had any bearing on the thinking here. (A connection error might be nice because it prevents a confused peer from sending a possibly incessant stream of datagrams.


Question: ?1.  A Capsule-Protocol header field with a value of ?0 has the same semantics as when the header is not present.  Intermediaries MAY use this header field to allow processing of HTTP Datagrams for unknown <del> HTTP methods or unknown HTTP Upgrade Tokens. </del> <ins> HTTP Upgrade Tokens; note that this is only possible for HTTP Upgrade or Extended CONNECT. </ins> The Capsule-Protocol header field MUST NOT be sent multiple times on a message.  The Capsule-Protocol header field MUST NOT be used on

On the other hand, confused peers gonna be confused and David's point about datagrams being strongly associated with a request is a good point)
I think it should be a stream error to enable method-agnostic gateways and proxies, which may be multiplexing different clients' traffic onto a single next-hop connection.
In , NAME points out that Content-Type doesn't make sense with the capsule protocol. Should we prohibit it?
In , NAME points out that status codes 204, 205, and 206 don't make sense with the capsule protocol. Should we prohibit them?
The spec currently says: In HTTP/1.x, the message content is generally delineated by the Content-Length header field or the Transfer-Encoding; another request can follow on the same connection. One of the (many) ways in which CONNECT and Upgrade are special is that in H1 it takes over the connection and makes the request extend to the end of the connection, preventing any further requests from being made. The description attempts to be generic about method, but implicitly assumes an indefinite length stream of bytes which (in H1) is only true of CONNECT or Upgrade. This concept is correct for what we have in mind, but the boundaries aren't crisply described right now. NAME may have opinions.
The sentence right after the bit you pasted is: That constrains this to CONNECT/Upgrade/new methods. Is that not enough?
I think "new methods" is probably the most questionable. It's not clear to me that a new method can obtain the special behaviors of CONNECT. If it were restricted to upgrade tokens (whether with HTTP/1.1 Upgrade or RFC 8441 Extended CONNECT), I think that would address the concern.
I believe what he means is this definition of a data stream only holds for CONNECT requests. There is no mechanism to extend that to new request methods since all other methods are required to have length-delimited data (or no data).
Likewise, I don't know of any reason we would want to support such extension methods in the future, since that is a known failure point for CONNECT. It is far simpler for a new method to require chunked or data frames.
Restricting this to extended CONNECT and Upgrade sounds reasonable to me
For Upgrade, the new protocol takes over after the current response is complete. Hence, the description above doesn't really work for Upgrade either.


Question: ?1.  A Capsule-Protocol header field with a value of ?0 has the same semantics as when the header is not present.  Intermediaries MAY use this header field to allow processing of HTTP Datagrams for unknown <del> HTTP methods or unknown HTTP Upgrade Tokens. </del> <ins> HTTP Upgrade Tokens; note that this is only possible for HTTP Upgrade or Extended CONNECT. </ins> The Capsule-Protocol header field MUST NOT be sent multiple times on a message.  The Capsule-Protocol header field MUST NOT be used on

NAME the intent of that text was to mean "after the current response is complete" - do you have a proposal for phrasing that would work better?
Semantics says: URL I think is consistent with the definition of "data stream" in this document. (And in fact uses the term "data stream" without defining it.) That doesn't seem to match deferring the new protocol until after the response.
I don't think there is any technical distinction between the two descriptions; it's nomenclature to say that what follows the CONNECT is a tunnel ended by connection closure, whereas what follows Upgrade is a different protocol that might very well come back to this one (as determined by the other protocol).
And point to URL This is an important part of the security analysis.
Only if you believe that the Sec- prefix is useful for the Capsule-Protocol header field. I don't.
Sorry, I don't mean that it's the only thing that makes it work, merely that if were going to talk about how to analyze it, this is something we should say.
NAME can you clarify your intent? Your issue title starts with "Add to JS" but I suspect you didn't mean that we should modify the JavaScript specification. Would a note next to where the "Capsule-Protocol" header is defined resolve this?
Aaargh. I meant "add to the security considerations".
Thanks, that makes more sense :) Adding something to security considerations sounds good to me, I'll add text to the . Note that this was filed on the wrong repository, is the droid you're looking for.
So this assumption is useful in that it helps us avoid an analysis. Though my sense is that that analysis isn't especially difficult. The header field exists to enable datagram forwarding behaviour in an intermediary. We only have to show that there is no harm inflicted if a client engages that behaviour for requests, under the constraint that the client is otherwise authorized to make from a web context. The risk comes if this forwarding behaviour somehow generates different semantics as a result. As the same client also provides the stream of data that will be forwarded, it is trivial to see that they are already in a position to engage whatever semantics they choose.


Question: ?1.  A Capsule-Protocol header field with a value of ?0 has the same semantics as when the header is not present.  Intermediaries MAY use this header field to allow processing of HTTP Datagrams for unknown <del> HTTP methods or unknown HTTP Upgrade Tokens. </del> <ins> HTTP Upgrade Tokens; note that this is only possible for HTTP Upgrade or Extended CONNECT. </ins> The Capsule-Protocol header field MUST NOT be sent multiple times on a message.  The Capsule-Protocol header field MUST NOT be used on

The only scenario that might benefit an attacker is where the elision of datagrams (or things that look like them) might be used to evade security protections that scan the stream of data. For an attack to be effective, those same protections would have to be ignorant of datagram forwarding behaviour at the same intermediary. This binding to CONNECT is a useful shortcut that means we don't need to engage with all that stuff, which wouldn't be that easy to write down. (This aversion to engagement is, I believe, a large part of why people want to slap "Sec-" on all new headers.)
MT's framing of this is helpful. Adding some security consideration about what might go wrong for an intermediary seems potentially useful. Spending text on why a browser is special in this regard seems less compelling to nme.
I was about to write a PR for this, but I think we should first If we decide that capsules are only allowed for HTTP upgrade tokens (and not new methods) then we've restricted ourselves to CONNECT and Upgrade which are both inaccessible from JavaScript.
LGTM thanks


Question: 4.1. There are several DHCP options that convey local domain hints of <del> different kinds.  The most directly relevant is "RDNSS Selection" RFC6731, which provides "a list of domains ... about which the RDNSS has special knowledge", along with a "High", "Medium", or "Low" preference for each name.  The specification notes the difficulty of relying on these hints without validation: Other local domain hints in DHCP include the "Domain Name" RFC2132, "Access Network Domain Name" RFC5986, "Client FQDN" RFC4704, and "Name Service Search" RFC2937 options.  This specification may help clients to interpret these hints.  For example, a rogue DHCP server could use the "Client FQDN" option to assign a client the name </del> <ins> different kinds.  The most directly relevant is RFC6731, which provides "a list of domains ... about which the RDNSS has special knowledge", along with a "High", "Medium", or "Low" preference for each name.  The specification notes the difficulty of relying on these hints without validation: Other local domain hints in DHCP include the RFC2132, RFC5986, "Client FQDN" RFC4704, and RFC2937 options.  This specification may help clients to interpret these hints.  For example, a rogue DHCP server could use the "Client FQDN" option to assign a client the name </ins> "www.example.com" in order to prevent the client from reaching the true "www.example.com".  A client could use this specification to check the network's authority over this name, and adjust its behavior

Includes: Text adjustments for grammar and clarity Replacing "public" resolver with "external" Changes to references and blockquotes Made diagrams narrower
NAME NAME Please review
Changes look good to me.


Question: of SP-800-56A.  For secp256r1, secp384r1, and secp521r1, at least partial public-key validation MUST be done. <del> A static Diffie-Hellman key for authentication in method 1, 2 or 3 MUST NOT not be used as a digital signature key for authentication in method 0, unless proven secure by a dedicated cryptographic analysis. </del> <ins> As noted in Section 12 of I-D.ietf-cose-rfc8152bis-struct the use of a single key for multiple algorithms is strongly disencouraged unless proven secure by a dedicated cryptographic analysis.  In particular this recommendation applies to using the same private key for static Diffie-Hellman authentication and digital signature authentication. </ins> A preliminary conjecture is that a minor change to EDHOC may be sufficient to fit the analysis of secure shared signature and ECDH key usage in Degabriele11 and Thormarker21.

Reformulating security of expand as stream cipher instead of removing. HKDF-Expand is very often used.Added note of HKDF-Expand length restriction.Key use for different algorithms is already covered by COSE. Nothing is special with use inside of EDHOC. The text is clearly not correct at as signate can also be used in other methods.
Channeling from Erik. Use of the HKDF as EDHOC-KDF for generation of KEYSTREAM2 and encryption of message2 induces a max size. For example, HKDF-SHA256 has max output size 255*32 = 8160 bytes.


Question: different forms.  For example, any Client can only remain private relative to the entire space of other Clients using the protocol. Moreover, by owning tokens for a given set of keys, the Client's <del> anonymity set shrinks to the total number of clients controlling </del> <ins> anonymity set shrinks to the total number of Clients controlling </ins> tokens for the same keys. In the following, we consider the possible ways that Issuers can

Supercede's .
Section 6 states: But there's just one subsection. :smiley: More importantly, it's not clear that the Clients are the malicious ones in the examples provided for token exhaustion.
Resolved in by removing the section header.
The security considerations section starts: But only one item, Token Exhaustion, is listed. Should there be more items listed here? Or should the section be collapsed to not have a subsection?
Resolved in by collapsing.


Question: ClientHelloInner.  The client-facing server forwards all other TLS messages between the client and backend server unmodified. <ins> Otherwise, if all candidate ECHConfigs fail to decrypt the extension, the client-facing server MUST ignore the extension and proceed with the connection using ClientHelloOuter.  This connection proceeds as usual, except the server MUST include the "encrypted_client_hello" extension in its EncryptedExtensions with the "retry_configs" field set to one or more ECHConfig structures with up-to-date keys. Servers MAY supply multiple ECHConfig values of different versions. This allows a server to support multiple versions at once. Note that decryption failure could indicate a GREASE ECH extension (see grease-extensions), so it is necessary for servers to proceed with the connection and rely on the client to abort if ECH was required.  In particular, the unrecognized value alone does not indicate a misconfigured ECH advertisement (misconfiguration). Instead, servers can measure occurrences of the "ech_required" alert to detect this case. </ins> 7.1.1. In case a HelloRetryRequest (HRR) is sent, the client-facing server

The spec describes an optional trial decryption mode, but most of the text contradicts it. This PR fixes the text up and tries to unify their processing models. In doing so, it flips the error handling from decrypterror to fallback to be consistent. This, combined with the ClientHelloOuterAAD change, plugs an active sticking out attack for free. It also makes easier because GREASE configid collisions with real configids are now harmless. Along the way, NAME and NAME observed that we're not authenticating the ECHConfig at all. (It used to be authenticated by way of the configid, which was a digest.) Instead, just pass the ECHConfig into the info field of the HPKE context. They also noticed the server rule about PSKs on ClientHelloOuter didn't work with GREASE. Instead, we can simply remove it.
This matches the acceptance signal length, and we've already accepted that probability of collision.


Question: Indicates that x is repeated zero or more times (and that each instance is length E) <ins> This document uses network byte order (that is, big endian) values. Fields are placed starting from the high-order bits of each byte. </ins> fig-ex-format shows an example structure: 5.

Editorial NiTs when reviewing the invariant text. These NiTs address readability issues, and do not intend to change the meaning of the text.
Is there an associated issue?
Thanks Gorry, these are all quite helpful. 1) I understand the acronyms DCID and SCID, but these aren't really expanded on first use in sect 5.1. 2) There's mention of "the high bit", but there doesn't seem to be any statement of bit order saying. Is it worth declaring network byte/bit order earlier in section 4? This also clarifies the placement of fields within a byte, which was basically assumed knowledge otherwise. 3) Personally, I don't think: "The length of the Destination Connection ID is not specified" is a great choice of words. Surely, this needs to be specified somewhere for a protocol instance to use it? This reads better as something like: The length of the Destination Connection ID is not encoded in packets with a short header and is not constrained by this specification. 4) The brackets here seem to point to connection IDs in general, not the DCID "(see Section 5.3)". Is it worth writing that as "Connection IDs are described in Section 5", rather than use brackets? The same is true for versions. 5) In section 5.3: "the wrong endpoint" is taken as the wrong transport endpoint, but some of our IP and subIP colleagues would use the term endpoint for other uses, so one insertion of "transport" would perhaps help? 6) In the appendix A, this: "QUIC forbids acknowledgments of packets" - still has me wondering what is actually intended to be understood, because the list of bullets is not guarenteed ... : /The last packet before a long period of quiescence might be assumed to contain an acknowledgment (it should be assumed that QUIC could allow acknowledgments of packets that only contain ACK frames)/ I'm not sure what to say here I think the combination of not... forbids threw me off the meaning. Changes proposed in
Thanks for changing SCID/DCID to "Source Connection ID" and "Destination Connection ID", that seems like a good change.


Question: 3.1. Adaptive BitRate (ABR) is a sort of application-level response <del> strategy in which the receiving media player attempts to detect the available bandwidth of the network path by experiment or by observing the successful application-layer download speed, then chooses a video bitrate (among the limited number of available options) that fits within that bandwidth, typically adjusting as changes in available bandwidth occur in the network or changes in capabilities occur in the player (such as available memory, CPU, display size, etc.). </del> <ins> strategy in which the streaming client attempts to detect the available bandwidth of the network path by observing the successful application-layer download speed, then chooses a bitrate for each of the video, audio, subtitles and metadata (among the limited number of available options) that fits within that bandwidth, typically adjusting as changes in available bandwidth occur in the network or changes in capabilities occur during the playback (such as available memory, CPU, display size, etc.). </ins> The choice of bitrate occurs within the context of optimizing for <del> some metric monitored by the video player, such as highest achievable video quality, or lowest rate of expected rebuffering events. </del> <ins> some metric monitored by the client, such as highest achievable video quality or lowest chances for a rebuffering (playback stall). </ins> 3.2. <del> ABR playback is commonly implemented by video players using HLS </del> <ins> ABR playback is commonly implemented by streaming clients using HLS </ins> RFC8216 or DASH DASH to perform a reliable segmented delivery of <del> video data over HTTP.  Different player implementations and receiving devices use different strategies, often proprietary algorithms (called rate adaptation or bitrate selection algorithms), to perform available bandwidth estimation/prediction and the bitrate selection. Most players only use passive observations, i.e., they do not generate probe traffic to measure the available bandwidth. </del> <ins> media over HTTP.  Different implementations use different strategies ABRSurvey, often proprietary algorithms (called rate adaptation or bitrate selection algorithms) to perform available bandwidth estimation/prediction and the bitrate selection.  Most clients only use passive observations, i.e., they do not generate probe traffic to measure the available bandwidth. </ins> This kind of bandwidth-measurement systems can experience trouble in several ways that can be affected by networking design choices.

Ali, this PR looks nice. Two meta-issues (which we can talk about whenever). I changed my references in the draft to a more complete format (using ins: can result in odd formatting in the References section). We don't have to do that for all the references in -04, but that would be a good thing to do in an editorial pass. I see that you're making some terminology changes (from "delivery" to "streaming", stuff like that). I agree with the changes you made in this PR, but we may want to make sure that they are made globally, for consistency.
I was not sure about the reference format, normally I just use the casual format: Authors, "Title," Journal/Conference, Date. I saw the missing author names and realized "ins" would do the trick. By no means, I am tied to that format - don't know even know what "ins" stands for here :)
From URL : "as in the author list, ins is an abbreviation for "initials/surname";" I tend to think an editorial pass on references would be better as a separate commit, where they need cleaning. Anything that somehow made it in and breaks the "make" needs fixing, but others maybe later?
I suggest a definition along these lines: Streaming is transmission of a continuous content from a server to a client and its simultaneous consumption by the client. ("simultaneous" is the key here) This has two implications: 1) Server transmission rate (loosely or tightly) matches to client consumption rate. That is, no buffer overrun or underrun is desirable/acceptable. 2) Client consumption rate is also limited by real-time constraints as opposed to just bandwidth availability. That is, client cannot fetch the content not available yet.
+1, this sgtm. But this probably implies a refactor of the intro section and the abstract, to better focus on the relevant use case.
I can take a crack at this.
Ali has text for this, will create a PR for the issue.


Question: storage provider, and give the encryption key to the user as a recovery value. <del> 6.4.1. With MAC-based recovery, the client proves to the server that it holds a secret value established in the initial registration transaction.  The client requests MAC-based recovery by sending a MAC over the new account key, using the recovery key from the initial registration. The string "mac" The URI for the registration to be recovered. A JSON-formatted JWS object using an HMAC algorithm, whose payload is the JWK representation of the public key of the new account key pair. On receiving such a request the server MUST verify that: The base registration has a recovery key associated with it The "alg" value in the "mac" JWS represents a MAC algorithm The "mac" JWS is valid according to the validation rules in RFC7515, using the recovery key as the MAC key The JWK in the payload represents the new account key (i.e. the key used to verify the ACME message) If those conditions are met, and the recovery request is otherwise acceptable to the server, then the recovery process has succeeded. The server creates a new registration resource based on the base registration and the new account key, and returns it on a 201 (Created) response, together with a Location header indicating a URI for the new registration.  If the recovery request is unsuccessful, the server returns an error response, such as 403 (Forbidden). 6.4.2. In the contact-based recovery process, the client requests that the server send a message to one of the contact URIs registered for the account.  That message indicates some action that the server requires the client's user to perform, e.g., clicking a link in an email.  If the user successfully completes the server's required actions, then the server will bind the account to the new account key. </del> <ins> The client requests recovery by asking that the server send a message to one of the contact URIs registered for the account.  That message indicates some action that the server requires the client's user to perform, e.g., clicking a link in an email.  If the user successfully completes the server's required actions, then the server will bind the account to the new account key. </ins> (Note that this process is almost entirely out of band with respect to ACME.  ACME only allows the client to initiate the process, and the server to indicate the result.) <del> To initiate contact-based recovery, the client sends a POST request to the server's recover-registration URI, with a body specifying which registration is to be recovered.  The body of the request MUST be signed by the client's new account key pair. </del> <ins> To initiate recovery, the client sends a POST request to the server's recover-registration URI, with a body specifying which registration is to be recovered.  The body of the request MUST be signed by the client's new account key pair. </ins> The string "contact" The URI for the registration to be recovered. <del> If the server agrees to attempt contact-based recovery, then it creates a new registration resource containing a stub registration object.  The stub registration has the client's new account key and contacts, but no authorizations or certificates associated.  The server returns the stub contact in a 201 (Created) response, along with a Location header field indicating the URI for the new registration resource (which will be the registration URI if the recovery succeeds). </del> <ins> If the server agrees to attempt recovery, then it creates a new registration resource containing a stub registration object.  The stub registration has the client's new account key and contacts, but no authorizations or certificates associated.  The server returns the stub contact in a 201 (Created) response, along with a Location header field indicating the URI for the new registration resource (which will be the registration URI if the recovery succeeds). </ins> After recovery has been initiated, the server follows its chosen recovery process, out-of-band to ACME.  While the recovery process is

As discussed at the F2F meeting at IETF94, MAC-based account recovery is not adding a lot of value, and it adds significant complexity to the spec. (And nobody has implemented it.) This PR removes MAC-based recovery and the crypto that it depends on.
Seeing no complaints on the mailing list, merging.


Question: data, unless priorities specified by the application indicate otherwise (see stream-prioritization). <ins> Even though a sender is encouraged to assemble frames containing up- to-date information every time it sends a packet, it is not forbidden to retransmit frames of lost packets as they are.  A receiver MUST accept packets containing an outdated frame, such as a MAX_DATA frame carrying a smaller maximum data than one found in an older packet. </ins> Upon detecting losses, a sender MUST take appropriate congestion control action.  The details of loss detection and congestion control are described in QUIC-RECOVERY.

In we agreed on this. Considering that the decision affects handling of multiple frames, I think it's worth clarifying the general rule in the draft. For discussions regarding specific frames, please refer: MAXSTREAMS, MAXDATA, MAXSTREAMDATA - RESETSTREAM, STOPSENDING - ACK -
If you want to be explicit, perhaps also mention that stream ranges can be retransmitted with different boundaries or partially, if this isn't already covered by some existing text.
NAME While that's possible, I think we should better handle retransmission rules of specific frames in separate PRs. The reason I suggest this having this catch-all sentence is because to me it seems that the concept is sometimes being lost.
I agree that I'd like to discourage this a bit more than this PR does.
NAME NAME Your comments make sense to me. I'll update the PR.
Moved to 13.2, expanding the text to encourage reassembling frames containing up-to-date information. PTAL.
This is implicitly assumed, and, as NAME points out in , not doing so can cause undesired outcomes. There should be normative text in the transport draft requiring this behavior.
So the situation is that if one so far have ACKed: 1,2,3,6,7. Then if 4,5 shows up at the receiver and it is going to ACK those, it must at least send an ACK that contains 4,5 and 7, thus likely acking 4-7? It should not be allowed to send an ACK saying 4, 5 in the above situation as that doesn't indicate the receiver total progress, i.e. all the way to 7? I think requiring Largest Acknowledge to always indicate highest solves some issues and likely simplifies a lot of implementations. But it may result in larger ACK frames as one will have include the full current state between the largest Acknowledged and so far into the past PNs that you need to go. In severe re-ordering cases that could be a lot. Will this cause cause the ACK to be to large to include? Especially maybe in connections with a large delay bandwidth product going full steam encountering a serious hick up in the network.


Question: data, unless priorities specified by the application indicate otherwise (see stream-prioritization). <ins> Even though a sender is encouraged to assemble frames containing up- to-date information every time it sends a packet, it is not forbidden to retransmit frames of lost packets as they are.  A receiver MUST accept packets containing an outdated frame, such as a MAX_DATA frame carrying a smaller maximum data than one found in an older packet. </ins> Upon detecting losses, a sender MUST take appropriate congestion control action.  The details of loss detection and congestion control are described in QUIC-RECOVERY.

For example if an ACK is required to ack packet 4000 + 1E9 and you have 500 gaps that has arrived the last RTT/4 and really should be included. Resulting in an ACK frame that is at least 1000 bytes large, possibly bigger.
There are a few things this precludes, and we we should understand those before doing this. 1) A very limited implementation(ie: hardware) can't always send only one ACK block without giving up on reordered packets. I don't have such an implementation, but at some point I remember discussing this idea with people who seemed interested in it. 2) One cannot do multipath with QUIC v1 and it means the multipath design will have to use a PN space per path, as described in Christian's draft: URL I think that's likely the right choice for other reasons, but I'm hesitant to make that decision now. 3) An RTT sample can only be taken based on the largest acked. Therefore, if there is a large amount of reordering(ie: 1RTT), you don't get any RTT samples for an RTT. If we care about this, we can probably solve it a different way in the recovery draft, but that likely means using ack delay sometimes and not others. In regards to Martin's comment, I thought we already had text that said ACKs with lower packet numbers than the largest ACK packet number should be ignored, since they're old?
NAME regarding your question. "In regards to Martin's comment, I thought we already had text that said ACKs with lower packet numbers than the largest ACK packet number should be ignored, since they're old?" At least when it comes to ECN, the editors have been working hard to reformulate which has resulted in that there is nothing that applies this from the PN increasing for the ACKs. So to solve the ECN part, I think (re-)introducing that aspect into the text is the simpliest fix for ECN. But there clearly are other aspects here.
NAME The problem doesn't go away if you ignore acks that are lower than largest_acked. The problem is that the receiver sent the acks in the wrong order because packets were received in the wrong order, but ECN counts are going up. But you raise good points. This is a corner case.


Question: data, unless priorities specified by the application indicate otherwise (see stream-prioritization). <ins> Even though a sender is encouraged to assemble frames containing up- to-date information every time it sends a packet, it is not forbidden to retransmit frames of lost packets as they are.  A receiver MUST accept packets containing an outdated frame, such as a MAX_DATA frame carrying a smaller maximum data than one found in an older packet. </ins> Upon detecting losses, a sender MUST take appropriate congestion control action.  The details of loss detection and congestion control are described in QUIC-RECOVERY.

I think that with the current spec, under these conditions, ECN gets turned off since validation fails. I think that's a reasonable outcome, and I'm fine with it. NAME
ECN Validation as I currently understand it will not fail if the sender to receiver reordering happens as long as the ACKs from the receiver to sender are not reordered. So to my understanding what is missing is a requirement for the sender to no process verfication for out of order ACKs. It will not fail if the largest acknowledge is not increasing as the comparison is done on number of newly ACKed packets versus counts change. The current sentence in Section 13.3.2 (-17): "Counts MUST NOT be verified if the ACK frame does not increase the largest received packet number at the endpoint." Which I interpret to mean that what PN the ACK reference (sender-receiver direction), rather than the PN of the receiver to sender direction. Can NAME or NAME fix that?
I think is enough to address the original problem, so I'd like to close this issue. I think and are enough. NAME sound ok?
Yes, the ECN related issue is resolved. What I don't know if it is resolved fully is the implementation requirements is that a sender MUST be capable of handling an ACK frame with Largest Acknowledged that is smaller than highest received? From my perspective there are good and valid arguments why this may be required, however I think consensus needs to be established on that.
NAME I am not sure if I'm following the context, but my understanding is that a sender MUST be capable of that, because we allow an endpoint to simply retransmit the payload of a packet that is being deemed lost; see .
Just a stray thought: is this requirement really strictly needed? It would complicate trasnmitters that split work into multiple processing units which might not be fully synced on the latest ACK'ed.
NAME what NAME says. Also, a sender needs to be able to simply deal with reordering on the ack path. Did you mean something else?
My concern was primarily about the clearness of this behavior in the specification text. In transport I find the following which indicates this but are not explicit. : To limit receiver state or the size of ACK frames, a receiver MAY limit the number of ACK Ranges it sends.


Question: data, unless priorities specified by the application indicate otherwise (see stream-prioritization). <ins> Even though a sender is encouraged to assemble frames containing up- to-date information every time it sends a packet, it is not forbidden to retransmit frames of lost packets as they are.  A receiver MUST accept packets containing an outdated frame, such as a MAX_DATA frame carrying a smaller maximum data than one found in an older packet. </ins> Upon detecting losses, a sender MUST take appropriate congestion control action.  The details of loss detection and congestion control are described in QUIC-RECOVERY.

: Largest Acknowledged: A variable-length integer representing the largest packet number the peer is acknowledging; this is usually the largest packet number that the peer has received prior to generating the ACK frame. I think there are strong hints, with the above "usually the largest" indicating that it is not always. I would have made this explicit in 19.3, but then I prefer being more explicit than not. I think it is possible interop issue point. Anywhere else this is more explicit? (I have read github master version) NAME I think there are strong points for allowing an ACK frame to acknowledge only a part of the range between highest received and confirmed to be have been ACKed. The two main reasons I see. high rate flows suffering an packet loss burst so that the number of ACK ranges becomes to large to fit a single QUIC packet. Low complexity receivers ACKing a single range of received packets and doing this for reordered packets.
NAME As suggested by NAME in , might be the correct place. I am advocating for describing the design principle the PR, but we might (or might not) be interested in expanding how ACK could look like.
So results in certain implications, that an ACK could arrive that addresses older state, thus resulting in acknowledging some PNs that was previously unacknowledged. As 13.2 is about retransmissions, I think there are other desing principle aspects of ACKs that probably should be covered, but then earlier in 13.1.
We're in the process of making our implementation accept smaller largest_acked values, so I'm wonder if we're any closer to consensus(one way or the other) on this issue?
I think this is mostly addressed and what's left is OBE. There's text in the draft now that says: "Processing counts out of order can result in verification failure. An endpoint SHOULD NOT perform this verification if the ACK frame is received in a packet with packet number lower than a previously received ACK frame. Verifying based on ACK frames that arrive out of order can result in disabling ECN unnecessarily." This would be adequate, but there's other text (thanks to ) that says old ACKs can be resent. I think we simply add a note about that in the para above, which should be adequate.
Discussed in London: NAME to prepare a PR for those remaining bits
NAME any progress here?


Question: data, unless priorities specified by the application indicate otherwise (see stream-prioritization). <ins> Even though a sender is encouraged to assemble frames containing up- to-date information every time it sends a packet, it is not forbidden to retransmit frames of lost packets as they are.  A receiver MUST accept packets containing an outdated frame, such as a MAX_DATA frame carrying a smaller maximum data than one found in an older packet. </ins> Upon detecting losses, a sender MUST take appropriate congestion control action.  The details of loss detection and congestion control are described in QUIC-RECOVERY.

I think the conclusion here is close with no further action, but it'd be good for NAME to confirm.
I've added , which I believe addresses what's left of this issue.
Note that we agreed that proposal-ready would be used when there were approvals for PRs (or at least apparent agreement, as determined by editors).
NAME : Yeah, my bad.
This gets fixed by , so marking this issue as well.
Fixed by .


Question: watch for increasing numbers of end users uploading significant amounts of content. <ins> 2.6. The causes of unpredictable usage described in sec-unpredictable were more or less the result of human choices, but we were reminded during a post-IETF 107 meeting that humans are not always in control, and forces of nature can cause enormous fluctuations in traffic patterns. In his talk, Sanjay Mishra Mishra reported that after the CoViD-19 pandemic broke out in early 2020, Comcast's streaming and web video consumption rose by 38%, with their reported peak traffic up 32% overall between March 1 to March 30 Comcast, AT&T reported a 28% jump in core network traffic (single day in April, as compared to pre stay-at-home daily average traffic), with video accounting for nearly half of all mobile network traffic, while social networking and web browsing remained the highest percentage (almost a quarter each) of overall mobility traffic ATT, and Verizon reported similar trends with video traffic up 36% over an average day (pre COVID-19) Verizon. We note that other operators saw similar spikes during this time period.  Craig Labowitz Labovitz reported Weekday peak traffic increases over 45%-50% from pre-lockdown levels, A 30% increase in upstream traffic over their pre-pandemic levels, and A steady increase in the overall volume of DDoS traffic, with amounts exceeding the pre-pandemic levels by 40%. (He attributed this increase to the significant rise in gaming-related DDoS attacks (LabovitzDDoS), as gaming usage also increased.) </ins> 3. 3.1.

This is based on the post-IETF 107 MOPS meeting where we talked about this. I chased some more references.
We should try to improve this reference - it's a long page, additions are at the top, so we have to either scroll for a long time or search for the date to get the relevant part of the page. Maybe reach out to ATT to get fragment tags that work?


Question: See iana-error-codes for details of registering new error codes. <ins> In defining these error codes, several principles are applied.  Error conditions that might require specific action on the part of a recipient are given unique codes.  Errors that represent common conditions are given specific codes.  Absent either of these conditions, error codes are used to identify a general function of the stack, like flow control or transport parameter handling. Finally, generic errors are provided for conditions where implementations are unable or unwilling to use more specific codes. </ins> 20.1. Application protocol error codes are 62-bit unsigned integers, but

This just writes down what was proposed in .
Looks fine, but what about some guidance on stream vs connection errors? And also the principle of nearly always choosing a hard protocol violation error, or a more granular error with same effect?
Stream vs. connection is something that application protocols (like HTTP) need to worry about. The transport only concerns itself with connection errors. The idea that you pick the most helpful error is not something that we need to codify (in my view).
Isn't that worth mentioning? Or do we already have such text?
This is already discussed in Section 11, which makes me wonder if it would make more sense for text on this PR to be placed there too.
This I do not disagree with. I was merely suggesting that we explain why, as a general rule, a hard error is preferred as a design principle, not the nature of the error message which I do think should have a large degree of freedom.
Maybe there is a followup needed for the HTTP draft. If the principles are generally the same, we can copy the text and then add some more to cover the idea that we make most errors fatal to the connection rather than the stream.
I like Lucas suggestion of adding this text to the existing and already fairly complete text in section 11.
I moved the second paragraph up to the error handling section, but the text about how codes are selected really belongs with the codes themselves.
We don't really have any real principles that we agree on for deciding what error codes we are describing. Proposal: if the error carries distinct semantics (like stream rejection in HTTP), then it gets a new error code if the error is frequent or particularly significant, then it gets a new error code otherwise, target a more generic error code that identifies the broad area of the protocol finally, if there is no more specific applicable error code, use PROTOCOL_VIOLATION
is example of an issue discussed where it would have been useful to have principles.


Question: Context (optional).  This parameter sets the Default Base URI under which the request's links are to be interpreted.  The <del> specified URI MUST NOT have a path component of its own, but MUST be suitable as a base URI to resolve any relative </del> <ins> specified URI typically does not have a path component of its own, and MUST be suitable as a base URI to resolve any relative </ins> references given in the registration.  The parameter is <del> therefore of the shape "scheme://authority" for HTTP and CoAP URIs.  In the absence of this parameter the scheme of the protocol, source address and source port of the registration request are assumed.  This parameter is mandatory when the directory is filled by a third party such as an commissioning tool.  If the endpoint uses an ephemeral port to register with, it MUST include the con parameter in the registration to provide a valid network path.  If the endpoint which is located behind a NAT gateway is registering with a Resource Directory which is on the network service side of the NAT gateway, the endpoint MUST use a persistent port for the outgoing registration in order to provide the NAT gateway with a valid network address for replies and incoming requests. </del> <ins> therefore usually of the shape "scheme://authority" for HTTP and CoAP URIs.  In the absence of this parameter the scheme of the protocol, source address and source port of the registration request are assumed.  This parameter is mandatory when the directory is filled by a third party such as an commissioning tool.  If the endpoint uses an ephemeral port to register with, it MUST include the con parameter in the registration to provide a valid network path.  If the endpoint which is located behind a NAT gateway is registering with a Resource Directory which is on the network service side of the NAT gateway, the endpoint MUST use a persistent port for the outgoing registration in order to provide the NAT gateway with a valid network address for replies and incoming requests. Endpoints that register with a con that contains a path component need to carefully consider the rules of relative URI resolution.  Typically, links submitted by such an endpoint are of the "path-noscheme" form. </ins> Additional registration attributes (optional).  The endpoint can pass any parameter registered at iana-registry to the

This allows for gateway devices that register their mapped legacy devices individually. Closes: URL The delta is smaller than I expected because at some places, paths were already allowed (eg. in the IANA table for "con"). One place where I'm unsure if we should change it because I don't know what it actually means is the "scheme, IP, port" annotation in fig-hierarchy -- what does it mean there?
what is a path no scheme form? An example might help here.
path-noscheme form is one of the possible ABNF forms for a relative reference from ; it basically means "relative references that does not even start with a slash". I'm conflicted about having an example in the draft (our examples already feel like a test suite), but I'll give one here and we can still consider moving it in: ~
Merging this with a clarification for the ABNF item, so we have a single version to talk about later today.
I'm aware this is a discussion we've already had, but back then we dropped it for its complexity and because we had no use cases. Matthias has brought up use cases for allowing a path in the con as part of the -13 reviews. He argues that a gateway bridging into a non-CoAP world would want to register its proxees (is that a word?) individually, and if it doesn't use name-based virtual hosting (which is kind of rare in CoAP and needs wildcard DNS records), could go for path-based hosting. As I see it, this would be a trivial addition from the RD point of view ("just allow it"). The onus is on the endpoint / gateway to do it right, ie. to never use path-absolute URI references unless they mean it. What does make this a bit more complicated is that none of the content formats we currently describe allows using that meaningfully -- but we are not limiting the RD to those content formats, and they may (and hopefully will) still change while we're finishing RD. On the editing track, I would keep those cases out of the examples (I'm game for building a test suite, but the examples shouldn't be that). Then, the editing becomes a matter of replacing "specified URI MUST NOT have a path component" with "typically does not have a path component", adding the one or the other "typically", and being done with it.


Question: Context (optional).  This parameter sets the Default Base URI under which the request's links are to be interpreted.  The <del> specified URI MUST NOT have a path component of its own, but MUST be suitable as a base URI to resolve any relative </del> <ins> specified URI typically does not have a path component of its own, and MUST be suitable as a base URI to resolve any relative </ins> references given in the registration.  The parameter is <del> therefore of the shape "scheme://authority" for HTTP and CoAP URIs.  In the absence of this parameter the scheme of the protocol, source address and source port of the registration request are assumed.  This parameter is mandatory when the directory is filled by a third party such as an commissioning tool.  If the endpoint uses an ephemeral port to register with, it MUST include the con parameter in the registration to provide a valid network path.  If the endpoint which is located behind a NAT gateway is registering with a Resource Directory which is on the network service side of the NAT gateway, the endpoint MUST use a persistent port for the outgoing registration in order to provide the NAT gateway with a valid network address for replies and incoming requests. </del> <ins> therefore usually of the shape "scheme://authority" for HTTP and CoAP URIs.  In the absence of this parameter the scheme of the protocol, source address and source port of the registration request are assumed.  This parameter is mandatory when the directory is filled by a third party such as an commissioning tool.  If the endpoint uses an ephemeral port to register with, it MUST include the con parameter in the registration to provide a valid network path.  If the endpoint which is located behind a NAT gateway is registering with a Resource Directory which is on the network service side of the NAT gateway, the endpoint MUST use a persistent port for the outgoing registration in order to provide the NAT gateway with a valid network address for replies and incoming requests. Endpoints that register with a con that contains a path component need to carefully consider the rules of relative URI resolution.  Typically, links submitted by such an endpoint are of the "path-noscheme" form. </ins> Additional registration attributes (optional).  The endpoint can pass any parameter registered at iana-registry to the

(This would also make URL obsolete, as those components would be allowed). NAME (and possibly NAME I'd assume you won't be too happy with (based on previous discussions of that topic), but do you see Matthias' point, or could point out concrete issues you see from allowing this?
I would prefer that not be made obsolete on this. You should be able to have a URI w/ a path and a relative URI which are then combined. If we need to combine things like query parameters then it is going to get really messy really fast because there are not good rules about that. I don't have any problems w/ allowing for the con to have a path and resolving with it. I just think that we need to establish what the rules are in the RD document rather than using the horrible link format rules.
There are very good rules about that query parts and fragments in the Base URI: Anything that is not an empty string or starts with a "#" removes the fragment identifier and the query parameters. The Base URI's fragment identifier is never kept. (Derived from RFC3986 Section 5.2). I'll try to write text on this issue on the weekend (NAME a "no we can't have that because" would be more appreciated today than later), let's talk about again when we have that. Dear list RD allows the "con" parameter to provide a base URI for relative resource URIs, when the registration is done from a different source address then the registered endpoint itself. "con" is restricted to the scheme and authority part of a URI, that is, no path segments are allowed. This came from the assumption that all CoRE devices will naturally correlate with socket-address endpoints. However, a registered device(=endpoint, "ep") might not be a natural endpoint. When using gateways or device proxies, the base URI will have path segments and multiple logically different endpoints will share the same socket-address (e.g., URL, URL, URL). This makes it expensive to move such logical endpoints, as updating "con" will not help. All links have to be removed, changed to the new prefix, and registered anew. This is a problem for some applications (including a bigger alliance using CoAP), in particular because the patch mechanism is still to be defined - yet rewriting URI prefixes still will not be really efficient even when having patch registration updates.


Question: Context (optional).  This parameter sets the Default Base URI under which the request's links are to be interpreted.  The <del> specified URI MUST NOT have a path component of its own, but MUST be suitable as a base URI to resolve any relative </del> <ins> specified URI typically does not have a path component of its own, and MUST be suitable as a base URI to resolve any relative </ins> references given in the registration.  The parameter is <del> therefore of the shape "scheme://authority" for HTTP and CoAP URIs.  In the absence of this parameter the scheme of the protocol, source address and source port of the registration request are assumed.  This parameter is mandatory when the directory is filled by a third party such as an commissioning tool.  If the endpoint uses an ephemeral port to register with, it MUST include the con parameter in the registration to provide a valid network path.  If the endpoint which is located behind a NAT gateway is registering with a Resource Directory which is on the network service side of the NAT gateway, the endpoint MUST use a persistent port for the outgoing registration in order to provide the NAT gateway with a valid network address for replies and incoming requests. </del> <ins> therefore usually of the shape "scheme://authority" for HTTP and CoAP URIs.  In the absence of this parameter the scheme of the protocol, source address and source port of the registration request are assumed.  This parameter is mandatory when the directory is filled by a third party such as an commissioning tool.  If the endpoint uses an ephemeral port to register with, it MUST include the con parameter in the registration to provide a valid network path.  If the endpoint which is located behind a NAT gateway is registering with a Resource Directory which is on the network service side of the NAT gateway, the endpoint MUST use a persistent port for the outgoing registration in order to provide the NAT gateway with a valid network address for replies and incoming requests. Endpoints that register with a con that contains a path component need to carefully consider the rules of relative URI resolution.  Typically, links submitted by such an endpoint are of the "path-noscheme" form. </ins> Additional registration attributes (optional).  The endpoint can pass any parameter registered at iana-registry to the

I thus propose to generalize "con" to be any base URI that will be applied to all relative links an endpoint registered. If there is a conflict with a deployed mechanism, we could look into adopting "anchor" and let RD use it similarly to "con", but allowing full base URIs (including paths). Or we align with RFC 8288 altogether and replace "con" with "anchor": URL Ciao, Matthias


Question: in RFC5888.  addTrack attempts to minimize the number of transceivers as follows: if the PeerConnection is in the "have-remote-offer" state, the track will be attached to the first compatible transceiver <del> that was created by the most recent call to setRemoteDescription() and does not have a local track.  Otherwise, a new transceiver will be created, as described in sec.addTransceiver. </del> <ins> that was created by the most recent call to setRemoteDescription and does not have a local track.  Otherwise, a new transceiver will be created, as described in sec.addTransceiver. </ins> 4.1.3.

Various fixes for 60.2: Removed parens from API names, removed comment. - put the term stable in quotes, removed comment. - put the term sess-id in angle brackets to match SDP spec, removed comment. - made the tls-id attribute consistent with other SDP attributes, removed comment. - removed quotes from IceRestart option, removed comment.

"IceRestart" option / IceRestart option Justin: LGTM
tls-id value / "a=tls-id" value Justin: The source RFC seems to prefer "tls-id" when discussing values.
During the editing of the Cluster 238 docs, it was decided that it's author's choice when formatting SDP attributes. Although RFC 8842 uses the format '"tls-id" attribute', this document more consistently uses "a=attribute-name" format for SDP attributes, which is the format that the SDP spec [RFC8866] uses. I'll update this document to consistently use "a=tls-id"
sess-id / (Section 5.2.1, second bullet item) Justin: LGTM
the stable state (1 instance) / the "stable" state (3 instances) >(Also, should 'the previous stable state' be 'a previous stable state' (per Section 5.7) or 'the previous "stable" state'?) Justin: The quoted form is preferred, including the case of "previous stable state".
[Breaking up issue /60 into smaller bites] The following terms appear to be used inconsistently in this document. Please let us know which form is preferred. Justin: There seems to be a pretty clear preponderance for the non-parenthetical form, so let's keep that. W3C also does not use (). Jean: We'll remove the parens (camelCase is sufficient formatting).


Question: operations, and "core.rd-group" is used to discover the URI path for RD Group operations.  Upon success, the response will contain a payload with a link format entry for each RD function discovered, <del> indicating the URI path of the RD function returned and the corresponding Resource Type.  When performing multicast discovery, the multicast IP address used will depend on the scope required and the multicast capabilities of the network. </del> <ins> indicating the URI of the RD function returned and the corresponding Resource Type.  When performing multicast discovery, the multicast IP address used will depend on the scope required and the multicast capabilities of the network. </ins> A Resource Directory MAY provide hints about the content-formats it supports in the links it exposes or registers, using the "ct" link

This contains what I think of the easy fixes to the requirements of replicated RDs. See URL for more discussion, please comment on whether you think those changes are acceptable.
The minimum for interoperability IMO is that client's don't always pick the first choice -- because if they do, no fault tolerance is possible. Do you think that that even this is too much specification of behavior, or did I write more in the PR than what would be needed to satisfy that minimum requirement?
chrysn schreef op 2018-02-01 17:03: Is that so? The first choice of one client is not necessarily the first choice of another when we are confronted with RDs which have contact problems. Several protocols have handled this problem: like dhcp for example. Why not copy that behavior?
I think we're talking about different "first"s here. I'm not concerned with what happens when multiple servers answer the multicast CoAP request. (Led to an interesting chat with PIM people but is not a matter that should concern the RD). What I do think we should give guidance is what happens if the RDAO announces multiple addresses (something explicitly allowed in the current draft), or the URI discovery response contains more than one rt="URL" link Both are within what I think we describe as acceptable server behavior. If clients are unaware and just always pick the first line (because it looks like a zero-or-one situation to the implementers), interoperability issues will arise when two are announced an the first one fails.
Ok, got it, see below chrysn schreef op 2018-02-02 12:11: Yeah, that's a nuisance. Someone seems to know what they want that for, annd probably have some intelligent algorithm to break ties.......... One might say that client MAY choose their RD randomly. I assume that is a multicast response? Then the first response is probably the closest and the best choice. And when one MC response contains multiple RD links, We are not responsible, and something clever is being thought out somewhere, we hope. I think DHCP specifies clients to wait so many seconds before choosing a server. When the first one fails, the client will try the second one, und so weiter ... What am I missing still?
for interoperability, the client behavior when multiple URIs are discovered, or the RD does not answer, need not be specified. The text starts to look more and more like Bonjour


Question: Universal Time, or might be defined relative to some other timestamp or timeticks counter. <del> We now walk through a number of hypothetical examples of how a solution might be built.  This list is not intended to be complete, but is just representative enough to highlight various timing considerations. </del> <ins> Using the table above, a number of hypothetical examples of how a solution might be built are illustrated below.  a solution might be built.  This list is not intended to be complete, but is just representative enough to highlight various timing considerations. </ins> 15.1.

only the most essential items: added three more timestamp types based on TUDA, trying to generalize it a bit added a few periods to text that seems to express sentences


Question: Finally QUIC-VN provides two mechanisms for endpoints to negotiate the QUIC version to use.  The "incompatible" version negotiation <del> method can support switching from any initial QUIC version to any other version with full generality, at the cost of an additional round-trip at the start of the connection.  "Compatible" version negotiation eliminates the round-trip penalty but levies some restrictions on how much the two versions can differ semantically. </del> <ins> method can support switching from any QUIC version to any other version with full generality, at the cost of an additional round-trip at the start of the connection.  "Compatible" version negotiation eliminates the round-trip penalty but levies some restrictions on how much the two versions can differ semantically. </ins> QUIC version 2 is meant to mitigate ossification concerns and exercise the version negotiation mechanisms.  The only change is a

The correct term from the VN document would be "original version" but just removing the word initial avoids the confusion
Fewer words means fewer nits


Question: 10.8.6. This design permits servers operating in Split Mode to forward <del> connections directly to backend origin servers, thereby avoiding unnecessary MiTM attacks. </del> <ins> connections directly to backend origin servers.  The client authenticates the identity of the backend origin server, thereby avoiding unnecessary MiTM attacks. </ins> <del> 10.8.7. Assuming ECH records retrieved from DNS are authenticated, e.g., via DNSSEC or fetched from a trusted Recursive Resolver, spoofing a server operating in Split Mode is not possible.  See plaintext-dns for more details regarding plaintext DNS. </del> <ins> Conversely, assuming ECH records retrieved from DNS are authenticated, e.g., via DNSSEC or fetched from a trusted Recursive Resolver, spoofing a client-facing server operating in Split Mode is not possible.  See plaintext-dns for more details regarding plaintext DNS. </ins> Authenticating the ECHConfigs structure naturally authenticates the included public name.  This also authenticates any retry signals from <del> the server because the client validates the server certificate against the public name before retrying. </del> <ins> the client-facing server because the client validates the server certificate against the public name before retrying. </ins> <del> 10.8.8. </del> <ins> 10.8.7. </ins> This design has no impact on application layer protocol negotiation. It may affect connection routing, server certificate selection, and client certificate verification.  Thus, it is compatible with <del> multiple protocols. </del> <ins> multiple application and transport protocols.  By encrypting the entire ClientHello, this design additionally supports encrypting the ALPN extension. </ins> 10.9.

We use a mix of sentence case and title case in the document. The RFC style guide says to use title case. This PR aligns with that. URL Additionally, the ESNI criteria document has changed slightly since the comparison against criteria section was written. I've aligned the titles with the final wording in RFC8744. RFC8744 has also merged "Proper security context" and "Split server spoofing", so I've done the same here. "Support Multiple Protocols" also now talks about transport protocols and ALPN, so I've added a few words about that.


Question: Group will rely upon.  features contains a more thorough discussion on the different features that can be used. <del> Once a document is published in a repository on GitHub, many features like pull requests, issue tracking or the wiki can be individually disabled.  If specific features are not used by the Working Group in the development of the document, disabling those features avoids creating confusion in the wider community about what can be used. </del> 3.2. Working Group Chairs that decide to use GitHub MUST inform their

Two changes, two issues, but really this is the one idea. The previous draft said that features not used could be disabled. This is bad advice because that might be denying editors access to tools that would make their task easier. The new advice says that editors can use features that the working group doesn't rely on. It also says that chairs should consult editors to ensure that policies aren't adversely affecting them.
Most of the operating modes assume that editors are given considerable latitude in how repositories are managed. This is good up until the point that the Working Group starts to formally rely on things that are in the respository. The document sort of prevaricates about this point, including strong admonitions that suggest rules be formalized for every aspect of usage. Instead, I think that it would be better if the document said - up-front - that editors are to be given control unless the Working Group starts to formally depend on a particular function (like issue opening/closing, labels, pull requests, whatever...). At that point, it is the chair's responsibility to identify what the WG depends on and to clearly articulate the policies around that usage.
Section 3.1 talks about turning off GitHub features not being used by the WG, but it doesn't say how to do that in the UI. I ask this because I cannot see a way to prevent issues or PRs just by wandering through the GUI.
This isn't something that I'd want to publish. The way that features are configured is too tightly coupled to UX decisions that GitHub might remake and any point. In fact, I might prefer not to include the offending text at all. Disabling features can be a useful way to slim down the options presented to users (which can help new users), but it can also be fairly hostile to new contributors. For instance, if the working group disables issues because they aren't using them, it sounds reasonable, but new contributors might then be dissuaded from opening a genuine issue. Working groups might be better served by informally letting contributors know how to best provide their input.
I'm happy with either the current text plus "At the time this is written, to turn of y" or removing the suggestion.


Question: elliptic curve equation.  For these curves, implementers do not need to verify membership in the correct subgroup. <del> Encryption keys are derived from shared secrets by taking the first 16 bytes of H(Z), where Z is the shared secret and H is SHA-256. </del> 5.6. A member of a group authenticates the identities of other

Initial attempt to solve . This defines the KDF as discussed in and relocates the DH computation obligation and verification as part of the Derive-Key-Pair function definition.
Fixing my own review comments here, since NAME appears to be offline and we need to publish -04.
The PR from NAME introducing a KDF was merged before I had a chance to review it. There are a number of problems with it: Instead of calling for an abstract KDF, it should define one, as we have with the use of HKDF elsewhere We can't just say , since KDFs produce octet strings, not private keys. We need , not just . This doesn't match what I recall discussing on the list. I think what you want is actually as follows: Or in prose:
That was exactly the question I was asking on the list, i.e., if we need an explicit "derive-keypair" function. The idea with deriving the private key directly was to avoid a redundant derive-key operation. I'm totally fine re-doing the PR to represent either approach.
Merging that PR too quickly is on me. For the parent derivation, we can just use what the formal model for TreeKEM does, which is roughly the Richard points out. The part I don't like about this, is to define in the MLS specification as it depends on the HPKE internal algorithm. The TreeKEM formal specification, it is done the following way (because we know that the HPKE interface we use can take random bytes as a secret key): In the MLS specification, I suggest we avoid defining anything new but point to the HPKE spec instead. As it provides the KEM scheme, it should also provide ways to derive the from an octet string and the function that transform an to a . I suggest we define, in the HPKE document, something like that we already need anyway and eventually that maps the random bytes to an . For X25519 we don't even need the second function but generically we probably need it. That would lead to define the following in the MLS spec: NAME ?
I don't think we can delegate this to HPKE. HPKE doesn't have a need for anything like Derive-Key-Pair. We do, so it's on us to define it.


Question: elliptic curve equation.  For these curves, implementers do not need to verify membership in the correct subgroup. <del> Encryption keys are derived from shared secrets by taking the first 16 bytes of H(Z), where Z is the shared secret and H is SHA-256. </del> 5.6. A member of a group authenticates the identities of other

The point NAME raises about avoiding unnecessary operations is relevant here: If we're forking the hashes like this, then we can remove the hashing part from Derive-Key-Pair, so that it's really just a definition of how you convert from an octet string to a private key (and thus its public key).
I disagree, it is not for MLS to define the and functions for all asymmetric schemes possibly used in HPKE. In MLS we should have to do only what TreeKEM does, aka, 2 KDFs, one outputing the parent's secret, one outputing the KEM encryption key, and that's it. I am willing to accept defining here but this is already odd.
If it's not our job, whose is it? It's not HPKE's job, because they don't have a need to convert byte strings to private keys. Some document needs to define this conversion in order for MLS to be implementable.
I agree we are in trouble here :) But I still wish that if we can avoid it, we should.
I agree that the KEM schemes themselves should define these things, like Curve25519 does. But it's like two lines of text. I'm not too bothered with it.
I think I'm a bit lost here. How do we go forward? Regarding the use of an abstract KDF: I was mostly just adapting the existing text, which used an abstract hash function if I recall correctly. I didn't touch the texts that got more concrete because they seemed to be a little outdated anyway. That shouldn't be a problem though.
NAME Ok, looking at this now, I am not sure what we decided in the end. I would be ok to define as you said but as it is KEM specific so there is no good solution for P256 or for whatever PQ KEM that would have a specific way of generating keys from pseudo random bytes...
NAME any suggestion here
Fixed by


Question: 2.3. <ins> Both the client and the server MUST send a Capability and Settings message (CSM see csm) as its first message on the connection.  This message establishes the initial settings and capabilities for the endpoint such as maximum message size or support for block-wise transfers.  The absence of options in the CSM indicates that base values are assumed. Clients and servers MUST treat a missing or invalid CSM as a connection error and abort the connection (see sec-abort). 2.4. </ins> The CoAP message format defined in RFC7252, as shown in CoAP-Header, relies on the datagram transport (UDP, or DTLS over UDP) for keeping the individual messages separate and for providing length

This text does not address who might be allowed to wait for the other guy to make their statement (if both wait, there is a deadlock).
The intention is that neither side needs to wait. The only open issue is whether we want to allow the client to immediately start sending messages after it sends its CSM without waiting for the server CSM similar to the HTTP/2 case. I planned to discuss that on-list when I "advertised" this set of pull requests.
From your message I understand that in HTTP/2 the client can send messages immediately without waiting for the server to respond either. To me it feels like we should be doing what has been done in the HTTP/2 case even though there is a risk that some problems occur when the client sends data in way that the server will subsequently not handle well. If that is the case, the client will have to re-send the data, I guess. For the currently defined options I don't see problems.
When I submitted the original pull request, I also posed a question on the but did not receive a response. One open question is whether we want to allow a client to immediately send messages after sending its CSM without waiting for the server CSM. This would be similar to HTTP/2: URL To avoid unnecessary latency, clients are permitted to send additional messages to the server immediately after sending the client connection preface, without waiting to receive the server connection preface. It is important to note, however, that the server connection preface SETTINGS frame might include parameters that necessarily alter how a client is expected to communicate with the server. Upon receiving the SETTINGS frame, the client is expected to honor any parameters established. In some configurations, it is possible for the server to transmit SETTINGS before the client sends additional frames, providing an opportunity to avoid this issue.
I support not blocking the device until the server CSM. The server can choose to not process messages that are invalid (e.g. too large) and immediately follow up with the server CSM. From the perspective of a cloud and gateway software provider, the CoAP (using TCP/TLS) server will usually be in the cloud or gateway and therefore usually not power constrained. I may be missing other scenarios where a battery powered device is acting as a CoAP/TCP server. Does anyone have plans for any of those scenarios?


Question: 2.3. <ins> Both the client and the server MUST send a Capability and Settings message (CSM see csm) as its first message on the connection.  This message establishes the initial settings and capabilities for the endpoint such as maximum message size or support for block-wise transfers.  The absence of options in the CSM indicates that base values are assumed. Clients and servers MUST treat a missing or invalid CSM as a connection error and abort the connection (see sec-abort). 2.4. </ins> The CoAP message format defined in RFC7252, as shown in CoAP-Header, relies on the datagram transport (UDP, or DTLS over UDP) for keeping the individual messages separate and for providing length

NAME added a related comment to (which is closed) From your message I understand that in HTTP/2 the client can send messages immediately without waiting for the server to respond either. To me it feels like we should be doing what has been done in the HTTP/2 case even though there is a risk that some problems occur when the client sends data in way that the server will subsequently not handle well. If that is the case, the client will have to re-send the data, I guess. For the currently defined options I don't see problems.
Michel Veillette points out that a peer that wants to use a new connection has an uncertainty whether a CSM message with capability indications will come or not, so it is hard to decide when to send the first request (either based on default capabilities or waiting for the CSM to come in). One way out of having to do arbitrary waits would be to require the exchange of a CSM message (even an option-less one) after connection setup. The burden is very low, as a minimal implementation would just need to send a constant message of 0x00 0xe1 at setup. This requirement could be stated without giving a sequence, effectively allowing both sides to send the initial CSM in parallel, or it could give the listener the opportunity to not send its CSM until the connection opener has sent theirs, trying to avoid the need to answer right away to a connection setup -- this makes it too easy to scan for ports (OK, we also have a default port, and making scanning harder does not by itself provide any security, but it sure makes life a little harder for the attacker). (To avoid deadlock, the connection opener would not have the opportunity to wait sending the CSM.)
+1 ... especially for Maximum-Message-Size. HTTP/2 has a similar flow for SETTINGS during connection including potentially empty settings: URL URL
No objections. I will create a pull request for review by the WG.


Question: Clients SHOULD NOT respond to challenges until they believe that the server's queries will succeed.  If a server's initial validation <del> query fails, the server SHOULD retry the query after some time. While the server is still trying, the status of the challenge remains "pending"; it is only marked "invalid" once the server has given up. </del> <ins> query fails, the server SHOULD retry the query after some time, in order to account for delay in setting up responses such as DNS records or HTTP resources.  The precise retry schedule is up to the server, but server operators should keep in mind the operational scenarios that the schedule is trying to accommodate.  Given that retries are intended to address things like propagation delays in HTTP or DNS provisioning, there should not usually be any reason to retry more often than every 5 or 10 seconds.  While the server is still trying, the status of the challenge remains "pending"; it is only marked "invalid" once the server has given up. </ins> The server MUST provide information about its retry state to the client via the "errors" field in the challenge and the Retry-After

Addresses Martin Stiemerling's TSV-ART review
Merging based on NAME review
On the mailing list, Rifaat Shekh-Yusuf pointed out these issues: Section 7.3.5, first paragraph, second line: A "bind" word is missing between the words "to" and "an" Section 7.4.1, second paragraph, second sentence: "case" should be "cases". When the server builds the authorization object, the document is stating that the response would include "challenges" and "combinations". Remove the "combinations" as it is not being used. Section 7.5.1, the Request URIs in the examples: Should not this be /acme/authz/1234/0?
In "Responding to challenges," we use the term "response fields." These fields are defined by each challenge type, but are not described as "response fields" there. We should add a heading describing them as such in the challenge type definitions.
The other challenges don't expect you to post a payload containing a type field, so it's inconsistent for OOB-01 to do so. It should just take an empty object "{}" as its payload.
This seems fine. It seems to be protected from replay by the and parameters. I think we're OK leaving the challenge name at "oob-01", since this isn't a breaking change.


Question: Any received 0-RTT data that the server responds to might be due to a replay attack. <del> Therefore, the server's use of 1-RTT keys MUST be limited to sending data before the handshake is complete.  A server MUST NOT process </del> <ins> Therefore, the server's use of 1-RTT keys before the handshake is complete is limited to sending data.  A server MUST NOT process </ins> incoming 1-RTT protected packets before the TLS handshake is complete.  Because sending acknowledgments indicates that all frames in a packet have been processed, a server cannot send acknowledgments

This was never explicit for the client as it is usually not possible. in a way that perhaps was not anticipated.
is complete. Consequently, a server might expect 0-RTT packets to start with a However, this is not necessarily strictly true, because you might have the ACKs in 0.5RTT. Now you might say that the TLS stack reports the handshake as complete as soon as it receives Finished but that's an implementation detail
I think that this is true. The server can send before then, but we require that the client not install 1-RTT keys until it considers the handshake complete.
That's not entirely true. It's the server that needs to hold back keys (namely, the 1-RTT read key) until the handshake completes. The client can use keys as soon as they become available.
I think NAME is correct in sense that the following three events happen at the same moment on the client side: handshake is declared complete TLS stack provides the 1-RTT read and write keys TLS stack provides ClientFinished
Martin is correct. There are two different forms of handshake completion: complete when 1rtt can be sent and received, confirmed when the peer is known to be complete. The client cannot receive 0rtt acks before installing 1rtt keys, hence before hanshake is complete.
a nit, but LGTM


Question: "offer" indicates that a description should be parsed as an offer; said description may include many possible media configurations.  A description used as an "offer" may be applied any time the <del> PeerConnection is in a stable state or applied as an update to a </del> <ins> PeerConnection is in a "stable" state or applied as an update to a </ins> previously supplied but unanswered "offer". "pranswer" indicates that a description should be parsed as an


Question: 10. The security considerations of HTTP/3 should be comparable to those <del> of HTTP/2 with TLS.  Note that where HTTP/2 employs PADDING frames and Padding fields in other frames to make a connection more resistant to traffic analysis, HTTP/3 can either rely on transport- layer padding or employ the reserved frame and stream types discussed in frame-grease and stream-grease. </del> <ins> of HTTP/2 with TLS; the considerations from Section 10 of HTTP2 apply in addition to those listed here. </ins> When HTTP Alternative Services is used for discovery for HTTP/3 endpoints, the security considerations of ALTSVC also apply. <ins> 10.1. Where HTTP/2 employs PADDING frames and Padding fields in other frames to make a connection more resistant to traffic analysis, HTTP/3 can either rely on transport-layer padding or employ the reserved frame and stream types discussed in frame-grease and stream- grease.  These methods of padding produce different results in terms of the granularity of padding, the effect of packet loss and recovery, and how an implementation might control padding. 10.2. </ins> Several protocol elements contain nested length elements, typically in the form of frames with an explicit length containing variable- length integers.  This could pose a security risk to an incautious implementer.  An implementation MUST ensure that the length of a frame exactly matches the length of the fields it contains. <ins> 10.3. </ins> The use of 0-RTT with HTTP/3 creates an exposure to replay attack. The anti-replay mitigations in HTTP-REPLAY MUST be applied when using HTTP/3 with 0-RTT. <ins> 10.4. </ins> Certain HTTP implementations use the client address for logging or access-control purposes.  Since a QUIC client's address might change during a connection (and future versions might support simultaneous

The initial request was simply to add sub-headings. I still feel like Security Considerations is a bit of a hodge-podge, and would welcome concrete suggestions or PRs for tightening it up.
Can you add a sub-heading(##) for each of these considerations, like in the transport draft? Originally posted by NAME in URL


Question: This document describes an architecture for implementing captive portals while addressing most of the problems arising for current captive portal mechanisms.  The architecture is guided by these <del> principles: </del> <ins> requirements: </ins> A side-benefit of the architecture described in this document is that devices without user interfaces are able to identify parameters of

Attempting to fix issue . I attempted to reword the principles, adding more prose for the rationale. Also upgraded some SHOULD NOT to MUST NOT because it seems some people thought the SHOULD NOT says the existing approach is OK. These are just some ideas. I won't be offended if rejected.
I believe I addressed all comments. You'll probably want to review the complete diff again.
Benjamin writes in his review: Michael replied with this suggested text: This seems reasonable, as I mentioned in the reply. We should go with it, unless anyone has an objection. Also, attribute it to Michael Richardson.
S. Moonesamy writes
One approach I suggested in my reply to the feedback:
This is good. Thanks for sorting through this; it's important that this is right, and you have cleared it up a lot.Much clearer. Thanks!