Question: 3.3. <del> The Transport Services API is envisioned as the abstract model for a family of APIs that share a common way to expose transport features and encourage flexibility.  The abstract API definition I-D.ietf- taps-interface describes this interface and how it can be exposed to application developers. Implementations that provide the Transport Services API I-D.ietf- taps-impl will vary due to system-specific support and the needs of the deployment scenario.  It is expected that all implementations of Transport Services will offer the entire mandatory API.  All implementations are expected to offer an API that is sufficient to use the distilled minimal set of features offered by transport protocols I-D.ietf-taps-minset, including API support for TCP and UDP transport.  However, some features provided by this API will not be functional in certain implementations.  For example, it is possible that some very constrained devices might not have a full TCP implementation beneath the API. To preserve flexibility and compatibility with future protocols, top- level features in the Transport Services API ought to avoid referencing particular transport protocols.  The mappings of these API features to specific implementations of each feature is explained in the I-D.ietf-taps-impl along with the implications of the feature on existing protocols.  It is expected that I-D.ietf-taps-interface will be updated and supplemented as new protocols and protocol features are developed. </del> <ins> A Transport Services implementation can select Protocol Stacks based on the Properties communicated by the application.  If two different Protocol Stacks can be safely swapped, or raced in parallel (see racing), then they are considered to be "equivalent".  Equivalent Protocol Stacks are defined as stacks that can provide the same transport properties and interface expectations as requested by the application. The following two examples show non-equivalent Protocol Stacks: If the application requires preservation of message boundaries, a Protocol Stack that runs UDP as the top-level interface to the application is not equivalent to a Protocol Stack that runs TCP as the top-level interface.  A UDP stack would allow an application to read out message boundaries based on datagrams sent from the remote system, whereas TCP does not preserve message boundaries on its own, but needs a framing protocol on top to determine message boundaries. If the application specifies that it requires reliable transmission of data, then a Protocol Stack using UDP without any reliability layer on top would not be allowed to replace a Protocol Stack using TCP. The following example shows equivalent Protocol Stacks: If the application does not require reliable transmission of data, then a Protocol Stack that adds reliability could be regarded as an equivalent Protocol Stack as long as providing this would not conflict with any other application-requested properties. To ensure that security protocols are not incorrectly swapped, Transport Services systems MUST only select Protocol Stacks that meet application requirements (I-D.ietf-taps-transport-security).  Systems SHOULD only race Protocol Stacks where the transport security protocols within the stacks are identical.  Transport Services systems MUST NOT automatically fall back from secure protocols to insecure protocols, or to weaker versions of secure protocols.  A Transport Services system MAY allow applications to explicitly specify that fallback to a specific other version of a protocol is allowed, e.g., to allow fallback to TLS 1.2 if TLS 1.3 is not available. 3.4. </ins> It is important to note that neither the Transport Services API I- D.ietf-taps-interface nor the Implementation document I-D.ietf-taps- impl define new protocols or protocol capabilities that affect what is communicated across the network.  Use of a Transport Services <del> system does not require that a peer on the other side of a connection </del> <ins> system MUST NOT require that a peer on the other side of a connection </ins> uses the same API or implementation.  A Transport Services system <del> acting as a connection initiator can communicate with any existing system that implements the transport protocol(s) selected by the Transport Services system.  Similarly, a Transport Services system acting as a listener can receive connections for any protocol that is supported by the system from existing initiators that implement the protocol, independent of whether the initiator uses Transport Services as well or not. </del> <ins> acting as a connection initiator is able to communicate with any existing system that implements the transport protocol(s) and all the required properties selected by the Transport Services system. Similarly, a Transport Services system acting as a listener can receive connections for any protocol that is supported by the system from existing initiators that implement the protocol, independent of whether the initiator uses a Transport Services system or not. In normal use, a Transport Services system SHOULD result in consistent protocol and interface selection decisions for the same network conditions given the same set of Properties.  This is intended to provide predictable outcomes to the application using the API. </ins> 4.

