Question: 3. <ins> Multiple components in the architecture interact with both the User Equipment and each other.  Since the User Equipment is the focus of these interactions, the components must be able to both identify the user equipment from their interactions with it, and be able to agree on the identify of the user equipment when interacting with each other. The methods by which the components interact restrict the type of information that may be used as an identifying charactertics.  This section discusses the identifying charactersitics. 3.1. An Identifier is a chatacteristic of the User Equipment used by the components of a Captive Portal to uniquely determine which specific User Equipment is interacting with them.  An Identifier MAY be a field contained in packets sent by the User Equipment to the External Network.  Or, an Identifier MAY be an ephemeral property not contained in packets destined for the External Network, but instead correlated with such information through knowledge available to the different components. 3.2. The set of possible identifiers is quite large.  However, in order to be considered a good identifer, an identifier SHOULD meet the following criteria.  Note that the optimal identifier will likely change depending on the positino of the components in the network as well as the information available to them.  An identifier SHOULD: Uniquely Identify the User Equipment Be Hard to Spoof Be Visible to the API Be Visible to the Enforcement Device 3.2.1. In order to uniquely identify the User Equipment, at most one user equipment interacting with the other components of the Captive Portal MUST have a given value of the identifier. Over time, the user equipment identified by the value MAY change. Allowing the identified device to change over time ensures that the space of possible identifying vallues need not be overly large. Independent Captive Portals MAY use the same identifying value to identify different User Equipment.  Allowing indendent captive portals to reuse identifying values allows the identifier to be a property of the local network, expanding the space of possible identifiers. 3.2.2. A good identifier does not lend itself to being easily spoofed.  At no time should it be simple or straightforward for one User Equipment to pretend to be another User Equipment, regardless of whether both are active at the same time.  This property is particularly important when the user equipment is extended externally to devices such as billing systems, or where the identity of the User Equipment could imply liability. 3.2.3. Since the API will need to perform operations which rely on the identify of the user equipment, such as query whether it is captive, the API needs to be able to relate requests to the User Equipment making the request. 3.2.4. The Enforcement Device will decide on a per packet basis whether it should be permitted to communicate with the external network.  Since this decision depends on which User Equipment sent the packet, the Enforcement Device requires that it be able to map the packet to its concept of the User Equipment. 3.3. To evaluate whether an identifer is appropriate, one should consider every recommended property from the perspective of interactions among the components in the architecture.  When comparing identifiers, choose the one which best satifies all of the recommended properties. The architecture does not provide an exact measure of how well an identifier satisfies a given property; care should be taken in performing the evaluation. 3.4. This section provides some examples of identifiers, along with some evaluation of whether they are good identifiers.  The list of identifiers is not exhaustive.  Other identifiers may be used.  An important point to note is that whether the identifiers are good depends heavily on the capabilities of the components and where in the network the components exist. 3.4.1. The physical interface by which the User Equipment is attached to the network can be used to identify the User Equipment.  This identifier has the property of being extremely difficult to spoof: the User Equipment is unaware of the property; one User Equipment cannot manipulate its interactions to appear as though it is another. Further, if only a single User Equipment is attatched to a given physical interface, then the identifier will be unique.  If multiple User Equipment is attached to the network on the same physical interface, then this property is not appropriate. Another consideration related to uniqueness of the User Equipment is that if the attached User Equipment changes, both the API server and the Enforcement Device must invalidate their state related to the User Equipment. The Enforcement Device needs to be aware of the physical interface, which constrains the environment: it must either be part of the device providing physical access (e.g., implemented in firmware), or packets traversing the network must be extended to include information about the source physical interface (e.g.  a tunnel). The API server faces a similar problem, implying that it should co- exist with the Enforcement Device, or that the enforcement device should extend requests to it with the identifying information. 3.4.2. A natural identifier to consider is the IP address of the User Equipment.  At any given time, no device on the network can have the same IP address without causing the network to malfunction, so it is appropriate from the perspective of uniqueness. However, it may be possible to spoof the IP address, particularly for malicious reasons where proper functioning of the network is not necessary for the malicious actor.  Consequently, any solution using the IP address should proactively try to prevent spoofing of the IP address.  Similarily, if the mapping of IP address to User Equipment is changed, the components of the architecture must remove or update their mapping to prevent spoofing.  Demonstrations of return routeability, such as that required for TCP connection establishment, might be sufficient defense against spoofing, though this might not be sufficient in networks that use broadcast media (such as some wireless networks). Since the IP address may traverse multiple segments of the network, more flexibility is afforded to the Enforcement Device and the API server: they simply must exist on a segment of the network where the IP address is still unique.  However, consider that a NAT may be deployed between the User Equipment and the Enforcement Device.  In such cases, it is possible for the components to still uniquely identify the device if they are aware of the port mapping. In some situtations, the User Equipment may have multiple IP addresses, while still satisfying all of the recommended properties. This raises some challenges to the components of the network.  For example, if the user equipment tries to access the network with multiple IP addresses, should the enforcement device and API server treat each IP address as a unique User Equipment, or should it tie the multiple addresses together into one view of the subscriber?  An implementation MAY do either.  Attention should be paid to IPv6 and the fact that it is expected for a device to have multiple IPv6 addresses on a single link.  In such cases, idenfication could be performed by subnet, such as the /64 to which the IP belongs. 4. </ins> This section aims to improve understanding by describing a possible workflow of solutions adhering to the architecture. <del> 3.1. </del> <ins> 4.1. </ins> This section describes a possible work-flow when User Equipment initially joins a Captive Network.

We need to discuss what information will be used to identify the UE from the perspective of the various components in the system. This updates the draft to discuss this concept, including desired properties of the identifier and some examples. This aims to address issue 5 (URL)


Question: To properly indicate use of DTLS, the <proto> field MUST be set to "UDP/TLS/RTP/SAVPF", as specified in RFC5764, Section 8, if the <del> default candidate uses UDP transport, or "TCP/TLS/RTP/SAVPF", as </del> <ins> default candidate uses UDP transport, or "TCP/DTLS/RTP/SAVPF", as </ins> specified inI-D.nandakumar-mmusic-proto-iana-registration if the default candidate uses TCP transport.

URL of draft-nandakumar. This is a merge of a previously approved PR
lgtm
LGTM
As per discussion in mmusic, to make it abundantly clear that DTLS is to be used even when running over ICE-TCP, the profile name should be TCP/DTLS/RTP/SAVPF. We'll leave the UDP/TLS/RTP/SAVPF one alone, since that ship has sailed, and it's less ambiguous.
Need Suhas to update URL to reflect the above.
For SCTP, URL has the correct UDP/DTLS/SCTP and TCP/DTLS/SCTP things that we want to refer to.
The action item here is to update this document to use the correct fields as agreed above as if draft-nandakumar was done, and then when that document is fixed we will be good.


Question: 6. <del> Security considerations are enumerated in I-D.ietf-rtcweb-security. </del> <ins> RTCWEB security considerations are enumerated in I-D.ietf-rtcweb- security. Security considerations pertaining to the use of DSCP are enumerated in I-D.ietf-tsvwg-rtcweb-qos. </ins>

reformulated the TCP point, addressed security with a reference to -qos.
From Ben Campbell's review:
Second point is fixed by . I'm not sure the third point is an improvement.
SSL is used exactly once, as part of the acronym "TURN/SSL". This is also the first mention of TURN, but the second was much more convenient to attach the expansion to. Given that it was so awkward to attach them, I included a new section listing the "used protocols" instead.
From Magnus Westerlund in IETF LC: Section 8.1: [I-D.martinsen-mmusic-ice-dualstack-fairness] Martinsen, P., Reddy, T., and P. Patil, "ICE IPv4/IPv6 Dual Stack Fairness", draft-martinsen-mmusic-ice- dualstack-fairness-02 (work in progress), February 2015. Can be updated as this is now an WG item in ICE.
Updated in
Fixed by
I have reviewed this document in preparation for IETF last call. It is in good shape and I have requested the last call. While the last call is ongoing, I would like to double-check that this document (particularly Section 4) raises no new security considerations that should be documented in Section 6. I'm wondering if there are scenarios where a malicious application could try to game the priority scheme to some ill effect? draft-ietf-tsvwg-rtcweb-qos talks a bit about this, so I'm wondering if anything needs to be said here. And I found a couple of nits to be resolved together with any LC comments: Sec 3.2 - Please update the citation to point to draft-ietf-mmusic-ice-dualstack-fairness-02. Sec 3.4 - "Third, using TCP only between the endpoint and its relay may result in less issues with TCP in regards to real-time constraints, e.g. due to head of line blocking." This is awkwardly phrased. I would suggest something like "Third, using TCP between the client's TURN server and its peer may result in more performance problems (due to head-of-line blocking) than using UDP."


Question: 6. <del> Security considerations are enumerated in I-D.ietf-rtcweb-security. </del> <ins> RTCWEB security considerations are enumerated in I-D.ietf-rtcweb- security. Security considerations pertaining to the use of DSCP are enumerated in I-D.ietf-tsvwg-rtcweb-qos. </ins>

And one bit I left out — if text is to be added to reference draft-ietf-rtcweb-return, that should be done together with addressing nits and LC comments.
There seems no consensus to add RETURN, so I'm skipping this for now.


Question: ChaCha20 function as defined in Section 2.4 of CHACHA.  This uses a 256-bit key and 16 bytes sampled from the packet protection output. <del> The first 4 bytes of the sampled ciphertext are interpreted as a 32-bit number in little-endian order and are used as the block count. The remaining 12 bytes are interpreted as three concatenated 32-bit numbers in little-endian order and used as the nonce. </del> <ins> The first 4 bytes of the sampled ciphertext are the block counter.  A ChaCha20 implementation could take a 32-bit integer in place of a byte sequence, in which case the byte sequence is interpreted as a little-endian value. The remaining 12 bytes are used as the nonce.  A ChaCha20 implementation might take an array of three 32-bit integers in place of a byte sequence, in which case the nonce bytes are interpreted as a sequence of 32-bit little-endian integers. </ins> The encryption mask is produced by invoking ChaCha20 to protect 5 zero bytes.  In pseudocode:

