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

NAME done; see change. P.S. GitHub lets you make suggestions using the little +/- icon in the inline comment UX :)
Pulling this conversation out of : It's clear that there's demand for error codes scoped to the API, without creating documentation pages for each code and linking to them in the field. There are many ways that implementers could do this, from linking to non-existent URLs to URNs to tags URIs, etc. It would be useful if the specification included examples of this, and made a clear recommendation for this case.
We (well, mostly NAME have made some good progress on the other issues raised out of but we haven't looked at this one yet. As strawman to get this moving, how about: we register a URN namespace id, and we recommend that non-dereferenceable URIs should be URNs using that, namespaced with an appropriate domain and raw type id, for example: . Would that work? It would give us a clear solution to recommend, which is explicit but easy to read, with minimal extra complexity or overhead for implementers (imo). I don't have examples, but I suspect there are other standards elsewhere that would appreciate having a problem id namespace for URNs as well. I don't love using a domain for namespacing a non-locator, but I think some namespacing is preferable, and I'm not sure what other namespaces would be suitable. Alternatives very welcome :smile:
We penciled in the URI prefix for registered types as "URL" in , but that was not finalised. I think registering one or more problems as exemplars is a good path forward for this and other issues (e.g., as discussed in ). We need to be very careful to set a good example in them, which means we need good candidates; I'm thinking 'JSON Validation Error' and 'XML Validation Error' might be appropriate (perhaps along with corresponding wellformedness errors). If we choose a urn, I suspect there will be considerable pressure to use or something similar, as per .
my understanding of the "urn:ietf:params" namespace is that it is meant to be used for parameters managed/defined by IETF specs. i think the original's suggestion intent was to have a "safe prefix" for a namespace which then would be "unmanaged" with some conventions around that, such as using domains names.


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

i think the idea of giving examples (and even a suggested namespace along with conventions for using it) is a good one. that way we can clearly support both scenarios: if you're planning on making documentation available, use a resolvable URI but keep in mind that this best should be managed in a way so that it works for a good number of years. if you're planning on just identifying problem types, use a non-resolvable URI, and here's a recipe for doing it.
:+1: exactly I think is relevant in that it would be helpful to everybody if we can follow our own recommendations in our own problem id registry, but it's otherwise independent.
the difficulty may be that IETF has an institutional approach for managing parameters (urn:ietf:params:http-problems mentioned by NAME above), whereas most orgs minting problem types probably won't have one and won't create one. which may lead to us to saying three things about what kind of URI to use: check out common problem types registered under urn:ietf:params:http-problems and consider reusing one if it fits. use URIs when creating dereferencable problem type identifiers. when using non-dereferencable problem type identifiers be clear about that by using non-dereferencable URIs, and here's an URN-based recipe how to do that.
Ah, I see, ok. Yes, that makes sense, and given that the 3 part recommendation seems reasonable to me.
to be used for parameters managed/defined by IETF specs. No, it's for parameter name spaces managed by IETF documents -- which this would be. We could also give an example that uses a URI.
that's what i wanted to say. so these URIs/examples would just cover the common problem types that would be managed by the spec. which then would be for those other types that people/orgs are minting and where they say these are not resolvable, right? i think for those terry proposed a URN namespace instead of tag URIs, but either way it simply would help to state the use case ("your own types, not intended to be resolvable") and provide a recipe ("here's one way to do it").


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

the main point seems to be: the spec should mention both "common types" which may even get a registry, and "private types" which probably are using a different namespace, and we could suggest one pattern for doing that.


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

In the Recovery genart review, Vijay Gurbani wrote:
Based on the proposed PR, I'm marking this as editorial.
In the Recovery genart review, Vijay Gurbani wrote:
Based on the proposed PR, I'm marking this as editorial.


Question: example, if reliable delivery was requested for a Message handed over before calling Close, the Closed Event will signify that this Message has indeed been delivered.  This action does not affect any other <del> Connection that is entangled with this one in a Connection Group. </del> <ins> Connection in the same Connection Group. </ins> The Closed Event informs the application that the Remote Endpoint has closed the Connection.  There is no guarantee that a remote Close will indeed be signaled. Abort terminates a Connection without delivering any remaining <del> Messages.  This action does not affect any other Connection that is entangled with this one in a Connection Group. </del> <ins> Messages.  This action does not affect any other Connection that in the same Connection Group. </ins> CloseGroup gracefully terminates a Connection and any other <del> Connections that are entangled with this one in a Connection Group. For example, all of the Connections in a group might be streams of a single session for a multistreaming protocol; closing the entire group will close the underlying session.  See also groups.  As with Close, any Messages remaining to be processed on a Connection will be handled prior to closing. AbortGroup terminates a Connection and any other Connections that are entangled with this one in a Connection Group without delivering any remaining Messages. </del> <ins> Connections in the same Connection Group.  For example, all of the Connections in a group might be streams of a single session for a multistreaming protocol; closing the entire group will close the underlying session.  See also groups.  As with Close, any Messages remaining to be processed on a Connection will be handled prior to closing. AbortGroup terminates a Connection and any other Connections in the same Connection Group without delivering any remaining Messages. </ins> A ConnectionError informs the application that: 1) data could not be delivered to the peer after a timeout, or 2) the Connection has been

This changes the use of the term "entanglement" as discussed in , and moves some text around in this section for better clarity and less repetition. Also, addressing , it introduces a framer as an optional parameter to the Clone call.
NAME I incorporated all of your suggestions, thanks!
This is not fully clear from section 5.4., however, if connections in a group are each QUIC streams, I think it should be possible to use different framers on each stream. So it might be okay that a framers is copied when clone is called but changing a framer on one connection should not change the framer on the other connection in a group...?
Also an related editorial comment (that could be addressed in the same PR eventually): this section on groups only at the very end has a paragraph starting with "Note that calling Clone() can result in on-the-wire signaling..." which kind of explains that groups are supposed to be used for multistream protocol but can also be mapped to separate connection if the protocol doesn't not support multiplexing of stream on one connection. I think this information should be added at the very beginning of this section.
Actually, now looking at the framer section, I guess you would rather like to already set the new framer before you clone a connection...?
I agree with everything you say here; about your last suggestion, maybe a framer should be an optional argument of the clone call?
I don’t actually understand the difference between a connection in a Connection Group and an “entangled connection” ? Both terms are used in API, but in different ways (possibly by different authors) - do we really really need the word “entangled”?? if we do we need, can we define and explain this.
I think that having the word is good as it indicates a deeper relationship than mere "grouping". Just based on terms, I'd (correctly) imagine that I can define priorities between members of a group, and that they somehow belong together... as in: Close with a common call, etc. ... but I don't think that I would expect, just from this term, that changing a property on one of them affects all the others. Hence the phrasing: "The connections within a group are 'entangled' with each other". However, I agree that in most other places, we should talk about "groups" instead.


Question: example, if reliable delivery was requested for a Message handed over before calling Close, the Closed Event will signify that this Message has indeed been delivered.  This action does not affect any other <del> Connection that is entangled with this one in a Connection Group. </del> <ins> Connection in the same Connection Group. </ins> The Closed Event informs the application that the Remote Endpoint has closed the Connection.  There is no guarantee that a remote Close will indeed be signaled. Abort terminates a Connection without delivering any remaining <del> Messages.  This action does not affect any other Connection that is entangled with this one in a Connection Group. </del> <ins> Messages.  This action does not affect any other Connection that in the same Connection Group. </ins> CloseGroup gracefully terminates a Connection and any other <del> Connections that are entangled with this one in a Connection Group. For example, all of the Connections in a group might be streams of a single session for a multistreaming protocol; closing the entire group will close the underlying session.  See also groups.  As with Close, any Messages remaining to be processed on a Connection will be handled prior to closing. AbortGroup terminates a Connection and any other Connections that are entangled with this one in a Connection Group without delivering any remaining Messages. </del> <ins> Connections in the same Connection Group.  For example, all of the Connections in a group might be streams of a single session for a multistreaming protocol; closing the entire group will close the underlying session.  See also groups.  As with Close, any Messages remaining to be processed on a Connection will be handled prior to closing. AbortGroup terminates a Connection and any other Connections in the same Connection Group without delivering any remaining Messages. </ins> A ConnectionError informs the application that: 1) data could not be delivered to the peer after a timeout, or 2) the Connection has been