This is intended to provide predictable outcomes to the application using the transport service. I would then suggest to use lower case within other parts of the document - except were pointed to from here, (we could refer to the requirements subsection, if we thought necessary).
for discussion at the interim, but IMO we could start the interim with a PR based on these suggestions and work from there.
I suspect that we need more protocol-specific properties to be able to talk to various kinds of native protocol peers (other than TCP and UDP: these should already work fine with what we have, I believe). A concrete example: we're hiding stream numbers. In NEAT, we needed to make them configurable though, because we wanted a NEAT client to be able to talk to a native SCTP server, where an application may expect certain type of data to arrive via a certain stream number. I suspect that we may need something similar for a QUIC peer. Should we address this? (I'd say yes) How .. is it a protocol-specific (per-Message) property? (I'd say yes... and perhaps a per-Connection property too, with text explaining that the per-Message one automatically becomes the Connection default unless otherwise specified) What other such things are we missing... what other expectations may e.g. a native QUIC or SCTP application have that we just cannot fulfil with our current system?


Question: A TLSCiphertext record was received that had a length more than <del> 2^14+256 bytes, or a record decrypted to a TLSPlaintext record </del> <ins> 2^14 + 256 bytes, or a record decrypted to a TLSPlaintext record </ins> with more than 2^14 bytes.  This alert is always fatal and should never be observed in communication between proper implementations (except when messages were corrupted in the network).

NAME Quick PR for fix noted for PR plus a couple other small nits. Still on draft 08. Fix a typo. ("permittion" is not a word) Consistently use spaces around the "+" in "2^14 + 256". (some did; some didn't)


Question: process the Commit (i.e., not including any members being added or removed by the Commit). <ins> The sender of a Commit SHOULD NOT include any Update proposals that the sender themselves generated.  If sender generated one or more Update proposals during an epoch, then it SHOULD instead update its leaf and direct path by sending "path" field in the Commit. </ins> If there are multiple proposals that apply to the same leaf, the committer chooses one and includes only that one in the Commit, considering the rest invalid.  The committer MUST prefer any Remove

Any Update proposal for the sender is redundant if the Commit includes a .
This is true, but they're also harmless, since the information in the will overwrite all of their effects. Note that: A requirement to this effect would only be binding on a committer. The receiver of a Commit MUST process all of the referenced proposals, as prescribed in the Commit. A is required if a Commit covers Updates or Removes; if a Commit covers a self-Update, then it must have a . So there's no reasn to condition on "if a is included". This seems fine for some advisory text, but not an absolute prohibition.
The way I read Section 11.2 is that the receiver should verify that the committer has followed the rules, e.g. that the commit contains all valid proposals, etc., even if that is not explicit in the list of things the receiver of a commit should do. So any requirement on the committer would also affect the receiver. So if we mandate that a committer can't include self-updates if the path is populated, then it would be implicit that the receiver checks that the committer actually followed the rules when processing a commit. I'm not sure I understand your second point. My reasoning would be that if a committer wants to do an update, they would just include a path rather than an update proposal, which is redundant anyway.
Sorry NAME I missed that there was still conversation going on here before merging . On the latter point: All I'm saying is that there is no case where there is both (a) a self-update and (b) no . So you're always in the bad scenario :) In our Wire chat, you made a good point that repeated proposals for the same leaf are invalid, and self-Updates are effectively repeats of the . Reopening, will file a fresh PR to adjust the text.


Question: protocols and paths without requiring major changes to the application. <del> design explains the design principles behind the Transport </del> <ins> requirements explains the fundamental requirements for a Transport </ins> Services API.  These principles are intended to make sure that transport protocols can continue to be enhanced and evolve without <del> requiring too many changes by application developers. </del> <ins> requiring significant changes by application developers. </ins> concepts presents the Transport Services architecture diagram and defines the concepts that are used by both the API and

This proposal consolidates normative language into the section on design principles (now requirements), using the suggestions in .
Please review the latest updates!
Early art-art review of draft-ietf-taps-architecture My first observation and request is that the group rethink the separation of the architecture and interface documents. It is a warning-sign that the interface document is a normative reference for the architecture document. As the documents are currently constructed, a new reader cannot grasp the architecture without inferring some of it through reading the interface. Consider reformulating the architecture document as an overview - introduce principles, concepts, and terminology, but don't attempt to be normative. (There are signs that this may already be, or have been, a path the document was being pushed towards). If nothing else, rename it, and acknowledge that the actual architecture is specified using the interface definition. Note that the first sentence of the Overview in the interface document also highlights the current structural problem.
I don't entirely agree with this ART-ART comment: I think I might well agree with moving more of the description to this Arch document, but as discussed before, I also think it useful here to set the actual requirements for the architecture, and to define the architecture. It may need to be much clearer that this architecture consists of more the API.
For completeness, this is the first statement of the interface document review: This document reads fairly well. I have some structural concerns (see the early review of the architecture document). In particular I think this document contains the actual definition of the architecture and some of that is inferential.
Discussion at September 2021 interim: pass through this document with a view toward making it a high level introduction, not an architecture definition: "An Introduction to the Transport Services Architecture". remove normative language from this document (moving it to API, where necessary). move details not useful in a high level intro to API.
I disagree with this conclusion at first pass—we did a specific analysis and pass on this over a year ago, with PR . The normative language and the standards-track aspect was very intentional and something the WG had consensus on. The point is that the API is a specific incarnation of the TAPS architecture, but there are overarching architectural properties that go beyond a specific abstract API.
I completely agree with Tommy here, and recommend we fix this in . We should also of course check for any stray text or missing concepts.


Question: protocols and paths without requiring major changes to the application. <del> design explains the design principles behind the Transport </del> <ins> requirements explains the fundamental requirements for a Transport </ins> Services API.  These principles are intended to make sure that transport protocols can continue to be enhanced and evolve without <del> requiring too many changes by application developers. </del> <ins> requiring significant changes by application developers. </ins> concepts presents the Transport Services architecture diagram and defines the concepts that are used by both the API and

I think it would also be useful to somehow better explain that in figure 3 the API function is ONE part of the system.
See linked PR first please to see if this resolves this?
A PR was merged that addressed important text issues with separation of requirements and overview, and should more clearly set out that the requirements are for the system. The question of whether the overall TAPS systems requirements belong in this ID; the API; or a separate RFC needs some discussion based on the review, before this can be closed.
Many good text improvements in the PR NAME but I noticed two smaller updates in the PR that I think were incorrect. Fixed in
The review comment showed were many places where the wording of architecture can be improved. There are some high level principles that I think should remain in the architecture document. The decision in today's interim is to review the architecture to get this more into a shape that is valuable as a reference, and then check the updated draft.
I now suggest the issues are addressed and we close this issue without moving text between documents
I agree with that; closing.
Overall review: I think we need to keep the normative language for the key features that differentiate the API. I'd really like to use REQUIRED, RECOMMENDED, rather MUST and SHOULD - because these are not protocol operation requirements, but are implementation requirements to conform. This includes requirements based on Minset - where the WG dervied this API: This is after all why the WG worked on Minset as the basis of the API. I suggest we group all the requirements on architecture as short one or two sentence blocks (preferably as a bullet or definition list) collected into a single subsection, so they are easy to find and read and we say that these are the key architectural requirements. We insert this new requirements text either their own section, or in section 1.3 (although I am open to other places where we can call-out the architectural requirements). The following are key requirements, that define the TAPS architecture: It is RECOMMENDED that functionality that is common across multiple transport protocols is made accessible through a unified set of TAPS interface calls. As a baseline, a Transport Services system interface is REQUIRED to allow access to the minimal set of features offered by transport protocols {{?I-D.ietf-taps-minset}}.


Question: protocols and paths without requiring major changes to the application. <del> design explains the design principles behind the Transport </del> <ins> requirements explains the fundamental requirements for a Transport </ins> Services API.  These principles are intended to make sure that transport protocols can continue to be enhanced and evolve without <del> requiring too many changes by application developers. </del> <ins> requiring significant changes by application developers. </ins> concepts presents the Transport Services architecture diagram and defines the concepts that are used by both the API and

A Transport Services system automates the selection of protocols and features and network, based on a set of Properties supplied through the TAPS interface. It is RECOMMENDED that a Transport Services system offers Properties that are common to multiple transport protocols. Specifying common Properties enables a system to appropriately select between protocols that offer equivalent features. This design permits evolution of the transport protocols and functions without affecting the programs using the system. Specifying common Properties enables a Transport Services system to appropriately select an appropriate network interface. It is RECOMMENDED that a system offers Properties that are common to a variety network layer interfaces and paths. This design permits racing of different network paths without affecting the programs using the system. Applications using the Transport Services system interface are REQUIRED to be robust to the automated selection provided by the system, including the possibility to express requirements and preferences that constrain the choices that can be made by the system. If two different Protocol Stacks can be safely swapped, or raced in parallel (see Section 4.2.2), by the Transport Services system then they are considered to be "equivalent". Equivalent Protocol Stacks need to meet the requirements for racing specified in section XX. Applications using a Transport Services system MAY explicitly require or prevent the use of specific transport features (and transport protocols) and XXXinterfaces using the "REQUIRED" and "PROHIBIT" preferences. This allows an application to constrain the set of protocols and features that will be selected for the transport service. It is RECOMMENDED that the default usage by applications does not necessarily restrict this selection, so that the system can make informed choices (e.g., based on the availability of interfaces or set of transport protocols available for the specified remote endpoint). When a Transport Services system races between two different Protocol Stacks, both SHOULD use the same security protocols and options. However, a Transport Services system MAY race different security protocols, e.g., if the application explicitly specifies that it considers them equivalent. Transport Services systems MUST NOT automatically fall back from secure protocols to insecure protocols, or to weaker versions of secure protocols. A Transport Services system MAY allow applications to specify that fallback to a specific other version of a protocol is allowed. It is RECOMMENDED that in normal use, a Transport Services system is designed so that all selection decisions result in consistent choices for the same network conditions when they have the same set of preferences.


Question: protocols and paths without requiring major changes to the application. <del> design explains the design principles behind the Transport </del> <ins> requirements explains the fundamental requirements for a Transport </ins> Services API.  These principles are intended to make sure that transport protocols can continue to be enhanced and evolve without <del> requiring too many changes by application developers. </del> <ins> requiring significant changes by application developers. </ins> concepts presents the Transport Services architecture diagram and defines the concepts that are used by both the API and


Question: Server.  On the other hand, if the HNA signs the Homenet Zone itself, the zone would be collected by the Synchronization Server and directly transferred to the Public Authoritative Server(s).  These <del> policies are discussed and detailed in sec-dnssec-deplyment and sec- views. </del> <ins> policies are discussed and detailed in sec-dnssec-deplyment. </ins> 4.2.

…ument, dealing with issue
handling different views (7.0) .... some would like to have different views, This document deals with the view that the Internet gets from the CPE(s) only.


Question: Unlike CONNECT-UDP requests, which require specifying a target host, CONNECT-IP requests can allow endpoints to send arbitrary IP packets to any host.  The client can choose to restrict a given request to a <del> specific host or IP protocol by adding parameters to its request. When the server knows that a request is scoped to a target host or </del> <ins> specific prefix or IP protocol by adding parameters to its request. When the server knows that a request is scoped to a target prefix or </ins> protocol, it can leverage this information to optimize its resource allocation; for example, the server can assign the same public IP <del> address to two CONNECT-IP requests that are scoped to different hosts and/or different protocols. </del> <ins> address to two CONNECT-IP requests that are scoped to different prefixes and/or different protocols. </ins> CONNECT-IP uses URI template variables (client-config) to determine the scope of the request for packet proxying.  All variables defined

Instead of just an address / hostname, could we ask to open a tunnel to a prefix?
Tommy, can you please clarify the reasoning why this functionality is useful. Specifying the target as a subnet would to my understanding compared to a general IP tunneling address just restrict that the client will never try to send IP packets to any IP addresses outside of this subnet. And thus potentially enable serving multiple masque clients using restricted targets to share the source IP address. Is that the intention? Or is the intention here to have the masque server potentially redirect to another instance based on the target in the request?
This came up in a discussion—if we let you ask to connect to a specific hostname or address instead of all addresses (as we do today), we wondered if there was any need to connect to a subnet of addresses. This would be for connecting to an IPv6 /64, which is unique enough for a device, and doesn't require needing to assign an IP address exclusively to the client that is issuing the request.
I'm supportive of adding this if we can come up with an encoding that's not a pain to implement. For example slash with prefix length seems fine to me - the slash would be percent-encoded just like the IPv6 address colons are.
In relation to my just raised issue on source address validation if we add this functionality, I would think that the proxy would need to do destination or source address validation depending on direction of traffic to enforce the signalled aspect.


Question: If the server sends a Retry packet, it MUST use the original version. The client ignores Retry packets using other versions.  The client <del> MUST NOT use a different version in the subsequent Initial that contains the Retry token.  The server MAY encode the QUIC version in its Retry token to validate that the client did not switch versions, and drop the packet if it switched. </del> <ins> MUST NOT use a different version in the subsequent Initial packet that contains the Retry token.  The server MAY encode the QUIC version in its Retry token to validate that the client did not switch versions, and drop the packet if it switched. </ins> QUIC version 2 uses the same transport parameters to authenticate the Retry as QUIC version 1.  After switching to a negotiated version

here (URL) it is better that we call it QUIC version 1 not just QUIC. As later it is referred as QUIC version 1.here (URL) I would add reference to VN draft instead of calling it "that document"here (URL) i would add "packet" after "Initial" just to be clear, as we have now a initial version in VN draft.
Thanks, fixed here URL


Question: 4.3.1. <del> An endpoint can use the critical Default-Uri-Host Option to indicate the default value for the Uri-Host Options in the messages that it sends to the other endpoint.  Its value MUST be a valid value for the Uri-Host Option (Section 5.10.1 of RFC7252). For TLS, the base value for the Default-Uri-Host Option in the direction from the Connection Initiator to the Connection Acceptor is given by the SNI value. For WebSockets, the base value for the Default-Uri-Host Option in the direction from the Connection Initiator to the Connection Acceptor is given by the HTTP Host header field. The active value of the Default-Uri-Host Option is replaced each time the option is sent with a modified value.  Its starting value is its base value (if available). 4.3.2. </del> The sender can use the elective Max-Message-Size Option to indicate the maximum message size in bytes that it can receive.

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


Question: This document Both <ins> 7.5. The following entry is added to the "HTTP/3 Error Code" registry established by HTTP3: H3_WEBTRANSPORT_BUFFERED_STREAM_REJECTED 0x3994bd84 WebTransport data stream rejected due to lack of associated session. This document. </ins>

.
cc NAME NAME
Looks great!
For a simple application that wants to send "hello world" over a WebTransport stream, it would take a minimum of 2.5 round trips for the data to arrive on the server. This is still an improvement over WebSockets but I'm wondering if we could do better. If the client is able to create streams prior to receiving the CONNECT response, then it would remove a round trip. The server would need to buffer any data received on streams associated with an unknown WebTransport session. If the server responds with a non-200 status code, then these streams are discarded. I believe 0-RTT is disabled for WebTransport because CONNECT is not idempotent and would be subject to replay attacks. An idempotent CONNECT would remove a round trip when 0-RTT is used... although I'm not sure this is a good idea.
I think this is a reasonable optimization
The client requirement is odd in comparison to MASQUE / CONNECT-UDP which says "client can risk sending datagrams before getting a 200 response, a different response means that datagrams will be discarded". What is the motivation for the requirement in WebTransport? If you need some kind of ordering guarantees, then stream IDs provide that.
Discussed at IETF 110. There were no objections to buffering (with some limits), so I think we should go ahead and add it.
After the client initiates the WebTransport session by sending a CONNECT request, the server sends a 200 response and is free to create streams. This means that a server-initiated stream may arrive prior to the CONNECT response. Is the client able to infer that the session was successfully established, or does the client need to buffer this stream until it receives a proper response?
Since there are no ordering guarantees across streams on the receiver side, I'd say you have to buffer until the 200 is processed.
I agree with Lucas here. We also had a similar problem in QuicTransport (server has to buffer streams before checking the origin), and we handled it by buffering.
Discussed at IETF 110. There were no objections to buffering (with some limits), so I think we should go ahead and add it.


Question: for the "encrypted_client_hello" extension.  Clients MUST ignore any "ECHConfig" structure with a version they do not support. <del> The length, in bytes, of the next field. </del> <ins> The length, in bytes, of the next field.  This length field allows implementations to skip over the elements in such a list where they cannot parse the specific version of ECHConfig. </ins> An opaque byte string whose contents depend on the version.  For this specification, the contents are an "ECHConfigContents"

The goal here is really to provide more clarify about cardinality, if there's a better way or place to do that, that'd be fine.
I don't believe this is necessary. This idiom is well understood in TLS and this just appears to be excess verbiage.
Hiya, (As with all these PRs, I'm ok if they're not accepted...) For me, that is better than the original, but I do think we ought state the expected cardinality that implementers need to handle somewhere. I reckon it's better to not assume implementers are very familiar with SVCB as for libraries at least, the DNS stuff happens elsewhere. They will have to figure that out eventually, but better to say it somewhere explicitly I think, or we may face some important code base that doesn't handle >1 public key when it ought. Cheers, S.


Question: 7.3.3. <del> This method is indicated by "jwsd" in the "proof" field.  A JWS RFC7515 object is created as follows: </del> <ins> This method is indicated by the method value "jwsd".  This method defines no additional parameters.  A JWS RFC7515 object is created as follows: </ins> To protect the request, the JOSE header of the signature contains the following claims:

Expands the key parameter to allow it to be an object or a string, to facilitate methods with multiple parameters such as HTTPSig.
To edit notification comments on pull requests, go to your .
Some key proofing methods have additional options that could be signaled in the GNAP protocol structure. Notable, HTTP Message Signatures has the ability to use different HTTP Signing Algorithms and different HTTP Digest Algorithms. The field could be changed to an object to accomodate this kind of use, allowing each proofing method to define its own parameters: Each method can also define "Default" values for missing parameters, allowing this to collapse in the simple case back to a string as it is today: These string values would have a deterministic expansion defined in the core protocol.
Note that the httpsig document itself wavers between and and does not require either of them. Though maybe this is OK if the current document makes mandatory for the appropriate cases.
There are some updates pending in the Digest draft -- once that's out, we'll reference using as that's the most appropriate for our use case, and examples will be updated.


Question: The WebRTC implementation MAY support accessing the Internet through an HTTP proxy.  If it does so, it MUST support the "connect" header <del> as specified in I-D.ietf-httpbis-tunnel-protocol. </del> <ins> as specified in I-D.ietf-httpbis-tunnel-protocol, and proxy authentication as described in Section 4.3.6 of RFC7231 and RFC7235 MUST also be supported. </ins> 3.5.

As described in URL
In the Dallas presentation on “transports” you stated that the reference to proxy authentication would be restored (See URL) but it does not seem to have happened. This is an oversight. (Noted by Andy Hutton)


Question: To avoid additional delays to connection migration confirmation when using this extension, a client can bundle an IMMEDIATE_ACK frame with the first non-probing frame (Section 9.2 of QUIC-TRANSPORT) it sends <del> or it can simply send an IMMEDIATE_ACK frame, which is a non-probing </del> <ins> or it can send only an IMMEDIATE_ACK frame, which is a non-probing </ins> frame. An endpoint's congestion controller and RTT estimator are reset upon

Connection Migration .... " it sends or it can simply send an IMMEDIATE_ACK frame" What is the intended difference between the words "it sends" or "it can simply send"?


Question: ASCII characters to facilitate transmission over HTTP headers within other protocols without requiring additional encoding. <del> RECOMMENDED.  Flag indicating if the token is bound to the client instance's key.  If the boolean value is "true" or the field is omitted, and the "key" field is omitted, the token is bound to the request-client in its request for access.  If the boolean value is "true" or the field is omitted, and the "key" field is present, the token is bound to the key and proofing mechanism indicated in the "key" field.  If the boolean value is "false", the token is a bearer token with no key bound to it and the "key" field MUST be omitted. </del> REQUIRED for multiple access tokens, OPTIONAL for single access token.  The value of the "label" the client instance provided in the associated request-token, if present.  If the token has been

URL match the flags array in the token request. While this is technically a breaking change, I think we should consider this editorial as this should have been changed when we made the original change to use a flags array in the request in .
:heavycheckmark: Deploy Preview for gnap-core-protocol-editors-draft ready! Built :hammer: Explore the source changes: 8c793bb446d82f053536358106485568fc457842 :mag: Inspect the deploy log: :sunglasses: Browse the preview:
You know, I had that thought, and I checked the request section and it doesn't have quotes. I'm going to add the quotes to both parts. This ended up with some other language changing, not just the examples, so let me know what you think.


Question: information about a client that any existing member can use to add this client to the group asynchronously. <del> A ClientInitKey object specifies what ciphersuites a client supports, as well as providing public keys that the client can use for key derivation and signing.  The client's identity key is intended to be stable throughout the lifetime of the group; there is no mechanism to change it.  Init keys are intended to be used a very limited number of times, potentially once. (see init-key-reuse).  ClientInitKeys also contain an identifier chosen by the client, which the client MUST assure uniquely identifies a given ClientInitKey object among the set of ClientInitKeys created by this client. The init_keys array MUST have the same length as the cipher_suites array, and each entry in the init_keys array MUST be a public key for the asymmetric encryption scheme defined in the cipher_suites array and used in the HPKE construction for TreeKEM. The whole structure is signed using the client's identity key.  A ClientInitKey object with an invalid signature field MUST be considered malformed.  The input to the signature computation comprises all of the fields except for the signature field. </del> <ins> A ClientInitKey object specifies a ciphersuite that the client supports, as well as providing a public key that others can use for key agreement.  The client's identity key is intended to be stable throughout the lifetime of the group; there is no mechanism to change it.  Init keys are intended to be used a very limited number of times, ideally only once.  (See init-key-reuse).  Clients MAY generate and publish multiple ClientInitKey objects to support multiple ciphersuites, or to reduce the likelihood of init key reuse. ClientInitKeys contain an identifier chosen by the client, which the client MUST assure uniquely identifies a given ClientInitKey object among the set of ClientInitKeys created by this client. The value for init_key MUST be a public key for the asymmetric encryption scheme defined by cipher_suite.  The whole structure is signed using the client's identity key.  A ClientInitKey object with an invalid signature field MUST be considered malformed.  The input to the signature computation comprises all of the fields except for the signature field. </ins> 8.

Here's the Weekly Digest for : - - Last week 3 issues were created. Of these, 1 issues have been closed and 2 issues are still open. :greenheart: , by :greenheart: , by :heart: , by :speaker: , by It received 1 comments. - - Last week, 6 pull requests were created, updated or merged. Last week, 1 pull request was opened. :greenheart: , by Last week, 1 pull request was updated. :yellowheart: , by Last week, 4 pull requests were merged. :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by - - Last week there were 6 commits. :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by - - Last week there was 1 contributor. :bustinsilhouette: - - Last week there was 1 stargazer. :star: You are the star! :star2: - - Last week there were no releases. - - That's all for last week, please :eyes: Watch and :star: Star the repository to receive next weekly updates. :smiley: You can also .
Here's the Weekly Digest for : - - Last week, no issues were created. - - Last week, 3 pull requests were created, updated or merged. Last week, 2 pull requests were updated. :yellowheart: , by :yellowheart: , by Last week, 1 pull request was merged. :purpleheart: , by - - Last week there was 1 commit. :hammerandwrench: by - - Last week there was 1 contributor. :bustin_silhouette: - - Last week there was 1 stargazer. :star: You are the star! :star2: - - Last week there were no releases. - - That's all for last week, please :eyes: Watch and :star: Star the repository to receive next weekly updates. :smiley: You can also .
Here's the Weekly Digest for : - - Last week 2 issues were created.


Question: information about a client that any existing member can use to add this client to the group asynchronously. <del> A ClientInitKey object specifies what ciphersuites a client supports, as well as providing public keys that the client can use for key derivation and signing.  The client's identity key is intended to be stable throughout the lifetime of the group; there is no mechanism to change it.  Init keys are intended to be used a very limited number of times, potentially once. (see init-key-reuse).  ClientInitKeys also contain an identifier chosen by the client, which the client MUST assure uniquely identifies a given ClientInitKey object among the set of ClientInitKeys created by this client. The init_keys array MUST have the same length as the cipher_suites array, and each entry in the init_keys array MUST be a public key for the asymmetric encryption scheme defined in the cipher_suites array and used in the HPKE construction for TreeKEM. The whole structure is signed using the client's identity key.  A ClientInitKey object with an invalid signature field MUST be considered malformed.  The input to the signature computation comprises all of the fields except for the signature field. </del> <ins> A ClientInitKey object specifies a ciphersuite that the client supports, as well as providing a public key that others can use for key agreement.  The client's identity key is intended to be stable throughout the lifetime of the group; there is no mechanism to change it.  Init keys are intended to be used a very limited number of times, ideally only once.  (See init-key-reuse).  Clients MAY generate and publish multiple ClientInitKey objects to support multiple ciphersuites, or to reduce the likelihood of init key reuse. ClientInitKeys contain an identifier chosen by the client, which the client MUST assure uniquely identifies a given ClientInitKey object among the set of ClientInitKeys created by this client. The value for init_key MUST be a public key for the asymmetric encryption scheme defined by cipher_suite.  The whole structure is signed using the client's identity key.  A ClientInitKey object with an invalid signature field MUST be considered malformed.  The input to the signature computation comprises all of the fields except for the signature field. </ins> 8.

Of these, 0 issues have been closed and 2 issues are still open. :greenheart: , by :greenheart: , by - - Last week, 2 pull requests were created, updated or merged. Last week, 2 pull requests were opened. :greenheart: , by :greenheart: , by - - Last week there were no commits. - - Last week there were no contributors. - - Last week there were 2 stagazers. :star: :star: You all are the stars! :star2: - - Last week there were no releases. - - That's all for last week, please :eyes: Watch and :star: Star the repository to receive next weekly updates. :smiley: You can also .


Question: additional information.  The format of the encoded identity is defined by the application. <del> For an X.509 credential, each entry in the chain represents a single DER-encoded X.509 certificate.  The chain is ordered such that the first entry (chain[0]) is the end-entity certificate and each subsequent certificate in the chain MUST be the issuer of the previous certificate.  The public key encoded in the "subjectPublicKeyInfo" of the end-entity certificate MUST be identical to the "signature_key" in the LeafNode containing this credential. </del> <ins> For an X.509 credential, each entry in the "certificates" field represents a single DER-encoded X.509 certificate.  The chain is ordered such that the first entry (chain[0]) is the end-entity certificate.  The public key encoded in the "subjectPublicKeyInfo" of the end-entity certificate MUST be identical to the "signature_key" in the LeafNode containing this credential.  A chain MAY omit any non-leaf certificates that supported peers are known to already possess. </ins> 5.3.1.

This updates the language around how certificate chains are constructed: We allow certificates to be omitted if the client knows any recipients will already possess the omitted certificate. We allow certificate chains to be out-of-order and potentially contain unused certificates. This is nice because it means less data needs to be sent on the wire, and also provides a method for root certificates to be rotated gracefully (as clients can provide chains for both old and new roots).
NAME it might be useful to also add this language from RFC 8446. It would make the process exactly the same as TLS which makes implementation easier. >The sender's certificate MUST come in the first >CertificateEntry in the list. Each following certificate SHOULD >directly certify the one immediately preceding it. Because >certificate validation requires that trust anchors be distributed >independently, a certificate that specifies a trust anchor MAY be >omitted from the chain, provided that supported peers are known to >possess any omitted certificates.
I think that is fine and is consistent with RFC8446. Don't we already have a better mechanism for rotating certificates? As soon as a member has a new certificate chain, it can update its LeafNode in an UpdatePath. This semantics of X.509 certificate bundles are already a bit fuzzy. Such a change will make validation more complicated and more error prone, when this seems completely unnecessary.
The scenario that this would address is: say that a root CA is compromised and needs to be replaced. Distributing the new CA certificate likely requires a software release, which not everyone will install simultaneously. During the rollout, some users will know only the old compromised CA and some users will know only the new CA and not the compromised one. To preserve interop during the rollout, users need to include two intermediates in their certificate chain: an intermediate signed by the old root that signs their leaf, and an intermediate signed by the new root that signs their leaf. (In the exact scenario I'm thinking of, the intermediate private key is held by the user, so it would not be compromised with the root. Though there may be other arrangements where this flexibility helps.) In terms of implementation complexity: the X509 chain validation libraries I'm aware of already support path building because it's necessary for TLS, so I would expect those could be used
This is actually the reason why I think it makes sense to adopt the same mechanism.


Question: additional information.  The format of the encoded identity is defined by the application. <del> For an X.509 credential, each entry in the chain represents a single DER-encoded X.509 certificate.  The chain is ordered such that the first entry (chain[0]) is the end-entity certificate and each subsequent certificate in the chain MUST be the issuer of the previous certificate.  The public key encoded in the "subjectPublicKeyInfo" of the end-entity certificate MUST be identical to the "signature_key" in the LeafNode containing this credential. </del> <ins> For an X.509 credential, each entry in the "certificates" field represents a single DER-encoded X.509 certificate.  The chain is ordered such that the first entry (chain[0]) is the end-entity certificate.  The public key encoded in the "subjectPublicKeyInfo" of the end-entity certificate MUST be identical to the "signature_key" in the LeafNode containing this credential.  A chain MAY omit any non-leaf certificates that supported peers are known to already possess. </ins> 5.3.1.

For example, if you use OpenSSL to validate the chain it does not take a chain as input. It takes a collection of certificates, a set of trusted root certs, and the leaf you want to validate. I believe not making this change has a higher complexity.
I'm sorry I missed this previously, but this requirement was a source of trouble in TLS and was removed in RFC 8446, which allows extra certificates in the middle. Was there a conscious decision to be more strict here.
I don't recall this ever being discussed. I think it was just added and nobody ever objected.
NAME can you elaborate a little bit? The way I read it the requirement is just that there is a valid signature chain, i.e. that one certificate signs the next and so on.
NAME - I deliberately reverted to the original TLS level of strictness here, in hopes that in starting over with a new ecosystem we could reset things to a cleaner state. Do you think there are legitimate reasons for violating the strict rule, or is it just a common misconfiguration in TLS servers? I would not really be inclined to accommodate the latter. NAME - I believe what NAME is envisioning are cases where there are multiple valid chains, say via old and new versions of an intermediate certificate. So you might do something like provide a "chain" of the form (leaf, oldintermediate, newintermediate), with the idea that the client could verify using whichever one makes it happy.
NAME take a look at the comment I left on the PR. I can see your point about starting over as being valid, but one thing that also caught my eye in the TLS RFC was language around allowing a root CA to be left out of the chain since those could potentially already exist in a local trust store.
I see. Thanks NAME for the clarification. Maybe we can phrase it in such a way that whatever the credential includes (added intermediary certificates or left-out root certificates) in the end the local client MUST be able to create a continuous certificate chain from the leaf to the root. Do we need to define how the client does that? Since we're already pushing everything else related to authentication into the AS, I'm inclined to say no.


Question: intensive, and reducing acknowledgement frequency reduces this cost at a data sender. <del> Severely asymmetric link technologies, such as DOCSIS, LTE, and satellite links, connection throughput in the data direction becomes constrained when the reverse bandwidth is filled by </del> <ins> For severely asymmetric link technologies, such as DOCSIS, LTE, and satellite links, connection throughput in the forward path can become constrained when the reverse path is filled by </ins> acknowledgment packets.  When traversing such links, reducing the <del> number of acknowledgments allows connection throughput to scale much further. </del> <ins> number of acknowledgments can achieve higher connection throughput. The rate of acknowledgment packets can impact link efficiency, including transmission opportunities or battery life. </ins> As discussed in implementation however, there can be undesirable consequences to congestion control and loss recovery if a receiver

I tried to work in what I thought were the important parts of Gorry's suggested text, PTAL if I captured everything.
It's also true that for many RF media, the performance of the forward path can be impacted by the rate of acknowledgment packets when the link bandwidth is shared.
“Severely asymmetric link technologies, such as DOCSIS, LTE, and satellite links, connection throughput in the data direction becomes constrained when the reverse bandwidth is filled by acknowledgment packets. When traversing such links, reducing the number of acknowledgments allows connection throughput to scale much further.” I’m going to push back again on this as largely wrong. Links such as DOCSIS, LTE, satellite and WiFi are asymmetric. But it’s not just that the design decisions made for these types of link resulted in asymmetric capacity (throughput limit), the designs also share the capacity, and it is important to mitigate the impact on that sharing of capacity, than purely thinking of it items of bytes/sec of capacity used. A lower feedback rate can help avoid inducing flow starvation to other flows that share resources along the path they use.On mobile devices sending data consumes RF and battery power and is more costly for a host of reasons not just asymmetry when present.
NAME -- I don't follow why you say that the statement is wrong. It seems to me that you think that the statement is inadequate. Would you mind responding here with some text you would prefer instead, and I'm happy to wordsmith and turn it into a PR?
I suggest some text something like: For some link technologies (e.g., DOCSIS, LTE, WiFi, and satellite links) transmission of acknowledgment packets contribute to link utilization and can incur significant forwarding costs. In some cases, the connection throughput in the data direction can become constrained when the reverse bandwidth is filled by acknowledgment packets. In other cases, the rate of acknowledgment packets can impact link efficiency (e.g. transmission opportunities or battery life). A lower ACK frequency can be beneficial when using paths that include such links.
NAME -- Is the text proposal in the issue enough for you to make a PR?
This is much better.


Question: layer.  By providing reliability at the stream level and congestion control across the entire connection, it has the capability to improve the performance of HTTP compared to a TCP mapping.  QUIC also <del> incorporates TLS 1.3 at the transport layer, offering comparable security to running TLS over TCP, with the improved connection setup latency of TCP Fast Open RFC7413. </del> <ins> incorporates TLS 1.3 TLS13 at the transport layer, offering comparable security to running TLS over TCP, with the improved connection setup latency of TCP Fast Open TFO. </ins> This document defines a mapping of HTTP semantics over the QUIC transport protocol, drawing heavily on the design of HTTP/2.  While

It might pay to reconcile: {{vars-of-interest}}) to be larger than the congestion window, unless the packet is sent on a PTO timer expiration; see {{pto}}. And now exceeds the recently reduced congestion window. Now, you might implement the latter using PTO machinery, but that text doesn't really suggest that in any way.
Where does this second sentence come from? I'm pretty sure I haven't implemented anything like this in quic-go. Should I?
That sentence is the the definition of the . We haven't implemented that either, and I was wondering if it truly helps.
For TCP this second case if important because as long as you don't retransmit the lost packet you will not get any ACK that acknowledges new data. I guess we don't need that for QUIC.
The second sentence was added later in , and the MUST wasn't updated, so I'll fix that. Chromium currently implements PRR(RFC6937), which is a more complex variant of this which is designed to keep the ACK clock going. I thought we discussed adding an informative reference to PRR when we added this text, and I'm not sure why we didn't.
seems to be the wrong issue you are pointed to...
Good catch, it's
I've suggested some symbolic references.


Question: Sending a Message with Message Properties inconsistent with the Selection Properties of the Connection yields an error. <del> Connection Properties describe the default behavior for all Messages on a Connection.  If a Message Property contradicts a Connection Property, and if this per-Message behavior can be supported, it overrides the Connection Property for the specific Message.  For example, if "Reliable Data Transfer (Connection)" is set to "Require" and a protocol with configurable per-Message reliability is used, setting "Reliable Data Transfer (Message)" to "false" for a particular Message will allow this Message to be sent without any reliability guarantees.  Changing the Reliable Data Transfer property on Messages is only possible for Connections that were established enabling the Selection Property "Configure Per-Message Reliability". </del> <ins> If a Message Property contradicts a Connection Property, and if this per-Message behavior can be supported, it overrides the Connection Property for the specific Message.  For example, if "Reliable Data Transfer (Connection)" is set to "Require" and a protocol with configurable per-Message reliability is used, setting "Reliable Data Transfer (Message)" to "false" for a particular Message will allow this Message to be sent without any reliability guarantees.  Changing the Reliable Data Transfer property on Messages is only possible for Connections that were established enabling the Selection Property "Configure Per-Message Reliability". </ins> The following Message Properties are supported:

Applied requested changes
In 3.2 it is clear that you can set Message Properties on Connections and Preconnections, but the rest of the document is not very clear about this. In 4.2 for instance the text only talks about setting Selection Properties and Connection Properties on PreConnections. In 7.1.3 the text says "Connection Properties describe the default behavior for all Messages on a Connection". But I think that Message Properties set on a Connection or PreConnection may also describe the default behavior so this relationship should be clarified. Also, the Message Property defaults given for Properties that do not depend on other Properties sets the defaults for all Messages in a Connection I assume? I also assume that a Message Property set on a Message Context overrides a Message Property set on a PreConnection or Connection, but this is also not specified. In 5.4. Connection Groups, I assume that setting Message Properties on a Connection applies to all Connections in the Connection Group? This is not clear.
In general, I agree. If you set a message property dynamically on a connection, though, I don't think it would affect the group—I could have one stream in a multiplexed protocol have separate behavior, such as priority.
+1 to tfpauly. But this is already written in 5.4, maybe you missed it (Anna)? "Message Properties are also not entangled. For example, changing Lifetime (see Section 7.1.3.1) of a Message will only affect a single Message on a single Connection."
I am fine with an update of a Message Property to a connection applying only to that connection. Priority is not a good example as it is already a special case, but my main issue was that we need to be more clear about the behavior in the specification. NAME the issue is about setting a Message Property on a Connection. The text you refer to talk about setting Message Properties on a message. You could interpret the first part as a general statement, but the way the text is structured it is easy to think it refers to setting Message Properties on a message so I think we should be explicit also about setting Message Properties on a Connection. Could be a second example.
So after looking at the text again, I think the example talking about setting Message Properties on a message should be removed, see comment in the pull request.
Thanks!!


Question: When EAP-TLS is used with TLS version 1.3, the EAP-TLS peers and EAP- TLS servers MUST comply with the compliance requirements (mandatory- to-implement cipher suites, signature algorithms, key exchange <del> algorithms, extensions, etc.) for the TLS version used.  For TLS 1.3 the compliance requirements are defined in Section 9 of RFC8446.  In </del> <ins> algorithms, extensions, etc.) defined in Section 9 of RFC8446.  In </ins> EAP-TLS with TLS 1.3, only cipher suites with confidentiality SHALL be supported.