The nonce can just be opaque bytes. The block counter is tricky, as noted in the issue. The "obvious" choice is little-endian, as that is consistent with the philosophy of the designer (as I understand it), but that is not anything more than a guess. Absent strong evidence that big-endian is a better choice, I'm going to err on the side of not making a substantive change here. But I think that we need a consensus call to support that viewpoint.
Here's what 5.4.4 says However, RFC 8439 says: This is a little confusing, but I think the correct way to read this is that the ChaCha function takes the nonce as a 96-bit opaque quantity, and the fact that it's little-endian is an internal detail irrelevant to our purposes, so we should just replace the second sentence with "The remaining 12 bytes are used as the 96-bit ChaCha nonce". This is reinforced by the fact that the test vectors have the nonce as a byte block. The situation with the counter is more complicated because we are told it is both a counter and 32-bits (which might make you think it's an integer parameter), but it is also treated as a little-endian integer, which makes one think it's a bitstring. And then the test vectors treat it as a value, rather than as a bitstring. If you look at code it typically thinks of this as an integer: See, for instance: URL So, I think the right answer here is to think of ChaCha as having the following API: Note that because the value on the wire is in big-endian format, this would invert the nonce, but I think it's the right answer anyway. Otherwise, you're having to pass in the counter in the wrong format on big-endian platforms.
As a completely general note, I don't think it is right to change endianness of crypto wire formats. AES-GCM has a completely backwards neither little nor big endian encoding (byte and bit swapped so no platform wins) this remains so on the wire. Especially for HW processing this is significant. But little endian is also more performant on nearly all relevant platforms today so there is no need to go over board forcing big endian if it can be avoided without insulting RFC's.
Yeah, this should simplify that text some.


Question: ChaCha20 function as defined in Section 2.4 of CHACHA.  This uses a 256-bit key and 16 bytes sampled from the packet protection output. <del> The first 4 bytes of the sampled ciphertext are interpreted as a 32-bit number in little-endian order and are used as the block count. The remaining 12 bytes are interpreted as three concatenated 32-bit numbers in little-endian order and used as the nonce. </del> <ins> The first 4 bytes of the sampled ciphertext are the block counter.  A ChaCha20 implementation could take a 32-bit integer in place of a byte sequence, in which case the byte sequence is interpreted as a little-endian value. The remaining 12 bytes are used as the nonce.  A ChaCha20 implementation might take an array of three 32-bit integers in place of a byte sequence, in which case the nonce bytes are interpreted as a sequence of 32-bit little-endian integers. </ins> The encryption mask is produced by invoking ChaCha20 to protect 5 zero bytes.  In pseudocode:

I like the proposed change, the text had somewhat confused me when implementing this in a previous life.
I don't think that the reinterpretation of the little-endian thing is safe, as per NAME comment. The takes a byte buffer as input rather than a . That is to allow for different block counter sizes. I'll make the editorial change, but leave the suggestion there alone.
I have a question out to the editor of the PKCS spec. It appears like there are no solid rules in the spec to support any particular position here. I'm going with my best guess at WWDJBD here, but I'm happy to make a change if there is a strong case made for something else.
NAME NAME can we flip this to please? I don't think that we need to change the substance here, but I want to confirm the little-endian/big-endian choice here. I hope to have more information to share on the question soon, but that might not be definitive. We might just have to make a call ourselves. Absent better information, I'm going to suggest that we continue with little-endian, but I this is far from an obvious conclusion.
The API I'm using for ChaCha20 takes a const uint8_t nonce[12], and I currently pass in a pointer (offset by 4 bytes) to the sample as the nonce, without doing any endianness conversions. I'm in favor of clarifying the language for this input. (Given that this has the design label instead of the editorial label, my design opinion is to keep with the simple thing of passing the bytes directly from the sample to the nonce input of ChaCha20 and not do any endianness conversions. I'm assuming that other crypto libraries have similar APIs though.)
The API I have takes . PKCS takes pointers just like the API NAME refers to (but it fails to specify the endianness, which is a critical oversight, compounded by the fact that the size of the counter can vary). I suspect that - as NAME says - the right idea is to note that ChaCha20 will interpret the nonce as three little-endian integers and that the counter might be expressed as a byte sequence that is then (probably) interpreted as a little-endian integer.


Question: ChaCha20 function as defined in Section 2.4 of CHACHA.  This uses a 256-bit key and 16 bytes sampled from the packet protection output. <del> The first 4 bytes of the sampled ciphertext are interpreted as a 32-bit number in little-endian order and are used as the block count. The remaining 12 bytes are interpreted as three concatenated 32-bit numbers in little-endian order and used as the nonce. </del> <ins> The first 4 bytes of the sampled ciphertext are the block counter.  A ChaCha20 implementation could take a 32-bit integer in place of a byte sequence, in which case the byte sequence is interpreted as a little-endian value. The remaining 12 bytes are used as the nonce.  A ChaCha20 implementation might take an array of three 32-bit integers in place of a byte sequence, in which case the nonce bytes are interpreted as a sequence of 32-bit little-endian integers. </ins> The encryption mask is produced by invoking ChaCha20 to protect 5 zero bytes.  In pseudocode:

I understand and appreciate this being marked as “design”, though I consider the text that landed in master as editorial, as it (in my view) ended as adding practical advice while retaining the definition we have had.
Yes, but as a design issue, we want to confirm that "no action" is the correct outcome. It's cheap enough to do so.
I like the updated text. It reads good as it gives the practical advice first, then amends that with the formal definition.


Question: The number of bits in the IP Address that are used to define the prefix that is being assigned.  This MUST be less than or equal to the length of the IP Address field, in bits.  If the prefix length <del> is equal to the length of the IP Address, the endpoint is only allowed to send packets from a single source address.  If the prefix length is less than the length of the IP address, the endpoint is allowed to send packets from any source address that falls within the prefix. </del> <ins> is equal to the length of the IP Address, the receiver of this capsule is only allowed to send packets from a single source address.  If the prefix length is less than the length of the IP address, the receiver of this capsule is allowed to send packets from any source address that falls within the prefix. </ins> If an endpoint receives multiple ADDRESS_ASSIGN capsules, all of the assigned addresses or prefixes can be used.  For example, multiple

This change adds text that addresses conveyed by ADDRESSASSIGN can be used in the "source address" field of an IP packet, while addresses conveyed by ROUTEADVERTISEMENT can be used in the "destination address" field. While we're here, also add a small clarification when a prefix is assigned/advertised that any of these addresses can be used in the source/destination field, respectively. A future extension could create semantics for these addreses, but that is not called out in the text at this time.
I'm know I'm late looking at this but thanks as this small clarification is really helpful
The current text in this draft needs to be updated to match the changes from URL I'll write up a PR once existing conflicting PRs are merged.
NAME is this unblocked now?
We need to clearly state that ADDRESSASSIGN defines a set of addresses the receiver of the capsule can use as a source IP address on packets it generates We need to clearly state that ROUTEADVERTISEMENT defines a set of addresses the receiver of the capsule can use as a destination IP address on packets it generates Should we rename the capsules to make this relationship more clear in all use cases?
Let's bike shed the name here NAME NAME NAME
(to clarify Tommy's comment - if anyone comes up with a new name they like, they should post it here. If not, we'll go with advertisement and withdraw)
Thanks!


Question: responds with an error status code and a problem document describing the error. <del> 6.3.3. </del> <ins> 6.3.4. </ins> A client may deactivate an account by posting a signed update to the server with a status field of "deactivated."  Clients may wish to do

This is a variant of that uses a MAC key to perform the account binding instead of a bearer token. Thanks to NAME for pointing out the need for this on the ACME mailing list.
Question: will you require a CA that doesn't use external account bindings to reject a request if it contains an external-account-binding member? nit: s/field/member/g, consistent with RFC 7159.
StartCom plan to use ACME protocol for StartEncrypt, we need to identify the client's validation level, so the subscriber administration can generate a special token in the URL account that send this token to the email address used in the registration. At the registration, user need to enter email and this token with the certificate to let the CA system know this customer's validation level. After the CA system receive the email, the token and signing certificate, CA system know what type of certificate we can issue to this client; if this client account is class 4 validated, then the client can get EV SSL certificate, not DV SSL. please add this a parameter to the ACME protocol, thanks.
This request should be sent to the ACME mailing list (EMAIL) for further discussion, it would also be very useful to know what your EV (or OV) validation flow would look like using ACME as most likely the current certificate application object would need to be changed to identify those requirements to the server.
This was fixed by
Minor editorial comments.


Question: Preference <del> Prefer </del> <ins> Ignore </ins> This property specifies whether the application needs or prefers to use a transport protocol that preserves message boundaries.

I am sure this has been discussed, but reading now it seems strange to me to use "Prefer" as the default for a Selection Property that affects how the application interacts with the API. Using "Prefer" means that I do not know what service I will get when using the default settings? In this case I do not know if I get messages or not if I use the defaults.
This should be Ignore as a default.


Question: Preconnection, Connection (read only) <del> This property specifies whether the application wishes to use a </del> <ins> This property specifies whether the application needs to use a </ins> transport protocol that ensures that all data is received on the other side without corruption.  This also entails being notified when a Connection is closed or aborted.  The default is to enable Reliable

I didn't like something about reliability (let's not throw an error when we can't be UNreliable, only when we can't be reliable). I updated the text on ordering a bit, to say that the Property is ignored for the first Message on a Connection, and rephrased it slightly to talk about the receiver-side transport system and the receiving application - before, the text might have talked about a sender-side behavior. I added a TODO DISCUSS comment about per-message Niceness.
Fine with me, maybe fix minor knitThanks, all good now I think.


Question: "supported_signature_algorithms" value: %%% Signature Algorithm Extension enum { // RSASSA-PKCS-v1_5 <del> algorithms.  rsa_pkcs1_sha1 (0x0201), rsa_pkcs1_sha256 (0x0401), </del> <ins> algorithms rsa_pkcs1_sha1 (0x0201), rsa_pkcs1_sha256 (0x0401), </ins> rsa_pkcs1_sha384 (0x0501), rsa_pkcs1_sha512 (0x0601), Note: This production is named "SignatureScheme" because there is

Minor editorial tweaks. I just noticed the extra line that gets left in there when shown up top (two lines between first two shown blocks, instead of one). This fixes that. Also drops the periods after the comments, as they're not sentences.


Question: monitor for new push messages. Requesting the delivery of events is particularly important for the <del> Web Push API.  The subscription, management and monitoring functions </del> <ins> W3C Push API.  The subscription, management and monitoring functions </ins> are currently fulfilled by proprietary protocols; these are adequate, but do not offer any of the advantages that standardization affords.

Pretty good. I think that we should at least try to put some MUST-strength language in regarding confidentiality, etc... That makes writing the rest of the security considerations that much easier (you don't have to worry that someone might have ignored your advice and account for it).
Looks good. Further refinements can be done later :)
There is an adequate explanation of the related W3C Push API in the Introduction. Additional references about specific API behavior in Section 9.3 and 9.4 can be removed.
Besides removing extraneous API references, informative references should be added for the separate drafts for optional content encoding and authentication.
Moving to -05. Waiting for a decision on the VAPID call for adoption.


Question: The connection is bi-directional, so requests can be sent both by the entity that established the connection and the remote host. <del> Retransmission and deduplication of messages is provided by the WebSocket protocol.  CoAP over WebSockets therefore does not make a distinction between Confirmable or Non-Confirmable messages, and does not provide Acknowledgement or Reset messages. </del> <ins> As with CoAP over TCP, retransmission and deduplication of messages is provided by the WebSocket protocol.  CoAP over WebSockets therefore does not make a distinction between Confirmable or Non- Confirmable messages, and does not provide Acknowledgement or Reset messages. </ins> 3.4. <del> When a client does not receive any response for some time after sending a CoAP request (or, similarly, when a client observes a resource and it does not receive any notification for some time), the connection between the WebSocket client and the WebSocket server may be lost or temporarily disrupted without the client being aware of it. To check the health of the WebSocket connection (and thereby of all active requests, if any), a client can send a CoAP Ping Signaling message (sec-ping).  WebSocket Ping and unsolicited Pong frames as specified in Section 5.5 of RFC6455 SHOULD NOT be used to ensure that redundant maintenance traffic is not transmitted. There is no way to retransmit a request without creating a new one. Re-registering interest in a resource is permitted, but entirely unnecessary. 3.5. The WebSocket connection is closed as specified in Section 7 of RFC6455. All requests for which the CoAP client has not received a response yet are cancelled when the connection is closed. </del> <ins> As with CoAP over TCP, the client can test the health of the CoAP over WebSocket connection by sending a CoAP Ping Signaling message (sec-ping).  WebSocket Ping and unsolicited Pong frames (Section 5.5 of RFC6455) SHOULD NOT be used to ensure that redundant maintenance traffic is not transmitted. </ins> 4.

URL CoAP over WebSockets The following now seems unrelated: Another possible configuration is to set up a CoAP forward proxy at the WebSocket endpoint. Depending on what transports are available Figure 12: CoAP Client (UDP client) accesses sleepy CoAP Server (WebSocket client) via a CoAP proxy (UDP server/WebSocket server) s/sleepy// (There is no mention of sleepiness here.) CoAP over WebSockets is intentionally very similar to CoAP over UDP. Therefore, instead of presenting CoAP over WebSockets as a new protocol, this document specifies it as a series of deltas from [RFC7252]. Probably best to delete that paragraph -- it is true not only for WS, but also for TCP. So why only here? 3.1. Opening Handshake Hmm, the title is confusing. WS also uses the same opening handshake as 2.3. The parts that relate to both TCP/TLS and WS/S need to be factored out. 3.2. Message Format The message format shown in Figure 14 is the same as the CoAP over TCP message format (see Section 2.4) with one restriction. The Length (Len) field MUST be set to zero because the WebSockets frame already contains the length. s/restriction/change/. The CoAP over TCP message format eliminates the Version field defined in CoAP over UDP. If CoAP version negotiation is required in the future, CoAP over WebSockets can address the requirement by the definition of a new subprotocol identifier that is negotiated during the opening handshake. This paragraph is a bit weird. Maybe: As with CoAP over TCP, the message format for CoAP over Websockets eliminates the Version field defined in CoAP over UDP. If CoAP Empty messages (Code 0.00) MUST be ignored by the recipient (see also Section 4.4). Why are we saying this here and not in Section 2? Factor out. 3.3. Message Transmission Similar as with CoAP over TCP, Retransmission and deduplication of messages is provided by the WebSocket protocol. CoAP over WebSockets therefore does not make a distinction between Confirmable or Non-Confirmable messages, and does not provide Acknowledgement or Reset messages. 3.4.


Question: The connection is bi-directional, so requests can be sent both by the entity that established the connection and the remote host. <del> Retransmission and deduplication of messages is provided by the WebSocket protocol.  CoAP over WebSockets therefore does not make a distinction between Confirmable or Non-Confirmable messages, and does not provide Acknowledgement or Reset messages. </del> <ins> As with CoAP over TCP, retransmission and deduplication of messages is provided by the WebSocket protocol.  CoAP over WebSockets therefore does not make a distinction between Confirmable or Non- Confirmable messages, and does not provide Acknowledgement or Reset messages. </ins> 3.4. <del> When a client does not receive any response for some time after sending a CoAP request (or, similarly, when a client observes a resource and it does not receive any notification for some time), the connection between the WebSocket client and the WebSocket server may be lost or temporarily disrupted without the client being aware of it. To check the health of the WebSocket connection (and thereby of all active requests, if any), a client can send a CoAP Ping Signaling message (sec-ping).  WebSocket Ping and unsolicited Pong frames as specified in Section 5.5 of RFC6455 SHOULD NOT be used to ensure that redundant maintenance traffic is not transmitted. There is no way to retransmit a request without creating a new one. Re-registering interest in a resource is permitted, but entirely unnecessary. 3.5. The WebSocket connection is closed as specified in Section 7 of RFC6455. All requests for which the CoAP client has not received a response yet are cancelled when the connection is closed. </del> <ins> As with CoAP over TCP, the client can test the health of the CoAP over WebSocket connection by sending a CoAP Ping Signaling message (sec-ping).  WebSocket Ping and unsolicited Pong frames (Section 5.5 of RFC6455) SHOULD NOT be used to ensure that redundant maintenance traffic is not transmitted. </ins> 4.

Connection Health There is no way to retransmit a request without creating a new one. Re-registering interest in a resource is permitted, but entirely unnecessary. (See the discussion we already had.) [Brian] - The reference is
Closing the Connection Does this mean, only the client must cancel the requests? Or should the server do this also? Then a clarfication may be useful.
The original - URL - was specific to Observe: ~ All updates to Observe are now captured in a single place - Appendix A. This specific case is in URL At this point, I think that Closing the Connection could simply be deleted because there are no specific changes required.
Let's say a client has sent one or more requests to a server but hasn't received any response yet, and/or is observing a resource at a server. If the client or the server closes the connection or if the connection goes down unexpectedly, then the client will never receive the responses or any further notifications. The client has to reconnect and send new requests. Neither the client nor the server needs to send anything to cancel active requests before closing the connection; when a connection closes, all active requests are canceled automatically. The client should signal that to the code waiting for the responses, e.g., by throwing an exception. The server should abort processing the requests or at least discard the responses once the requests have been processed. The server also should remove the client from the lists of observers (at latest when it tries to send the next notification and it notices that the connection is down).
URL General - It's not clear "how" mandatory the use of the CSM is. Clause 2.3 on TCP/TLS indicates that the CSM message must be sent at the start of the connection. Clause 3.1 on Websockets makes no mention of CSM messages. Clause 4.3 indicates that the CSM MUST be sent at the start of the connection also and makes no distinction between TCP/TLS and Websockets. Clause 2.3 also indicates that the connection must be aborted if the CSM is missing or invalid as the first message on the connection. Given the discussion about address changes does more information need to be provided what start of connection means?
In the , the intent of this statement is unclear: There is no way to retransmit a request without creating a new one.


Question: The connection is bi-directional, so requests can be sent both by the entity that established the connection and the remote host. <del> Retransmission and deduplication of messages is provided by the WebSocket protocol.  CoAP over WebSockets therefore does not make a distinction between Confirmable or Non-Confirmable messages, and does not provide Acknowledgement or Reset messages. </del> <ins> As with CoAP over TCP, retransmission and deduplication of messages is provided by the WebSocket protocol.  CoAP over WebSockets therefore does not make a distinction between Confirmable or Non- Confirmable messages, and does not provide Acknowledgement or Reset messages. </ins> 3.4. <del> When a client does not receive any response for some time after sending a CoAP request (or, similarly, when a client observes a resource and it does not receive any notification for some time), the connection between the WebSocket client and the WebSocket server may be lost or temporarily disrupted without the client being aware of it. To check the health of the WebSocket connection (and thereby of all active requests, if any), a client can send a CoAP Ping Signaling message (sec-ping).  WebSocket Ping and unsolicited Pong frames as specified in Section 5.5 of RFC6455 SHOULD NOT be used to ensure that redundant maintenance traffic is not transmitted. There is no way to retransmit a request without creating a new one. Re-registering interest in a resource is permitted, but entirely unnecessary. 3.5. The WebSocket connection is closed as specified in Section 7 of RFC6455. All requests for which the CoAP client has not received a response yet are cancelled when the connection is closed. </del> <ins> As with CoAP over TCP, the client can test the health of the CoAP over WebSocket connection by sending a CoAP Ping Signaling message (sec-ping).  WebSocket Ping and unsolicited Pong frames (Section 5.5 of RFC6455) SHOULD NOT be used to ensure that redundant maintenance traffic is not transmitted. </ins> 4.

Re-registering interest in a resource is permitted, but entirely unnecessary.
Response from Klaus Hartke: In general, CoAP clients are not allowed to use a token while it is still in use. RFC 7641 defines an exception: a client is allowed to confirm its interest in receiving notifications for a resource by sending a request identical to the original registration request, including the token that is already in use. The above paragraph just says that this is also the case for CoAP over TCP/TLS/WebSockets, but points out that sending a Ping (which checks the health of the connection and hence of all active observations) is better than confirming the interest for all active observations individually. Response from Carsten: Yes, the text is much easier to understand in that context — in the old draft, it was clear that this talks about reregistering interest. So in the new text, we probably need to prefix a sentence like For use with UDP, RFC 7641 discusses ways to re-register interest in a resource to deal with the case that the server providing this resource might have lost the information about this interest. In CoAP over TCP, the framework of the current connection provides fate-sharing between the health of the connection and the health of the expression of interest.
After further review, I think that this note belongs in Appendix A with the other updates/guidance for Observe on reliable transports. Connection Health should limit its discussion to WebSocket specific changes - in this case, the use of the CoAP Ping Signaling message instead of WebSocket Ping/Pong.


Question: This specification does not cover the throttling scope, that may be the given resource-target, its parent path or the whole Origin <del> RFC6454 section 7. </del> <ins> (see Section 7 of RFC6454). </ins> The rate-limit headers may be returned in both Successful and non Successful responses.  This specification does not cover whether

uses http-core semantics fixes Sections refs cc: NAME
I'll wait for the new i-d-template image, but will do.
Please use either [RFCxxxx], Section yyy or Section yyy of [RFCxxxx]
Addressed by now.
If you start using the new kramdown-rcf2629 section ref syntax, you may want to do that consistently...


Question: The Transport Services architecture evolves this general model of interaction, aiming to both modernize the API surface presented to applications by the transport layer and enrich the capabilities of <del> the Transport System implementation.  It combines interfaces for </del> <ins> the Transport Services implementation.  It combines interfaces for </ins> multiple interaction patterns into a unified whole.  By combining name resolution with connection establishment and data transfer in a single API, it allows for more flexible implementations to provide

Addresses
In the architecture document, I noticed that we sometimes say "Transport Services system" and sometimes "Transport System". Are these the same? Are "Transport Services implementation" and "Transport System implementation" the same, too?
I prefer "Transport Services system" and "Transport Services implementation"
I find it long and clumsy :( Side note: we'll have to rename it everywhere in the API draft too if we go with this.
was this fixed by ?
Yes it was. We already used Transport Services most places so it's not all that different.
Looks good, thanks!


Question: Lastly, if a data channel has been created, a m= section MUST be generated for data.  The <media> field MUST be set to "application" <del> and the <proto> field MUST be set to "UDP/TLS/SCTP" if the default candidate uses UDP transport, or "TCP/TLS/SCTP" if the default </del> <ins> and the <proto> field MUST be set to "UDP/DTLS/SCTP" if the default candidate uses UDP transport, or "TCP/DTLS/SCTP" if the default </ins> candidate uses TCP transport I-D.ietf-mmusic-sctp-sdp.  The "fmt" value MUST be set to the SCTP port number, as specified in Section 4.1.  [TODO: update this to use a=sctp-port, as indicated in

URL of draft-nandakumar. This is a merge of a previously approved PR
lgtm
LGTM
As per discussion in mmusic, to make it abundantly clear that DTLS is to be used even when running over ICE-TCP, the profile name should be TCP/DTLS/RTP/SAVPF. We'll leave the UDP/TLS/RTP/SAVPF one alone, since that ship has sailed, and it's less ambiguous.
Need Suhas to update URL to reflect the above.
For SCTP, URL has the correct UDP/DTLS/SCTP and TCP/DTLS/SCTP things that we want to refer to.
The action item here is to update this document to use the correct fields as agreed above as if draft-nandakumar was done, and then when that document is fixed we will be good.


Question: (this document) <del> Martin Thomson (martin.thomson@gmail) or the Web Push WG (webpush@ietf.org) </del> <ins> The Web Push WG (webpush@ietf.org) </ins> urn:ietf:params:push:sub

This is a work in progress, but ready for an initial review. I will add more commits to the branch for dealing with IANA registration of the header field. I also need to do some massaging of Section 7.2 to account for changes there. I'll have a follow-up pull request that deals with learning the server TTL. I think that the simplest thing to do would be to have the server echo the header field, using a lower value if it doesn't support it. Application servers can discover the maximum by sending a large value, like . The alternative is a declarative push service policy, but I want to encourage an adaptive policy with respect to TTL.
An alternative to echoing the TTL is just using the header field, as is currently described. I think that might actually be sufficient. That still leaves user agents unable to determine whether they need a full resync though. We need something for .
Looking at the semantics of and in relation to and , I think that it would be unwise to use them here. Current plan is to echo .
It was less clear that this was needed than was, but the idea is that it would be good for a user agent (or maybe an application server too) to be able to learn the maximum TTL that a push service was willing to maintain.
Discussed today: conclusion was to have subscriptions expire if the server is unwilling to maintain them over a long period of inactivity.
It should be fine if we let subscriptions expire if the server is unwilling to maintain them over a long period of inactivity.
There is a related failure case in the current draft related to acknowledgements: The push server MUST push a response with a status code of 5XX (TBD) if the user agent fails to acknowledge the receipt of the push message or the push server fails to deliver the message prior to its expiration.
Discussed. Discovery of maximum TTL is not required at this time.
This is just for the request from the application server to the push service.


Question: in compliance with RFC6437, unless the local API does not allow setting IPv6 flow labels. <del> The IPv6 flow label SHOULD be a pseudo-random function of the source and destination addresses, source and destination UDP ports, and the Destination Connection ID field.  The flow label generation MUST be designed to minimize the chances of linkability with a previously used flow label, as a stable flow label would enable correlating activity on multiple paths; see migration-linkability. A possible implementation is to compute the flow label as a cryptographic hash function of the source and destination addresses, source and destination UDP ports, Destination Connection ID field, and a local secret. </del> <ins> The flow label generation MUST be designed to minimize the chances of linkability with a previously used flow label, as a stable flow label would enable correlating activity on multiple paths; see migration- linkability. RFC6437 suggests deriving values using a pseudorandom function to generate flow labels.  Including the Destination Connection ID field in addition to source and destination addresses when generating flow labels ensures that changes are synchronized with changes in other observable identifiers.  A cryptographic hash function that combines these inputs with a local secret is one way this might be implemented. </ins> 10.

This was a little tricky as the current text already had what we wanted. But it wasn't quite clear on rationale, so I added some of that.
Éric Vyncke said:
I believe that the view was that a PRNG was inferior to a PRF because it required state, but yes, it should be fine. Should we have avoided repeating advice from 6437? (I forget who contributed this text, but I think that it was an RFC 6437 author.)
Text originates with Christian NAME in . A few people have touched it since for editorial purposes, but that doesn't change the point of what you're asking about.


Question: 6. <del> Prio assumes a powerful adversary with the ability to compromise an unbounded number of clients.  In doing so, the adversary can provide malicious (yet truthful) inputs to the aggregation function.  Prio also assumes that all but one server operates honestly, where a dishonest server does not execute the protocol faithfully as specified.  The system also assumes that servers communicate over secure and mutually authenticated channels.  In practice, this can be done by TLS or some other form of application-layer authentication. In the presence of this adversary, Prio provides two important properties for computing an aggregation function F: Privacy.  The aggregators and collector learn only the output of F computed over all client inputs, and nothing else. Robustness.  As long as the aggregators execute the input- validation protocol correctly, a malicious client can skew the output of F only by reporting false (untruthful) input.  The output cannot be influenced in any other way. There are several additional constraints that a Prio deployment must satisfy in order to achieve these goals: Minimum batch size.  The aggregation batch size has an obvious impact on privacy.  (A batch size of one hides nothing of the input.) Aggregation function choice.  Some aggregation functions leak slightly more than the function output itself. [TODO: discuss these in more detail.] </del> <ins> PPM assumes an active attacker that controls the network and has the ability to statically corrupt any number of clients, aggregators, and collectors.  That is, the attacker can learn the secret state of any party prior to the start of its attack.  For example, it may coerce a client into providing malicious input shares for aggregation or coerce an aggregator into diverting from the protocol specified (e.g., by divulging its input shares to the attacker). In the presence of this adversary, PPM aims to achieve the following high-level secure aggregation goals: Privacy.  Clients trust that some aggregator is honest.  That is, as long as at least one aggregator executes the protocol faithfully, the parties learn nothing beyond the aggregate result (i.e., the output of the aggregation function computed over the honest measurements). Correctness.  The collector trusts that the aggregators execute the protocol correctly.  That is, as long as the aggregators execute the protocol faithfully, a malicious client can skew the aggregate result only by reporting a false (untruthful) measurement.  The result cannot be influenced in any other way. Currently, the specification does not achieve these goals.  In particular, there are several open issues that need to be addressed before these goals are met.  Details for each issue are below. When crafted maliciously, collect requests may leak more information about the measurements than the system intends.  For example, the spec currently allows sequences of collect requests to reveal an aggregate result for a batch smaller than the minimum batch size.  [OPEN ISSUE: See issue#195.  This also has implications for how we solve issue#183.] Even benign collect requests may leak information beyond what one might expect intuitively.  For example, the Poplar1 VDAF VDAF can be used to compute the set of heavy hitters among a set of arbitrary bit strings uploaded by clients.  This requires multiple evaluations of the VDAF, the results of which reveal information to the aggregators and collector beyond what follows from the heavy hitters themselves.  Note that this leakage can be mitigated using differential privacy.  [OPEN ISSUE: We have yet not specified how to add DP.] The core PPM spec does not defend against Sybil attacks.  In this type of attack, the adversary adds to a batch a number of reports that skew the aggregate result in its favor.  For example: The result may reveal additional information about the honest measurements, leading to a privacy violation; or the result may have some property that is desirable to the adversary ("stats poisoning").  The upload sub-protocol includes an extensions mechanism that can be used to prevent -- or at least mitigate -- these types of attacks.  See upload-extensions.  [OPEN ISSUE: No such extension has been implemented, so we're not yet sure if the current mechanism is sufficient.] Attacks may also come from the network.  Thus, it is required that the aggregators and collector communicate with one another over mutually authenticated and confidential channels.  The core PPM spec does not specify such a mechanism beyond requiring server authentication for HTTPS sessions.  Note that clients are not required to authenticate themselves.  [OPEN ISSUE: It might be better to be prescriptive about leader authentication in leader- helper channels and collector authenticaiton in collector-leader channels.  For the latter we have issue#155.] </ins> 6.1. <ins> [OPEN ISSUE: This subsection is a bit out-of-date.] </ins> In this section, we enumerate the actors participating in the Prio system and enumerate their assets (secrets that are either inherently valuable or which confer some capability that enables further attack

This change is primarily editorial and includes the following changes: Replace references to "Prio" with references to a generic VDAF. (This section was written long ago when we had Prio in mind.) Elaborate on known issues for collect requests. Discuss Sybil attacks, including enumerating the different types ().
From dkg in Vienna:
It seems like there are a bunch of assumptions about Sybil attacks generally that are not well articulated yet. This would certainly help.
The list of attacks is really a list of things we ought to fix in the protocol, so I would not even bother including them in the security considerations. If we want to use this as an opportunity to identify open issues that need to be addressed before we consider the protocol secure, I would simply list the open issues and keep discussion in GitHub. (That is, the text here seems redundant with the issue )


Question: optimization requires some care in implementation, since it can cause premature PTOs under packet loss when "ignore_order" is enabled. <del> 8. </del> <ins> 9. </ins> There are tradeoffs inherent in a sender sending an ACK_FREQUENCY frame to the receiver.  As such it is recommended that implementers

by adding a one byte IMMEDIATE_ACK frame.
editorial nit: my preference would be for frame diagrams to use the notation in QUIC transport. I see that ACK_FREQUENCY is defined using ASCII art, so perhaps you want to consider a separate follow up PR to switch styles after this lands.
Thanks Lucas, I filed to update them.
They currently use ascii art. Will write this up once is merged.
sgtm, thanks!
When sending a PTO packet, a sender wants to induce an immediate ACK. The only trick I know to induce such an ACK is intentionally skip the packet number. However, the problem of that approach is that it relies on the receiver not ignoring reorders. When an ACKFREQUENCY frame previously sent had set the bit, then it become impossible for a sender to induce an immediate ACK when sending a PTO packet. At the moment, the only solution is to bundle an ACK_FREQUENCY packet in each PTO packet, but that seems like a bit of unnecessary overhead to me. Should we have a dedicated frame for inducing immediate ACKs instead?
That's an option. Another option is to revisit the max_reordering idea discussed in . If the max reordering was 5, then you could skip 5 PNs. I do feel like it'd be nice to allow specifying an int for max reordering, since that matches up with adaptive packet threshold loss detection, but as I expressed in , I think getting the details right are deceptively difficult, so I'm torn.
This does seem like a real problem. I like the idea of a single "ELICIT_ACK" type frame. With one byte a sender could effectively mark its PTOs ensuring they get an ACK without relying on the trick. An explicit frame is also easier to implement for the sender than the packet number skipping.
There's quite a bit of discussion on this on the tcpm mailing list at the moment, ie: URL I'm increasingly thinking it's worth using an unused protected bit in the header for this. It'd end up competing with the 2-bit packet loss measurements, but given those are experimental and may never be widely deployed, I think it might be worth it. For example, I believe this could allow an implementation to not include maxackdelay in PTO if it set the "ACK-pull"(or whatever it's called) bit on the final packet.


Question: optimization requires some care in implementation, since it can cause premature PTOs under packet loss when "ignore_order" is enabled. <del> 8. </del> <ins> 9. </ins> There are tradeoffs inherent in a sender sending an ACK_FREQUENCY frame to the receiver.  As such it is recommended that implementers

That already seems possible if more than the threshold number of ack-eliciting packets are outstanding.
I've thought more about this, and I think most of the time a 1-byte frame would be acceptable, but it definitely adds some implementation complexity, so I'd be curious which design others prefer? If we can decide, then I'll be happy to write a PR(or NAME can). Besides PTO, a use case would be making the last packet before becoming app-limited elicit an immediate ACK. This could allow skipping maxackdelay for all PTOs(see ), though always doing it could be a bit much in some cases. For example, browsers commonly send a series of requests, but to the transport it seems app-limited between them, because it doesn't know the browser has another request to send. It might be useful for 'chirping' as well, but I've never tried that, so it's mostly speculation.
We don't currently have any intention of deploying them either, and I think that's unlikely to change. I haven't seen a lot of good evidence that they are terribly helpful, and content providers don't seem to have a good incentive for implementing it. For us at least, the difference in complexity for a frame versus a bit in the header is negligible. A frame is actually be slightly easier to implement and losing a byte here and there isn't so bad.
I strongly prefer using the header bit. Although it will be a bit more work to implement, the fact that I won't end up with a 1-byte STREAM frame that I have to split off at the end of the packet will be worth the effort.
Is testimony of network operators not taken as evidence? I remember a line of people, from different companies -- BT, ATT, and so on, at IETF 101 practically begging for some information in QUIC packets to be exposed for monitoring and troubleshooting.
I do not see anyone propose a 1-byte STREAM frame. I believe what is meant is a new frame type. If anything, using a new frame type to elicit an ACK is easier than using a header bit, as it involves fewer parts of the code to change.
Nobody is proposing a 1-byte STREAM frame (you can't just make up stream data anyway). The problem is that a new frame would consume bytes (or probably one byte) in the packet payload.


Question: optimization requires some care in implementation, since it can cause premature PTOs under packet loss when "ignore_order" is enabled. <del> 8. </del> <ins> 9. </ins> There are tradeoffs inherent in a sender sending an ACK_FREQUENCY frame to the receiver.  As such it is recommended that implementers

Given that you set this signal on a PTO, and PTOs are often retransmissions of packets, this would require you to repackage (and, most likely, cut off a single byte from a STREAM frame). Using a header bit would solve that problem.
NAME and I discussed this and there are number of ways to fix this, but given this issue of not being able to elicit an immediate ACK by skipping packet numbers is introduced by the draft, we feel it's important it be fixed in some way. One more option is new STREAM frame codepoints that elicit an immediate ACK.
I'm ready to write a PR, but I'd appreciate thoughts on whether the existing PING frame should be repurposed or we should add a new frame(ACK, PONG, etc). I lean towards a new frame, since there are enough code-points and I believe there are use cases for the existing PING frame that does not elicit an immediate ACK.
+1. While I would not be opposed to repurposing the existing PING frame, I do not see the necessity of doing that. Let's simply consume one code point of the remaining 33.
Thanks, now for bikeshedding time. Some possible names: ACKME ACKPULL (from TCP) FAST_ACK PONG
Putting on my bikeshedding hat: I don't think we should prefix the frame name with ACK since that almost makes it looks like yet another variant of the ACK frame. The "pull" TCP terminology is fine (e.g. PULLACK) but we could also be more explicit with something like SOLICIT_ACK.
SCTP has something similar and calls it SACK-IMMEDIATELY (RFC 7053).
Thanks, I'd be happy with ACKIMMEDIATELY or IMMEDIATEACK
For those two options I'd prefer IMMEDIATE_ACK for the same reasoning as above -- so it appears less like an ACK variant.
IMMEDIATEACK sounds good to me. Alternatively, I'd be also fine with something like ACKNOW.
IMMEDIATE_ACK it is, PR coming.


Question: 5.2. The solution described here assumes that when the User Equipment <del> needs to trust the API server, server authentication will be utilized using TLS mechanisms. </del> <ins> needs to trust the API server, server authentication will be performed using TLS mechanisms. </ins> 5.3. <ins> The solution described here requires that the API be secured using TLS.  This is required to allow the user equipment and API server to exchange secrets which can be used to validate future interactions. The API must ensure the integrity of this information, as well as its confidentiality. 5.4. </ins> It is possible for any user on the Internet to send ICMP packets in an attempt to cause the receiving equipment to go to the captive portal.  This has been considered and addressed in the following

We want to make TLS a requirement, not a suggestion, so I've chagned the wording around TLS to reflect this. I also added a section to the security section discussing the motivation behind the requirement.
Can you forward to the list please?


Question: in the "PreSharedKeyID" object.  Specifically, "psk_secret" is computed as follows: <del> The "index" field in "PSKLabel" corresponds to the index of the PSK in the "psk" array, while the "count" field contains the total number of PSKs. </del> <ins> Here "0" represents the all-zero vector of length KDF.Nh.  The "index" field in "PSKLabel" corresponds to the index of the PSK in the "psk" array, while the "count" field contains the total number of PSKs.  In other words, the PSKs are chained together with KDF.Extract invocations, as follows: In particular, if there are no PreSharedKey proposals in a given Commit, then the resulting "psk_secret" is "psk_secret_[0]", the all- zero vector. </ins> 8.3.

In , NAME noted that the concatenation approach used to combine multiple PSKs is not well validated. At the 2021-10-04 interim, we discussed moving from this approach to a "cascaded HKDF" approach, with the idea of doing the same thing here as the main key schedule. This PR implements that suggestion. One nice implication of the algorithm here is that when there are no PSKs, it produces the zero vector as a degenerate case. So you could implement it pretty cleanly:
The spec currently doesn't distinguish much between an external and a member commit w.r.t. how proposals by reference are handled. In theory, the server could keep track of proposals and send the external committer all proposals that were sent up until the time they want to commit externally. However, there are a few difficulties in committing proposals by reference in an external commit. Membership tags: The external committer doesn't have the ability to verify membership tags on proposals. This is probably not a show-stopper, as proposals still need to be signed by a group member, but if nothing else, this should be noted in the spec. Leaf positioning: The spec was changed such that the committer is added into the tree without an Add proposal being present. If there are other Add (and Remove) proposals present, it is unclear in what order they should be processed. Should the committer be added when the path is processed? Or should it still be processed as if it were an Add? There are probably other things that can go wrong when committing referenced proposals externally, but those are the first that come to mind. The simplest solution would be to simply ignore proposals by reference, although this would break the current principle that a commit must always include all valid proposals that were sent during the epoch. The consequence would be that Parties that sent proposals will have to re-send them if the epoch is ended by an external commit. It should be noted, that a Preconfigured sender will have no way to detect if their proposal was committed or not.
I'm not sure your worries here are very real: Membership tags: I don't think the membership tag issue matters, because the existing members will reject the proposal (and thus the commit) if the membership tag is invalid; at worst the joiner gets themselves wedged into a group by themselves.


Question: in the "PreSharedKeyID" object.  Specifically, "psk_secret" is computed as follows: <del> The "index" field in "PSKLabel" corresponds to the index of the PSK in the "psk" array, while the "count" field contains the total number of PSKs. </del> <ins> Here "0" represents the all-zero vector of length KDF.Nh.  The "index" field in "PSKLabel" corresponds to the index of the PSK in the "psk" array, while the "count" field contains the total number of PSKs.  In other words, the PSKs are chained together with KDF.Extract invocations, as follows: In particular, if there are no PreSharedKey proposals in a given Commit, then the resulting "psk_secret" is "psk_secret_[0]", the all- zero vector. </ins> 8.3.

And as you say, they're signed, and they keys can be tied back to the tree hash in the GroupInfo. Leaf positioning: We need to clear this up regardless of proposals-by-reference. It seems like basically having a synthetic Add at the beginning or end of the proposal list would work fine. Preconfigured proposer: This is a problem only when Commits are encrypted, so it's not a problem in the external commit case (since an external Commit cannot be encrypted). Nonetheless, the point that an external joiner can't fully verify a Proposal seems to argue pretty strongly for forbidding proposals by reference. I don't think this even violates the semantic of "include all valid proposals received in the epoch", since (1) that requirement is receiver oriented (it's not enough for the proposals to have been sent) and (2) the external joiner can't tell if the proposals or valid. Overall, I would lean slightly toward removing proposals by reference. And if we do that, it might even make sense to just define an ExternalCommit message that packages together the few things that are still allowed.
I'm not sure I understand how the receiver-orientation of the "all valid proposals must be included" rule matters to its application to this case. If we remove the requirement for external commits to include proposals by reference and don't soften that rule to exclude external commits, receivers will consider all external commits invalid in the presence of valid pending proposals by reference. In any case, I'm also in favor of keeping it simple and restrict the External Commit to a few, well defined components that do not include any proposals by reference.
Discussion on working call: "No proposals by reference" kind of follows from "all valid proposals", since the joiner can't necessarily determine that proposals are valid Maybe allow attempts? Might not get feedback to retry, though. Whole point of external commit is to allow async. Agreement to prohibit proposals by reference in external Commit
I believe there's a small mismatch between the text and the Key Schedule figure. The text says that if there are no PSK proposals, the should be a zero-length string, while the Key Schedule figure seems to indicate that it's a string of zeros of length .
Fixed in
One brief comment, otherwise looks good!


Question: Servers SHOULD NOT increase the QUIC MAX_STREAM_ID limit after sending a GOAWAY frame. <del> Once GOAWAY is sent, the server MUST reject requests sent on streams with an identifier greater than or equal to the indicated last Stream ID.  Clients MUST NOT send new requests on the connection after receiving GOAWAY, although requests might already be in transit.  A new connection can be established for new requests. If the client has sent requests on streams with a Stream ID greater than or equal to that indicated in the GOAWAY frame, those requests are considered rejected (request-cancellation).  Clients SHOULD cancel any requests on streams above this ID.  Servers MAY also reject requests on streams below the indicated ID if these requests were not processed. </del> <ins> Clients MUST NOT send new requests on the connection after receiving GOAWAY; a new connection MAY be established to send additional requests. Some requests might already be in transit.  If the client has already sent requests on streams with a Stream ID greater than or equal to that indicated in the GOAWAY frame, those requests will not be processed and MAY be retried by the client on a different connection. The client MAY cancel these requests.  It is RECOMMENDED that the server explicitly reject such requests (see request-cancellation) in order to clean up transport state for the affected streams. </ins> Requests on Stream IDs less than the Stream ID in the GOAWAY frame <del> might have been processed; their status cannot be known until they are completed successfully, reset individually, or the connection terminates. </del> <ins> might have been processed; their status cannot be known until a response is received, the stream is reset individually, or the connection terminates.  Servers MAY reject individual requests on streams below the indicated ID if these requests were not processed. </ins> Servers SHOULD send a GOAWAY frame when the closing of a connection is known in advance, even if the advance notice is small, so that the

Another attempt to group related concepts in this section which hopefully (This is technically design, because previously-required server behavior is now only recommended.)
Why do I have to explicitly cancel after GOAWAY? Given that GOAWAY already tells the client this, what's the point?
GOAWAY tells the client that those requests aren't going to be serviced, but the streams will continue to exist. If the cleanup period is significant, having the streams open is a bad idea. However, attaching SHOULD to this is unnecessary, I think that we might instead just note that clients are free to do as they please with streams that won't be answered.
Discussed in Tokyo; this doesn't need to be required server behavior, but recommended (or RECOMMENDED) as a method to clean up state. Should have a reminder cross-reference to request rejection.
Lgtm now


Question: "vdaf_verify_key" is the VDAF verification key shared by the aggregators; "agg_id" is the aggregator ID ("0x00" for the Leader and <del> "0x01" for the helper); and "agg_param" is the opaque aggregation parameter distributed to the aggregtors by the collector. </del> <ins> "0x01" for the helper); "agg_param" is the opaque aggregation parameter distributed to the aggregtors by the collector; "public_share" is the public share generated by the client and distributed to each aggregator; and "input_share" is the aggregator's input share. </ins> If either step fails, the aggregator marks the report as invalid with error "vdaf-prep-error".  Otherwise, the value "out" is interpreted

Align with the latest VDAF draft. This requires two minor protocol changes: 02 added a value called the "publicshare" to the VDAF syntax. This is to support Poplar1 (and likely other schemes that need a similar extractability property). To accommodate this, the publicshare field has been added to the Report and ReportShare structures and appended to the AAD for input share encryption. (This may end up being useful for privacy.) 02 added the report count to the aggregate result computation. This is already passed to the Collector in the CollectResp, so we just need to update the aggregate result computation in the draft to match.
Rebased and pushed a minor update: The public share in Report and ReportStore now both have the same length prefix.
Rebased.
This will be VDAF-02 or 03, depending on when we need to cut DAP-02.
VDAF-03 is out, I will send a PR by end of week. URL


Question: by applying an Appraisal Policy for Evidence to assess the trustworthiness of the Attester, and generates Attestation Results for use by Relying Parties.  The Appraisal Policy for Evidence might <del> be obtained from an Endorser along with the Endorsements, or might be obtained via some other mechanism such as being configured in the Verifier by an administrator. </del> <ins> be obtained from an Endorser along with the Endorsements, and/or might be obtained via some other mechanism such as being configured in the Verifier by the Verifier Owner. </ins> The Relying Party uses Attestation Results by applying its own Appraisal Policy to make application-specific decisions such as authorization decisions.  The Appraisal Policy for Attestation <del> Results might, for example, be configured in the Relying Party by an administrator. </del> <ins> Results is configured in the Relying Party by the Relying Party Owner, and/or is programmed into the Relying Party. </ins> 4.1.

Also, my assumption is that all messages, configs and such go over one of the arrows in the figure. There are no back channels for things that are vital to or a major part of attestation. Seems like it would be a poor document if the major parts of attestation are not explicitly carried in the flows depicted.


Question: but not the requested action. The client cannot always know a priori if an Authorized Resource <del> Request will succeed.  If the client repeatedly gets error responses containing AS Creation Hints (cf.  Section 5.1.2 of I-D.ietf-ace- oauth-authz as response to its requests, it SHOULD request a new access token from the authorization server in order to continue communication with the resource server. </del> <ins> Request will succeed.  It must check the validity of its keying material before sending a request or processing a response.  If the client repeatedly gets error responses containing AS Creation Hints (cf.  Section 5.1.2 of I-D.ietf-ace-oauth-authz as response to its requests, it SHOULD request a new access token from the authorization server in order to continue communication with the resource server. </ins> Unauthorized requests that have been received over a DTLS session SHOULD be treated as non-fatal by the RS, i.e., the DTLS session

This change addresses the issue raised by NAME among the authors that it is worth mentioning This is already addressed in the framework document but to avoid implementation errors it seems worth mentioning here as well.
Merged as two other authors have agreed.


Question: The Path Maximum Transmission Unit (PMTU) is the maximum size of the entire IP packet including the IP header, UDP header, and UDP <del> payload.  The UDP payload includes the QUIC packet header, protected payload, and any authentication fields.  The PMTU can depend on path characteristics, and can therefore change over time.  The largest UDP payload an endpoint sends at any given time is referred to as the endpoint's maximum packet size. </del> <ins> payload.  The UDP payload includes one or more QUIC packet headers and protected payloads.  The PMTU can depend on path characteristics, and can therefore change over time.  The largest UDP payload an endpoint sends at any given time is referred to as the endpoint's maximum datagram size. </ins> An endpoint SHOULD use DPLPMTUD (dplpmtud) or PMTUD (pmtud) to determine whether the path to a destination will support a desired <del> maximum packet size without fragmentation.  In the absence of these mechanisms, QUIC endpoints SHOULD NOT send IP packets larger than the smallest allowed maximum packet size. </del> <ins> maximum datagram size without fragmentation.  In the absence of these mechanisms, QUIC endpoints SHOULD NOT send datagrams larger than the smallest allowed maximum datagram size. </ins> <del> Both DPLPMTUD and PMTUD send IP packets that are larger than the current maximum packet size, referred to as PMTU probes.  All QUIC </del> <ins> Both DPLPMTUD and PMTUD send datagrams that are larger than the current maximum datagram size, referred to as PMTU probes.  All QUIC </ins> packets that are not sent in a PMTU probe SHOULD be sized to fit <del> within the maximum packet size to avoid the packet being fragmented or dropped (RFC8085). </del> <ins> within the maximum datagram size to avoid the datagram being fragmented or dropped (RFC8085). </ins> If a QUIC endpoint determines that the PMTU between any pair of local and remote IP addresses has fallen below the smallest allowed maximum <del> packet size of 1200 bytes, it MUST immediately cease sending QUIC </del> <ins> datagram size of 1200 bytes, it MUST immediately cease sending QUIC </ins> packets, except for those in PMTU probes or those containing CONNECTION_CLOSE frames, on the affected path.  An endpoint MAY terminate the connection if an alternative path cannot be found. Each pair of local and remote addresses could have a different PMTU. QUIC implementations that implement any kind of PMTU discovery <del> therefore SHOULD maintain a maximum packet size for each combination of local and remote IP addresses. </del> <ins> therefore SHOULD maintain a maximum datagram size for each combination of local and remote IP addresses. </ins> A QUIC implementation MAY be more conservative in computing the <del> maximum packet size to allow for unknown tunnel overheads or IP </del> <ins> maximum datagram size to allow for unknown tunnel overheads or IP </ins> header options/extensions. 14.2.1. Path Maximum Transmission Unit Discovery (PMTUD; RFC1191, RFC8201) relies on reception of ICMP messages (e.g., IPv6 Packet Too Big <del> messages) that indicate when a packet is dropped because it is larger than the local router MTU.  DPLPMTUD can also optionally use these messages.  This use of ICMP messages is potentially vulnerable to off-path attacks that successfully guess the addresses used on the </del> <ins> messages) that indicate when an IP packet is dropped because it is larger than the local router MTU.  DPLPMTUD can also optionally use these messages.  This use of ICMP messages is potentially vulnerable to off-path attacks that successfully guess the addresses used on the </ins> path and reduce the PMTU to a bandwidth-inefficient value. An endpoint MUST ignore an ICMP message that claims the PMTU has <del> decreased below the minimum QUIC packet size. </del> <ins> decreased below QUIC's smallest allowed maximum datagram size. </ins> The requirements for generating ICMP (RFC1812, RFC4443) state that the quoted packet should contain as much of the original packet as

Addresses . NAME points out in that we use in the transport draft and in the recovery draft. In reading carefully, I realized that in the transport draft was actually historical, and is the more appropriate term. This is an entirely editorial PR, and it's largely simple changes, despite the fact that it looks a bit big. It is a bit subtle though. Sorry about that.
This issue will list a number of minor editorial things that should be checked and likely addressed with some editorial fixes: Section 5.3: "These delays are computed using the ACK Delay field of the ACK frame as described in Section 19.3 of [QUIC-TRANSPORT]." This text implies that the computation of the delay is described in Section 19.3 of QUIC-TRANSPORT. However, I don't think it is described the calculation, only the definition of the field. Please reformulate to imply only field definition not calculation. Section 5.3: "On the first RTT sample for the network path, that sample is used as rttsample. This ensures that the first measurement erases the history of any persisted or default values." I think this intended to cover cases where path changes are detected. But it is not well expressed. Does this need a reformulation and a reference into QUIC-TRANSPORT where it states when such a reset should occur? Section 6.1: "Either its packet number is kPacketThreshold smaller than an acknowledged packet" Nitpicking, assuming no PN gaps in transmission. Does that need a note? Section 6.2.4: "An endpoint MAY send up to two full-sized datagrams containing ack-eliciting packets, to avoid an expensive consecutive PTO expiration due to a single lost datagram or transmit data from multiple packet number spaces." This last part, I assume intended to generate additional datagrams to prevent single loss to impact. However, due to coalescing this is unclear in this context. Section 7: "Endpoints can unilaterally choose a different algorithm to use, such as Cubic ([RFC8312])." I think this sentence should be explicit that in needs to be sender-based algorithms. I think we need to have the requirement on performing congestion control on the sender unless there has been explicit agreement with the receiver that they will do it.


Question: The Path Maximum Transmission Unit (PMTU) is the maximum size of the entire IP packet including the IP header, UDP header, and UDP <del> payload.  The UDP payload includes the QUIC packet header, protected payload, and any authentication fields.  The PMTU can depend on path characteristics, and can therefore change over time.  The largest UDP payload an endpoint sends at any given time is referred to as the endpoint's maximum packet size. </del> <ins> payload.  The UDP payload includes one or more QUIC packet headers and protected payloads.  The PMTU can depend on path characteristics, and can therefore change over time.  The largest UDP payload an endpoint sends at any given time is referred to as the endpoint's maximum datagram size. </ins> An endpoint SHOULD use DPLPMTUD (dplpmtud) or PMTUD (pmtud) to determine whether the path to a destination will support a desired <del> maximum packet size without fragmentation.  In the absence of these mechanisms, QUIC endpoints SHOULD NOT send IP packets larger than the smallest allowed maximum packet size. </del> <ins> maximum datagram size without fragmentation.  In the absence of these mechanisms, QUIC endpoints SHOULD NOT send datagrams larger than the smallest allowed maximum datagram size. </ins> <del> Both DPLPMTUD and PMTUD send IP packets that are larger than the current maximum packet size, referred to as PMTU probes.  All QUIC </del> <ins> Both DPLPMTUD and PMTUD send datagrams that are larger than the current maximum datagram size, referred to as PMTU probes.  All QUIC </ins> packets that are not sent in a PMTU probe SHOULD be sized to fit <del> within the maximum packet size to avoid the packet being fragmented or dropped (RFC8085). </del> <ins> within the maximum datagram size to avoid the datagram being fragmented or dropped (RFC8085). </ins> If a QUIC endpoint determines that the PMTU between any pair of local and remote IP addresses has fallen below the smallest allowed maximum <del> packet size of 1200 bytes, it MUST immediately cease sending QUIC </del> <ins> datagram size of 1200 bytes, it MUST immediately cease sending QUIC </ins> packets, except for those in PMTU probes or those containing CONNECTION_CLOSE frames, on the affected path.  An endpoint MAY terminate the connection if an alternative path cannot be found. Each pair of local and remote addresses could have a different PMTU. QUIC implementations that implement any kind of PMTU discovery <del> therefore SHOULD maintain a maximum packet size for each combination of local and remote IP addresses. </del> <ins> therefore SHOULD maintain a maximum datagram size for each combination of local and remote IP addresses. </ins> A QUIC implementation MAY be more conservative in computing the <del> maximum packet size to allow for unknown tunnel overheads or IP </del> <ins> maximum datagram size to allow for unknown tunnel overheads or IP </ins> header options/extensions. 14.2.1. Path Maximum Transmission Unit Discovery (PMTUD; RFC1191, RFC8201) relies on reception of ICMP messages (e.g., IPv6 Packet Too Big <del> messages) that indicate when a packet is dropped because it is larger than the local router MTU.  DPLPMTUD can also optionally use these messages.  This use of ICMP messages is potentially vulnerable to off-path attacks that successfully guess the addresses used on the </del> <ins> messages) that indicate when an IP packet is dropped because it is larger than the local router MTU.  DPLPMTUD can also optionally use these messages.  This use of ICMP messages is potentially vulnerable to off-path attacks that successfully guess the addresses used on the </ins> path and reduce the PMTU to a bandwidth-inefficient value. An endpoint MUST ignore an ICMP message that claims the PMTU has <del> decreased below the minimum QUIC packet size. </del> <ins> decreased below QUIC's smallest allowed maximum datagram size. </ins> The requirements for generating ICMP (RFC1812, RFC4443) state that the quoted packet should contain as much of the original packet as

Section 7.2: "Endpoints SHOULD use an initial congestion window of 10 times the maximum datagram size (maxdatagramsize), limited to the larger of 14720 bytes or twice the maximum datagram size." "maximum datagram size" is not used in Transport there need to be alignment here of what name to use. Transport has Maximum Packet Size, which appears to match the definition in the appendix of maxdatagram_size.
Thanks for your careful review, NAME -- these are good finds! I've addressed your comments below and in . I'll address point 6 in a separate PR. Section 19.3 has the following text, which does tell how to compute acknowledgement delay from the ACK Delay field: I've replaced "computed" with "decoded" in the recovery document to make it clearer. Coalescing applies to packets, not to datagrams. We've explicitly stated that a sender could send 2 datagrams to avoid any effects of coalescing. I think the text is pretty clear on this: "An endpoint MAY send up to two full-sized datagrams containing ack-eliciting packets". I've added "sender-side" to make the controller more explicit. To your point about making this a sender requirement, that is covered in the transport doc (end of ):
Based on and , labeling this as "editorial"
I think these issues are resolved once the two PRs are completely ready.
Except for the one erronous exchange of packet this looks good.


Question: RETIRE_CONNECTION_ID frames and retransmitted if the packet containing them is lost. <ins> NEW_TOKEN frames are retransmitted if the packet containing them is lost.  No special support is made for detecting reordered and duplicated NEW_TOKEN frames other than a direct comparison of the frame contents. </ins> PING and PADDING frames contain no information, so lost PING or PADDING frames do not require repair.

Is that not implied by the text here?
Kind of, but this text talks about the sender's perspective. Furthermore, checking for duplicates is inherently racy if you're using tokens for new connections while the old connection is still alive.
You know, I think that I put some proposed fixes for this in c016639e39c with rather than this branch. Moved it over here. NAME you approved , so I hope that moving that commit over here works for you.
Sec 13.2 of QUIC Transport explains what to do for the loss of a packet for every stream type except NEW_TOKEN. IMO it's nice but not critical to repair this loss, but I care less about how we resolve it than that we write it up.
Somewhat related question: Does this section fit better in the recovery draft?
I don't think so. This talks about the repair semantics of these frames, not the process of detecting loss. Recovery doesn't care about the distinction between PING and STREAM when it comes to repair.
LGTM, but do we need some text saying that when receiving a NEW_TOKEN frame, you MUST make sure that it's not a duplicate? Otherwise, a client might just save the token twice, and effectively reuse the token.


Question: 12. <del> QUIC assumes that all packets of a QUIC connection, or at least with the same 5-tuple {dest addr, source addr, protocol, dest port, source port}, will receive similar network treatment since feedback about loss or delay of each packet is used as input to the congestion controller.  Therefore, it is not recommended to use different DiffServ Code Points (DSCPs) RFC2475 for packets belonging to the same connection.  If differential network treatment, e.g. by the use of different DSCPs, is desired, multiple QUIC connections to the same server may be used.  However, in general it is recommended to minimize the number of QUIC connections to the same server, to avoid increased overheads and, more importantly, competing congestion control. </del> <ins> QUIC, as defined in RFC9000, has a single congestion controller and recovery handler.  This design assumes that all packets of a QUIC connection, or at least with the same 5-tuple {dest addr, source addr, protocol, dest port, source port} that same the same DiffServ Code Point (DSCP) RFC2475, will receive similar network treatment since feedback about loss or delay of each packet is used as input to the congestion controller.  Therefore, packets belonging to the same connection should use a single DSCP.  Section 5.1 of RFC7657 provides a discussion of DiffServ interactions with datagram transport protocols RFC7657 (in this respect the interactions with QUIC resemble those of SCTP). When multiplexing multiple flows over a single QUIC connection, the selected DSCP value should be the one associated with the highest priority requested for all multiplexed flows. If differential network treatment is desired, e.g., by the use of different DSCPs, multiple QUIC connections to the same server may be used.  However, in general it is recommended to minimize the number of QUIC connections to the same server, to avoid increased overhead and, more importantly, competing congestion control. As in other uses of DiffServ, when a packet enters a network segment that does not support the DSCP value, this could result in the connection not receiving the network treatment it expects.  The DSCP value in this packet could also be remarked as the packet travels along the network path, changing the requested treatment. </ins> 13.

Separates for manageability and this PR for applicability
I actually find this sentence weak: "Therefore it is not recommended to use different DiffServ Code Points (DSCPs) {{?RFC2475}} for ... Considering that QUIC v1 as defined has a single congestion controller and recovery handler and don't treat different DSCP values as separate transport flows I would think that this should be stronger formulated. However, I could see that one could provide a bit more context to this DSCP and single QUIC connections vs multiple QUIC streams discussion by referencing Section 5.1 of URL and be explicit about the point that QUIC v1 is similar to SCTP in regards to the issues raised.
I think the new text do work.


Question: multiple documents. Maintaining multiple documents in the same repository can add <del> overheads that negatively affect individual documents.  For instance, </del> <ins> overhead that negatively affects individual documents.  For instance, </ins> issues might require additional markings to identify the document that they affect.  Also, because editors all have write access to the repository, managing the set of people with write access to a larger

A good start. Would you like to open another PR adding yourself as an author?
Let me know if what I created (experiences + author) needs to be something different. This is a very scary world for me. Ultra light description is next. Barbara


Question: performed on an ongoing basis, resulting in routine, or even event- driven, collection of basic endpoint information. <del> See "Data Attribute Tables and Definitions" for information-specific details. </del> <ins> See data-attribute-table for information-specific details. </ins> 4.2.

We should review the appendices and include the appropriate references to them through the main body of the document.


Question: events: Ready<> occurs when a Connection created with Initiate() or <del> InitiateWithIdempotentData() transitions to Established state. </del> <ins> InitiateWithSend() transitions to Established state. </ins> ConnectionReceived<> occurs when a Connection created with Listen() transitions to Established state.

Notable changes: added control over using multipath (which was a late addition to minset) added a timeout for conn. establishment, separate from the other conn. abort timeout (see ) renamed InitiateWithIdempotentSend into InitiateWithSend, and adjusted the text to recommend declaring idempotence. This addresses the minset function that goes back to TCP's send-with-SYN.
Status: NAME said "LGTM modulo tiny nits" and I think these nits are now addressed. NAME requests something more than just a boolean to enable/disable usage of multiple paths. It seems to me that this needs more discussion, but it also doesn't seem like a show-stopper for the boolean to begin with; I think we can discuss this more after landing this PR. NAME hasn't reacted (or am I missing this), but this has an ok from NAME and NAME In conclusion: I think this is good to go. I'll wait until tomorrow; unless someone speaks up by then, I'll merge this PR.
If you make it a boolean it cannot be used as a selection property, so I do not think that is a good choice. Or how should it be interpreted for the selection?
NAME what do you mean, that it should be a (binary - yes/no) Preference instead? I thought this would be more limiting but I'm fine with this as well.
NAME I meant that it should be a Preference as pointed out in the original comment by NAME I do not understand what a boolean means during selection (is it a requirement or a preference?) I also do not understand what it means in the middle of a connection. You mean you should try and use a single or several subflows for scheduling data, assuming you already have a multipath connection? I guess this is possible, but then the description needs to be more clear that this is what it means. In the appendix about minset your have "Disable MPTCP: "Parallel Use of Multiple Paths" Property." I assume this refers to the Protocol Selection phase? It does not make sense to disable or enable MPTCP in the middle of a connection I think. I guess part of how to specify the property depends on how to interpret this part from the intro to the Managing Connections section: "The application can set and query Connection Properties on a per-Connection basis.


Question: events: Ready<> occurs when a Connection created with Initiate() or <del> InitiateWithIdempotentData() transitions to Established state. </del> <ins> InitiateWithSend() transitions to Established state. </ins> ConnectionReceived<> occurs when a Connection created with Listen() transitions to Established state.

Connection Properties that are not read-only can be set during pre-establishment (see {{selection-props}}), as well as on connections directly using the SetProperty action" I interpreted this as properties set during pre-establishment are selection properties, but maybe this is not the intention as they may need to be expressed differently? If they are not intended as selection properties, we are missing a selection property for multipath I guess.
NAME Ok. That's what I meant, yes - but I agree that's not covered by the description, it really is a selection preference only as it's written now. OK (though you CAN do it with the "real" API, by closing subflows, but this goes beyond the spec'd protocol, and I'm also not sure it's a good idea, especially when limited to only enabling / disabling it altogether). I would have understood this as in your first interpretation: "properties set during pre-establishment are selection properties".
NAME Closing a subflow is not the same as disabling MPTCP to me. You will still be using MPTCP, only with a single subflow. And you can certainly not open a subflow unless MPTCP is already enabled. But seems we now have a common understanding.
NAME ack, we've converged. I just pushed a commit that turns the "Parallel Use of Multiple Paths" property into a Selection property.
these are a few minor changes to apply, and properties to add (e.g. "disable MPTCP")
this is done, yes?
No. But I'm planning to do a PR to address this issue this week.
Note that this also requires closing , which I re-opened with a concrete proposal to address something from minset.
LGTM modulo tiny nitsSorry, missed this until just now. Looks fine with me, I just have a small question and my 2 cents to the multipath discussion (which we can have at a later point).


Question: 2.1. If the application server wishes to provide contact details it MAY <del> include an "sub" (Subject) claim in the JWT.  The "sub" claim SHOULD </del> <ins> include a "sub" (Subject) claim in the JWT.  The "sub" claim SHOULD </ins> include a contact URI for the application server as either a "mailto:" (email) RFC6068 or an "https:" RFC2818 URI.

Found some minor stuff in the draft, and had two questions (below). If I should send those to the list instead, let me know :) Does an application server have to have a unique keypair? E.g lets say I have multiple application servers sitting behind a load balancer, could I just share the keys used for vapid between them? In 5.2: Why is a MAY? If I, as a UA, create a restricted subscription my assumption would be that that is actually checked, right? If the Push Service is not planning to check it anyway, wouldn't it make sense to tell the UA directly by responding w/ an error at restricted subscription creation time?
The concept of an application server does not define the quantity— it's fine for multiple servers to share a single key. Martin added text allowing additional claims () which further clarifies that it's fine to include more specific information, for example which server created the message, which is useful if the push service has means for dealing with this. (E.g. QoS or analytics.) I don't recall why that's a MAY. We certainly shouldn't forward unauthorized messages for restricted subscriptions to the user. /cc NAME The changes themselves look good, thanks! :)
Thanks for the explanation NAME Should I open an issue regarding the ?


Question: directly communicating with an Issuer.  Depending on the attestation, Attesters can store state about a Client, such as the number of overall tokens issued thus far.  As an example of an issuance <del> protocol, in the original Privacy Pass protocol PPSRV, tokens were </del> <ins> protocol, in the original Privacy Pass protocol PPEXT, tokens were </ins> only issued to Clients that solved CAPTCHAs.  In this context, the Attester attested that some client solved a CAPTCHA and the resulting token produced by the Issuer was proof of this fact.

[x] 1. The Reference PPEXT is not cited in the document. seems it could be sited in the into PR [x] 2. I think it would be good to explicitly say that the HTTP authentication protocol is targeted at redemption and the issuer protocol is targeted at issuance. PR [ ] 3. Last paragraph in section 3.2.1 mentions Origin Allow Lists. These allow lists are not specifically mentioned earlier in the document. Can you clarify this. [ ] 4. In section 4.3 and 4.4 is the attester involved in the TokeRequest and TokenResponse messages? Is the attester proxying the communication? It would be good to clarify this in the text. [ ] 5. Section 6 has an incomplete reference. [x] 6. It seems that the Reference to RFC 8446 is not needed. PR [ ] 7. The link - URL does not work perhaps this is the updated one? - URL


Question: For example, the IP proxy could respond with: <del> 4.3. </del> <ins> 4.4. </ins> When using HTTP/2 H2 or HTTP/3 H3, IP proxying requests use HTTP Extended CONNECT.  This requires that servers send an HTTP Setting as

I'll just use a single example here because I think it makes it easier to express my point but the problems might be wider The URI template may include a variable, which is later defined in URL as . The value can only be between 0 through 255, I presume this is a decimal value. What is expected to happen if I send some bad values like: I presume that the recipient would reject the request with a bad path, by virtue of applying the requirement in section 4 that :path SHALL NOT be empty and following the expansion requirements in Section 3 and following those requirements on to Section 4.5. That's a lot of hops to get things right. Is there any easier way to present these?
Agreed, we need better text to specify server handling. For example, we don't currently explicitly that the server has to percent-decode these variables (but we say they have to be percent-encoded). When we add new text about how to extract the variables and decode them, let's also say that the server has to validate that they match requirements and has treat the request as malformed if they don't
NAME can you write up some text?
Appear to look good.