Question: threshold, or the quality of RTT or loss rate is becoming worse) and wants to close the initial path. <del> In Figure fig-example-path-close the server's 1-RTT packets use DCID C1, which has a sequence number of 1, for the first path; the client's 1-RTT packets use DCID S2, which has a sequence number of 2. For the second path, the server's 1-RTT packets use DCID C2, which has a sequence number of 2; the client's 1-RTT packets use CID S3, which has a sequence number of 3.  Note that two paths use different packet number space. The client initiates the path closure for the path with ID 1 by sending a packet with an PATH_ABANDON frame.  When the server received the PATH_ABANDON frame, it also sends an PATH_ABANDON frame in the next packet.  Afterwards the connection IDs in both directions can be retired using the RETIRE_CONNECTION_ID frame. </del> <ins> fig-example-path-close1 illustrates an example of path closing when both the client and the server use non-zero-length CIDs.  For the first path, the server's 1-RTT packets use DCID C1, which has a sequence number of 1; the client's 1-RTT packets use DCID S2, which has a sequence number of 2.  For the second path, the server's 1-RTT packets use DCID C2, which has a sequence number of 2; the client's 1-RTT packets use DCID S3, which has a sequence number of 3.  Note that the paths use different packet number spaces.  In this case, the client is going to close the first path.  It identifies the path by the sequence number of the received packet's DCID over that path (path identifier type 0x00), hence using the path_id 1.  Optionally, the server confirms the path closure by sending an PATH_ABANDON frame using the sequence number of the received packet's DCID over that path (path identifier type 0x00) as path identifier, which corresponds to the path_id 2.  Both the client and the server can close the path after receiving the RETIRE_CONNECTION_ID frame for that path. fig-example-path-close2 illustrates an example of path closing when the client chooses to receive zero-length CIDs while the server chooses to receive non-zero-length CIDs.  Because there is a zero- length CID in one direction, single packet number spaces are used. For the first path, the client's 1-RTT packets use DCID S2, which has a sequence number of 2.  For the second path, the client's 1-RTT packets use DCID S3, which has a sequence number of 3.  Again, in this case, the client is going to close the first path.  Because the client now receives zero-length CID packets, it needs to use path identifier type 0x01, which identifies a path by the DCID sequence number of the packets it sends over that path, and hence, it uses a path_id 2 in its PATH_ABANDON frame.  The server SHOULD stop sending new data on the path indicated by the PATH_ABANDON frame after receiving it.  However, The client may want to repeat the PATH_ABANDON frame if it sees the server continuing to send data. When the client's PATH_ABANDON frame is acknowledged, it sends out a RETIRE_CONNECTION_ID frame for the CID used on the first path.  The server can readily close the first path when it receives the RETIRE_CONNECTION_ID frame from the client.  However, since the client will not receive a RETIRE_CONNECTION_ID frame, after sending out the RETIRE_CONNECTION_ID frame, the client waits for 3 RTO before closing the path. </ins> 11.

This PR is to resolve issue . The description of the path-closing figure is rephrased for better clarity. The pathidtype field in the PATHABANDON frame is also added in the figure to give an idea how the type is used. Moreover, one case for single PN is added (where the client receives zero-length CID while the server receives long CID). According to previous discussion, in the single PN case, only the client needs to send out a PATHABANDON. The server SHOULD stop sending new data on the path indicated by the PATHABANDON frame after receiving it. However, The client may want to repeat the PATHABANDON frame if it sees the server continuing to send data. It is optional for the server to respond with a PATHABANDON after it receives a PATHABANDON frame from the client.
There is one part I am afraid people might feel a little bit hard to follow: the three types of path identifiers in the PATH_STATUS frame. Those three types of path identifiers were introduced in order to be compatible with zero-length CID use cases, so I think we might need two additional example figures (like figure 3 in the current draft), one for (non-zero length CID, zero-length CID) and the other one for (zero-length CID & zero-length CID). Do you think that is a good idea? I can work on those figures if it doesn't complicate the flow of the draft.
This might be indeed useful in the "Example" section.
Yes, please create a PR!
NAME I am editing the path closing figures with zero-length CID and single PN. Is it similar to what you have in mind? {: #fig-example-path-close2 title="Example of closing a path when the server chooses to use zero-length CID"} {: #fig-example-path-close3 title="Example of closing a path when the both client and server choose to use zero-length CIDs."}
In the case of single number space, we use ACK, not ACKMP. But in fact you do not need to draw the ACKs there, there is no special processing of ACKs required. Also, there is no need to wait for an idle timeout, which typically is 10 to 30 seconds. That's too large. Do we really need to send "abandon path" in both directions?


Question: threshold, or the quality of RTT or loss rate is becoming worse) and wants to close the initial path. <del> In Figure fig-example-path-close the server's 1-RTT packets use DCID C1, which has a sequence number of 1, for the first path; the client's 1-RTT packets use DCID S2, which has a sequence number of 2. For the second path, the server's 1-RTT packets use DCID C2, which has a sequence number of 2; the client's 1-RTT packets use CID S3, which has a sequence number of 3.  Note that two paths use different packet number space. The client initiates the path closure for the path with ID 1 by sending a packet with an PATH_ABANDON frame.  When the server received the PATH_ABANDON frame, it also sends an PATH_ABANDON frame in the next packet.  Afterwards the connection IDs in both directions can be retired using the RETIRE_CONNECTION_ID frame. </del> <ins> fig-example-path-close1 illustrates an example of path closing when both the client and the server use non-zero-length CIDs.  For the first path, the server's 1-RTT packets use DCID C1, which has a sequence number of 1; the client's 1-RTT packets use DCID S2, which has a sequence number of 2.  For the second path, the server's 1-RTT packets use DCID C2, which has a sequence number of 2; the client's 1-RTT packets use DCID S3, which has a sequence number of 3.  Note that the paths use different packet number spaces.  In this case, the client is going to close the first path.  It identifies the path by the sequence number of the received packet's DCID over that path (path identifier type 0x00), hence using the path_id 1.  Optionally, the server confirms the path closure by sending an PATH_ABANDON frame using the sequence number of the received packet's DCID over that path (path identifier type 0x00) as path identifier, which corresponds to the path_id 2.  Both the client and the server can close the path after receiving the RETIRE_CONNECTION_ID frame for that path. fig-example-path-close2 illustrates an example of path closing when the client chooses to receive zero-length CIDs while the server chooses to receive non-zero-length CIDs.  Because there is a zero- length CID in one direction, single packet number spaces are used. For the first path, the client's 1-RTT packets use DCID S2, which has a sequence number of 2.  For the second path, the client's 1-RTT packets use DCID S3, which has a sequence number of 3.  Again, in this case, the client is going to close the first path.  Because the client now receives zero-length CID packets, it needs to use path identifier type 0x01, which identifies a path by the DCID sequence number of the packets it sends over that path, and hence, it uses a path_id 2 in its PATH_ABANDON frame.  The server SHOULD stop sending new data on the path indicated by the PATH_ABANDON frame after receiving it.  However, The client may want to repeat the PATH_ABANDON frame if it sees the server continuing to send data. When the client's PATH_ABANDON frame is acknowledged, it sends out a RETIRE_CONNECTION_ID frame for the CID used on the first path.  The server can readily close the first path when it receives the RETIRE_CONNECTION_ID frame from the client.  However, since the client will not receive a RETIRE_CONNECTION_ID frame, after sending out the RETIRE_CONNECTION_ID frame, the client waits for 3 RTO before closing the path. </ins> 11.

If I think about it, the real concern is that client will send a PATHABANDON message, but some time later, due to differences in delay, etc., the server receive data on the same four tuples. How does the server know whether it should create a new path or not? In the single space case, the logical test may be to check the sequence numbers of the packet. If the sequence number of the new packet is greater than that of the path_abandon, then the client is reactivating a path that was abandoned previously. Maybe the client connected again to the same network, after some disconnected interval. The server can start sending on the reactivated path. If the packet number is lower than that of the path abandon, then the server should not reactivate the path. In the multiple space case, if the CID is defined, there is no ambiguity.
ACK works for me. I think we might also want to add a sentence in the Sec. of "one packet number space" explicitly specifying that "for single PN, use ACK instead of ACKMP", and change some texts in the ACKMP frame section that is related to zero-length CID (the current draft says "if the endpoint receives 1-RTT packets with 0-length Connection ID, it SHOULD use Packet Number Space Identifier 0 in ACKMP frames". ). I think in single PN, sending "abandon path" in both directions is helpful. When the client sends "PATHABANDON", it promises not to send non-probing packets in the current activity cycle. It could send probing packets to reactivate the path a moment later if the client thinks the network environment has changed. After sending out "PATHABANDON", the client should still be able to receive packets from the server for a while on that path because there may be the server's inflight packets on that path. It was not until the client sees the server's "PATHABANDON", the client then knows that no more server's data is to be expected except for some out-of-order packets. So after receiving "PATHABANDON", the endpoint can start preparing to free memories and clear path stats allocated for that path. The time interval from seeing "PATHABANDON" to actually releasing relevant resources is going to be an important parameter, and yes, 10-30 seconds is too long.