Hi! I performed a second AD review on draft-ietf-emu-eap-tls13. This time on -18. Thank you to the authors, the responsible co-chair, and the WG for all of the work to redesign the -13 protocol in response to the initial IESG review in December 2020. My review feedback consists of my own minimal additional comments and highlights of where previously stated IESG ballot items do not appear to be responded to or addressed. All items appear to be minor. ** Section 2.4. Previously, this text referenced TLS 1.3 or higher necessitating more ambiguous reference to version numbers. However, now the text only notes TLS 1.3. OLD When EAP-TLS is used with TLS version 1.3, the EAP-TLS peers and EAP- TLS servers MUST comply with the compliance requirements (mandatory- to-implement cipher suites, signature algorithms, key exchange algorithms, extensions, etc.) for the TLS version used. For TLS 1.3 the compliance requirements are defined in Section 9 of [RFC8446]. NEW When EAP-TLS is used with TLS version 1.3, the EAP-TLS peers and EAP-TLS servers MUST comply with the compliance requirements (mandatory- to-implement cipher suites, signature algorithms, key exchange algorithms, extensions, etc.) defined in Section 9 of [RFC8446]. ==[ COMMENT (Ben Kaduk) Section 2.1.4 The two paragraphs below replaces the corresponding paragraphs in Section 2.1.3 of [RFC5216] when EAP-TLS is used with TLS 1.3 or higher. The other paragraphs in Section 2.1.3 of [RFC5216] still apply with the exception that SessionID is deprecated. If the EAP-TLS peer authenticates successfully, the EAP-TLS server MUST send an EAP-Request packet with EAP-Type=EAP-TLS containing TLS records conforming to the version of TLS used. The message flow ends with the EAP-TLS server sending an EAP-Success message.


Question: When EAP-TLS is used with TLS version 1.3, the EAP-TLS peers and EAP- TLS servers MUST comply with the compliance requirements (mandatory- to-implement cipher suites, signature algorithms, key exchange <del> algorithms, extensions, etc.) for the TLS version used.  For TLS 1.3 the compliance requirements are defined in Section 9 of RFC8446.  In </del> <ins> algorithms, extensions, etc.) defined in Section 9 of RFC8446.  In </ins> EAP-TLS with TLS 1.3, only cipher suites with confidentiality SHALL be supported.