I can try to fix this.
Sounds good - we should add that explanation upfront in the definitions then also?
[Yes, I think so.] EDIT: no, now I don't think so anymore. (see )
I have addressed this in PR . Note that the text interchangeably talked about both Connections and Connection Properties as being "entangled". I have now written this such that the term "entanglement" applies to Connection Properties only, whereas Connections in a group are, well, members of the same Connection Group.
Looks good to me.


Question: ACK-FREQUENCY frames have a type of 0xXX, and contain the following fields: <del> An optional variable-length integer representing the maximum number of ack-eliciting packets after which the receiver sends an acknowledgement. </del> <ins> A variable-length integer representing the maximum number of ack- eliciting packets after which the receiver sends an acknowledgement.  A value of 1 will result in an acknowledgement being sent for every ack-eliciting packet received.  A value of 0 is invalid. A variable-length integer representing an update to the peer's "max_ack_delay" transport parameter (Section 18.2 in QUIC- TRANSPORT).  The value of this field is in microseconds.  Any value smaller than the min_ack_delay advertised by this endpoint is invalid. </ins> <del> An optional variable-length integer representing the maximum amount of time, in microseconds, after which the receiver sends an acknowledgement.  The value of the Time Tolerance field is scaled by multiplying the encoded value by 2 to the power of the value of the "ack_delay_exponent" transport parameter set by the sender of the ACK-FREQUENCY frame (see Section XX in QUIC-TRANSPORT). Scaling in this fashion allows for a larger range of values with a shorter encoding at the cost of lower resolution. </del> <ins> Receipt of invalid values in an ACK-FREQUENCY frame MUST be treated as a connection error of type PROTOCOL_VIOLATION. </ins> ACK-FREQUENCY frames are ack-eliciting.  However, their loss does not require retransmission.

This PR changes a few things: Introduces a TP for negotiating extension use Changes to Makes the fields required Specifies invalid values
I'm merging this, let's address issues in later PRs.
I think it'll be easier to make both parameters required. Not doing so saves 1 to 2 bytes, which is really not much in a frame I expect will be sent a few times a connection. Also, I think 0 should be an invalid value for both params, and 1 should be invalid for the number of packets, though I can see someone arguing that point.
addresses these issues, with the exception that 1 is allowed for packet tolerance. I think that's actually useful for some startup schemes, so we shouldn't disallow it.


Question: Changing one of these Protocol Properties on one Connection in the group changes it for all others.  Per-Message Protocol Properties, however, are not entangled.  For example, changing "Timeout for <del> aborting Connection" (see timeout) on one Connection in a group will automatically change this Protocol Property for all Connections in the group in the same way.  However, changing "Lifetime" (see msg- </del> <ins> aborting Connection" (see conn-timeout) on one Connection in a group will automatically change this Protocol Property for all Connections in the group in the same way.  However, changing "Lifetime" (see msg- </ins> lifetime) of a Message will only affect a single Message on a single Connection, entangled or not.

This is the second step towards applying our new Properties Classification. It moves up the Connection Properties and annotates most places with stuff to do.
As discussed in
Thanks for moving this forward! I only found a few nits. Also, I have a question about whether two of these Properties should maybe be changed to be Selection Properties, but that's more of a discussion and not something that needs to be done in this URL modulo NAME commentsI carefully checked it, but I find it very hard to be sure that this is 100% ok (as is usually the case IMO with diff's about text blocks being moved around). My suggestion is to land it and see.


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

From Stephane:
Shouldn't the CA / cert hierarchy be a point of control? For example, KZ is requiring users to install their CA, to allow them to MITM all traffic: URL Another example of CA abuse is ROA whacking, RPKI manipulation, etc.: URL
Also got this feedback from Will Scott:


Question: "proto": The PDA protocol, e.g., Prio or Hits.  The rest of the structure contains the protocol specific parameters. <del> Each task has a unique _task id_ derived from the PDA parameters: </del> <ins> Each task has a unique _task ID_ derived from the PDA parameters: The task ID of a "PDAParam" `is derived using the following procedure: </ins> <del> The task id is derived using the following procedure.  [TODO: Specify derivation of the task ID.] </del> <ins> Where "SHA-256" is as specified in FIPS180-4. </ins> 3.1.2.

I added a clarification that the nonce is random. IMO the question of who randomly generates the nonce goes with the question of how participants agree upon PDAParams, which is to say it's outside the protocol.
On the 2021/7/7 design call we decided that the ID should be derived deterministically from the serialized PAParam by, for example, hashing it. This solves a few problems simultaneously. This settles the question of whether there should be 1:1 correspondence between a task ID and the parameters used for that task. NAME brought up an interesting question, which is how to make the task ID unique when two different data collection tasks use the same parameters. Thoughts?
The consensus here is to do SHA-256 over the PDAParams structure and use that as the 32 byte PDATaskID. However, hashing a protocol message requires us to decide on a canonical representation of a protocol message, which I think forces us to decide how to encode messages on the wire. I filed for that question. I'll proceed with a PR for this issue on the assumption that we'll pick JSON.
As I mentioned there, the assumption would be that we're adopting TLS' binary encoding. If so, in TLS notation, you would write as the hash of , which itself is a serialized data structure.
All we require is that each PAParam have some unique value, right? A random nonce would probably suffice. r.e. the encoding, yes, let's stick with TLS's wire format as NAME suggests.
Yes, my thinking was that we would just stick 16 bytes of random data in (a UUID's worth). I agree that we should stick with TLS binary encoding.
Approved, with the following suggestion: Let's leave a [TODO: ...] comment under the definition of for clarifying how it should be chosen.


Question: options. An Outer Max-Age message field is used to avoid unnecessary caching <del> of OSCORE error responses at OSCORE-unaware intermediary nodes.  A server MAY set a Class U Max-Age message field with value zero to OSCORE error responses, which are described in Sections replay- protection, ver-req, and ver-res.  Such a message field is then processed according to outer-options. </del> <ins> of error responses caused by OSCORE processing at OSCORE-unaware intermediary nodes.  A server MAY set a Class U Max-Age message field with value zero to such error responses, described in Sections replay-protection, ver-req, and ver-res, since these error responses are cacheable, but subsequent OSCORE requests would never create a hit in the intermediary caching it.  Setting the Outer Max-Age to zero relieves the intermediary from uselessly caching responses. </ins> Successful OSCORE responses do not need to include an Outer Max-Age <del> option since the responses are non-cacheable by construction (see coap-header). </del> <ins> option since the responses appear to the OSCORE-unaware intermediary as 2.04 Changed responses, which are non-cacheable (see coap-header). The Outer Max-Age message field is processed according to outer- options. </ins> 4.1.3.2.

Solves issue (from review comments by NAME : URL)
Section 4.1.3.1 - I am unclear why an OSCORE error response can be cached by an OSCORE unaware intermediate would be cached, but a success message is never going to be cached. Based on this, I don't plan to set an outer Max-Age option.
Closed in 84403c4c4 Section 4.1.3.1 - I am unclear why an OSCORE error response can be cached by an OSCORE unaware intermediate would be cached, but a success message is never going to be cached. Based on this, I don't plan to set an outer Max-Age option. In section 5.4 you have the text requestpiv: contains the value of the 'Partial IV' in the COSE object of the request (see Section 5), with one exception: in case of protection or verification of Observe cancellations, the requestpiv contains the value of the 'Partial IV' in the COSE object of the corresponding registration (see Section 4.1.3.5.1). I am unclear how/why this is different for observations. A cancelation is a message, so the IV is the request. A re-registration is a request message, any response would correspond to that request. The only interesting question has to do with updating the MID on a re-registration but not how PIVs work for this field. Section 6.1 - Is a registry needed for the leading byte of compression? Behavior if bits 0, 1, or 2 is set in the flags byte on decode? Section C - given the way that my system is implemented, it would be nice if the outputs included the first full IV to be used for both the sender and the recipient. That would allow for a test that the combination of ids and common ivs is done correctly. In my case I do not have the shared IV available for testing as I immediately or in the id.


Question: <del> Combining EDHOC and OSCORE </del> <ins> Using EDHOC for OSCORE with CoAP Transport </ins> draft-ietf-core-oscore-edhoc-latest Abstract <del> This document defines an optimization approach for combining the lightweight authenticated key exchange protocol EDHOC run over CoAP with the first subsequent OSCORE transaction.  This combination reduces the number of round trips required to set up an OSCORE Security Context and to complete an OSCORE transaction using that Security Context. </del> <ins> This document defines how the lightweight authenticated key exchange protocol EDHOC is used for establishing an OSCORE Security Context, using CoAP for message transferring.  Furthermore, this document defines an optimization approach for combining EDHOC run over CoAP with the first subsequent OSCORE transaction.  This reduces the number of round trips required to set up an OSCORE Security Context and to complete an OSCORE transaction using that Security Context. </ins> 1. <del> This document defines an optimization approach to combine the lightweight authenticated key exchange protocol EDHOC I-D.ietf-lake- edhoc, when running over CoAP RFC7252, with the first subsequent OSCORE RFC8613 transaction. </del> <ins> Ephemeral Diffie-Hellman Over COSE (EDHOC) I-D.ietf-lake-edhoc is a lightweight authenticated key exchange protocol, especially intended for use in constrained scenarios.  As defined in Section 7.2 of I- D.ietf-lake-edhoc, EDHOC messages can be transported over the Constrained Application Protocol (CoAP) RFC7252. </ins> <del> This allows for a minimum number of round trips necessary to setup the OSCORE Security Context and complete an OSCORE transaction, for example when an IoT device gets configured in a network for the first time. </del> <ins> This document builds on the EDHOC specification I-D.ietf-lake-edhoc and defines how EDHOC run over CoAP is used for establishing a Security Context for Object Security for Constrained RESTful Environments (OSCORE) RFC8613. In addition, this document defines an optimization approach that combines EDHOC run over CoAP with the first subsequent OSCORE transaction.  This allows for a minimum number of round trips necessary to setup the OSCORE Security Context and complete an OSCORE transaction, for example, when an IoT device gets configured in a network for the first time. </ins> This optimization is desirable, since the number of protocol round trips impacts the minimum number of flights, which in turn can have a

Clean-up after URL As the content-from-edhoc branch seems to be the most up-to-date one (in which the parts changed are introduced in the first place), this builds on , and only the latest commit is actually relevant.
Compared to the original bstridentifier mapping, this is a different int-to-bstr mapping, but one that's most likely efficient to implement. I have not made any statement on the efficiencies, but some guidance we could give is that from a coding density point of view, numeric Cx should only be used with -24..23; for all other values, doing it in a bstr is just as good and saves a byte in OSCORE. (In fact we may want to make that normative, so that only the single-byte case needs to be implemented where this needs explicit implementation).


Question: certificate when the certificate permits the usage of delegated credentials. <del> Conforming CAs MUST mark this extension as non-critical.  This allows the certificate to be used by service owners for clients that do not support certificate delegation as well and not need to obtain two certificates. </del> The client MUST NOT accept a delegated credential unless the server's end-entity certificate satisfies the following criteria:

Based on The delegation certificate MAY have the DelegationUsage extension marked critical. This also adds a "strict" flag to the extension that, if set, requires the server to offer a DC. An alternative that was discussed is to add an optional TLS-feature extension (per RFC 7633) that would provide a "must-use-DC" feature, analogous to "must-staple-OCSP". Howver, it's possible for a certificate with such an extension to be used in a handshake without DCs if the client doesn't indicate support for DCs.


Question: more. connection-props provides a list of Connection Properties, while <del> Selection Properties are listed in the subsections below.  Many properties are only considered during establishment, and can not be changed after a Connection is established; however, they can still be queried.  The return type of a queried Selection Property is Boolean, where "true" means that the Selection Property has been applied and "false" means that the Selection Property has not been applied.  Note that "true" does not mean that a request has been honored.  For example, if "Congestion control" was requested with preference level "Prefer", but congestion control could not be supported, querying the "congestionControl" property yields the value "false".  If the preference level "Avoid" was used for "Congestion control", and, as requested, the Connection is not congestion controlled, querying the "congestionControl" property also yields the value "false". </del> <ins> Selection Properties are listed in the subsections below.  Selection Properties are only considered during establishment, and can not be changed after a Connection is established.  After a Connection is established, Selection Properties can only be read to check the properties used by the Connection.  Upon reading, the Preference type of a Selection Property changes into Boolean, where "true" means that the selected Protocol Stack supports the feature or uses the path associated with the Selection Property, and "false" means that the Protocol Stack does not support the feature or use the path. Implementations of Transport Services systems may alternatively use the two Preference values "Require" and "Prohibit" to represent "true" and "false", respectively. </ins> An implementation of the Transport Services API must provide sensible defaults for Selection Properties.  The default values for each

NAME wrote: "Why is the text talking about "many properties" that can no longer be changed, instead of relying on the earlier, nice and clear distinction between Selection and Connection Properties?". => In line with the suggestion from NAME this is now changed, it says Selection Properties. NAME wrote: "Where earlier, Selection Properties were said to remain readable, now they are only queryable?". => In line with NAME answer, this PR replaces "query" with "read" in this text. NAME wrote: "Are "applied" Selection Properties still Selection Properties? Shouldn't they better be referred to using a different term?" and here, NAME suggested: "In the , we define Protocol Stack as a Transport Services implementation concept, and we talk about a certain protocol stacks providing certain features (see . Perhaps we could rephrase this part of the API draft to use that terminology, e.g., the application can query the actually used protocol stack and then know which Transport Features it supports." => I don't know how to apply this change, and it generally sounds a bit complicated to me. I think that Selection Properties should keep their name. Regarding the confusing text with the example, I removed this and I think it makes things clearer. Regarding the return type, I think I now finally understood the bigger problem. Returning a Boolean instead of a Preference should make sense and should be easy to implement (as also described in this PR). The problem is that not all Selection Properties are of type Preference. E.g., is an enumeration, representing , or . What sense does it make if this becomes only or ? Similarly, and are of type "Collection of (Preference, Enumeration)", and indeed it would make sense to expect a Collection of booleans, not a singular boolean. This PR now explicitly says that, upon reading, the Preference type of a Selection Property (not the whole Selection Property!) changes into Boolean.
MANY thanks for the proposed fix (which I committed)! I hadn't really understood the problem just from reading the issue discussion.


Question: more. connection-props provides a list of Connection Properties, while <del> Selection Properties are listed in the subsections below.  Many properties are only considered during establishment, and can not be changed after a Connection is established; however, they can still be queried.  The return type of a queried Selection Property is Boolean, where "true" means that the Selection Property has been applied and "false" means that the Selection Property has not been applied.  Note that "true" does not mean that a request has been honored.  For example, if "Congestion control" was requested with preference level "Prefer", but congestion control could not be supported, querying the "congestionControl" property yields the value "false".  If the preference level "Avoid" was used for "Congestion control", and, as requested, the Connection is not congestion controlled, querying the "congestionControl" property also yields the value "false". </del> <ins> Selection Properties are listed in the subsections below.  Selection Properties are only considered during establishment, and can not be changed after a Connection is established.  After a Connection is established, Selection Properties can only be read to check the properties used by the Connection.  Upon reading, the Preference type of a Selection Property changes into Boolean, where "true" means that the selected Protocol Stack supports the feature or uses the path associated with the Selection Property, and "false" means that the Protocol Stack does not support the feature or use the path. Implementations of Transport Services systems may alternatively use the two Preference values "Require" and "Prohibit" to represent "true" and "false", respectively. </ins> An implementation of the Transport Services API must provide sensible defaults for Selection Properties.  The default values for each

As , here follows a bit of feedback on the different Property types in the Interface draft, from the perspective of an academic developer who is currently attempting to follow the draft spec as closely as possible while trying to implement a path-aware transport system in a In , it says: At this point, the reader of the document could be expected to conclude the following: Selection Properties are a set of preferences for protocol/path selection that (obviously) can no longer be meaningfully changed once a connection has been established. Connection Properties are a set of "run-time preferences" for connections which could still be adjusted when a connection is already established, but should ideally already be known during protocol/path selection The text goes on to state: With this wording, the reader can now reasonably conclude that the original Selection Properties that have resulted in a given Connection should remain available during the lifetime of that Connection, perhaps in form of a copy of the original data structure. So far so straight forward. In however, this conclusion is called into question. After the text has gone on to introduce the 5 different Preference Levels, it states At this point, the reader becomes confused. Why is the text talking about "many properties" that can no longer be changed, instead of relying on the earlier, nice and clear distinction between Selection and Connection Properties? Where earlier, Selection Properties were said to remain readable, now they are only queryable? The type of a Selection Property that has been "applied" mutates from a Preference Level to become a Boolean? Are "applied" Selection Properties still Selection Properties? Shouldn't they better be referred to using a different term? So the original Selection Preferences that resulted in the current Connection are not available after all? Only the (Boolean) Properties of the chosen Protocol can be "queried"? But wait, the text goes on: This is a complicated way of saying that the values only reflect the actual Properties of the chosen Connection and (in direct contradiction to the previous paragraph) do not actually indicate whether a Selection Property has also been "applied" or not. (A Boolean only carries exactly one bit of information after all.) In other words, the Protocol Properties can be queried. The usefulness of this is probably limited however.


Question: more. connection-props provides a list of Connection Properties, while <del> Selection Properties are listed in the subsections below.  Many properties are only considered during establishment, and can not be changed after a Connection is established; however, they can still be queried.  The return type of a queried Selection Property is Boolean, where "true" means that the Selection Property has been applied and "false" means that the Selection Property has not been applied.  Note that "true" does not mean that a request has been honored.  For example, if "Congestion control" was requested with preference level "Prefer", but congestion control could not be supported, querying the "congestionControl" property yields the value "false".  If the preference level "Avoid" was used for "Congestion control", and, as requested, the Connection is not congestion controlled, querying the "congestionControl" property also yields the value "false". </del> <ins> Selection Properties are listed in the subsections below.  Selection Properties are only considered during establishment, and can not be changed after a Connection is established.  After a Connection is established, Selection Properties can only be read to check the properties used by the Connection.  Upon reading, the Preference type of a Selection Property changes into Boolean, where "true" means that the selected Protocol Stack supports the feature or uses the path associated with the Selection Property, and "false" means that the Protocol Stack does not support the feature or use the path. Implementations of Transport Services systems may alternatively use the two Preference values "Require" and "Prohibit" to represent "true" and "false", respectively. </ins> An implementation of the Transport Services API must provide sensible defaults for Selection Properties.  The default values for each

If we already know that our Connection is using, e.g., TCP, we don't have to issue any "queries" to know that the Connection offers reliable transport, is subject to congestion control and preserves packet ordering. (This is indeed how I have chosen to implement this. The chosen Protocol can be queried for the Properties it inherently has. In the Preconnection phase, the Selection Preferences are matched against these and any / conflict results in that Protocol being dropped from consideration.) Hoping not to be unreasonable (or somehow block-headed), I have the following suggestions Either introduce a new term for Properties that have been "applied", or Use the term "Preferences" (e.g., "Selection Preferences", "Connection Preferences") to refer to a collection of adjustable "Settings" and the term "Properties" to refer to measured or queried values that are actual Properties of underlying Connections and Protocols Go into a bit more detail about what the draft really means when talking about "querying" Properties (versus setting them), maybe even in terms of exemplary interactions with Property data structures. (After all, the draft elsewhere goes into considerable detail with it's exemplary Event-based system) Think about whether it in general would clear things up when the explicit notion of Protocol Properties as a (static) counterpoint to (adjustable) Selection Properties is introduced
(Replying as an individual and co-author) Thanks for raising this issue! Yes, this matches my understanding is well. If the later text confuses this issue for the reader, then perhaps we'll need to tweak it. I'd say that Selection Properties can no longer be changed, Connection Properties still can be changed (though maybe changing a Connection Property later would not have any effect, e.g., if Capacity Profile changes but was only taken into account when selecting a path). Perhaps the text should reflect that. For me, these are synonyms, whereby a "query" is what the application has to do in order to read the properties. Perhaps the "queried" should become "read" to avoid confusion. That is indeed how I think of it on a conceptual level, but I understand how this might confuse implementers, especially if they can't just change a data type of a property. In the , we define Protocol Stack as a Transport Services implementation concept, and we talk about a certain protocol stacks providing certain features (see .


Question: more. connection-props provides a list of Connection Properties, while <del> Selection Properties are listed in the subsections below.  Many properties are only considered during establishment, and can not be changed after a Connection is established; however, they can still be queried.  The return type of a queried Selection Property is Boolean, where "true" means that the Selection Property has been applied and "false" means that the Selection Property has not been applied.  Note that "true" does not mean that a request has been honored.  For example, if "Congestion control" was requested with preference level "Prefer", but congestion control could not be supported, querying the "congestionControl" property yields the value "false".  If the preference level "Avoid" was used for "Congestion control", and, as requested, the Connection is not congestion controlled, querying the "congestionControl" property also yields the value "false". </del> <ins> Selection Properties are listed in the subsections below.  Selection Properties are only considered during establishment, and can not be changed after a Connection is established.  After a Connection is established, Selection Properties can only be read to check the properties used by the Connection.  Upon reading, the Preference type of a Selection Property changes into Boolean, where "true" means that the selected Protocol Stack supports the feature or uses the path associated with the Selection Property, and "false" means that the Protocol Stack does not support the feature or use the path. Implementations of Transport Services systems may alternatively use the two Preference values "Require" and "Prohibit" to represent "true" and "false", respectively. </ins> An implementation of the Transport Services API must provide sensible defaults for Selection Properties.  The default values for each

Perhaps we could rephrase this part of the API draft to use that terminology, e.g., the application can query the actually used protocol stack and then know which Transport Features it supports. I would strongly prefer using our existing terminology to introducing yet another term. Good question. I vaguely remember discussing this, and I think folks felt like querying the Selection Properties that the application had set was not very useful at that stage. The other text you quoted indeed sounds a bit complicated and maybe it can be reworded to be clearer. Curious to hear what my co-authors and/or other TAPS participants think!
I completely second what NAME wrote. With regards to querying the Transport Features selected vs. getting the preferences provided earlier, I remember we had lengthy discussions and somewhat converged to the current state. Primary arguments ware Multiple read/query variants are confusing Original Preferences are not really useful - if you really want to read them later, keep the Preferences Object Constrained implementations don't want to be forced to store them. NAME based on these arguments, what option would you prefer a) different get/query operations of selection properties after the connection has been set up b) the current way of "mutating" preferences with clearer description in the text
Just to add: having finally gotten around to carefully reading this, I also completely agree with everything NAME wrote. This is exactly how I would have answered, and her suggestions are exactly what I think should be done to address these comments. I also agree with NAME that these were the arguments regarding querying the querying issue, and I agree with the arguments as well. The quoted text containing the example is a great catch! Such a terribly convoluted paragraph. I have a nagging feeling that this was my fault! :-(
PR tries to solve this; the PR itself contains a full explanation of my rationale for the changes. Please take a look!
Great, this looks good to me now. I think now it is simple enough that we don't need an example anymore.Looks good, one clarification suggestedWorks for me (with NAME changes). I would propose a slight rewording -> and add a hint that this exposing can also be implemented differently.


Question: then the server SHOULD change the status of the application to "invalid" and MAY delete the application resource. <del> The server SHOULD issue the requested certificate and update the </del> <ins> The server MUST issue the requested certificate and update the </ins> application resource with a URL for the certificate as soon as the client has fulfilled the server's requirements.  If the client has already satisfied the server's requirements at the time of this request (e.g., by obtaining authorization for all of the identifiers <del> in the certificate in previous transactions), then the server MAY </del> <ins> in the certificate in previous transactions), then the server MUST </ins> proactively issue the requested certificate and provide a URL for it in the "certificate" field of the application.  The server MUST, however, still list the satisfied requirements in the "requirements"

Based on the acme mailing list discussion[0] on "proactive" vs "on-finalization" issuance it seems there is more support for the proactive approach. Speaking on behalf of Let's Encrypt and the Boulder developers we're willing to compromise and support proactive issuance as the sole issuance method in order to simplify the protocol & implementations. This PR changes the language around certificate issuance to reflect that the server MUST issue the certificate proactively once all the required challenges for an application have been fulfilled. The open issue corresponding to making this decision is removed now that there is one supported option. In an effort to close out open questions around applications this commit also removes the open issue around multiple certificates per application. If there is a demand for automating repeat issuance there should be a new thread started with a concrete proposal. 0: URL
NAME apologies! I missed your comments until today. Both are resolved in URL Thank you for the feedback.
Oh! They were fresh and I misread the dates. Not such a bad turn around after all :-)
NAME Fantastic, thanks. Merging. Hi folks, I wanted to revisit a discussion on the server proactively issuing certificates. Section 4, "Protocol Overview"[0] currently has a paragraph that reads: the the application be to the There is also an "Open Issue" remark related to proactive issuance in Section [1]. I think the specification should decide whether proactive issuance or on-finalization issuance should be used instead of allowing both with no indication to the client which will happen. It's the preference of Let's Encrypt that the specification only support on-finalization issuance. This is cheaper to implement and seems to be the path of least surprise. It also seems to better support large volume issuance when the client may want explicit control over when the certificates for multiple applications are issued. In the earlier "Re: [Acme] Preconditions" thread[2] Andrew Ayer seems to agree that there should be only one issuance method to simplify client behaviours, though he favours proactive issuance instead of on-finalization issuance. While it saves a round-trip message I'm not sure that this alone is convincing enough to choose proactive issuance as the one issuance method. What are the thoughts of other list members? Daniel/cpu [0] URL [1] URL [2] URL


Question: still being transmitted to the cache, and while the cache does not yet know the size of the object.  Some of the popular caching systems were designed around cache footprint and had deeply ingrained <del> assumptions about knowing the size of objects being stored, so the change in design requirements in long-established systems caused some errors in production.  Incidents occurred where a transmission error in the connection from the upstream source to the cache could result in the cache holding a truncated segment and transmitting it to the end user's device.  In this case, players rendering the stream often had the video freeze until the player was reset.  In some cases the truncated object was even cached that way and served later to other players, causing continued stalls at the same spot in the video for all players playing the segment delivered from that cache node. </del> <ins> assumptions about knowing the size of objects that are being stored, so the change in design requirements in long-established systems caused some errors in production.  Incidents occurred where a transmission error in the connection from the upstream source to the cache could result in the cache holding a truncated segment and transmitting it to the end user's device.  In this case, players rendering the stream often had the video freeze until the player was reset.  In some cases the truncated object was even cached that way and served later to other players as well, causing continued stalls at the same spot in the video for all players playing the segment delivered from that cache node. </ins> 3.5.

Fixed a few typos, otherwise ready to merge.
Merging on Ali's review.
From NAME (URL) (In Section 3.6. Unpredictable Usage Profiles / Section 3.7. Extremely) Unpredictable Usage Profiles I am not fully convinced by the distinction between "unpredictable" and "extremely unpredictable". To me, these two sections could be merged and maybe also be shortened. More specifically, Section 3.7 lists a lot of statistics from the past. What is IMHO a bit missing in Section 3.7 are actual operational considerations. For instance, are there any lessons learnt for the future? Note that Section 3.6 has a reasonable conclusion at the end. Reviewer: Michael Scharf Review result: Ready with Issues This document has been reviewed as part of the transport area review team's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors and WG to allow them to address any issues raised and also to the IETF discussion list for information. When done at the time of IETF Last Call, the authors should consider this review as part of the last-call comments they receive. Please always CC EMAIL if you reply to or forward this review. This informational document surveys network and transport protocol issues that affect quality of experience for streaming applications, in particular video. The overview covers many topics across different technologies. Readers may only be familiar with a subset of these topics and could therefore learn quite a bit from this kind of tutorial. Nonetheless, it remains somewhat unclear what the actual objective of some of the text is. For some topics, quite a bit of technical background is provided, but the discussion is not really comprehensive. In many sections, the document neither derives technical challenges, nor system/protocol requirements, nor practical usage guidance. It is just a kind of tutorial. Quite a bit of text also presents ongoing IETF work, and an RFC with this scope may thus get outdated soon. Section 6.2 deals with topics owned by TCPM. In similar past documents, I have asked for a TCPM presentation prior to an IETF last call in order to ensure that owners of running code are in the loop. I believe this strategy has worked well in the past.


Question: still being transmitted to the cache, and while the cache does not yet know the size of the object.  Some of the popular caching systems were designed around cache footprint and had deeply ingrained <del> assumptions about knowing the size of objects being stored, so the change in design requirements in long-established systems caused some errors in production.  Incidents occurred where a transmission error in the connection from the upstream source to the cache could result in the cache holding a truncated segment and transmitting it to the end user's device.  In this case, players rendering the stream often had the video freeze until the player was reset.  In some cases the truncated object was even cached that way and served later to other players, causing continued stalls at the same spot in the video for all players playing the segment delivered from that cache node. </del> <ins> assumptions about knowing the size of objects that are being stored, so the change in design requirements in long-established systems caused some errors in production.  Incidents occurred where a transmission error in the connection from the upstream source to the cache could result in the cache holding a truncated segment and transmitting it to the end user's device.  In this case, players rendering the stream often had the video freeze until the player was reset.  In some cases the truncated object was even cached that way and served later to other players as well, causing continued stalls at the same spot in the video for all players playing the segment delivered from that cache node. </ins> 3.5.

Having said this, as TSV-ART reviewer I don't strongly disagree with a publication. All these issues may just be OK for an informational RFC. Some more specific comments: Section 3.2.1. Recognizing Changes from an Expected Baseline This section apparently assumes relatively static path properties, e.g., fixed network connectivity. It would be more useful to analyze the impact of Wifi and 4G/5G networks in one place. Some of this follows later in sections 3.2.1 and Yet, the split between these three sections is unclear. Having a discussion about today's Internet path characteristics and the dynamics at one place could be more useful. The text could also better distinguish between what matters to endpoints and considerations relevant only for middleboxes (such as passive monitors). Section 3.3 Path Requirements The statement "to find the bandwidth requirements for a router on the delivery path" may assume that the bottleneck on the path will be routers. Yet, on a path the bottlenecks could also be a link layer device (e.g., an Ethernet Switch, a Wifi access point, etc.). RFC 6077 (specifically Section 3.1.3) also explains that issue. A better wording may be "to find the bandwidth requirements for a delivery path". Section 3.6. Unpredictable Usage Profiles / Section 3.7. Extremely Unpredictable Usage Profiles I am not fully convinced by the distinction between "unpredictable" and "extremely unpredictable". To me, these two sections could be merged and maybe also be shortened. More specifically, Section 3.7 lists a lot of statistics from the past. What is IMHO a bit missing in Section 3.7 are actual operational considerations. For instance, are there any lessons learnt for the future? Note that Section 3.6 has a reasonable conclusion at the end. Section 4. Latency Considerations and Section 4.1. Ultra Low-Latency I am surprised by the definition "ultra low-latency (less than 1 second)", as well as some of the other numbers. For other real-time communication use cases, "ultra low-latency" would probably imply a latency requirement of the order of one millisecond.


Question: still being transmitted to the cache, and while the cache does not yet know the size of the object.  Some of the popular caching systems were designed around cache footprint and had deeply ingrained <del> assumptions about knowing the size of objects being stored, so the change in design requirements in long-established systems caused some errors in production.  Incidents occurred where a transmission error in the connection from the upstream source to the cache could result in the cache holding a truncated segment and transmitting it to the end user's device.  In this case, players rendering the stream often had the video freeze until the player was reset.  In some cases the truncated object was even cached that way and served later to other players, causing continued stalls at the same spot in the video for all players playing the segment delivered from that cache node. </del> <ins> assumptions about knowing the size of objects that are being stored, so the change in design requirements in long-established systems caused some errors in production.  Incidents occurred where a transmission error in the connection from the upstream source to the cache could result in the cache holding a truncated segment and transmitting it to the end user's device.  In this case, players rendering the stream often had the video freeze until the player was reset.  In some cases the truncated object was even cached that way and served later to other players as well, causing continued stalls at the same spot in the video for all players playing the segment delivered from that cache node. </ins> 3.5.

For instance, isochronous traffic for motion control in industrial networks may require a latency of 1 ms, and such "ultra-low latency" requirements are discussed elsewhere, e.g., in the DetNet WG. The terminology in this section should be better explained to readers dealing with networked systems with much harder latency requirements. And a reference should be added for these definitions in the context of video streaming. Section 5.5.2 Head-of-Line Blocking If Head-of-Line Blocking is indeed a relevant operational problem, it would be useful to add a corresponding reference (e.g., with measurements). Section 5.5.3. Wide and Rapid Variation in Path Capacity The statement "As many end devices have moved to wireless connectivity for the final hop (Wi-Fi, 5G, or LTE), new problems in bandwidth detction have emerged from radio interference and signal strength effects." could be moved to earlier parts of the document. Quite a bit of new computers apparently only have Wifi connectivity and no Ethernet port, i.e., Wifi may just be their default. Also, wireless may not only be used on the last hop, for instance in meshed setups. This may make the problem even harder. Section 6. Evolution of Transport Protocols and Transport Protocol Behaviors I really wonder whether UDP vs. TCP vs. QUIC is actually the relevant distinction. What may actually matter are the transport services provided by the protocol stack (e.g., RFC 8095). I fully agree to a related comment in the INTDIR review. Section 6.1. UDP and Its Behavior UDP is also used for encrypted tunnels (OpenVPN, Wireguard, etc.). Does encrypted tunneling really have no operational impact on streaming apps other than circuit breakers? (I am thinking about 4K streaming over OpenVPN and the like.) Section 6.2. TCP and Its Behavior This text should IMHO be presented and be discussed in TCPM. Personally, I am not convinced that this document is a good place for discussing the long history of TCP congestion control. If the objective of the document is to provide a tutorial, IMHO it would be more useful to briefly explain the state-of-the-art in year 2022.


Question: still being transmitted to the cache, and while the cache does not yet know the size of the object.  Some of the popular caching systems were designed around cache footprint and had deeply ingrained <del> assumptions about knowing the size of objects being stored, so the change in design requirements in long-established systems caused some errors in production.  Incidents occurred where a transmission error in the connection from the upstream source to the cache could result in the cache holding a truncated segment and transmitting it to the end user's device.  In this case, players rendering the stream often had the video freeze until the player was reset.  In some cases the truncated object was even cached that way and served later to other players, causing continued stalls at the same spot in the video for all players playing the segment delivered from that cache node. </del> <ins> assumptions about knowing the size of objects that are being stored, so the change in design requirements in long-established systems caused some errors in production.  Incidents occurred where a transmission error in the connection from the upstream source to the cache could result in the cache holding a truncated segment and transmitting it to the end user's device.  In this case, players rendering the stream often had the video freeze until the player was reset.  In some cases the truncated object was even cached that way and served later to other players as well, causing continued stalls at the same spot in the video for all players playing the segment delivered from that cache node. </ins> 3.5.

Some further specific comments on TCP congestion control: It is surprising that RFC 5681 is not referenced.793bis has normative statements regarding congestion control, and most stacks are compatible to what is written in 793bis. Several operating systems use CUBIC by default and support standard Reno. Another general good reference for TCP standards is RFC 7414.Does ECN, DCTCP, etc. really not matter at all, for instance, if a data center hosts video playout servers? Section 6.3. QUIC and Its Behavior As already noted, the discussion about head-of-line-blocking would really benefit from backing by a reference. Section 7. Streaming Encrypted Media As far as I know, streaming users sometimes use encrypted tunnels such as OpenVPN or WireGuard (or IPsec) to access video content. I may miss something, but it is unclear to me how that fits into the categories presented in Section


Question: Outer Observe value, it stops processing the message, as specified in ver-res. <del> It the server accepts the Observe registration, a Partial IV must be </del> <ins> In order to support Observe processing in OSCORE-unaware intermediaries, for messages with the Observe option the Outer Code SHALL be set to 0.05 (FETCH) for requests and to 2.05 (Content) for responses. 4.1.3.4.2. It the server accepts an Observe registration, a Partial IV must be </ins> included in all notifications (both successful and error).  To secure the order of notifications, the client SHALL maintain a Notification Number for each Observation it registers.  The Notification Number is

This PR should (hopefully) conclude the main rewrite of Observe which was triggered by the security analysis and additional reviews of Observe. It should (hopefully) now be clear what part of the Observe related processing can be omitted in case Observe is not supported or in case intermediaries are not used. A new appendix E is covering the latter case.


Question: of a codepoint in the 0-63 range to replace the provisional codepoint described above. <del> 9.2. </del> <ins> 10.2. </ins> This document registers a new value in the "QUIC Transport Error Codes" registry maintained at <<https://www.iana.org/assignments/

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: Verify that the signature on the KeyPackage is valid using the public key in "leaf_node.credential". <ins> Verify that the value of "leaf_node.public_key" is different from the value of the "init_key" field. </ins> 11.2. Within MLS, a KeyPackage is identified by its hash (see, e.g.,

This change ensures that the "init" key pair associated to the key package is one-time-use, at least to the degree that KeyPackages are one-time-use. The init key pair is used to encrypt/decrypt the Welcome message, then never again. The main drawback is requiring the KeyPackage sender to generate an additional key pair, which requires more computation and more entropy.


Question: Protocol-specific Properties MUST use the protocol acronym as the Namespace (e.g., a "tcp" Connection could support a TCP-specific <del> Transport Property, such as the user timeout value, in a protocol- specific property called "tcp.userTimeoutValue" (see tcp-uto). </del> <ins> Transport Property, such as the user timeout value, in a Protocol- specific Property called "tcp.userTimeoutValue" (see tcp-uto). </ins> Vendor or implementation specific properties MUST use a string identifying the vendor or implementation as the Namespace.

We don't have "Protocol Properties" - two occurrences in -interface should really refer to "protocol-specific Properties", and two occurrences in -impl should really refer to properties.
URL Are Protocol Specific Properties and Protocol Properties same or different? Also note that we are first time defining the Protocol Properties in the interface document ( described along with Connection Properties) and not introduced in the architecture document. I think we should be clear about what we are defining where and describing where. I would suggest use of cross reference rather describing everything again and again, which might create confusion and inconsistency.
Oh, this seems like a mistake (great catch, thanks!) - "Protocol Properties" don't exist, I think we only have "protocol-specific Properties".
I caught this when reading the implementation doc. So it should be fixed there as well.


Question: not want an account to be created if one does not already exist, then it SHOULD do so by sending a POST request to the new-account URL with a JWS whose payload has an "only-return-existing" field set to "true" <del> ({"only-return-existing": true}). </del> <ins> ({"only-return-existing": true}).  If a client sends such a request and an account does not exist, then the server MUST return an error response with status code 400 (Bad Request) and type "urn:ietf:params:acme:error:accountDoesNotExist". </ins> 7.3.2.

Is 200 really correct? This seems like a 404 maybe? Also we should specify the body (empty).
Would a problem document be appropriate (with either a pre-existing ACME error type or a new one like "accountDoesNotExist")?
404 talks about the effective request URI, so that's not going to work. I think that a 400 would be better on the basis that the request checked, but failed (NAME suggestion is a fine enhancement). The reason you make this request is to check; and having a 4xx series code is easier to test than the absence of a header field.
Thanks NAME and NAME implemented this in the latest commit.
As discussed; this is fine.


Question: Fields and variables may be assigned a fixed value using "=", as in: <del> 3.7.1. </del> <ins> 3.8. </ins> Defined structures may have variants based on some knowledge that is available within the environment.  The selector must be an enumerated

Variants is not a subsection of Constants; just have them all be subsections of same depth within Presentation Language URL


Question: find out the plaintext by correlation between the question and the length. <del> The content and length of the "padding" field in "MLSCiphertextContent" can be chosen at the time of message encryption by the sender.  It is recommended that padding data is comprised of zero-valued bytes and follows an established deterministic padding scheme. </del> <ins> The length of the "padding" field in "MLSCiphertextContent" can be chosen at the time of message encryption by the sender.  Senders may use padding to reduce the ability of attackers outside the group to infer the size of the encrypted content. </ins> 16.2.

Also requires that padding be all-zero. Before, the sender was allowed to put arbitrary octets in there.
Looks good to me. NAME I think this covers your issue on the mailing list
Discussed at 19 May interim. Decision to merge.
As discussed , we should refactor so that the padding is not length-delimited, something like: In the MLSCiphertextContent struct we have a field for padding represented using a variable-size vector which helps hide information about the length of content; notably application messages. But because of the way we encode variable-size vectors it turns out you can't actually pad the rest of the content with certain number of bytes: namely 0, 65, 16386, 16387. (E.g. if you pad with a vector of 63 bytes the TLS encoding actually produces 64 bytes for padding: 63 bytes + 1 length byte. But if you pad with 64 bytes you end up with a 66 byte encoding as now you need 2 bytes for the length. Not being able to pad with 0 is OK. But 65 is kind of annoying. E.g. if you want to pad to a target content length X bytes then if the rest of the content ends up being X-65 bytes long you are out of luck. (Assuming I'm right about how this all works) it seems a bit silly to me for a padding scheme to have somewhat arbitrary gaps like that; especially at a not unreasonable number of bytes to want to pad with. If I didn't miss something, and you all agree that its better to avoid having gaps like that then how about represent padding as, say, a fixed length vector's? Joël Amazon Development Center Austria GmbH Brueckenkopfgasse 1 8020 Graz Oesterreich Sitz in Graz Firmenbuchnummer: FN 439453 f Firmenbuchgericht: Landesgericht fuer Zivilrechtssachen Graz


Question: without accompanying evidence about its validity - used as proof of identity. <del> The Attester is issued with a credential by the Endorser that is randomised and then used to anonymously confirm the validity of their evidence.  The evidence is verified using the Endorser's public key. </del> _mandatory_ A statement representing an identifier list that MUST be

… 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: without accompanying evidence about its validity - used as proof of identity. <del> The Attester is issued with a credential by the Endorser that is randomised and then used to anonymously confirm the validity of their evidence.  The evidence is verified using the Endorser's public key. </del> _mandatory_ A statement representing an identifier list that MUST be

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: without accompanying evidence about its validity - used as proof of identity. <del> The Attester is issued with a credential by the Endorser that is randomised and then used to anonymously confirm the validity of their evidence.  The evidence is verified using the Endorser's public key. </del> _mandatory_ A statement representing an identifier list that MUST be

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: without accompanying evidence about its validity - used as proof of identity. <del> The Attester is issued with a credential by the Endorser that is randomised and then used to anonymously confirm the validity of their evidence.  The evidence is verified using the Endorser's public key. </del> _mandatory_ A statement representing an identifier list that MUST be

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: without accompanying evidence about its validity - used as proof of identity. <del> The Attester is issued with a credential by the Endorser that is randomised and then used to anonymously confirm the validity of their evidence.  The evidence is verified using the Endorser's public key. </del> _mandatory_ A statement representing an identifier list that MUST be

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: without accompanying evidence about its validity - used as proof of identity. <del> The Attester is issued with a credential by the Endorser that is randomised and then used to anonymously confirm the validity of their evidence.  The evidence is verified using the Endorser's public key. </del> _mandatory_ A statement representing an identifier list that MUST be

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: 3. <ins> Endpoints advertise their support of the extension described in this document by sending the following transport parameter: A variable-length integer representing the minimum amount of time in microseconds by which the endpoint can delay an acknowledgement.  Values of 0 and 2^14 or greater are invalid, and receipt of these values MUST be treated as a connection error of type PROTOCOL_VIOLATION. An endpoint's min_ack_delay MUST NOT be greater than the its max_ack_delay.  Endpoints that support this extension MUST treat receipt of a min_ack_delay that is greater than the received max_ack_delay as a connection error of type PROTOCOL_VIOLATION.  Note that while the endpoint's max_ack_delay transport parameter is in milliseconds (Section 18.2 in QUIC-TRANSPORT), min_ack_delay is specified in microseconds. 4. </ins> Delaying acknowledgements as much as possible reduces both work done by the endpoints and network load.  An endpoint's loss detection and congestion control mechanisms however need to be tolerant of this

This PR changes a few things: Introduces a TP for negotiating extension use Changes to Makes the fields required Specifies invalid values
I'm merging this, let's address issues in later PRs.
I think it'll be easier to make both parameters required. Not doing so saves 1 to 2 bytes, which is really not much in a frame I expect will be sent a few times a connection. Also, I think 0 should be an invalid value for both params, and 1 should be invalid for the number of packets, though I can see someone arguing that point.
addresses these issues, with the exception that 1 is allowed for packet tolerance. I think that's actually useful for some startup schemes, so we shouldn't disallow it.


Question: identifiers have privacy implications; see endpoint-privacy. Each endpoint SHOULD know the identifier of the other endpoint with <del> which its wants to connect and SHOULD compare it with the other </del> <ins> which it wants to connect and SHOULD compare it with the other </ins> endpoint's identifier used in ImportedIdentity.context.  It is however important to remember that endpoints sharing the same group PSK can always impersonate each other.

Address comments from IESG evaluation. Due to the holiday season, we may not get prompt confirmation that these changes fully resolve the comments.


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

I've found a few typos and fixed some sentences that didn't quite make sense. I don't think the meaning has been changed in any significant way.


Question: "struct { Extension extensions<0..2^32-1>; } GroupContextExtensions; " <del> A member of the group applies a GroupContextExtensions proposal by removing all of the existing extensions from the GroupContext object for the group and replacing them with the list of extensions in the proposal.  (This is a wholesale replacement, not a merge.  An extension is only carried over if the sender of the proposal includes it in the new list.)  Note that once the GroupContext is updated, its inclusion in the confirmation_tag by way of the key schedule will confirm that all members of the group agree on the extensions in use. </del> <ins> A member of the group applies a GroupContextExtensions proposal with the following steps: If the new extensions include a "required_capabilities" extension, verify that all members of the group support the required capabilities (including those added in the same commit, and excluding those removed). Remove all of the existing extensions from the GroupContext object for the group and replacing them with the list of extensions in the proposal.  (This is a wholesale replacement, not a merge.  An extension is only carried over if the sender of the proposal includes it in the new list.) Note that once the GroupContext is updated, its inclusion in the confirmation_tag by way of the key schedule will confirm that all members of the group agree on the extensions in use. </ins> 11.1.9.

This PR adds a RequiredCapabilities extension that allows the members of a group to impose a requirement that new joiners support certain capabilities. The extension is carried in the GroupContext and verified at Add time (including on external commits). In the interim 2021-10-04, we briefly discussed whether this mechanism needed to be included in the core protocol. Because of its interactions with Add and GroupContextExtensions proposals, it seems worth having in the main protocol.
s currently have two usages in the spec: Pre-published key packages that you can download and put in a leaf when adding a new member leaf node content that you update when doing a full Currently, things have been designed to use only one structure for both uses, leading to some weirdness such as: and are useful in the usage 1, but are parameters of the group in usage 2. is a good name in usage 1, but would better be named in usage 2. some data is important in usage 2 and have no meaning in usage 1, hence they were designed as "mandatory-when-updating extensions" (such as , and we were also discussing about adding the in to help prevent cross-group attacks) How about using different structures for these? // Essentially identical to KeyPackage struct { ProtocolVersion version; CipherSuite ciphersuite; HPKEPublicKey hpkeinitkey; opaque endpointid; Credential credential; Extension extensions; opaque signature; } PrePublishedKeyPackage; struct { HPKEPublicKey hpkekey; opaque endpointid; Credential credential; opaque parenthash; opaque groupid; Extension extensions; opaque signature; } LeafNodeContent; enum { reserved(0), prepublishedkeypackage(1), leafnodecontent(2), (255) } LeafNodeType; struct LeafNode { // This is not included in the signature, but with the "unambiguous signature" PR that's not a problem LeafNodeType type; select(URL) { case prepublishedkeypackage: PrePublishedKeyPackage data; case leafnode_content: LeafNodeContent data; } } What would you think about refactoring like this?
If we're doing this, I'd suggest including a dedicated public key to encrypt Welcome messages to for the . NAME suggested this at some point.


Question: "struct { Extension extensions<0..2^32-1>; } GroupContextExtensions; " <del> A member of the group applies a GroupContextExtensions proposal by removing all of the existing extensions from the GroupContext object for the group and replacing them with the list of extensions in the proposal.  (This is a wholesale replacement, not a merge.  An extension is only carried over if the sender of the proposal includes it in the new list.)  Note that once the GroupContext is updated, its inclusion in the confirmation_tag by way of the key schedule will confirm that all members of the group agree on the extensions in use. </del> <ins> A member of the group applies a GroupContextExtensions proposal with the following steps: If the new extensions include a "required_capabilities" extension, verify that all members of the group support the required capabilities (including those added in the same commit, and excluding those removed). Remove all of the existing extensions from the GroupContext object for the group and replacing them with the list of extensions in the proposal.  (This is a wholesale replacement, not a merge.  An extension is only carried over if the sender of the proposal includes it in the new list.) Note that once the GroupContext is updated, its inclusion in the confirmation_tag by way of the key schedule will confirm that all members of the group agree on the extensions in use. </ins> 11.1.9.

It gives us better FS guarantees, because the receiver of the can delete the corresponding private key immediately after decryption, while they might have to keep the other key around for a bit until they can actually issue an update. This might also help clarify .
Ties into as well because is an example of an extension that is required and should be a field instead
NAME one concern I have is how is that field in created?
When sending a full , the participant includes a new in the (it replaces the field). It computes the signature with where: corresponds to all the fields of except (the usual thing) comes from
What about the scenario where Alice pulls down Bob's key package to add him to the group? In that case Alice can't do the conversion between formats on Bob's behalf.
Alice don't have to do the conversion, this is why either contain a (when adding someone to the group) or a (when updating your own key package).
Ah somehow I missed that part in your original post. Makes sense
I like this general direction. It solves a few things. Instead of having leaf nodes contain either a prepublished thing or a normal leaf node, how about having the prepublished thing wrap the leaf node thing? As a bonus, we get separation between the key pair used for Welcome encryption and the key pair that goes in the leaf for TreeKEM. Then when Alice adds Bob, she extracts his LeafNodeContent and sends that in the Add. That doesn't let the other members of the group verify that Alice did the right thing w.r.t. expiry, but I'm not heartbroken about that. We might also be able to remove the extensions field from the outer (KeyPackage) wrapping if we turn the extension into KeyPackage field. I expect we probably need leaf extensions, but would be open to making into a field.
Why not keep sending the KeyPackage in the Add? That wouldn't cost much and would allow everyone to validate the lifetime. Note, that the lifetime is crucial in achieving PCS for pre-published key material. If I compromise Bob and get hold of the private key material of a bunch of his KeyPackages, I can add "Bob" to any group I want as long as the Credential inside the LeafNodeContent remains valid and Bob doesn't revoke the LeafNodeContent somehow.


Question: "struct { Extension extensions<0..2^32-1>; } GroupContextExtensions; " <del> A member of the group applies a GroupContextExtensions proposal by removing all of the existing extensions from the GroupContext object for the group and replacing them with the list of extensions in the proposal.  (This is a wholesale replacement, not a merge.  An extension is only carried over if the sender of the proposal includes it in the new list.)  Note that once the GroupContext is updated, its inclusion in the confirmation_tag by way of the key schedule will confirm that all members of the group agree on the extensions in use. </del> <ins> A member of the group applies a GroupContextExtensions proposal with the following steps: If the new extensions include a "required_capabilities" extension, verify that all members of the group support the required capabilities (including those added in the same commit, and excluding those removed). Remove all of the existing extensions from the GroupContext object for the group and replacing them with the list of extensions in the proposal.  (This is a wholesale replacement, not a merge.  An extension is only carried over if the sender of the proposal includes it in the new list.) Note that once the GroupContext is updated, its inclusion in the confirmation_tag by way of the key schedule will confirm that all members of the group agree on the extensions in use. </ins> 11.1.9.

Also, we'll have to do this if we want to enable any member to send the Welcome message as you proposed here: URL
I agree that including inside is quite clean, but something is bothering me with this approach: I'd like that the is signed by the participant occupying that leaf, to protect against cross-group attacks. In the first message of this issue I did this by including in , but in fact we don't need to store it in the leaf, we just need to include it in the . In any case, if we want to include in the signature, we need a way to differentiate between leaves that triggered a commit and the ones that are "fresh". And for that I think using a tagged-union struct is the cleanest way to do it.
It always feels a bit lazy to use an extension (and implementations have to be careful to check for their presence), but we could use a extension in the same way that we use a extension. You will find both of them only on LeafContents that were updated at least once. Another result of including GroupId in the KeyPackage is that the signature will explicitly sign the and I'm not sure if that doesn't completely destroy any deniability guarantees we can still get from MLS.
I don't think there's really a good way to get the into the leaf. Because of prepublication, it would have to be optional, but in order to prevent attacks, you need rules to decide whether it's required in a given situation. It seems like the best you can do is basically TOFU: When you first get the tree, you can't validate whether the groupid should be in a given leaf or not Once you're a member, you require that groupid is sent in Update and UpdatePath.leafkey_package I could live with a solution of that character, but given it's a bit complex, might prefer to leave it out unless we get a useful property from it. NAME - Re: Sending KeyPackage in Add - Yep, that makes sense. So you would send KeyPackage in Add, and LeafNode in Update.
I tried to worked through what would be necessary to implement this. It looks like it would require some fairly invasive changes to be made to rationalize the document's structure before making this change. But those changes should probably be made anyway.