Question: threshold, or the quality of RTT or loss rate is becoming worse) and wants to close the initial path. <del> In Figure fig-example-path-close the server's 1-RTT packets use DCID C1, which has a sequence number of 1, for the first path; the client's 1-RTT packets use DCID S2, which has a sequence number of 2. For the second path, the server's 1-RTT packets use DCID C2, which has a sequence number of 2; the client's 1-RTT packets use CID S3, which has a sequence number of 3.  Note that two paths use different packet number space. The client initiates the path closure for the path with ID 1 by sending a packet with an PATH_ABANDON frame.  When the server received the PATH_ABANDON frame, it also sends an PATH_ABANDON frame in the next packet.  Afterwards the connection IDs in both directions can be retired using the RETIRE_CONNECTION_ID frame. </del> <ins> fig-example-path-close1 illustrates an example of path closing when both the client and the server use non-zero-length CIDs.  For the first path, the server's 1-RTT packets use DCID C1, which has a sequence number of 1; the client's 1-RTT packets use DCID S2, which has a sequence number of 2.  For the second path, the server's 1-RTT packets use DCID C2, which has a sequence number of 2; the client's 1-RTT packets use DCID S3, which has a sequence number of 3.  Note that the paths use different packet number spaces.  In this case, the client is going to close the first path.  It identifies the path by the sequence number of the received packet's DCID over that path (path identifier type 0x00), hence using the path_id 1.  Optionally, the server confirms the path closure by sending an PATH_ABANDON frame using the sequence number of the received packet's DCID over that path (path identifier type 0x00) as path identifier, which corresponds to the path_id 2.  Both the client and the server can close the path after receiving the RETIRE_CONNECTION_ID frame for that path. fig-example-path-close2 illustrates an example of path closing when the client chooses to receive zero-length CIDs while the server chooses to receive non-zero-length CIDs.  Because there is a zero- length CID in one direction, single packet number spaces are used. For the first path, the client's 1-RTT packets use DCID S2, which has a sequence number of 2.  For the second path, the client's 1-RTT packets use DCID S3, which has a sequence number of 3.  Again, in this case, the client is going to close the first path.  Because the client now receives zero-length CID packets, it needs to use path identifier type 0x01, which identifies a path by the DCID sequence number of the packets it sends over that path, and hence, it uses a path_id 2 in its PATH_ABANDON frame.  The server SHOULD stop sending new data on the path indicated by the PATH_ABANDON frame after receiving it.  However, The client may want to repeat the PATH_ABANDON frame if it sees the server continuing to send data. When the client's PATH_ABANDON frame is acknowledged, it sends out a RETIRE_CONNECTION_ID frame for the CID used on the first path.  The server can readily close the first path when it receives the RETIRE_CONNECTION_ID frame from the client.  However, since the client will not receive a RETIRE_CONNECTION_ID frame, after sending out the RETIRE_CONNECTION_ID frame, the client waits for 3 RTO before closing the path. </ins> 11.