If the EAP-TLS server authenticates successfully, the EAP-TLS peer MUST send an EAP-Response message with EAP-Type=EAP-TLS containing TLS records conforming to the version of TLS used. Just to walk through the various scenarios here; if the last message of the TLS handshake for a given TLS version is sent by the TLS client, that will go in an EAP-Response, so the server is then able to send EAP-Success directly. On the other hand, if the last TLS handshake message is sent by the server, that will have to go in an EAP-TLS EAP-Request, and so the peer will have to send an empty EAP-TLS response in order for the server to be able to wend EAP-Success? Do we need to have any text here to handle that empty EAP-TLS Eap-Request case? ==[ COMMENT(Alvaro Retana) Is the intention of the Appendix to provide additional formal updates to rfc5216? That is what it looks like to me, but there's no reference to it from the main text. Please either reference the Appendix when talking about some of the other updates (if appropriate) or specifically include the text somewhere more prominent. [Roman] As proposed above, please provide some forward reference. ==[ COMMENT (Éric Vyncke) I find "This section updates Section 2.1.1 of [RFC5216]." a little ambiguous as it the 'updated section' is not identified clearly. I.e., as the sections in RFC 5216 are not too long, why not simply providing whole new sections ? [Roman] I'd propose a simple fix by using (approximate phrases such as) either: This section updates Section xxx of [RFC5216] by amending it with the following text. (for the cases where the intent is to keep the existing text in rfc5216 but add this new text) This section updates Section xxx of [RFC5216] by replacing it with the following text. (for the cases where the intent is to replace an entire section in rfc5216) ==[ COMMENT (Éric Vyncke) None of us are native English speaker, but "e.g." as "i.e."


Question: When EAP-TLS is used with TLS version 1.3, the EAP-TLS peers and EAP- TLS servers MUST comply with the compliance requirements (mandatory- to-implement cipher suites, signature algorithms, key exchange <del> algorithms, extensions, etc.) for the TLS version used.  For TLS 1.3 the compliance requirements are defined in Section 9 of RFC8446.  In </del> <ins> algorithms, extensions, etc.) defined in Section 9 of RFC8446.  In </ins> EAP-TLS with TLS 1.3, only cipher suites with confidentiality SHALL be supported.

are usually followed by a comma while "but" has usually no comma before ;-) [Roman] A simple s/e.g./e.g.,/ and s/i.e./i.e.,/ would catch this. Regards, Roman
==[ COMMENT (Éric Vyncke) None of us are native English speaker, but "e.g." as "i.e." are usually followed by a comma while "but" has usually no comma before ;-) [Roman] A simple s/e.g./e.g.,/ and s/i.e./i.e.,/ would catch this. Eric is correct that US english i.e. and e.g. is usually followed by a comma. I corrected this in d9f5028 I also run a word spell check on the document. Word does not suggest removing any comma after "but" but rather insert an additional comma after a but. I think this can be left to the RFC editor. The word spell check caught two other grammar errors (s after plural, no s after singular) RFC 8446 does not use capitalization on post-handshake as that is just a name for a set of messages. I corrected these things in
I Made a new PR
Made a commit with NEW When EAP-TLS is used with TLS version 1.3, the EAP-TLS peers and EAP-TLS servers MUST comply with the compliance requirements (mandatory- to-implement cipher suites, signature algorithms, key exchange algorithms, extensions, etc.) defined in Section 9 of [RFC8446].
Section 2.1.4 Changed the text to: The message flow ends with a protected success indication from the EAP-TLS server, follwed by an EAP-Response packet of EAP-Type=EAP-TLS and no data from the EAP-TLS peer, follwed by EAP-Success from the server.
I added a forward reference to the appendix in the introduction
NAME looks like you have got everything covered? are there any comments from Roman which still need to be addressed? should we submit a new version and ask for IETF last call?
I have tried to do everything. Problem with the updates thing.


Question: When EAP-TLS is used with TLS version 1.3, the EAP-TLS peers and EAP- TLS servers MUST comply with the compliance requirements (mandatory- to-implement cipher suites, signature algorithms, key exchange <del> algorithms, extensions, etc.) for the TLS version used.  For TLS 1.3 the compliance requirements are defined in Section 9 of RFC8446.  In </del> <ins> algorithms, extensions, etc.) defined in Section 9 of RFC8446.  In </ins> EAP-TLS with TLS 1.3, only cipher suites with confidentiality SHALL be supported.

The replace or amend strategy does not really work.... [Roman] I'd propose a simple fix by using (approximate phrases such as) either: This section updates Section xxx of [RFC5216] by amending it with the following text. (for the cases where the intent is to keep the existing text in rfc5216 but add this new text) This section updates Section xxx of [RFC5216] by replacing it with the following text. (for the cases where the intent is to replace an entire section in rfc5216)
NAME We should likely not do to much changes. Maybe we can write something like Amends with the following text. TLS 1.2 specific details in RFC 5216 are replaced. Requirement in the new takes precedence over requirements in the old text.
This review was addressed in earlier submissions. closing


Question: This property applies to Connections and Connection Groups.  The default is to have this option. <del> 5.2.7. </del> <ins> 5.2.8. </ins> Type: Boolean