What would be a more appropriate number for this interval? Does it imply that we need to track the packet number of the PATH_ABANDON for a path that is closed? When a path is in a closed state, the server may reject any newly received packets unless it is a probing packet (back to our path initialization process). In this way, it should be OK to forget any info related to that path in the last activity cycle.
In most similar situations, RFC 9000 uses a delay of 3xRTO. Note that in the "simple" case, the client can receive packets from the server on any tuple. There are no resource allocated per path for receiving packets. There will be local resource allocated for sending packets, congestion context for example. But not on for receiving: all packets can be decrypted and processed. If the client knows that it will not send, it can discard the resource allocated for sending without risking a side effect.
I changed the timeout to 3RTO. As the problem is similar to FIN-ACK&FIN-ACK when TCP closes, I kept the ACK in the graph (because the pathidtype=2 refers to the path where the packet is traveling, we want to make sure it is acked before we close the path.). Regarding the resource, I think if we keep a unified receive record, which is not per-path, yes, we can discard the sending resources. But if we have some path stats (e.g. how many packets received in total in this current activity cycle), we need to keep these data structures until we are sure that the peer is not going to send more packets on that path. Indeed, it depends on the implementation, but I feel it is generally helpful to have PATH_ABANDON sent in both directions. What do you think? {: #fig-example-path-close2 title="Example of closing a path when the server chooses to use zero-length CID"} {: #fig-example-path-close3 title="Example of closing a path when both client and server choose to use zero-length CIDs."}
I submitted PR . Let's first have sth that we can start modifying.
addressed by PR
I think there is still a mismatch between the proposed examples and the definition of the pathidtype in Section 11.1 (definition of PATH_ABANDON frame).


Question: stored or transported, as compared to the less efficient text-based form of the original vocabulary. <ins> Through use of CDDL-based integer labels, CoSWID allows for future expansion in subsequent revisions of this specification and through extensions (see model-extension).  New constructs can be associated with a new integer index.  A deprecated construct can be replaced by a new construct with a new integer index.  An implementation can use these integer indexes to identify the construct to parse.  The CoSWID Items registry, defined in iana-coswid-items, is used to ensure that new constructs are assigned a unique index value on a first-come, first-served basis.  This approach avoids the need to have an explicit CoSWID version. </ins> The root of the CDDL specification provided by this document is the rule "coswid" (as defined in tagged):

Addressed the following comments: [Per IETF 110] Add text on the order of native CDDL approach for handling version is used. If a future version of SWID is published which alters the semantics of exists fields, a future version of CoSWID SHOULD (MUST?) use a different tag to represent it. [daw: A new paragraph was added to section 2 detailing how index values are used to support revisions and extensions.] [Per IETF 110] see -16. Use ISO SWID reference for the IANA registry and if desired, used [SEMVER] as an informal reference in the text [daw: This has been done in section 4.1.] [daw: The FIXME markers have been replaced with actual text.] [daw: Section 7 now details the construction of a signed CoSWID. A SHOULD sign requirement was also added to section 7.] [Per IETF 110] We discussed adding language on the order of "This document specifies a data format and an associated integrity mechanism agnostic of a deployment. Application which choose to use CoSWID will need to specify explicit guidance which security properties are needed and under which circumstances." > ** [-15] Section 6. Per "When an authoritative tag is signed, the software [daw: Authenticating the signer is the software provider will require a match between a CoSWID entity and the signer. We are working out a means to do this.] 2 [daw: Not sure which tags this applies to? Signing? All of section 2?] [daw: done.] [daw: This confusing text has been removed.] [daw: done.] [daw: We added a note about this.] [daw: Done.] [daw: Added signature validation as a way.] Regards, Roman


Question: 5.1. The media type is "application/dns-udpwireformat".  The body is the <del> DNS on-the-wire format is defined in RFC1035.  The body MUST be encoded with base64url RFC4648.  Padding characters for base64url MUST NOT be included. </del> <ins> DNS on-the-wire format is defined in RFC1035. When using the GET method, the body MUST be encoded with base64url RFC4648.  Padding characters for base64url MUST NOT be included. When using the POST method, the body is not encoded. </ins> DNS API clients using the DNS wire format MAY have one or more EDNS(0) extensions RFC6891 in the request.

I think that we should specify behaviour for truncated responses with the TC bit more clearly. Right now the text is a little vague. There seem to be three options: mandate the generation of an HTTP error mandate the forwarding of the truncated response explicitly allow either forbid the use of truncated responses and recommend fallback to TCP if the DNS API server is just making DNS requests to another server I think that the draft current vacilates in the direction of 3, but I tend to like 1 or 4. Choosing 4 wouldn't be consistent with the dnsop DNS-over-HTTP draft using DOH though.
is the right answer, so the text should just be stronger about it. If DOH requires or , that means that the DNS server code will need to be heavily reworked to capture these from going out, which seems pointless. DOH clients can act like normal stubs: either they do or don't know about truncation and TC.
I agree - I don't think doh needs to behave differently here than any other datagram based client - i.e. its not a transport error. NAME can you do a pr to clarify?
Will do.


Question: RFC2119. This document assumes that readers are familiar with the terms and <del> concepts that are used in RFC6455 and RFC7252. </del> <ins> concepts that are used in RFC6455, RFC7252, and RFC7641. </ins> The term "reliable transport" only refers to stream-based transport protocols such as TCP.

Added tag for updates: Removed Observe references scattered throughout the draft Added appendix to collect clarifications to RFC7641 in one place
Captured from : There needs to be a section on how resources can be observed over TCP/TLS. Questions include: Do servers need to include a sequence number in notifications, given that TCP/TLS provides reliable, in-order delivery? How do servers throttle the stream of notifications when the resource changes its state more frequently than the server can send notifications? Does a client have to re-register its interest in a resource if it hasn't received a notification for a while but the connection is still up?
URL In a conference call with Klaus, Simon, Bill and myself we discussed the issue and the raised questions. QUESTION 1: Do servers need to include a sequence number in notifications, given that TCP/TLS provides reliable, in-order delivery? The text from the CoAP over Websockets could be re-used. Here is what it could say: Since the TCP provides ordered delivery of messages, the mechanism for reordering detection when observing resources [RFC7641] is not needed. The value of the Observe Option in notifications therefore MAY be empty on transmission and MUST be ignored on reception. The Observe Option still has to be sent since it contains other information as well. QUESTION 2: Does a client have to re-register its interest in a resource if it hasn't received a notification for a while but the connection is still up? We believe it is enough to send keep-alive message for the CoAP over TCP draft (as opposed to send a re-registration message when used over UDP). QUESTION 3: How do servers throttle the stream of notifications when the resource changes its state more frequently than the server can send notifications? TCP offers a flow control mechanism as a means for the receiver to govern the amount of data sent by the sender. This is functionality that can be re-used.
URL (1) -- I agree with the proposed solution. (2) -- we need text that empty messages are no-ops and can be used as a keep-alive mechanism. (3) -- this is a problem that most applications that start using reliable streams run into. Early implementations sometimes ignore the need for proper flow control.


Question: RFC2119. This document assumes that readers are familiar with the terms and <del> concepts that are used in RFC6455 and RFC7252. </del> <ins> concepts that are used in RFC6455, RFC7252, and RFC7641. </ins> The term "reliable transport" only refers to stream-based transport protocols such as TCP.

That is not a reason to add more mechanism (that would also not be in those early implementations), but the solution should be to use the flow control mechanisms we already have. Maybe an LWIG document could have information about flow control support in implementations, e.g., URL
URL Has someone thought about the following setup, that is, will it work with keep-alives only? There is a cluster behind a load balancer. I client sets up a connection, is assigned to one node and starts observing. For some reason the node fails and through a fail-over strategy the client is handed over to another node. All further requests are answered transparently be the new node. However, the Observe relationship got lost...
URL Subissue 1 is covered by the Websockets draft; close this when merged. Subissue 2 is covered by text in the Websockets draft; the failover problem described can be addressed by proper implementation of failover. This may however be costly, so we should have some more discussion about this. Subissue 3 is an implementation quality issue. Just don't implement stream-based without some flow control.
On the 7/6 call with the authors, NAME agreed to review and determine whether all issues were addressed.
This issue does not include a question about the use of confirmable messages for notifications in to determine client aliveness and interest: A notification can be confirmable or non-confirmable ... An acknowledgement message signals to the server that the client is alive and interested in receiving further notifications; if the server does not receive an acknowledgement in reply to a confirmable notification, it will assume that the client is no longer interested and will eventually remove the associated entry from the list of observers This is inappropriate for CoAP over reliable transports.
The phrasing is a bit unfortunate. What is meant is "if the confirmable notification times out". The same would be true in TCP -- if the connection times out, you remove the interests. We could clarify this in a section of CoAP-TCP about the impact of no longer sending back and forth acknowledgements.
Discussing the scope of this issue with the authors. This probably needs a more complete treatment rather than small references like: Since the TCP protocol provides ordered delivery of messages, the mechanism for reordering detection when observing resources [RFC7641] is not needed.


Question: RFC2119. This document assumes that readers are familiar with the terms and <del> concepts that are used in RFC6455 and RFC7252. </del> <ins> concepts that are used in RFC6455, RFC7252, and RFC7641. </ins> The term "reliable transport" only refers to stream-based transport protocols such as TCP.

The value of the Observe Option in notifications MAY be empty on transmission and MUST be ignored on reception.
My reading of the discussion thread gives me the impression that we had closed the initial set of questions. The subsequently raised issue regarding the wording in RFC 7641 I am wondering whether there is any change needed. We definitely are not going to change RFC 7641. I personally don't think that the highlighted text from RFC7641 will be wrongly implemented. I would suggest to close issue.
NAME - this would be - any comments on that pull request?


Question: 5.3. <ins> A server operating in Shared Mode uses PaddedServerNameList.sni as if it were the "server_name" extension to finish the handshake.  It SHOULD pad the Certificate message, via padding at the record layer, such that its length equals the size of the largest possible Certificate (message) covered by the same ESNI key. 5.4. </ins> The Hidden Server ignores both the "encrypted_server_name" and the "server_name" (if any) and completes the handshake as usual.  If in Shared Mode, the server will still know the true SNI, and can use it for certificate selection.  In Split Mode, it may not know the true <del> SNI and so will generally be configured to use a single certificate </del> <ins> SNI and so will generally be configured to use a single certificate. </ins> communicating-sni describes a mechanism for communicating the true <del> SNI to the hidden server.  [[OPEN ISSUE: Do we want "encrypted_server_name" in EE?  It's clearer communication, but gets in the way of stock servers.]] </del> <ins> SNI to the hidden server. Similar to the Shared Mode behavior, the hidden server in Split Mode SHOULD pad the Certificate message, via padding at the record layer such that its length equals the size of the largest possible Certificate (message) covered by the same ESNI key. [[OPEN ISSUE: Do we want "encrypted_server_name" in EE?  It's clearer communication, but gets in the way of stock servers.]] </ins> 6.

Current text says: the "encryptedservername" extension. However, I am not sure if this is the desired behavior. I would rather suggest encrypting even when the hostname exceeds the padded_length. Having some protection is better than none. The issue is that in certain deployments it is impossible to guess what the maximum length of the hostname will be. Consider . It uses a wildcard certificate. Anybody can add a new hostname of any length by creating a new Github account (it might be true that Github some limitation on the length, but that does not necessarily mean that Github shares the maximum length information with the fronting CDN, assuming that it uses a CDN).
I have filed that fixes another issue (it's just a clarification of an open issue) related to wildcard delegation.
Technically, it is possible to guess the maximum length of the hostname, as that maximum textual representation length is defined as 253 bytes per RFC 1034.
Yes. So the question is if a CDN that has a wildcard mapping needs to set to 253 (since current text is a MUST NOT for sending a server name longer than the paddedlength), or if we should introduce a different rule.
How about something like: padded_length : The length to pad the ServerNameList value to prior to encryption. This value SHOULD be set to the largest ServerNameList the fronting server expects to support rounded up the nearest multiple of 16. If the fronting server supports wildcard names, it SHOULD set this value to 256.
NAME Thank you for the suggestion. I was feeling uneasy (and am still feeling a bit) about requiring the client to send an ESNI extension as large as ~300 bytes, assuming that CDN's would have at least one wildcard mappings. But it's about the first packet sent from the client, and we typically have enough room even when 0-RTT data is involved. So I think that we can live with that.
To be
Thank you for working on this! LGTM aside from the two comments shown below.Sorry, I missed the padding thing, so you'll need to adjust


Question: If the argument is "Nothing" or contains multiple nodes, the result is "Nothing". <del> Note: a Singular Query may be used anywhere where a ValueType is </del> <ins> Note: a singular query may be used anywhere where a ValueType is </ins> expected, so there is no need to use the "value" function extension <del> with a Singular Query. </del> <ins> with a singular query. </ins> 2.6.9.

Also, delete a term which is used only in the definition of the next term. Fixes URL
I only found the two occurrences you suggested changing. If there are others, please let me know!
Sometimes the spec uses "Singular Query" and sometimes "singular query". We should be consistent. (If we decide to use lower case, it's probably best to address this issue after PR has been merged, since that PR adds some usages of "Singular Query".) Also, there is one instance of "Logical context", which I think would be better uncapitalised ("logical context").
Thanks.


Question: Specify a Local Endpoint using a STUN server: <del> 6.1.4. </del> <ins> 6.1.5. </ins> Specify a Local Endpoint using an Any-Source Multicast group to join on a named local interface:

Explain the different use-cases on specifying interfaces to
There's something obvious I'm not seeing: if I want to specify a multicast or link-local address for an endpoint, why not simply specify that address? What's the use of adding the interface into it? Some addresses will inherently limit interfaces; I thought interface preference was about preferring wifi to 4G, etc.
Like, in section 6.1.1:
Multicast groups can be scoped (see RFC7346), thus, may only be available on certain interfaces or even have different meanings based on the interface. So for Interface- and Link-Local scope, specifying the interface is strictly required. For others use cases (like coping with non-unique use of RFC1918 addresses) this may also be helpful.
Why does the API have both the ability to say LocalSpecifier.WithInterface and to set interface requirements on TransportProperties? Why not just keep the latter and remove the former?
There's history here: LocalSpecifier.WithInterface predates explicitly setting the interface name in interface requirements. There might be reasons to keep this: LocalSpecifier is more likely to show up in application UI than in transport properties. Any text proposed to keep both would need to have an unambiguous way to resolve conflicts between the two. This might be a source of hard-to-debug errors.
To discuss next interim


Question: where Ns is as defined in OPRF, Section 4. The Issuer generates an HTTP response with status code 200 whose body <del> consists of TokenResponse, with the content type set as "message/ token-response". </del> <ins> consists of TokenResponse, with the content type set as "application/ private-token-response". </ins> 5.3.

I also moved from the message namespace to the application namespace. The difference is helpfully summarized .
I see in the current draft that they register and . Since "token" is a very broad term, I'm wondering if something slightly more specific to Privacy Pass such as and might be reasonable?
If we make it more specific, it should be "private" instead of "privacy", to be "private-token" and align with the auth scheme. There's a fair amount of deployment on these types today, so this would be a relatively large change, or servers would need to tolerate both versions.
I'm in favor of making this change and having issuers support both for a little while.
Cool, that would work. NAME want to make the proposed update?
Will do!
NAME PR's up!
Looks good!


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

It's no longer normative and it's in a single section. I only moved text so far, and not as far as NAME suggested. I can go farther here or in a follow-up PR.
NAME I would like to merge this. WDYT?
Can we merge this soon. I'm worried about it developing conflicts.
Yep, NAME lost the chance to fix the PR. We are - of course - still open for editorial improvements in the form of new pull requests though.
calls them "exemplary" but 13.2.4 has MUST in it.
For reference, this refers to and in the editor's copy. I'm in favour of striking the exemplary note and saying that while the recovery draft is advisory, this document depends on implementations following something like what is recommended.
The specific MUSTs aren't really about the ACK algorithm per se, but about state endpoints will have to maintain for other reasons that are typically folded into your loss recovery code. If an implementation is unable to do duplicate detection for a packet number range, it MUST fail toward rejecting all packets, not toward accepting potential duplicates. An implementation must track the greatest packet number ever received, for use in recovering future packet numbers. In fact, the first requirement is discussed in 12.3 and could probably be dropped here. The second isn't actually called out (MUST) in 17.1, but could easily be moved there.
I think I'm inclined towards reorganizing the text and putting all the 'exemplary' parts into one section(ie: "Limiting ACK Ranges") and moving the normative text either into "Managing ACK Ranges" or elsewhere in the draft.
I thought I could clean this up fairly quickly, but I think a fair number of paragraphs need to move, including some of NAME suggestions. I'm happy to try to improve this in a few days if no one else has beaten me to it.
Anyone want to help NAME out and take this on?
Sorry about dropping this one. I'm fine with it, and happy to make editorials one later.Thanks Ian. When you lay it out like this, it seems so obvious. I checked that we don't have citations for {{ack-tracking}}, so this works nicely. If you care about the "MAY", then we can fix that in another PR.


Question: be perceived as creating a conflict of interest for a particular MLS DE, that MLS DE SHOULD defer to the judgment of the other MLS DEs. <del> 17.9. </del> <ins> 17.10. </ins> This document registers the "message/mls" MIME media type in order to allow other protocols (e.g., HTTP RFC7540) to convey MLS messages.

As discussed in the virtual interim 2022-12-16, it is possible that extensions might be tempted to re-use HPKE public keys created for MLS. Even within MLS, we have two different public-key encryption cases, Welcome and Commit (though these currently use different keys). Currently, for Commit encryption, the HPKE parameter is set to the group context. The content of is actually undefined for Welcome encryption (!) This PR makes the following changes: Define general and functions that populte the HPKE parameter with an encoded label and context Apply these to Commit and Welcome encryption: Commit: label="UpdatePathNode", context= Welcome: label="Welcome", context= Add an IANA registry of public-key encryption labels (as for signing) There is also a bit of reorganization of the Ciphersuites section to split it into three subsections.
Note that any previous analysis of MLS had to take this particular reuse into account. This can't be the case for any arbitrary extensions reusing the key. So if MLS uses an extension that reuses the key, none of the existing analysis applies, which is a much bigger issue. This said, this reuse did decrease security -- it weakened FS in that a joiner had to hold on to their HPKE leaf key, which also allowed to decrypt the init secret from the welcome message, long after joining.
I think this captures what we discussed during the interim. FWIW, I'm wondering if we didn't have a domain separation issue in the past when we only had one HPKE public key in KeyPackages and used it for both the Welcome subsequently for UpdatePath as well. Either way, I think this is a good defense-in-depth mechanism.


Question: Claims are assertions that represent characteristics of an Attester's Target Environment. <del> Claims are part Conceptual Message and are, for example, used to appraise the integrity of Attesters via a Verifiers.  The other </del> <ins> Claims are part of a Conceptual Message and are, for example, used to appraise the integrity of Attesters via Verifiers.  The other </ins> information elements in this section can be expressed as Claims in any type of Conceptional Messages. <ins> _optional_ Event Logs accompany Claims by providing event trails of security- critical events in a system.  The primary purpose of Event Logs is to support Claim reproducibility by providing information on how Claims originated. </ins> _mandatory_ Reference Values as defined in I-D.ietf-rats-architecture.  This

… in diagram. Also fixed "randomized" (was British English before). Signed-off-by: Michael Eckel
An handle mustbe created/generated before it can be distributed. Adding a generateHandle() call would also strengthen understanding by readers.
Based on URL In the sequence diagram, some elements in the bracket are not defined in the “Information Elements” section, such as targetEnvironment, collectedClaims, eventLog. Should these elements be defined?
I totally agree. These elements should either be put into Information elements (preferred), or at least be mentioned in the text. Hi Henk, I've reviewed the reference interaction models I-D recently, I hope the comments below can help improve the draft before the IETF110 draft submission cut-off. Section 3 Disambiguation Comment > This section is talking about the disambiguation of terminology, so I suggest making it a sub-section of Section 2 Terminology. Examples of these types of co-located environments include: a Trusted Execution Environment (TEE), Baseboard Management Controllers (BMCs), as well as other physical or logical protected/isolated/shielded Computing Environments (e.g. embedded Secure Elements (eSE) or Trusted Platform Modules (TPM)). Comment > About "these types of co-located environments", The previous sentences are about the Verifier and Attester don't need to be remote. So "these" is weird here, because here is about the attesting environment and target environment. Section 5 Direct Anonymous Attestation Comment > I think it's better to move this section to the bottom of the draft. DAA doesn't introduce a new information elements, and only augments the scope/definition of Attester Identity and Authentication Secret IDs, describing it after the introduction of all the 3 basic interaction models would be better. Putting DAA in the middle makes me feel the basic interaction models rely upon DAA, but actually it's not. This document extends the duties of the Endorser role as defined by the RATS architecture with respect to the provision of these Attester Identity documents to Attesters. The existing duties of the Endorser role and the duties of a DAA Issuer are quite similar as illustrated in the following subsections.


Question: Claims are assertions that represent characteristics of an Attester's Target Environment. <del> Claims are part Conceptual Message and are, for example, used to appraise the integrity of Attesters via a Verifiers.  The other </del> <ins> Claims are part of a Conceptual Message and are, for example, used to appraise the integrity of Attesters via Verifiers.  The other </ins> information elements in this section can be expressed as Claims in any type of Conceptional Messages. <ins> _optional_ Event Logs accompany Claims by providing event trails of security- critical events in a system.  The primary purpose of Event Logs is to support Claim reproducibility by providing information on how Claims originated. </ins> _mandatory_ Reference Values as defined in I-D.ietf-rats-architecture.  This

Comment > Without DAA, I think the Endorser also needs to provision the Attester Identity to Attesters. And as I understand, the DAA Issuer is a supply chain entity before the Attester being shipped, so it is the Endorser when DAA is used, right? If yes, then in the next sentence, the comparison between Endorser and DAA Issuer doesn't make sense to me. Section 5.1 Endorsers Comment > Does this section have difference with the definition of Endorser in architecture draft? If not, is it necessary to keep this section? Comment > This section only describes the Layered Attestation, but the scope of Endorsement is more than what's described here. Endorsement indicates the Attester's various capabilities such as Claims collection and Evidence signing. For other situations than Layered Attestation, the Endorser and Endorsement are also needed. So why only mention Layered Attestation here? I don't see any special relationship between DAA and Layered Attestation. Section 5.2 Endorsers for Direct Anonymous Attestation In order to enable the use of DAA, an Endorser role takes on the duties of a DAA Issuer in addition to its already defined duties. DAA Issuers offer zero-knowledge proofs based on public key certificates used for a group of Attesters [DAA]. Effectively, these certificates share the semantics of Endorsements, with the following exceptions: Comment > In the first sentence, I suggest saying that "a DAA Issuer takes on the role of an Endorser". o The associated private keys are used by the DAA Issuer to provide an Attester with a credential that it can use to convince the Verifier that its Evidence is valid. To keep their anonymity the Attester randomizes this credential each time that it is used. Comment > How to understand "Evidence is valid"? Does it mean the Evidence is sent from an authentic Attester and not tampered during the conveyance? Or does it mean the Evidence comes from a RoT and is trustable (although the Evidence can diverge from the Reference Values)? Comment > When saying "Attester randomizes this credential", how many credentials does an Attester have?


Question: Claims are assertions that represent characteristics of an Attester's Target Environment. <del> Claims are part Conceptual Message and are, for example, used to appraise the integrity of Attesters via a Verifiers.  The other </del> <ins> Claims are part of a Conceptual Message and are, for example, used to appraise the integrity of Attesters via Verifiers.  The other </ins> information elements in this section can be expressed as Claims in any type of Conceptional Messages. <ins> _optional_ Event Logs accompany Claims by providing event trails of security- critical events in a system.  The primary purpose of Event Logs is to support Claim reproducibility by providing information on how Claims originated. </ins> _mandatory_ Reference Values as defined in I-D.ietf-rats-architecture.  This

1) Can a DAA Issuer have multiple key pairs and use them for one Attester? 2) Can a DAA Issuer use one key pair to generate multiple credentials for one Attester? o A credential is conveyed from an Endorser to an Attester in combination with the conveyance of the public key certificates from Endorser to Verifier. Comment > Is there another way to convey the public key certificate, for example, can the public key certificates be conveyed from Endorser to Attester first and then from Attester to Verifier? The zero-knowledge proofs required cannot be created by an Attester alone - like the Endorsements of RoTs - and have to be created by a trustable third entity - like an Endorser. Due to that semantic overlap, the Endorser role is augmented via the definition of DAA duties as defined below. This augmentation enables the Endorser to convey trustable third party statements both to Verifier roles and Attester roles. Comment > For "the definition of DAA duties as defined below", what is the definition of DAA duties? Comment > In the last sentence, the Endorsement with its original definition is the third party statement for Verifier and Attester, isn't it? So, "augmentation" isn't the correct expression. Section 6 Normative Prerequisites Attester Identity: The provenance of Evidence with respect to a distinguishable Attesting Environment MUST be correct and unambiguous. Comment > The Attester Identity is to identify which Attester the Evidence comes from. But if the Attester has multiple Attesting Environments, what should be the Attester Identity? Comment > The TPM's AIK certificate is one kind of Attester Identity, right? Attestation Evidence Authenticity: Attestation Evidence MUST be correct and authentic. Comment > Is it appropriate to say "correct Evidence"? If saying so, I think it means that the Evidence satisfies the Attestation Policy for Evidence. Authentication Secret: An Authentication Secret MUST be available exclusively to an Attester's Attesting Environment. The Attester MUST protect Claims with that Authentication Secret, thereby proving the authenticity of the Claims included in Evidence. The Authentication Secret MUST be established before RATS can take place. Comment > Does the Authentication Secret represent the identity of the Attesting Environment?


Question: Claims are assertions that represent characteristics of an Attester's Target Environment. <del> Claims are part Conceptual Message and are, for example, used to appraise the integrity of Attesters via a Verifiers.  The other </del> <ins> Claims are part of a Conceptual Message and are, for example, used to appraise the integrity of Attesters via Verifiers.  The other </ins> information elements in this section can be expressed as Claims in any type of Conceptional Messages. <ins> _optional_ Event Logs accompany Claims by providing event trails of security- critical events in a system.  The primary purpose of Event Logs is to support Claim reproducibility by providing information on how Claims originated. </ins> _mandatory_ Reference Values as defined in I-D.ietf-rats-architecture.  This

Comment > How to understand the Authentication Secret, and is it necessary all the time? For example, in our implementation, during the router booting up, the BIOS measures the BootLoader and records the measured hash value into the TPM, and the BootLoader measures the OS Kernel and records the measured hash value into the TPM as well. From the Layered Attestation perspective, I think (BIOS + TPM) is the Attesting Environment and (BootLoader + TPM) is also the Attesting Environment. But the Claims (measured hash values) aren't protected separately, and they finally becomes the Evidence (TPM Quote) and it's only protected by the TPM's AIK. So, what is the Authentication Secret? Section 7 Generic Information Elements Attester Identity ('attesterIdentity'): mandatory A statement about a distinguishable Attester made by an Endorser without accompanying evidence about its validity - used as proof of identity. Comment > Previous section says "Attester Identity" is about "a distinguishable Attesting Environment", and here says it's about "a distinguishable Attester". Comment > How to understand "without accompanying evidence about its validity"? Attester Identity ('attesterIdentity'): mandatory In DAA, the Attester's identity is not revealed to the verifier. The Attester is issued with a credential by the Endorser that is randomized and then used to anonymously confirm the validity of their evidence. The evidence is verified using the Endorser's public key. Comment > I think here means the DAA credential represents the Attester Identity. Comment > There is ambiguity of "that is randomized", does it mean randomized Endorser or randomized credential? Comment > For "confirm the validity of their evidence", what does "their" refer to? And what does "the validity of evidence" mean? Authentication Secret IDs ('authSecID'): mandatory A statement representing an identifier list that MUST be associated with corresponding Authentication Secrets used to protect Evidence. Comment > Previous section says "Authentication Secret" is used to protect Claims, but here says it's used to protect Evidence. Comment > As I understand, if Authentication Secret represents the identity of Attesting Environment, then it's not mandatory, at least in our implementation.


Question: Claims are assertions that represent characteristics of an Attester's Target Environment. <del> Claims are part Conceptual Message and are, for example, used to appraise the integrity of Attesters via a Verifiers.  The other </del> <ins> Claims are part of a Conceptual Message and are, for example, used to appraise the integrity of Attesters via Verifiers.  The other </ins> information elements in this section can be expressed as Claims in any type of Conceptional Messages. <ins> _optional_ Event Logs accompany Claims by providing event trails of security- critical events in a system.  The primary purpose of Event Logs is to support Claim reproducibility by providing information on how Claims originated. </ins> _mandatory_ Reference Values as defined in I-D.ietf-rats-architecture.  This

Authentication Secret IDs ('authSecID'): mandatory In DAA, Authentication Secret IDs are represented by the Endorser (DAA issuer)'s public key that MUST be used to create DAA credentials for the corresponding Authentication Secrets used to protect Evidence. In DAA, an Authentication Secret ID does not identify a unique Attesting Environment but associated with a group of Attesting Environments. This is because an Attesting Environment should not be distinguishable and the DAA credential which represents the Attesting Environment is randomised each time it used. Comment > In my understanding, here says that the DAA credential identities the Attesting Environment. Compared with the description in the "Attester Identity" part, what does the DAA credential represent actually? Reference Claims ('refClaims') mandatory Reference Claims are components of Reference Values as defined in [I-D.ietf-rats-architecture]. [Editor's Note: Definition might become obsolete, if replaced by Reference Values. Is there a difference between Claims and Values here? Analogously, why is not named Reference Claims in the RATS arch?] Comment > I suggest using Reference Values to keep consistent with the RATS arch. Reference Claims are used to appraise the Claims received from an Attester via appraisal by direct comparison. Comment > "Direct comparison" isn't the correct expression, the comparison can have other rules. Claim Selection ('claimSelection'): optional A statement that represents a (sub-)set of Claims that can be created by an Attester. Claim Selections can act as filters that can specify the exact set of Claims to be included in Evidence. An Attester MAY decide whether or not to provide all Claims as requested via a Claim Selection. Comment > The "all Claims" may be ambiguous, I'd like to double check, does it refer to all Claims that the Attester can create or refer to all Claims requested in the Claim Selection? Section 8.1 Challenge/Response Remote Attestation Comment > In the sequence diagram, some elements in the bracket are not defined in the "Information Elements" section, such as targetEnvironment, collectedClaims, eventLog. Should these elements be defined? Section 9 Additional Application-Specific Requirements Depending on the use cases covered, there can be additional requirements. An exemplary subset is illustrated in this section.