This closed As we have no methods on a connection object that query properties, cansend/canreceive also became connection properties. As with all the other connection properties, these are indeed a little underspecified. I want to keep it that way till we fix it for all connection properties with and
Aehm… that comes surprising – NAME why didn't you bring this up in ? Do you think this pull-request is the right place to discuss this issue? I would prefer we merge it now and make a new issue for the question whether the uni-directional connection should be more reflected in the connection. I am not particularly found on keeping it a selection property but would like to have the concept of unidirectional connections rather sooner than later. Our consensus in was that unidirectional connection should use the same abstraction for QUIC unidirectional streams, multicast sources/sinks, and half-closed connections – despite they are constructed in completely different ways. The Selection property is just for the QUIC style ones…

Aehm… that comes surprising – NAME why didn't you bring this up in ? Do you think this pull-request is the right place to discuss this issue? Happy to move the discussion back over to the issue if you like. Will continue the thread here for now though since you've got points to address below. fine, but keep open then, because adding the selection property is possibly-necessary but definitely-not-sufficient to fully address unidirectional connection semantics. good, I agree with this. then I'm confused why this PR purports to since it only addresses part of the issue...?
NAME agreed. The question (and discussion) was about support for including some support for unidirectional connections (with focus on QUIC and half-closed), but omitted details on multicast, as this has not laned yet. So indeed, this pull-requests does everything requested by , but does not fully capture the topic. I will move the open issues (Multicast support, is the Selection Property enough, find some place for more explanation of Uni/Bidi Streams) to once this PR is merged.
In Section 9 – "Setting and Querying of Connection Properties" – the properties of an established connection and path are heavily underspecified. Should be fixed along with .
I'm working on this issue within our pull request for , using the terminology as simplified there.


Question: This property applies to Connections and Connection Groups.  The default is to have this option. <del> 5.2.7. </del> <ins> 5.2.8. </ins> Type: Boolean

For Section 9, I'm proposing the following: An application can query Connection Properties on a connection. Connection Properties include the status of the connection and whether it is possible to send and to receive data on it. (One of them might not be possible, e.g., in a unidirectional connection.) Additionally, Connection Properties include the Connection's Transport Properties. Transport Properties include Selection Properties, so the application can know which Protocol Selection Properties had been specified, and which ones are actually supported by the protocol that has been chosen. For Establishing connections (i.e., we are not done racing yet, the final protocols have not been selected yet), the application gets the Selection Properties that had been specified on the Preconnection earlier. For Established, Closing, or Closed connections (i.e., the protocols have been selected), the application learns whether the Selection Properties are actually provided by the selected protocols. For example, if the application specified earlier, "Control Checksum Coverage: Prefer", now it will get "Control checksum coverage: True", indicating that on this connection it can indeed control the checksum coverage. Transport Properties also include Protocol Properties (Generic and Specific). These Protocol Properties can still be modified by the application. Basically, Protocol Properties are the only thing that the application can still set, everything else it can only query at this point. Finally, the application can query properties of the path. Not sure how well we have to specify them, probably this part will be implementation-specific just like, e.g., the Interface Instance or Type. Does everyone agree, or is there anything to discuss here? For me this is not a big change, it's just putting what was already there in terms of . The only thing I'm wondering if whether the Protocol Selection Properties of the finally chosen protocols are still "Selection Properties", as the selection is already done. That's why they were called "Transport Features" before, but now I want less terms and they're almost the same thing...
OK - so I commented on these things before - but in these things I think I agree. I'd personally prefer to keep the features as attributes implemented in the transport (etc) and the properties as the things requested. Indeed this begs the question about what to call the resulting transport when you selected properties and now get a transport. I think still calling them (for consistency) properties seems really good to me. :-).


Question: This property applies to Connections and Connection Groups.  The default is to have this option. <del> 5.2.7. </del> <ins> 5.2.8. </ins> Type: Boolean

As QUIC has unidirectional streams, we might want to be able to accommodate them in our transport API. Do we want to handle them fundamentally different from a half-closed connection? This should match the decisions made in .
Side note: we don't support half-closed connections to begin with. As for unidirectional streams, is this the final decision in QUIC's design, or might it change? I'd suggest postponing this until we can be sure.
NAME regarding half-closed connections: we don't have any top-level state in the connection for being half-closed. However, being able to express that a message is final in a given direction when sending allows the same functionality. As I've discussed before, we absolutely need the ability to express sending a TCP FIN, but I whole-heartedly agree it doesn't need to be a top level concept. I think this is somewhat different from half-closing, since a unidirectional stream never allows sending on one end. You could imagine that it is a connection object that returns an error if you ever try to send on it, etc. If you wanted it to look like half-closing, you could open a connection (stream), and then mark it complete in a direction immediately? But that's a bit odd.
All ok, I agree with your suggestion to fin-mark a message
I agreee with NAME regarding half-closed. My suggestion is to explicitly state that connections can be uni- or bi-directional and to add a method to query that (cansend / canrecv). This aligns nicely with final messages after which can_send becomes false. I can do a PR for that.
Thanks! I like this
Still missing unidirectional stream for multicast. – please continue discussion of multicast aspects in The connection properties (can send/receive data) are still a little under-specified - please discuss in details in – we should fix this together with .
We need unidirectional connections. You know, for multicast. And ICN. And unidirectional streaming protocols.
This is a dup of , which has more discussion
I am re-opening this ticket as only dealt with unidirectional streams in unicast context (added with PR ): Current status: The current model for unidirectional streams supports half-closed connections and QUIC style unidirectional streams so far.


Question: This property applies to Connections and Connection Groups.  The default is to have this option. <del> 5.2.7. </del> <ins> 5.2.8. </ins> Type: Boolean

We don't know yet whether it is sufficient to have canread/canwrite property on the connection level to model unidirectional connections We don't have pre-connection methods to create multicast sessions yet
there's a selection property for this, tagged discuss, which we haven't discussed yet. I'm moving this down to the appendix as part of my restructuring in my work on
If help is still wanted here, I'm maybe up for an attempt or 2 at adding multicast support. Has there been some prior discussion I can review about rough ideas on pre-connection methods for multicast sessions, or should I just try making something up?

ok, with the caveat that we need to keep multicast as an open issueLGTM About the multicast concern: I agree that it would be good if this could function for multicast reception too, and I couldn't tell if this is suitable for multicast. I suspect that multicast support is much harder anyway - see RFC 3678... so for now, this is a good step forward IMO, and let's discuss how this relates to multicast when we see a concrete text proposal that addresses it.