Question: Claims are assertions that represent characteristics of an Attester's Target Environment. <del> Claims are part Conceptual Message and are, for example, used to appraise the integrity of Attesters via a Verifiers.  The other </del> <ins> Claims are part of a Conceptual Message and are, for example, used to appraise the integrity of Attesters via Verifiers.  The other </ins> information elements in this section can be expressed as Claims in any type of Conceptional Messages. <ins> _optional_ Event Logs accompany Claims by providing event trails of security- critical events in a system.  The primary purpose of Event Logs is to support Claim reproducibility by providing information on how Claims originated. </ins> _mandatory_ Reference Values as defined in I-D.ietf-rats-architecture.  This

Comment > Here starts to talk about "additional requirements", but I wonder there is no other places in this draft talking about requirement, so what are the basic requirements? Regards & Thanks! Wei Pan


Question: may be using a version of WebTransport extension that is different from the one used by the server. <ins> In addition to the setting above, the server MUST send a SETTINGS_MAX_WEBTRANSPORT_SESSIONS parameter indicating the maximum number of concurrent sessions it is willing to receive.  The default value for the SETTINGS_MAX_WEBTRANSPORT_SESSIONS parameter is "0", meaning that the server is not willing to receive any WebTransport sessions. </ins> 3.2. RFC8441 defines an extended CONNECT method in Section 4, enabled by