Question: 7. <del> In order to satisfy the security requirements of DNS over HTTPS, this protocol MUST use HTTP/2 RFC7540 or its successors.  HTTP/2 enforces a modern TLS profile necessary for achieving the security requirements of this protocol. </del> This protocol MUST be used with https scheme URI RFC7230. <del> The messages in classic UDP based DNS RFC1035 are inherently unordered and have low overhead.  A competitive HTTP transport needs to support reordering, priority, parallelism, and header compression. For this additional reason, this protocol MUST use HTTP/2 RFC7540 or its successors. </del> <ins> This protocol MUST use HTTP/2 RFC7540 or its successors in order to satisfy the security requirements of DNS over HTTPS.  Further, the messages in classic UDP based DNS RFC1035 are inherently unordered and have low overhead.  A competitive HTTP transport needs to support reordering, priority, parallelism, and header compression, all of which are supported by HTTP/2 RFC7540 or its successors. </ins> 8.

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


Question: more on this, as well as https://mailarchive.ietf.org/arch/msg/tls/ TugB5ddJu3nYg7chcyeIyUqWSbA.]] <ins> contains keys that are not required to be understood by the client.  Server operators MUST NOT place a key in this section unless the server is able to determine whether the key is in use based on the client data it receives.  A key MUST NOT appear in both the main template and the optional section. </ins> 2.1.1. To be compatible with the specializations described in this section,

This PR looks good to me.
cTLS enumerates keys in the template, but does not explain how templates can be extended. Suggestion: Clients must reject the whole template if it contains any key they do not understand. The “optional” key holds a map of optional extensions that are safe to ignore.
Thanks for addressing your own issue with a PR. Creating an IANA registry for the keys used in the configuration data makes sense. I would, however, like to point out (and maybe we need to make this explicit) that the configuration information is defined for convenience but is not a mandatory-to-implement functionality for a stack.
Sure, some use cases can pre-arrange, or even hardcode, a specific configuration through a nonstandard channel. Some use cases (where the client and server are developed separately) obviously cannot.


Question: is not applicable to the approach defined in this specification. If step 4 (EDHOC processing) fails, the server discontinues the <del> protocol as per Section 5.4.3 of I-D.ietf-lake-edhoc and sends an EDHOC error message, formatted as defined in Section 6.1 of I-D.ietf- lake-edhoc.  In particular, the CoAP response conveying the EDHOC error message: MUST have Content-Format set to application/edhoc defined in Section 9.5 of I-D.ietf-lake-edhoc. MUST specify a CoAP error response code, i.e. 4.00 (Bad Request) in case of client error (e.g. due to a malformed EDHOC message_3), or 5.00 (Internal Server Error) in case of server error (e.g. due to failure in deriving EDHOC key material). </del> <ins> protocol as per Section 5.4.3 of I-D.ietf-lake-edhoc and responds with an EDHOC error message, formatted as defined in Section 6.1 of I-D.ietf-lake-edhoc.  In particular, the CoAP response conveying the EDHOC error message MUST have Content-Format set to application/edhoc defined in Section 9.5 of I-D.ietf-lake-edhoc. </ins> If step 4 (EDHOC processing) is successfully completed but step 7 (OSCORE processing) fails, the same OSCORE error handling applies as defined in Section 8.2 of RFC8613. <del> 5. </del> <ins> 5.4. </ins> <del> An example based on the OSCORE test vector from Appendix C.4 of RFC8613 and the EDHOC test vector from Appendix B.2 of I-D.ietf-lake- edhoc is given in fig-edhoc-opt-2.  In particular, the example assumes that: </del> <ins> fig-edhoc-opt-2 shows an example of EDHOC + OSCORE Request, based on the OSCORE test vector from Appendix C.4 of RFC8613 and the EDHOC test vector from Appendix B.2 of I-D.ietf-lake-edhoc.  In particular, the example assumes that: </ins> The used OSCORE Partial IV is 0, consistently with the first request protected with the new OSCORE Security Context. <del> The OSCORE Sender ID of the Client is 0x20.  This corresponds to </del> <ins> The OSCORE Sender ID of the Client is 0x00.  This corresponds to </ins> the EDHOC Connection Identifier C_R, which is encoded as the <del> bstr_identifier 0x08 in EDHOC message_3. </del> <ins> bstr_identifier 0x37 in EDHOC message_3. </ins> <del> The EDHOC option is registered with CoAP option number 13. </del> <ins> The EDHOC option is registered with CoAP option number 21. </ins> 6.

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: If PSK is not combined with fresh ephemeral key exchange, then compromise of any group member allows the attacker to passively <del> read (and actively modify) all traffic. </del> <ins> read (and actively modify) all traffic, including past traffic. </ins> Additionally, a malicious non-member can reroute handshakes between honest group members to connect them in unintended ways, as described

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


Question: will never show up when queuing the value of a preference - the effective preference must be returned instead. <del> Internally, the transport system will first exclude all protocols and paths that match a Prohibit, then exclude all protocols and paths that do not match a Require, then sort candidates according to </del> <ins> The implementation MUST ensure a consistent outcome given the same Selection Properties.  Internally, it MUST exclude all protocols and paths that match a Prohibit and exclude all protocols and paths that do not match a Require.  It MUST then sort candidates according to </ins> Preferred properties, and then use Avoided properties as a <del> tiebreaker.  Selection Properties that select paths take preference over those that select protocols.  For example, if an application indicates a preference for a specific path by specifying an interface, but also a preference for a protocol not available on this path, the transport system will try the path first, ignoring the protocol preference. </del> <ins> tiebreaker. Note that the protocols and paths which are available on a specific system may vary, such that application preferences may conflict with each other.  For example, if an application indicates a preference for a specific path by specifying an interface, but also a preference for a protocol, a situation might occur in which the preferred protocol is not available on the preferred path.  In such cases, implementations MUST ensure a deterministic outcome by prioritizing Selection Properties that select paths over those that select protocols.  Therefore, the transport system MUST try the path first, ignoring the protocol preference if the protocol does not work on the path. </ins> Selection and Connection Properties, as well as defaults for Message Properties, can be added to a Preconnection to configure the

Took a stab at normative language for the rules to process Selection Properties, as discussed in . As far as I remember, we always said that outcomes have to be deterministic/consistent, so I made everything that matters a MUST. I guess our example illustrates that even given the same Selection Properties, the outcome might change depending on the situation, e.g., your path might still be Wifi but it might or might not support your preferred protocol. So, does this really have to be all MUST, or is there a SHOULD in there? Discuss. :) Also, if anyone can name a good reason why the outcome has to be deterministic, please suggest text - maybe something like "avoid surprises for the application", but this didn't really sound right, so I left it out for now.
In section 5.2. in the API doc: "Internally, the transport system will first exclude all protocols and paths that match a Prohibit, then exclude all protocols and paths that do not match a Require, then sort candidates according to Preferred properties, and then use Avoided properties as a tiebreaker. Selection Properties that select paths take preference over those that select protocols. For example, if an application indicates a preference for a specific path by specifying an interface, but also a preference for a protocol not available on this path, the transport system will try the path first, ignoring the preference." This sounds rather like an example algorithm that should maybe go into the implementation doc instead? Or is there any part of this that we need to specify normatively in order to ensure that all systems implement the same?
This goes back to issue on "conflicting policies". At the time, we decided that there must be a deterministic outcome, therefore, text was added to both the API and the Implementation document, see . If we keep it that way, perhaps the text here should point out that the goal is to resolve conflicting policies, so we achieve a deterministic outcome.
Ah okay, thanks for the background info; missed that. I think we need to use normative language here then. Maybe also a separate subsection makes this more prominent.
This reads to me like the rules for processing polices rather than an example algorithm. I think it is part of the API... Normative language would be good and a stronger opening that explains why the rules exist.


Question: will never show up when queuing the value of a preference - the effective preference must be returned instead. <del> Internally, the transport system will first exclude all protocols and paths that match a Prohibit, then exclude all protocols and paths that do not match a Require, then sort candidates according to </del> <ins> The implementation MUST ensure a consistent outcome given the same Selection Properties.  Internally, it MUST exclude all protocols and paths that match a Prohibit and exclude all protocols and paths that do not match a Require.  It MUST then sort candidates according to </ins> Preferred properties, and then use Avoided properties as a <del> tiebreaker.  Selection Properties that select paths take preference over those that select protocols.  For example, if an application indicates a preference for a specific path by specifying an interface, but also a preference for a protocol not available on this path, the transport system will try the path first, ignoring the protocol preference. </del> <ins> tiebreaker. Note that the protocols and paths which are available on a specific system may vary, such that application preferences may conflict with each other.  For example, if an application indicates a preference for a specific path by specifying an interface, but also a preference for a protocol, a situation might occur in which the preferred protocol is not available on the preferred path.  In such cases, implementations MUST ensure a deterministic outcome by prioritizing Selection Properties that select paths over those that select protocols.  Therefore, the transport system MUST try the path first, ignoring the protocol preference if the protocol does not work on the path. </ins> Selection and Connection Properties, as well as defaults for Message Properties, can be added to a Preconnection to configure the