Capsule design team output. Minimal changes to HTTP/3, which was already using capsules and is now joined by . Same content as draft PR, thank you to those who have already reviewed!
Does this actually with a no-op, or are we supposed to discuss that at 115? Otherwise LGTM.
It as a no-op with the exception of one bullet point that we did want to address, that got split out into , which we'll discuss at 115 separately from this PR.
Should the protocol share framing semantics with the HTTP/2 draft so that it is easy/easier to take datagrams or streams and put them on the CONNECT stream? Should it be possible to use that mechanism, or should it instead be forbidden? As much as possible, it would be desirable to have the forwarding logic be fairly uniform across different protocol versions. Right now, we have two almost completely different protocols.
I was discussing this with NAME and NAME What happens when an H3 WT server receives "version independent" WT framing on its CONNECT stream. Since WT over H3 requires H3 datagrams, then there is no need to fold datagrams into the CONNECT stream. There shouldn't be a need to fold streams either, unless you want to defeat QUIC stream limits :) Allowing this would also increase work to implement an H3 only WT client/server: you have to re-implement QUIC over an HTTP byte-stream just in case the peer decides to send you "version independent" WT. Right now I think they are totally different and never the twain shall meet. Proxies can convert between the two versions. If we did that, should we have different upgrade tokens?
Is this issue still relevant now that we have the outcome of HTTP Datagram Design Team?
NAME gentle ping
Actually never mind, this is blocked on the capsule design team - the output of that design team will decide on whether the h2 capsules are allowed in h3 or not
The H3 draft by its nature allows for the parallel processing of multiple WT sessions and also the intermixing of normal H3 request with WT. Server endpoints may wish to negotiate or disable this behavior. Clients can simply choose not to do either kind of pooling if they don't want to. There's already a PR open () with a design idea.


Question: may be using a version of WebTransport extension that is different from the one used by the server. <ins> In addition to the setting above, the server MUST send a SETTINGS_MAX_WEBTRANSPORT_SESSIONS parameter indicating the maximum number of concurrent sessions it is willing to receive.  The default value for the SETTINGS_MAX_WEBTRANSPORT_SESSIONS parameter is "0", meaning that the server is not willing to receive any WebTransport sessions. </ins> 3.2. RFC8441 defines an extended CONNECT method in Section 4, enabled by