I don't think a separate subsection would make this a better read - this fits fine as it stands, as an intro to the transport property specification IMO. Regarding normative language, that's a separate discussion. So, can we close this issue?
Agree that we don't need a separate subsection. I can try to tweak the beginning of this part a bit to explain why the rules exist as NAME suggested. Regarding normative language - we definitely have it in the API draft, right? So why not have the discussion on it here as well? if we're serious about deterministic outcomes, I guess the whole thing needs to be a MUST, right?
Sorry, true, that normative language debate was about the arch draft, and we definitely have it in the API draft. So yes, let's discuss it here. I also think a MUST would make sense.
So the order of filtering out require/prohibit is not important (outcome is the same) - making the order a MUST does not make sense. Also, first sorting by preference and then filtering has the same outcome as doing it the other way around. the only thing we need to say is that filtering MUST happen and sorting SHOULD happen.
ok - I have to admit I didn't think this through, I just agree that we want a deterministic outcome from this.
Why did we require a deterministic behavior in first place? Does this prevent TAPS implementations from running experiments like Apple did with TCP SACK and ECN? Does this prevent probabilistic path probing?
This was discussed in the TAPS BoF? ... I thought it was about developers being assured that X will happen if they choose Y and not finding the ground shifting as they use the interface.
Interim: Prefers and avoids allow the implementation to decide the ordering and weighting; require and prohibit are the only hard requirements. Applications should be able to cope with any possibility that isn't prohibited. Likely should add implementation text to say how preferences weight racing.
During the interim discussion, we found that was too strict and limiting, so we opted for another approach that moves the selection algorithm to the Implementation draft. I'm preparing another PR implementing these changes.
The text that ended up in the implementation draft is not fully consistent with the racing text, opening a new issue for this and closing this issue.
LGTM, merging this. thanks, Theresa!This reads good to me.


Question: will never show up when queuing the value of a preference - the effective preference must be returned instead. <del> Internally, the transport system will first exclude all protocols and paths that match a Prohibit, then exclude all protocols and paths that do not match a Require, then sort candidates according to </del> <ins> The implementation MUST ensure a consistent outcome given the same Selection Properties.  Internally, it MUST exclude all protocols and paths that match a Prohibit and exclude all protocols and paths that do not match a Require.  It MUST then sort candidates according to </ins> Preferred properties, and then use Avoided properties as a <del> tiebreaker.  Selection Properties that select paths take preference over those that select protocols.  For example, if an application indicates a preference for a specific path by specifying an interface, but also a preference for a protocol not available on this path, the transport system will try the path first, ignoring the protocol preference. </del> <ins> tiebreaker. Note that the protocols and paths which are available on a specific system may vary, such that application preferences may conflict with each other.  For example, if an application indicates a preference for a specific path by specifying an interface, but also a preference for a protocol, a situation might occur in which the preferred protocol is not available on the preferred path.  In such cases, implementations MUST ensure a deterministic outcome by prioritizing Selection Properties that select paths over those that select protocols.  Therefore, the transport system MUST try the path first, ignoring the protocol preference if the protocol does not work on the path. </ins> Selection and Connection Properties, as well as defaults for Message Properties, can be added to a Preconnection to configure the

Regarding the request for text, I don't have any ideas... but I think this could be fine as it stands? Needs more eyes though.


Question: A user agent requests the delivery of new push messages by making a GET request to a push message subscription resource.  The push <del> service does not respond to this request, it instead uses I-D.ietf- httpbis-http2 to send the contents of push messages as they are sent by application servers. </del> <ins> service does not respond to this request, it instead uses RFC7540 to send the contents of push messages as they are sent by application servers. </ins> Each push message is pushed in response to a synthesized GET request. The GET request is made to the push message resource that was created

closed closed renamed draft-thomson-webpush-URL to draft-ietf-webpush-URL updated the HTTP/2 reference updated the alt-svc reference
From Darshak Thakore feedback: Add Push-Receipt header to Section 5 example Reference in Section 5.1
From Darshak Thakore review: Section 5 - In the example, Is the post operation to the right URL? Is that just an editorial oversight or is that the intended URL? Current example: POST /p/LBhhw0OohO-Wl4Oi971UGsB7sdQGUibx HTTP/1.1 Probably should be: POST /p/JzLQ3raZJfFBR0aqvOMsLrt54w4rJUsV HTTP/1.1 The current example is incorrect. It should match the urn:ietf:params:push link relation returned in the Subscription response - /p/JzLQ3raZJfFBR0aqvOMsLrt54w4rJUsV - and distributed to the application server.


Question: 5.4. <ins> If a client decides to cache the certificate chain an re-validate it when resuming a connection, the client SHOULD also cache the associated delegated credential and re-validate it. 5.5. </ins> Delegated credentials can be valid for 7 days and it is much easier for a service to create delegated credential than a certificate signed by a CA.  A service could determine the client time and clock

Use RFC references
Maybe use generic language, like "signing oracle" :)
ooh, naming things is so difficult :) Maybe "remote certificate signing offload"?
Please double-check. At least one of these appears to be wrong.
were you looking at the editor copy perhaps, does the latest draft appear wrong as well? URL i think the editor copy went out of sync
Ahh. I was seeing Richard as being out of date. I was also wondering if NAME wanted to consider affiliation adjustment also.
NAME Should we update your affiliation to Mozilla here?
Request an extension point from the IANA experts and add it to the document.
shipit. As these are all editorial changes, I don't think we need a long discussion.


Question: freshness", i.e., allowing Alice to verify that Bob is still prepared to receive her communications so that Alice does not continue to send large traffic volumes to entities which went abruptly offline.  ICE <del> specifies periodic STUN keepalizes but only if media is not flowing. Because the consent issue is more difficult here, we require RTCWeb </del> <ins> specifies periodic STUN keepalives but only if media is not flowing. Because the consent issue is more difficult here, we require WebRTC </ins> implementations to periodically send keepalives.  As described in Section 5.3, these keepalives MUST be based on the consent freshness mechanism specified in I-D.muthu-behave-consent-freshness.  If a

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: A variable-length integer that indicates how many out of order packets can arrive before eliciting an immediate ACK.  If no <del> ACK_FREQUENCY frames have been received, this value defaults to 3, which is the recommended packet threhold for loss detection in (Section 18.2 of QUIC-RECOVERY).  A value of 0 indicates immediate ACKs SHOULD never be sent due to receiving an out-of-order packet. </del> <ins> ACK_FREQUENCY frames have been received, the endpoint immediately acknowledges any subsequent packets that are received out of order, as specified in Section 13.2 of QUIC-TRANSPORT, as such the default value is 1.  A value of 0 indicates immediate ACKs SHOULD never be sent due to receiving an out-of-order packet. </ins> ACK_FREQUENCY frames are ack-eliciting.  However, their loss does not require retransmission if an ACK_FREQUENCY frame with a larger

Sec #ack-frequency-frame says: and Sec #out-of-order says:
It seems optimal to default it to 3, because that's the default packet threshold, but the principle of least surprise argues for 1 (ie: no behavior change until an ACK_FREQUENCY frame is received), so I lean toward 1.
This PR adds a SHOULD NOT, but it seems sensible.


Question: Finally, Clients should not be able to perform DoS attacks denial-of- service. <ins> 5. This document makes no requests of IANA. </ins>

We need an IANA considerations section even if we make no requests of them. It's just part of the process and the section can be removed during the final publication phase.


Question: External Commits work like regular Commits, with a few differences: <del> External Commits MUST reference an Add Proposal that adds the issuing new member to the group </del> <ins> The proposals included by value in an External Commit MUST meet the following conditions: There MUST be a single Add proposal that adds the new issuing new member to the group There MUST be a single ExternalInit proposal There MUST NOT be any Update proposals If a Remove proposal is present, then the "credential" and "endpoint_id" of the removed leaf MUST be the same as the corresponding values in the Add KeyPackage. The proposals included by reference in an External Commit MUST meet the following conditions: There MUST NOT be any ExternalInit proposals </ins> External Commits MUST contain a "path" field (and is therefore a "full" Commit)

NAME NAME r?
Discussed at 20211004 interim, remove resynch with a single op (external join + remove in one op). NAME research why resynch was dropped.
A good point was raised by Jonathon Hoyland during the MLS IETF 109 meeting regarding possible concerns in using external commits for resync, particularly in the case of Alice adding/removing herself. Richard noted that this is a feature in the case that Alice is no longer synchronized with the group and therefore can use an external commit to add herself back in, removing the previous version. As opposed to any newcomer joining with an external commit, the case of Alice re-joining presents a potential security issue. Namely, as currently specified (in my reading of the draft), an existing group member, Bob, has no means to distinguish between the following cases: 1) Alice needs to resync and therefore performs an external commit and removes her prior version. 2) Alice’s signature keys are compromised (it is not necessary for the adversary to compromise any group state). The adversary performs an external commit in Alice’s name, and then removes her prior version and impersonates her to the group. One might hope that Alice notices that she is removed and communicates this to the group members OOB, but it is also possible that that she assumes some other reason for the removal, is offline, or simply is not active enough to take action for a fairly long compromise window. Even if she tries to use an external commit to get back into the group and then removes the adversary-as-Alice, there is no means for other group members distinguish the real Alice from the adversary-as-Alice and the process could be circular (until new valid identity keys are issued). While a newcomer is a fresh source to be trusted or not, Alice has been “healing” along with the group and the above option (2) allows the adversary to bypass all of that. The source of the problem is that when Alice re-syncs, she is not providing any validation of being the same/previous identity, so it is easy for other group members to accept that nothing more than a resync has taken place. Thus, a fairly straightforward solution is to require PSK use in cases where an external commit is used for resync.