I'd like to propose a different model than the one in : The server sends the maximum WebTransport Session ID, or since 0 is a valid value, it's really the minimum invalid WebTransport Session ID. To indicate WT is not supported, server sends 0. To allow for only 1 session ever, server sends 4, and never updates it. To allow for only 1 session at a time, server sends 4, and updates it by 4 as each session closes/resets. To allow for N parallel sessions, server sends 4 * N. and updates as sessions close/reset. This mirrors H3 PUSH, and requires at least one more frame (MAXWTSESSIONID). Perhaps it would also require CANCELWT_SESSION? A client need only declare that it supports webtransport, and even that could be optional. The server will know if it receives a CONNECT with :protocol=webtransport.
I wanted to have a negotiation mechanism in , but my conclusion after talking with NAME about it was that we should not do negotiation, and servers should just reject extra streams with a 400 (or maybe even a RESET_STREAM) if they ever see more sessions than they expect; meaning it's on the clients to know if they can pool or not.
Though we may want a more specific 4XX error code so the client knows it should retry in a non-pooled connection
That's certainly a lot simpler than session credits ;) The cost of at least an RTT for a client that tries to pool against a server that can't handle it seems somewhat high. I guess it depends what the common client pooling strategies are and how many servers don't support pooling.
NAME since it's looking like the JavaScript API will provide a way to disable pooling, I expect that the scenario of pooling-attempted-but-rejected will be quite rare, so a round trip cost should be acceptable
I'm also considering use cases for WT which are not tied to the JS API.
NAME that's interesting - and those use-cases won't have a similar mechanism to disable pooling? I suspect they'll need a way to get the WT server's hostname somehow, and having config properties attached to that (such as disable_pooling) could be useful?
NAME : the opposite -- the clients may attempt pooling to servers that might or might not support it. You can't tell from a hostname if it supports pooling.


Question: may be using a version of WebTransport extension that is different from the one used by the server. <ins> In addition to the setting above, the server MUST send a SETTINGS_MAX_WEBTRANSPORT_SESSIONS parameter indicating the maximum number of concurrent sessions it is willing to receive.  The default value for the SETTINGS_MAX_WEBTRANSPORT_SESSIONS parameter is "0", meaning that the server is not willing to receive any WebTransport sessions. </ins> 3.2. RFC8441 defines an extended CONNECT method in Section 4, enabled by

NAME how did the client get the hostname in the first place? I'm suggesting to carry pooling_support next to that.
Actually, let's go back to JS for a second. The people who write JS at Facebook are very unlikely to know if the edge server terminating their connection supports pooling, or that configuration could change over time.
(I appreciate the irony of me saying this as a Googler, but) should the JS people talk to the edge people? I agree that this shouldn't fail, but it being inefficient seems reasonable - these teams should talk if they're trying to reach good performance.
I think my main problem with is that most people who want to disallow pooling want to exclude not only other WebTransport sessions, but also general HTTP traffic. was written with that assumption in mind.
Ok, MAXWTSESSION_ID doesn't handle that case, so it may be an over-engineered solution to the wrong problem.
As I said in the meeting, I don't think that we should have any signals for dedicated connections from either client or server. Yutaka made the point that the client can decide to make a connection dedicated after seeing the server settings. It doesn't need to signal its intent (and signaling would have negative privacy consequences potentially). I agree with this observation. A server needs to support HTTP if we're using HTTP. So pooling with h3 is already a settled matter. If the server doesn't want to answer requests, it can use 406 or 421 or other HTTP mechanisms to tell the client to go away. More generally, the server can just not provide links to that server, such that it might have to respond to GET/OPTIONS/POST/etc. The question then becomes managing resource limits on the server. Having a way to limit the number of WebTransport sessions is a good thing and I believe that will be sufficient for this. Thus, I'm a supporter of option 3: MAXWTSESSIONS or similar.
I agree that we should have limits of how many WT can be active at the same time on a connection. It should also define what happens if the limit is exceeded. Should a client open another QUIC connection to the same server or should it fail? Probably it should be former, but that should also have limits defined (6 parallel QUIC connection, may be too much?


Question: may be using a version of WebTransport extension that is different from the one used by the server. <ins> In addition to the setting above, the server MUST send a SETTINGS_MAX_WEBTRANSPORT_SESSIONS parameter indicating the maximum number of concurrent sessions it is willing to receive.  The default value for the SETTINGS_MAX_WEBTRANSPORT_SESSIONS parameter is "0", meaning that the server is not willing to receive any WebTransport sessions. </ins> 3.2. RFC8441 defines an extended CONNECT method in Section 4, enabled by

HTTP/1.1 have the 6 parallel connection limit).
Chair: discussed at IETF 113, consensus in room to change the WT SETTING to carry the number of concurrent WT sessions allowed on this h3 connection
Note that all of the below works when you swap "server" and "client". I wanted to focus on a poor Javascript client implementation, but it's equally possible to run into these cases with a poor server implementation. Let's say that you have a Http3Transport session that shares a connection with HTTP/3 or another Http3Transport session. The client has limited buffer space and hypothetically advertises MAXDATA of 1MB for the connection. If the server pushes 1MB of unprocessed data over a Http3Transport session, then it will prevent the server from sending data over the connection, including HTTP/3 responses and other Http3Transport sessions. This can occur if the application does not accept all remote-created streams or does not fully read every stream. This will be VERY easy for a developer to mess up. It can also occur if the application can not process data faster than it is received. In my case, the server creates unidirectional streams and pushes a large amount of media over them. The flow control limit would be hit if the Javascript application: Only accepts bidirectional streams (ex. initialization) Does not accept a unidirectional stream (ex. error or teardown) Does not fully read or abort every stream (ex. parsing error) Is not able to parse the media fast enough (ex. underpowered). This is mostly intended behavior, otherwise these "bugs" would cause unbounded memory usage. However, the blast radius is bigger when sharing a connection. In my use-case, hitting the flow control limit would also block any HTTP/3 RPC calls or unrelated traffic on the connection. This introduces more scenarios for the connection to become deadlocked or generally stalled. HTTP/3 implementations use MAXSTREAMS to limit the number of simultaneous requests. This use-case no longer works when sharing a connection with a Http3Transport session, and HTTP/3 implementations must instead return explicit error status codes when this threshold is reached. The same issues with MAXDATA also apply to MAXSTREAMS. A Javascript application that fails to accept or read/abort every stream will consume flow control resources.


Question: may be using a version of WebTransport extension that is different from the one used by the server. <ins> In addition to the setting above, the server MUST send a SETTINGS_MAX_WEBTRANSPORT_SESSIONS parameter indicating the maximum number of concurrent sessions it is willing to receive.  The default value for the SETTINGS_MAX_WEBTRANSPORT_SESSIONS parameter is "0", meaning that the server is not willing to receive any WebTransport sessions. </ins> 3.2. RFC8441 defines an extended CONNECT method in Section 4, enabled by

This can manifest itself in strange ways, such as HTTP/3 being unable to create control streams, or simply being unable to create new request streams.
Thanks for the salient overview, it makes it easier to understand your concerns. My first comment would be that some of these points apply to QuicTransport too. Its just that their made worse by Http3Transport pooling allowing the mashing together of orthogonal protocols with no application-layer oversight. Just as you might interfere with a page load, a browser could easily interfere with your finely crafted application protocol. I would anticipate that, due to different browsers having different HTTP usage patterns, and different pages being composed differently by time, region, etc, one might find that Http3Transport apps subject to pooling would experience inconsistencies and transient issues. You rightly point out that the connection flow control is a shared resource. But the problems described seem to relate to stream flow control and overlooks the different flow control setting afforded by the Transport Parameters. A possible mitigation is to more tightly constrain the initial flow windows of server-initiated streams so that they can't interfere with requests. However, I still think that the notion of pooling together WebTransports in an uncoordinated fashion is going to manifest undesirable properties. The MAX_STREAMS observation is a good one. I think the competition between request streams and client bidirectional streams is going to be hard to resolve.
Yeah, and enforcing any per sort of per-session flow control might get difficult because you can only identify the protocol and session after you receive the first few bytes of each stream. For example, assume a brand new connection (for simplicity only) and you receive a STREAM frame with id=100, offset=16, and size=1000. You don't know yet which protocol or session created this stream or the 25 preceding it.


Question: may be using a version of WebTransport extension that is different from the one used by the server. <ins> In addition to the setting above, the server MUST send a SETTINGS_MAX_WEBTRANSPORT_SESSIONS parameter indicating the maximum number of concurrent sessions it is willing to receive.  The default value for the SETTINGS_MAX_WEBTRANSPORT_SESSIONS parameter is "0", meaning that the server is not willing to receive any WebTransport sessions. </ins> 3.2. RFC8441 defines an extended CONNECT method in Section 4, enabled by

And hopefully you eventually get those first few bytes for each stream...
Chair notes from IETF 112 meeting: this needs more discussion (on the issue or mailing list)
Chair: discussed at 113, consensus in room to: use a setting to limit number of WT sessions (see ) figure out MAXSTREAMS, a way to limit the number of streams within a session abandon MAXDATA as too hard, do not limit amount of data sent within a session (anyone can open a new issue to revisit this discussion if they have a concrete proposal on how to do this) let QUIC take care of MAXSTREAMDATA
Capsule DT is doing all of the above bullet points except the second one, for which I opened . Apologies for the extremely delayed response here, but hearing no objections we are declaring consensus and merging the PRs. David David Schinazi wrote:


Question: treat receipt of a non-empty value as a connection error of type TRANSPORT_PARAMETER_ERROR. <del> Advertising the grease_quic_bit transport parameter indicates that packets sent to this endpoint MAY set a value of 0 for the QUIC Bit. The QUIC Bit is defined as the second-to-most significant bit of the first byte of QUIC packets (that is, the value 0x40). </del> <ins> An endpoint that advertises the grease_quic_bit transport parameter MUST accept packets with the QUIC Bit set to a value of 0.  The QUIC Bit is defined as the second-to-most significant bit of the first byte of QUIC packets (that is, the value 0x40). </ins> A server MUST respect the value it previously provided for the grease_quic_bit transport parameter if it accepts 0-RTT.  A client

Inappropriate use of MAY, lack of MUST [NOT]. Thanks to Russ Housley for schooling me on the correct usage.


Question: 3.4.1. <del> If the ClientHello is not encrypted, it can be derived from the </del> <ins> If the ClientHello is not encrypted, SNI can be derived from the </ins> client's Initial packet by calculating the Initial secret to decrypt the packet payload and parsing the QUIC CRYPTO Frame containing the TLS ClientHello.

This goes to the end of "Server Name Indication" Some changes are attempts at clarifications, but I could have incorrectly clarified something, so feel free to reject changes.


Question: mechanism to allow for such application-specific features and options to be configured or otherwise negotiated. <ins> Transport dependency: None. Application dependency: Specification of application-layer features or functionality. </ins> Configuration extensions: The protocol negotiation should be extensible with addition of new configuration options. <ins> Transport dependency: None. Application dependency: Specification of application-specific extensions. </ins> Session caching and management: Sessions should be cacheable to enable reuse and amortize the cost of performing session establishment handshakes. <del> 4.2.2. </del> <ins> Transport dependency: None. </ins> <del> Connection mobility: Sessions should not be bound to a network connection (or 5-tuple).  This allows cryptographic key material and other state information to be reused in the event of a connection change.  Examples of this include a NAT rebinding that occurs without a client's knowledge. </del> <ins> Application dependency: None. </ins> 5. This section describes the interface surface exposed by the security <del> protocols described above, with each interface.  Note that not all protocols support each interface. </del> <ins> protocols described above.  Note that not all protocols support each interface.  We partition these interfaces into pre-connection (configuration), connection, and post-connection interfaces. </ins> 5.1.

…/security and security/transport dependencies.
NAME can you please take a look before Wednesday?
Yep, I will review Monday morning.
I think this is fine. We can do further tweaks in subsequent PRs.


Question: The COSE_encrypt structure for the recipient is organized as follows: <ins> The 'protected', 'aad', 'iv', and 'tag' fields all use the 'null' value. At a minimum, the 'unprotected' field SHOULD contain the 'alg' parameter as well as a parameter identifying the asymmetric key. The 'unprotected' field MUST contain the 'epk' parameter. </ins> 5.2.5. Key Agreement with Key Wrapping uses a randomly generated CEK.  The

Correct descriptions of Direct and Key Agreement Direct Change examples in the back to have "real" examples - they are JSON rather than CBOR, but that makes them shorter and easier to read.


Question: 6. <ins> When a client creates a QUIC connection, its goal is to use an application layer protocol.  Therefore, when considering which versions are compatible, clients will only consider versions that support one of the intended application layer protocols.  If the client's first flight advertises multiple Application Layer Protocol Negotiation (ALPN) ALPN tokens and multiple compatible versions, it is possible for some application layer protocols to not be able to run over some of the offered compatible versions.  It is the server's responsibility to only select an ALPN token that can run over the compatible QUIC version that it selects. A given ALPN token MUST NOT be used with a new QUIC version different from the version for which the ALPN token was originally defined, unless all the following requirements are met: The new QUIC version supports the transport features required by the application protocol. The new QUIC version supports ALPN. The version of QUIC for which the ALPN token was originally defined is compatible with the new QUIC version. When incompatible version negotiation is in use, the second connection which is created in response to the received version negotiation packet MUST restart its application layer protocol negotiation process without taking into account the original version. 7. </ins> In order to facilitate the deployment of future versions of QUIC, designers of future versions SHOULD attempt to design their new version such that commonly deployed versions are compatible with it.

Can an ALPN label be used for multiple QUIC versions? I think that the text should say something like: NAME adds (and I wholly agree):
I'm merging into this one where NAME said "The point is that your ALPN offer when you offer QUICvX shouldn't be dependent on if you did VN or not."
LGTM


Question: the option is sent with a modified value.  Its starting value is its base value. <del> 4.3.3. </del> <ins> 4.3.2. </ins> A sender can use the elective Block-wise Transfer Option to indicate that it supports the block-wise transfer protocol RFC7959.

The next pass will add text related to the default URI-Host for TLS SNI cases.


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

IANA's review wanted to know whether the 148 quadrillion GREASE values should be listed on the registry page as Reserved, and what note should be present if not. They should not, lest it be challenging to actually download the registry page within the lifetime of the human race. This rewords the restriction and clarifies that the restriction should be the note.
NAME Can you add the same text to 22.2 (Transport parameter registry) in the transport doc as well?
NAME said
We believe the note, updated based on IANA feedback during Last Call, is sufficient. Reserving 148 quadrillion values in the registry would cause the registry to be impossible to download in the lifetime of humanity; see . The purpose is described in , to exercise the requirement to ignore unknown frame types (a.k.a. GREASE). Proposal is to make no change; this was already covered during IANA review.
If IANA has agreed, then I am fine with it. BTW, I was not asking to make those zillions of reservations but leaving a note in the registry ;-)
It's a fair question but the WG and the responsible AD are satisfied with our IANA considerations at this stage, closing with no action.
Please see the for full context. This issue is tracking the following IANA question:
Copying my e-mail reply here: unknown values; having an explicit list encourages an explicitly defined reaction. This also applies to and , where the latter has better wording.
NAME replied to IANA . Closing this issue.
Actually, NAME said in response to the e-mail that this guidance should be in the document: Let's re-open to track. I don't think all instances of this question need separate issues, though.
So the related questions were: Should the GREASE values be listed in the registry as Reserved? No, because some rough estimation suggests it would take a few millennia to download the registry page if this were the case. Should there be a note indicating which values cannot be assigned? I'm of two minds, because while I really don't want people embedding the formula into their parsers, I do want people embedding the formula into their generators. says no Reserved listing, yes note.
I think this is proposal ready. Forwarding Mike's response to the list, to there is an archive to link to. Lars >


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

This makes it clearer that the notation is copied from v1, not defined there and normatively referenced. (Note, figures aren't normative anyway.)
Éric Vyncke said:
In my response to , I explain this. This ensures that the transport reference can remain informative.
Perhaps the intro needs to be reworded to indicate that it's using some of the same conventions as the transport document, which are reproduced below?
Éric Vyncke said:
Barry's point (captured in ) was that one or other might need to be normative. This is a different point, suggesting that this document concretely depends on the transport draft for terminology that has normative effect. Haven't checked, I don't think that is the case and the reference can remain informative. The reason for that being that all of the terminology used in this draft is also defined in this draft.
Any other bids?


Question: Time-Sensitive Networking, TSN is a Task Group of the IEEE 802.1 Working Group. <del> 2.3. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. </del> 3. <del> I-D.ietf-detnet-ip describes how IP is used by DetNet nodes, i.e., hosts and routers, to identify DetNet flows and provide a DetNet service.  From a data plane perspective, an end-to-end IP model is followed.  DetNet uses "6-tuple" based flow identification, where "6-tuple" refers to information carried in IP and higher layer protocol headers. </del> <ins> RFC8939 describes how IP is used by DetNet nodes, i.e., hosts and routers, to identify DetNet flows and provide a DetNet service.  From a data plane perspective, an end-to-end IP model is followed.  DetNet uses "6-tuple" based flow identification, where "6-tuple" refers to information carried in IP and higher layer protocol headers. </ins> DetNet flow aggregation may be enabled via the use of wildcards, masks, prefixes and ranges.  IP tunnels may also be used to support

ip-over-tsn (nits) mpls-over-tsn (nits) tsn-vpn-over-mpls (nits, ch5.2, ch5.3)


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

As planned in the last authors' meeting: et should become just one of the registrable endpoint attributes (registry is already being prepared as RD parameter registry, but needs some work) lookup should allow using any of those registered attributes lookup should define how endpoint attributes are used in resource lookups (after all, should be possible even though none of the resource links actually carry that attribute) This PR is not final as it is, but will track my branch as I'm assembling (and possibly rewriting/rebasing) commits for this change.
et is not used by Fairhair, but that should not influence the text, I think
The bulk of the announced changes is now in the pull request; I'll go through it one more time myself before I merge it into master. (I might still add a big reshuffling change to the lookup interface, because the text has grown in the past by always inserting paragraphs, and they're not necessarily in a logical overall sequence.)
NAME I only just now merged the current state of the branch into master, the rebuild just completed.
See-Also: Some of what could be the review of this PR has come up in URL
I don't see any reason to keep this section as pointed out during the last telco. When it is removed some examples i Registration update must be changed. The request GET /rd/4521 should change to GET /rd-lookup/ep?href=rd/4521
Apologies, that will not return the links of the endpoint The request GET /rd/4521 should change to GET /rd-lookup/res?ep=/rd/4521 or GET /rd-lookup/res?ep=node1 I am afraid we need to stay with ep name, difficult to use /rd/4521 as ep identifier.
The equivalent requests would be GET /rd-lookup/res?ep=node1 and GET /rd-lookup/res?href=/rd/4521 (where the link has neither the ep=node1 nor the href=/rd/4521 link parameter, but its registration does).
I think that we don't need the GET as long as there are no PATCHes (and I recently saw we don't even define PUT for the registration resource). The discussion has shown that this is one of the points where our understanding of resolved and unresolved addresses is tested: Can we have a resource whose content is "unresolved link-format" to operate on?


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

Or do we need to resolve the links even in there, and any PATCH format would need to work semantically from a shared understanding of both the RD and the client? NAME you wanted to meditate on that; have you found deeper truth, or a path there?
This weird indeed: In my understanding this means return all link resource paths with ep name node1 and GET /rd-lookup/res?href=skins/larry/rd/4521 means return all link resource paths with href is skins/larry/rd/4521 and will be empty chrysn schreef op 2017-10-30 13:03:
returns resources that either have as their own link href, or are contained in an endpoint or group with that href. This was introduced in because we do not have (due to the extensibility of the link attributes and the lack of a definitive registry) a partition on attribute names that clearly states that one attribute can only be on a group, another only on an endpoint and a third only on a resource. Thus, we need to expect matches from either level -- and once we already have to do this, we can just as well do it with href because it's treated like any other attribute. IMO the alternatives to this would be either having registries set up to partition the names so every query parameter is clearly an endpoint, group or resource attribute (probably not going to happen with resource attributes, as requested and denied in RFC5988bis), or we'd need a more complex lookup language than RFC6690-style search -- something like so we could be explicit there. (See also URL )
Ok, you go faster than my shadow. As long as the text covers the example, and the intention is clear. I will need to read the finished text again. chrysn schreef op 2017-10-30 16:29:
(Moving some comments here from EMail to keep track:) [Peter] I thought we agreed to remove section 5.4.3, [Christian] I had that taken down as "we should think about it some more"; I do expect that interfact to only become useful when we have a way to patch it.


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

Given the current direction of lookup with construction of absolute URI, we can leave section 5.4.3 in
The "RD Parameters" subregistry is set up in the IANA considerations, but only referenced at the registration interface. The lookup interface allows lookup by parameters of the same names (and page and count are exclusively used for lookup), but doesn't make a reference to the iana-registry. Next steps (→CA): Add a reference to lookup interface description (and reviewing that text, decide on whether that does create linkage to any other existing registry).


Question: _mandatory_ <ins> Collected Claims represent a (sub-)set of Claims created by an Attester. Collected Claims are gathered based on the Claims selected in the Claim Selection.  If a Verifier does not provide a Claim Selection, then all available Claims on the Attester are part of the Collected Claims. _mandatory_ </ins> A set of Claims that consists of a list of Authentication Secret IDs that each identifies an Authentication Secret in a single Attesting Environment, the Attester Identity, Claims, and a

… in diagram. Also fixed "randomized" (was British English before). Signed-off-by: Michael Eckel
An handle mustbe created/generated before it can be distributed. Adding a generateHandle() call would also strengthen understanding by readers.
Based on URL In the sequence diagram, some elements in the bracket are not defined in the “Information Elements” section, such as targetEnvironment, collectedClaims, eventLog. Should these elements be defined?
I totally agree. These elements should either be put into Information elements (preferred), or at least be mentioned in the text. Hi Henk, I've reviewed the reference interaction models I-D recently, I hope the comments below can help improve the draft before the IETF110 draft submission cut-off. Section 3 Disambiguation Comment > This section is talking about the disambiguation of terminology, so I suggest making it a sub-section of Section 2 Terminology. Examples of these types of co-located environments include: a Trusted Execution Environment (TEE), Baseboard Management Controllers (BMCs), as well as other physical or logical protected/isolated/shielded Computing Environments (e.g. embedded Secure Elements (eSE) or Trusted Platform Modules (TPM)). Comment > About "these types of co-located environments", The previous sentences are about the Verifier and Attester don't need to be remote. So "these" is weird here, because here is about the attesting environment and target environment. Section 5 Direct Anonymous Attestation Comment > I think it's better to move this section to the bottom of the draft. DAA doesn't introduce a new information elements, and only augments the scope/definition of Attester Identity and Authentication Secret IDs, describing it after the introduction of all the 3 basic interaction models would be better. Putting DAA in the middle makes me feel the basic interaction models rely upon DAA, but actually it's not. This document extends the duties of the Endorser role as defined by the RATS architecture with respect to the provision of these Attester Identity documents to Attesters. The existing duties of the Endorser role and the duties of a DAA Issuer are quite similar as illustrated in the following subsections.


Question: _mandatory_ <ins> Collected Claims represent a (sub-)set of Claims created by an Attester. Collected Claims are gathered based on the Claims selected in the Claim Selection.  If a Verifier does not provide a Claim Selection, then all available Claims on the Attester are part of the Collected Claims. _mandatory_ </ins> A set of Claims that consists of a list of Authentication Secret IDs that each identifies an Authentication Secret in a single Attesting Environment, the Attester Identity, Claims, and a

Comment > Without DAA, I think the Endorser also needs to provision the Attester Identity to Attesters. And as I understand, the DAA Issuer is a supply chain entity before the Attester being shipped, so it is the Endorser when DAA is used, right? If yes, then in the next sentence, the comparison between Endorser and DAA Issuer doesn't make sense to me. Section 5.1 Endorsers Comment > Does this section have difference with the definition of Endorser in architecture draft? If not, is it necessary to keep this section? Comment > This section only describes the Layered Attestation, but the scope of Endorsement is more than what's described here. Endorsement indicates the Attester's various capabilities such as Claims collection and Evidence signing. For other situations than Layered Attestation, the Endorser and Endorsement are also needed. So why only mention Layered Attestation here? I don't see any special relationship between DAA and Layered Attestation. Section 5.2 Endorsers for Direct Anonymous Attestation In order to enable the use of DAA, an Endorser role takes on the duties of a DAA Issuer in addition to its already defined duties. DAA Issuers offer zero-knowledge proofs based on public key certificates used for a group of Attesters [DAA]. Effectively, these certificates share the semantics of Endorsements, with the following exceptions: Comment > In the first sentence, I suggest saying that "a DAA Issuer takes on the role of an Endorser". o The associated private keys are used by the DAA Issuer to provide an Attester with a credential that it can use to convince the Verifier that its Evidence is valid. To keep their anonymity the Attester randomizes this credential each time that it is used. Comment > How to understand "Evidence is valid"? Does it mean the Evidence is sent from an authentic Attester and not tampered during the conveyance? Or does it mean the Evidence comes from a RoT and is trustable (although the Evidence can diverge from the Reference Values)? Comment > When saying "Attester randomizes this credential", how many credentials does an Attester have?


Question: _mandatory_ <ins> Collected Claims represent a (sub-)set of Claims created by an Attester. Collected Claims are gathered based on the Claims selected in the Claim Selection.  If a Verifier does not provide a Claim Selection, then all available Claims on the Attester are part of the Collected Claims. _mandatory_ </ins> A set of Claims that consists of a list of Authentication Secret IDs that each identifies an Authentication Secret in a single Attesting Environment, the Attester Identity, Claims, and a

1) Can a DAA Issuer have multiple key pairs and use them for one Attester? 2) Can a DAA Issuer use one key pair to generate multiple credentials for one Attester? o A credential is conveyed from an Endorser to an Attester in combination with the conveyance of the public key certificates from Endorser to Verifier. Comment > Is there another way to convey the public key certificate, for example, can the public key certificates be conveyed from Endorser to Attester first and then from Attester to Verifier? The zero-knowledge proofs required cannot be created by an Attester alone - like the Endorsements of RoTs - and have to be created by a trustable third entity - like an Endorser. Due to that semantic overlap, the Endorser role is augmented via the definition of DAA duties as defined below. This augmentation enables the Endorser to convey trustable third party statements both to Verifier roles and Attester roles. Comment > For "the definition of DAA duties as defined below", what is the definition of DAA duties? Comment > In the last sentence, the Endorsement with its original definition is the third party statement for Verifier and Attester, isn't it? So, "augmentation" isn't the correct expression. Section 6 Normative Prerequisites Attester Identity: The provenance of Evidence with respect to a distinguishable Attesting Environment MUST be correct and unambiguous. Comment > The Attester Identity is to identify which Attester the Evidence comes from. But if the Attester has multiple Attesting Environments, what should be the Attester Identity? Comment > The TPM's AIK certificate is one kind of Attester Identity, right? Attestation Evidence Authenticity: Attestation Evidence MUST be correct and authentic. Comment > Is it appropriate to say "correct Evidence"? If saying so, I think it means that the Evidence satisfies the Attestation Policy for Evidence. Authentication Secret: An Authentication Secret MUST be available exclusively to an Attester's Attesting Environment. The Attester MUST protect Claims with that Authentication Secret, thereby proving the authenticity of the Claims included in Evidence. The Authentication Secret MUST be established before RATS can take place. Comment > Does the Authentication Secret represent the identity of the Attesting Environment?