Question: the congestion window. The minimum congestion window is the smallest value the congestion <del> window can decrease to as a response to loss, ECN-CE, or persistent congestion.  The RECOMMENDED value is 2 * max_datagram_size. </del> <ins> window can decrease to as a response to loss, increase in the peer- reported ECN-CE count, or persistent congestion.  The RECOMMENDED value is 2 * max_datagram_size. </ins> 7.3.

For example, text such as "an algorithm such as the one specified in [RFCxxxx] would be acceptable" indicates an informative reference, since that cited algorithm is just one of several possible algorithms that could be used. I am also somewhat concerned that trying to get the downrefs into the registry is more likely to run into trouble (Sec 3) This procedure should not be used if the proper step is to move the document to which the reference is being made into the appropriate category. It is not intended as an easy way out of normal process. Rather, the procedure is intended for dealing with specific cases where putting particular documents into the required category is problematic and unlikely ever to happen.
Thanks for digging up the relevant text, NAME Based on that text from RFC 3967, it doesn't seem like we need to make these references normative. I agree that the pipeACK reference is odd, but I think that's probably because of the use of MAY there. I'm happy to replace the MAY with a can -- it is meant to present an option, not a permission -- and make that reference informative as well. NAME : thoughts?
I think at last RFC3168 should be referenced normatively somewhere (probably section 7.1 though) because you need to know what the ECN bits are in order to do anything with it. I guess because of section 7.1. RFC8311 should also be a normative reference.
NAME RFC3168 is already a normative reference in the transport doc, which in my view is appropriate.
Was wondering about this as well given the transport doc is of course a normative reference of this doc. However, as this doc uses terms like CE also directly itself I think the right practice is to also have it as a normative reference here, and as you have to read it no matter what, it definitely shouldn't hurt.
talks about ECN-CE markings, but really all of Section 7 talks about a response to an increase in ECN-CE count by the peer, which is defined in the transport doc. This does point to a small editorial issue. The text in Section 4.1 says: This really should be:
Good point on the editorial issue.
With that change, the only thing we're left with is .


Question: the congestion window. The minimum congestion window is the smallest value the congestion <del> window can decrease to as a response to loss, ECN-CE, or persistent congestion.  The RECOMMENDED value is 2 * max_datagram_size. </del> <ins> window can decrease to as a response to loss, increase in the peer- reported ECN-CE count, or persistent congestion.  The RECOMMENDED value is 2 * max_datagram_size. </ins> 7.3.

This does require an understanding of ECN, and it has RFC 2119 keywords, but it's really an optional mechanism that is suggested. We could remove the RFC 2119 words there, since they're really unnecessary.
My point is that RFC3168 should be normative because not matter what you need to understand what an ECN-CE mark is and that is defined/specified in RFC3168.
Mirja has a point, see URL
-transport is a normative reference. So 3168 is already (transitively) a normative reference. The question is whether this specific text requires anything from 3168 to understand. I don't see that it does, especially given the suggested change, which talks about a concept defined in -transport, not 3168.
has made these editorial changes; NAME can you see if anything else needs to be done here?
I will note that it was never my intention to let any of theses Experimental or informational TCP specs to be added into the downref registry by this last call. So, the pipeack reference needs to be reformulated to not be a normative one. As currently stated it is a clear normative reference per IESG Statement ([URL]) , and especially "Note 1: Even references that are relevant only for optional features must be classified as normative if they meet the above conditions for normative references. " You need to find a formulation that normative describes what the implementation MAY do, and then you can exemplify with the TCP version. Then one in Section 7.3.2 I can accept as still being informative as the MAY statement is related to the primary aspect of the sentence and the reference to PPR is exemplifying. Still this is very much on the border and may still generate a comment in IESG. For RFC 3168 I don't understand why not making it to a normative one. There are no issues with its status as it is proposed standard. And simply the security consideration section still implies that you need to know what a ECN-CE mark is to interpret this. So please make this one normative.
I'm ok with RFC 3168 being normative, particularly since it's already normative in transport, but would like to avoid making the others normative.


Question: the congestion window. The minimum congestion window is the smallest value the congestion <del> window can decrease to as a response to loss, ECN-CE, or persistent congestion.  The RECOMMENDED value is 2 * max_datagram_size. </del> <ins> window can decrease to as a response to loss, increase in the peer- reported ECN-CE count, or persistent congestion.  The RECOMMENDED value is 2 * max_datagram_size. </ins> 7.3.

NAME if pipeack is not normative then a reformulation is necessary of that sentence in Section 7.8 to not state is as a mechanism that MAY be implemented.
The sentence currently has a can, not a MAY: "A sender can use the pipeACK method described in Section 4.3 of {{?RFC7661}} to determine if the congestion window is sufficiently utilized." But I sent out PR to make it clearer that pipeACK is an example, PTAL and see if that helps.
NAME what PR proposes removing that first sentence do resolve the pipeack to me. So merging , and moving RFC3168 to normative will resolve this issue to my understanding.
Thanks! I'll update PR to include moving RFC3168 to normative.
NAME NAME : I believe this is purely editorial, but I'd like to confirm.
We've meandered to a route that AFAICT makes reference types accurate to their existing intent, or avoids them becoming normative. I'm happy for this to be editorials.
I think that this is the most appropriate response.


Question: would apply to multiple recipient structures. contains information about the plain text that is not integrity <del> protected.  If there are no field, then the value 'null' is used. </del> <ins> protected.  If there are no field, then the value 'nil' is used. </ins> Only values associated with the current cipher text are to be placed in this location even if the value would apply to multiple recipient structures. contains the initialization vector (IV), or it's equivalent, if one is needed by the encryption algorithm.  If there is no IV, <del> then the value 'null' is used. </del> <ins> then the value 'nil' is used. </ins> contains additional authenticated data (aad) supplied by the application.  This field contains information about the plain text data that is authenticated, but not encrypted.  If the application <del> does not provide this data, the value 'null' is used. </del> <ins> does not provide this data, the value 'nil' is used. </ins> contains the encrypted plain text.  If the cipherText is to be transported independently of the control information about the <del> encryption process (i.e. detached content) then the value 'null' is encoded here. </del> <ins> encryption process (i.e. detached content) then the value 'nil' is encoded here. </ins> contains the recipient information.  The field can have one of three data types:

The document is updated to use the CDDL grammer from the latest version (-05) Fixed a couple of small errors where my thinking and my text did not match.


Question: large as to not be usable, the implementation SHOULD discard the capsule without buffering its contents into memory. <del> Note that use of the Capsule Protocol is not required to use HTTP Datagrams.  If an HTTP extension that uses HTTP Datagrams is only defined over transports that support QUIC DATAGRAM frames, it might not need a stream encoding.  Additionally, HTTP extensions can use HTTP Datagrams with their own data stream protocol.  However, new HTTP extensions that wish to use HTTP Datagrams SHOULD use the Capsule Protocol unless they have a good reason not to. </del> <ins> Note that it is possible for an HTTP extension to use HTTP Datagrams without using the Capsule Protocol.  For example, if an HTTP extension that uses HTTP Datagrams is only defined over transports that support QUIC DATAGRAM frames, it might not need a stream encoding.  Additionally, HTTP extensions can use HTTP Datagrams with their own data stream protocol.  However, new HTTP extensions that wish to use HTTP Datagrams SHOULD use the Capsule Protocol as failing to do so will make it harder for the HTTP extension to support versions of HTTP other than HTTP/3 and will prevent interoperability with intermediaries that only support the Capsule Protocol. </ins> 4.

This is a good step but I think it overlooks one of the points that Magnus articulated. If an HTTP extension does what we say here, it might fall foul of intermediaries and protocol version conversion. That not some we have to solve but I suspect if we can concisely describe those considerations we would address the issue.
Good point, added text
Thanks, this is much clearer and is a descent explanation of the issues and motivation behind the should. I guess a more correct part will require much more text.
The first SHOULD should be a MUST because there is a clear exception specified but in all other cases this is a MUST. The second SHOULD should really be a MUST. Or why is that a SHOULD? If there is a reason for a SHOULD this needs to be explained but I think it would break interoperability.
I personally preferred MUST, however the consensus of the design team was SHOULD, and that was confirmed by the WG. Let's no reopen that unless we have new information.
On , NAME said:
I think the main motivation was that the MUST was unenforceable, and that there will be intermediaries that explicitly want to block unknown extensions for security reasons.
Whatever we might prefer, isn't this a case where whatever the specification says, intermediaries will do what they want?
I agree. That's why in the interest of making progress I'd rather move forward with the design team consensus instead of reopening this topic.
design team outputs don't have any special status here; perhaps the answer is not to say "SHOULD this" or "MUST that" but to instead articulate the intent behind the design and the potential consequences of not complying with that intent. Perhaps the key reason for mandating forwarding is that the meaning of various protocol elements is only valid in the context of all of the messages that an endpoint says. That is, you might send a bunch of datagram capsules that have meaning derived from other capsules. Remove the other capsules and you change the meaning of those datagram capsules. An intermediary that adds, modifies, or removes any capsules needs to understand the totality of the effect of their interventions. This is why I remain skeptical about the value of the generic capsule protocol. It only has value if it can be acted upon generically, but it is not obvious that it can be.


Question: large as to not be usable, the implementation SHOULD discard the capsule without buffering its contents into memory. <del> Note that use of the Capsule Protocol is not required to use HTTP Datagrams.  If an HTTP extension that uses HTTP Datagrams is only defined over transports that support QUIC DATAGRAM frames, it might not need a stream encoding.  Additionally, HTTP extensions can use HTTP Datagrams with their own data stream protocol.  However, new HTTP extensions that wish to use HTTP Datagrams SHOULD use the Capsule Protocol unless they have a good reason not to. </del> <ins> Note that it is possible for an HTTP extension to use HTTP Datagrams without using the Capsule Protocol.  For example, if an HTTP extension that uses HTTP Datagrams is only defined over transports that support QUIC DATAGRAM frames, it might not need a stream encoding.  Additionally, HTTP extensions can use HTTP Datagrams with their own data stream protocol.  However, new HTTP extensions that wish to use HTTP Datagrams SHOULD use the Capsule Protocol as failing to do so will make it harder for the HTTP extension to support versions of HTTP other than HTTP/3 and will prevent interoperability with intermediaries that only support the Capsule Protocol. </ins> 4.

Put differently, the existence of a generic capsule protocol implies a number of constraints on the operation of extensions that are not obvious and not clearly articulated. NAME might be asking about similar effects in .
So lets start with explaining the interoperability issue that is at the core of this: So the draft currently has several statements that interact with each other to cause this interoperability issue. Section 3.5 says: 'Note that use of the Capsule Protocol is not required to use HTTP Datagrams. If an HTTP extension that uses HTTP Datagrams is only defined over transports that support QUIC DATAGRAM frames, it might not need a stream encoding.' Section 3.5 also says: 'An intermediary can reencode HTTP Datagrams as it forwards them. In other words, an intermediary MAY send a DATAGRAM capsule to forward an HTTP Datagram which was received in a QUIC DATAGRAM frame, and vice versa.' Thus the following may occur: Endpoint 1 sends a HTTP datagram as HTTP/3 Datagram over QUIC datagram. The HTTP intermediary re-encode this blind of its context to an Capsule Datagram and forward it to another HTTP intermediary that forwards it to an HTTP/3 endpoint using Datagram Capsule. As this HTTP datagram usage is one that does not require to support of Capsule Datagram this endpoint is not setup to handle this Datagram capsule and discards it. So this can either be fixed in various ways, not only what this issue text suggests: requiring the Datagram capsule support for all HTTP datagram handling nodes. In other words change the first quote. Require the HTTP intermediary to re-encode any Datagram capsules to HTTP/3 datagram if the next hop is know to support it. i.e. make additional requirements on how HTTP Intermediaries act when forwarding. Forbid blind forwarding of HTTP datagram in HTTP intermediaries. I think we should settle this part before going back to see how the text Mirja suggested changing matter. I think 1 and 2 are both working solutions, and would like to avoid 3. I think there is also a question on the implication of what it means to support HTTP datagram when one is an HTTP/3 endpoint or intermediary. Who is expected to support the Datagram capsule if the next node is not capable?


Question: large as to not be usable, the implementation SHOULD discard the capsule without buffering its contents into memory. <del> Note that use of the Capsule Protocol is not required to use HTTP Datagrams.  If an HTTP extension that uses HTTP Datagrams is only defined over transports that support QUIC DATAGRAM frames, it might not need a stream encoding.  Additionally, HTTP extensions can use HTTP Datagrams with their own data stream protocol.  However, new HTTP extensions that wish to use HTTP Datagrams SHOULD use the Capsule Protocol unless they have a good reason not to. </del> <ins> Note that it is possible for an HTTP extension to use HTTP Datagrams without using the Capsule Protocol.  For example, if an HTTP extension that uses HTTP Datagrams is only defined over transports that support QUIC DATAGRAM frames, it might not need a stream encoding.  Additionally, HTTP extensions can use HTTP Datagrams with their own data stream protocol.  However, new HTTP extensions that wish to use HTTP Datagrams SHOULD use the Capsule Protocol as failing to do so will make it harder for the HTTP extension to support versions of HTTP other than HTTP/3 and will prevent interoperability with intermediaries that only support the Capsule Protocol. </ins> 4.

So I think at the bottom this issue is really the question about the possibility to convert between HTTP/3 Datagram and Datagram capsule. I think we need to settle that question first. It is a question of what requirements one have on endpoints vs intermediaries. Lets start in that end.
I actually think I prefer your option 3, caveated by saying "if you're an intermediary and you don't know the upgrade token, don't insert datagram capsules" . What concern do you have about option 3?
Okay, I am skeptical against 3) on how it may make deployment of future extensions that require HTTP Datagram but doesn't need other than Intermediary forwarding. In that case deployment could be hampered if not all HTTP intermediaries are also HTTP/3 capable. It appears that using capsule protocol would be easier to enable over a legacy system. That might be a misconception from my part.
NAME Thank you for clarifying, now I understand where the disconnect is. The draft currently says and you interpreted that as but that's not what we intended, we meant . I've written up to remedy this
NAME great that we managed to sort out what was the issue. As Lucas noted in the PR unless all HTTP Datagram implementation support and accept receiving Datagram capsule, even if not intended by the HTTP Extension, if unaware of HTTP extension transformation is allowed, it can fail. I think we need a bit more feedback on where people stand in this aspect.
Thanks NAME If the HTTP extension doesn't use capsules, then the implementation won't parse the data stream as capsules so there is no risk of accidentally receiving capsules. We added text to to clarify the risks of not using the capsule protocol.
I think this was closed prematurely because the issue originally was about MUST or SHOULD and I don't think we concluded on this. If the argument is that this is not enforceable, I think we should not use normatively language at all (and say something like "intermediaries are expected ..."). However, using SHOULD were we actually mean MUST, weakens the requirement and risk that this is misunderstood to be optional (while I think this is the core of the whole capsule protocol).
Reopening to discuss SHOULD vs MUST.
I'd consider capsules to be similar to header fields (headers specifically, not trailers).


Question: large as to not be usable, the implementation SHOULD discard the capsule without buffering its contents into memory. <del> Note that use of the Capsule Protocol is not required to use HTTP Datagrams.  If an HTTP extension that uses HTTP Datagrams is only defined over transports that support QUIC DATAGRAM frames, it might not need a stream encoding.  Additionally, HTTP extensions can use HTTP Datagrams with their own data stream protocol.  However, new HTTP extensions that wish to use HTTP Datagrams SHOULD use the Capsule Protocol unless they have a good reason not to. </del> <ins> Note that it is possible for an HTTP extension to use HTTP Datagrams without using the Capsule Protocol.  For example, if an HTTP extension that uses HTTP Datagrams is only defined over transports that support QUIC DATAGRAM frames, it might not need a stream encoding.  Additionally, HTTP extensions can use HTTP Datagrams with their own data stream protocol.  However, new HTTP extensions that wish to use HTTP Datagrams SHOULD use the Capsule Protocol as failing to do so will make it harder for the HTTP extension to support versions of HTTP other than HTTP/3 and will prevent interoperability with intermediaries that only support the Capsule Protocol. </ins> 4.

Here's what HTTP says about them in URL >A proxy MUST forward unrecognized header fields unless the field name is listed in the header field () or the proxy is specifically configured to block, or otherwise transform, such fields. Other recipients SHOULD ignore unrecognized header and trailer fields. Adhering to these requirements allows HTTP's functionality to be extended without updating or removing deployed intermediaries. Yeah, in actuality an intermediary can do lots of stuff, and in practice they do. But if a MUST is good enough for HTTP headers, why isn't it here?
From memory it was either NAME or NAME who cared strongly about this not being a MUST. I'm fine either way as long as we don't drag this one needlessly.
To summarize the discussion on this issue up to this point: we're debating whether to tell intermediaries that they MUST or SHOULD forward unknown capsules unmodified implementors of intermediaries will not react to either one of these words differently endpoints have no way of enforcing this MUST some folks felt very strongly against MUST the working group landed on this design and no new information has surfaced since Based on the points above, there is no reason to hold up document progress based on a single word that will not have any impact. Therefore I'm closing this issue with no action. Hearing no objections, we’re declaring consensus. Thanks again to the participants of the Design Team for their hard work in preparing these changes, and to everyone else for offering reviews and feedback! Best, Chris and Eric


Question: actions are alternatives (e.g., whether to initiate a connection or to listen for incoming connections), while others are optional (e.g., setting Connection and Message Properties in Pre-Establishment) or <del> have been omitted for brevity. </del> <ins> have been omitted for brevity and simplicity. </ins> 4.1.1.

Fig. 4 isn't fully consistent with sec. 12 in the API document. A few things that stood out to me: InitiateWithSend() is missing. I can see that this isn't trying to cover everything, but randomly leaving some things out makes it all a bit confusing IMO... "Connection Received" reads as if it should really be the "ConnectionReceived<>" event in the API doc. So I would put these events there and use the "<>" to indicate them. Same with "Closed"... this is actually an event, so why not write it as such, with the "<>"? RendezvousDone is missing... should we include all events or not? Of course that would then also require adding Sent, Received, ... maybe it would be better to indicate that events are events, but put a statement somewhere saying that not all events are shown. In the same vein, I would replace "Connection Ready" with "Ready<>" "Conn. Finished" reads as if it might be an event, but this event doesn't exist... I would just remove this
I've added InitiateWithSend(), and removed Conn. Finished; you're right, these are confusing. This diagram does not use the API draft's event notation, and I'm not sure it makes sense to introduce it here -- it would require a bit more expository text only to make a diagram that is an attempt to provide a high-level view provide a... less high-level view. (The expository text now says "... some actions ... have been omitted for brevity and simplicity" and I think that's the right approach.)
Agreed!
lgtm


Question: The COSE_encrypt structure for the recipient is organized as follows: <del> The 'protected', 'aad', and 'iv' fields all use the 'null' value. </del> <ins> The 'protected', 'aad', and 'iv' fields all use the 'nil' value. </ins> At a minimum, the 'unprotected' field SHOULD contain the 'alg' parameter as well as a parameter identifying the asymmetric key.


Question: One example of "RateLimit-Remaining" use is below. <del> 5.3. The "RateLimit-Reset" response field indicates either </del> <ins> 5.4. </ins> <del> the number of seconds until the quota resets. </del> <ins> The "RateLimit-Reset" response field indicates the number of seconds until the quota resets. </ins> <del> The field is an Integer Structured Field and its value is </del> <ins> The field is a non-negative Integer. </ins> The delay-seconds format is used because:

moves quota-policies from RateLimit-Limit -> RateLimit-Policyrequires WG discussion -
Given this hint from Mark URL I think it's fine to merge this PR (separate Policy from Limit) since there seems to be agreement to use different fields at least in this case.
Perhaps best to continue discussion in that issue before merging this? While the change will happen in a similar vein, we might want to wait to flesh out further details.
This seems quite arbitrary for a MUST; what is "too far in the future" and "too high"?
Agree, this is an tricky point. I think an implementation: MUST define internal threeshold of allowed values; MUST validate ratelimit fields according to those thresholds. I think we could borrow some text from Signature. See
OK, but RFC2119 language is for interoperability, and this doesn't provide any; different implementations (or deployments) are going to have different values, and that may cause issues. It'd be better to defines precise limits if you think this is important enough to merit a MUST. Personally, I'd remove the 2119 language and just give guidelines about what implementations should consider when they're looking for abuse.
Ok, great!
Addressed in
The draft today suggests putting quota policies, a list, into the header. But that's a sort of breaking change, because that header's equivalent is strictly a number (not a list) in most existing implementations. Could be kept as a plain number (like and ), and instead a new header like or some such can contain supplementary information? That way, the story for upgrading to this draft is simpler. Sorry if this is asked and answered.
iirc we considered this but we initially had some requests of conflating as much as possible in fewer fields. Probably it's a more interoperable choice. I am open in re-considering the idea, provided we get in touch with the current implementers including 3scale, kong and envoy cc: 3scale: NAME , kong: NAME , envoyproxy: NAME
There's no inherent problem in using a specific header for policies, and no issue in moving to use them from the 3scale side. The only downside is we're adding yet another header for rate limiting, currently 4 of them, which might raise a few eyebrows.


Question: One example of "RateLimit-Remaining" use is below. <del> 5.3. The "RateLimit-Reset" response field indicates either </del> <ins> 5.4. </ins> <del> the number of seconds until the quota resets. </del> <ins> The "RateLimit-Reset" response field indicates the number of seconds until the quota resets. </ins> <del> The field is an Integer Structured Field and its value is </del> <ins> The field is a non-negative Integer. </ins> The delay-seconds format is used because:

NAME thanks :) do you think that splitting is a more interoperable choice wrt to the parsing implementation / usability? Do you see other practical drawbacks? if we don't get feedback on this issue, can you ping the other implementers you know?
Yes, it's easier for people to pick up a new header for this to apply a policy, since as it stands they might break when seeing extra stuff in the limit one by expecting a single value rather than multiple, as NAME mentions above. No, just dealing with people (maybe) opposing too-many-headers - I don't know if this is something that we can predictably foresee happening in the HTTPAPI WG or in the HTTP WG, but my intuition says "likely" given how we were asked to "condense" this information, so I think we might want to spend some time making a good case out of it. NAME other than potential breakages in pre-existing implementations, is there any additional point we could make to justify the additional header? I think they are all currently listed - that being said I think porting to a new header should be an easy task, so hopefully not a problem.
if almost everyone is implementing just the minimal specification, probably this could even simplify the addition of ...
The primary motivation is breakage, as you suggest, NAME The secondary motivation is ease of "upgrading" to adoption of quota policies, as NAME suggests. The flipside of "easy to adopt, easy to upgrade" is that the spec would also make it easy to never upgrade at all. This is a good thing, supposing that most services can operate perfectly fine without quota policies. A third, much weaker argument, is that the current approach of putting the "limit" and "quota policy" in the same header is that it's confusing. I would need more time to really state this argument more clearly, but what rubs me the wrong way here is that the current design basically puts two different kinds of data in the same list. As it stands, is a list of a numbers, but the first number (the "limit") is not like the rest of the numbers (the policy). The first number cannot have SFV parameters, but the others can (and typically will). It's an accident of SFV's syntax that this is even conceivable as an approach.


Question: One example of "RateLimit-Remaining" use is below. <del> 5.3. The "RateLimit-Reset" response field indicates either </del> <ins> 5.4. </ins> <del> the number of seconds until the quota resets. </del> <ins> The "RateLimit-Reset" response field indicates the number of seconds until the quota resets. </ins> <del> The field is an Integer Structured Field and its value is </del> <ins> The field is a non-negative Integer. </ins> The delay-seconds format is used because:

For implementors, this means that does not simply deserialize as some sort of . It deserializes into a list, where the first element is an and the tail is a . I fear this will at minimum confuse folks, and perhaps even lead to incorrect implementations, such as people not realizing the first element of the list is not a quota policy at all.
Given URL it seems there's some consensus in providing quota policy in a separate field.


Question: IDs from other QUIC versions in order to properly form a version negotiation packet. <del> The Source Connection ID field follows the SCID Length field and is between 0 and 20 bytes in length. negotiating-connection-ids describes the use of this field in more detail. </del> <ins> The Source Connection ID field follows the Source Connection ID Length field and is between 0 and 20 bytes in length. negotiating- connection-ids describes the use of this field in more detail. </ins> In this version of QUIC, the following packet types with the long header are defined:

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


Question: PATH_ABANDON frame is considered lost, the peer SHOULD repeat it. PATH_ABANDON frames MAY be sent on any path, not only the path <del> identified by the Packet Number Space Identifier. </del> <ins> identified by the Path Identifier. </ins> 8.2.

From PR from NAME
Let's do another editorial pass and evtl. some re-org first and then address this issue. I think we all already agreed that we only need one of the two. So we only need to decide with name we keep.
I prefer to use the name "Path ID", as it is more intuitive in the context of multipath.
The conflict was solved. LGTM.Sounds good.


Question: analysis could be used to match messages that are forwarded by the relay. <del> A relay could, as part of its function, add delays in order to increase the anonymity set into which each message is attributed. This could latency to the overall time clients take to receive a response, which might not be what some clients want. </del> <ins> A relay could, as part of its function, delay requests before forwarding them.  Delays might increase the anonymity set into which each request is attributed.  Any delay also increases the time that a client waits for a response, so delays SHOULD only be added with the consent - or at least awareness - of clients. </ins> A relay that forwards large volumes of exchanges can provide better privacy by providing larger sets of messages that need to be matched.

I presume the idea here is to add jitter to the system (different delays for different requests) rather than compound delays on a single request? Even if not, this paragraph could probably benefit from some language fixups. There's a missing word and "might not be what some clients want" could benefit from a rephrasing to make it stronger.
clearer, thanks


Question: than -1, it sets the minimum protection in protocols that allow limiting the checksum length (e.g.  UDP-Lite). <del> Singular Transmission: when this is true, the application requests to avoid transport-layer segmentation or network-layer fragmentation.  Some transports implement network-layer fragmentation avoidance (Path MTU Discovery) without exposing this functionality to the application; in this case, only transport- layer segmentation should be avoided, by fitting the message into a single transport-layer segment or otherwise failing.  Otherwise, network-layer fragmentation should be avoided--e.g. by requesting the IP Don't Fragment bit to be set in case of UDP(-Lite) and IPv4 (SET_DF in RFC8304). </del> <ins> Singular Transmission: When set, this property limits the message size to the Maximum Message Size Before Fragmentation or Segmentation (see Section 10.1.7 of I-D.ietf-taps-interface). Messages larger than this size generate an error.  Setting this avoids transport-layer segmentation or network-layer fragmentation.  When used with transports running over IP version 4 the Don't Fragment bit will be set to avoid on-path IP fragmentation (RFC8304). </ins> 5.1.2.

this should
Right there was a typo: Replacing the last 2 sentences, the last sentence ought to be: " Endpoints should avoid IP fragmentation ({{!RFC8304}}) and when used with transports running over IP version 4 the Don't Fragment bit will be set." These are two separate issues that a stack implementor has to decide to do: (1) Decide if the endpoint will fragment; (2) decide if the path can fragment the fragments. In some OS this will be bundled together, in other OS they will not.
Discussed on the interim call. The name probably could be much better. We also want to model in the text the atomicity property of UDP transfers.
This text is broken: section 5.1 / o Singular Transmission: when this is true, the application requests to avoid transport-layer segmentation or network-layer fragmentation. Some transports implement network-layer fragmentation avoidance (Path MTU Discovery) without exposing this functionality to the application; in this case, only transport- layer segmentation should be avoided, by fitting the message into a single transport-layer segment or otherwise failing. Otherwise, network-layer fragmentation should be avoided--e.g. by requesting the IP Don't Fragment bit to be set in case of UDP(-Lite) and IPv4 (SET_DF in [RFC8304]). / we need to rewrite
Waiting to see exactly how DPLPMTUD finishes WGLC ... will be ready for text in Jan.
Reads much better except the last broken sentence


Question: If more than one Remote Endpoint is specified on the Preconnection, then all the Remote Endpoints on the Preconnection SHOULD represent <del> the same host.  For example, the Remote Endpoints might represent </del> <ins> the same service.  For example, the Remote Endpoints might represent </ins> various network interfaces of a host, or a server reflexive address that can be used to reach a host, or a set of hosts that provide equivalent local balanced service.

, , , , , .
In 8.1.1 the second sentence is convoluted. Is there a way to restate it without as many nots, nons, an different zeros?
Do you really mean "host" at "(endpoints) SHOULD represent the same host" in section 6, or do you mean something more like service, given that an endpoint may configured with a DNS name?
actually we mean service, good catch.
The "reformatted where necessary" part of the requirement in the last paragraph of 4.1 makes the MUST NOT almost impossible to conform to. I think I understand what the paragraph is trying to say, but the current formulation leaves the reader guessing. I think you are trying to say "Avoid using any of the terms listed as keywords in the protocol numbers registry as any part of a vendor or implementation-specific property name".
The first sentence-paragraph of section 4 is complex. Please break it apart.
has a comment that's too long for the text version
In the text version of the document, the last paragraph before 3.1.3 has some markup (~~~) that has leaked through.
As you can tell, I don't think the documents do what the first sentence of the API summary claims. This document would not lose anything if you deleted the sentence.
Agreed, we can lose this sentence.
Why? Removing this makes no sense to me.
For one, it's redundant - it only repeats what we already say earlier twice.
Ah, I see - so just this one instance..... then go ahead, we don't need to say something twice.


Question: The COSE_encrypt structure for the recipient is organized as follows: <del> The 'protected', 'aad', and 'iv' fields all use the 'null' value. </del> <ins> The 'protected', 'aad', and 'iv' fields all use the 'nil' value. </ins> The plain text to be encrypted is the key from next layer down (usually the content layer).


Question: whether in the same conveyance protocol as part of the Evidence or not. <ins> As explained in overview, artifacts are defined by which roles produce them or consume them.  In some protocol instantiations, other roles may cache and forward artifacts as opaque data, to one or more entities implementing the consuming role. </ins> 4. RFC4949 has defined a number of terms that are also used in this

attempt to provide forward reference as requested on Monday
This looks good to me, although I wonder whether the sentence would make more sense at the end of the "Implementation Considerations" section (a couple lines earlier in the document). I am ok either way.
Works for me. That would put that into section 1.
"artifacts are defined by which roles produce them or consume them" - This sentence structure seems awkward. Is "artifacts are defined by the roles that produce or consume them" better?LGTM


Question: A KeyPackage object specifies a ciphersuite that the client supports, as well as providing a public key that others can use for key <del> agreement.  The client's identity key can be updated throughout the </del> <ins> agreement.  The client's signature key can be updated throughout the </ins> lifetime of the group by sending a new KeyPackage with a new <del> identity; the new identity MUST be validated by the authentication service. </del> <ins> signature key; the new signature key MUST be validated by the authentication service. </ins> When used as InitKeys, KeyPackages are intended to be used only once and SHOULD NOT be reused except in case of last resort.  (See

The credentials we have defined at the moment only contain a single public key and no information regarding what signature scheme that keypair works with (even though the Spec actually says it should include the signature scheme as well). It would be nice, however, to support potential CredentialTypes that, similar to KeyPackages, include multiple supported signature schemes, each accompanied by a corresponding public key. The Key that should be used in any given group is then determined by the CipherSuite of the group (which includes a Signature Scheme). When choosing a KeyPackage of a new member, it has to be one that contains a Credential which supports that Signature Scheme. Note, that I'm not suggesting that this be the case in all Credentials, or even that we change the BasicCredential. I understand that it's possible to have multiple credentials per identity, but in some authentication settings it can be beneficial to have a 1-to-1 mapping between Credential and identity.
KeyPackages don't support multiple signature schemes? In what scenario is it beneficial?
Ah, right. I think that was the case in the past, but you're right, they don't. Of course it's always possible to just bundle a bunch of certificates, each supporting a different signature scheme and then treat that as your "Multi-Scheme Credential" in the grand scheme of things. However, if you end up rotating them a lot, where you have to sign them and potentially store the whole chain for a longer period of time, being able to support multiple signature schemes in only one credential means less overhead.
Credentials are stored in each group's ratchet tree though, so you're keeping a bunch of unnecessary key material in the group's tree which everyone has to store
That's fair. And it's not something you have to do if you don't want to. I'm just proposing for MLS to support that type of Credential in general.
To support hybrid PQ/standard schemes at any point in the future, allowing for multiple schemes is reasonable (in addition to the above arguments for it). Most applications probably will not use the feature, especially to start with, but providing support for just the option is not going to cause any of the problems noted.
PQ schemes can be used by switching the entire group to a new ciphersuite using those schemes.


Question: A KeyPackage object specifies a ciphersuite that the client supports, as well as providing a public key that others can use for key <del> agreement.  The client's identity key can be updated throughout the </del> <ins> agreement.  The client's signature key can be updated throughout the </ins> lifetime of the group by sending a new KeyPackage with a new <del> identity; the new identity MUST be validated by the authentication service. </del> <ins> signature key; the new signature key MUST be validated by the authentication service. </ins> When used as InitKeys, KeyPackages are intended to be used only once and SHOULD NOT be reused except in case of last resort.  (See

Requiring everybody in the group to store a bunch of unused key material isn't reasonable
The statement was not about PQ, but hybrid PQ/standard schemes. Those require use to two signature schemes, for which both types of keying material are used.
Then you need a ciphersuite that specifies a hybrid scheme.
It would be ideal to have a ciphersuite specifying a single hybrid scheme, but even that does not imply use of a single credential, unfortunately. In fact, hybrid schemes may rely on two separate credentials, with the ciphersuite specifying the hybrid algorithm for combining them. Since the "main" method of building a solo hybrid credential is under patent, there is also additional motivation for applications to use two.
I concur with Brendan here. To be consistent with our earlier decisions to (a) keep KeyPackages to one ciphersuite and (b) include the signature algorithm in the ciphersuite, we should keep credentials to one signature algorithm as well. Propose closing this PR without merging.
Discussed at 2020-10-06 interim, TODO: Re-add SignatureScheme enum, re-using the TLS signature schemes Clarify that the main job of a Credential is to provide a public key for verifying messages How it provides the credential might be different per credential type e.g., in BasicCredential, it's provided directly, X509Credential, have to parse the leaf certificate
LGTM with a couple nits.


Question: 2.2. <del> For any remote host ICE candidate received by the ICE agent, the following procedure is used: </del> <ins> For any remote ICE candidate received by the ICE agent, the following procedure is used: </ins> If the connection-address field value of the ICE candidate does not end with ".local" or if the value contains more than one ".",

PR for
Seems all feedback is addresses?
Host ICE candidates, ICE host candidates, or something else?


Question: Responder, respectively, see m3 and m2. When the credential is a certificate, CRED_x is an end-entity <del> certificate (i.e., not the certificate chain), encoded as a CBOR bstr.  In X.509 and C509 certificates, signature keys typically have key usage "digitalSignature" and Diffie-Hellman public keys typically have key usage "keyAgreement". </del> <ins> certificate (i.e., not the certificate chain).  In X.509 and C509 certificates, signature keys typically have key usage "digitalSignature" and Diffie-Hellman public keys typically have key usage "keyAgreement". </ins> To prevent misbinding attacks in systems where an attacker can register public keys without proving knowledge of the private key,

CRED_R - bstr containing the credential This is not true for C509 which is an CBOR array


Question: Endpoints validate ECN for packets sent on each network path independently.  An endpoint thus validates ECN on new connection establishment, when switching to a new server preferred address, and <del> on active connection migration to a new path. </del> <ins> on active connection migration to a new path.  ecn-alg describes one possible algorithm for testing paths for ECN support. </ins> Even if an endpoint does not use ECN markings on packets it transmits, the endpoint MUST provide feedback about ECN markings

This turned out to be fairly simple, but I think that it's worth writing down. I don't have concrete recommendations, but I could add them if people thought that they help. See the commented-out bit.
Thanks both for the reviews, I've taken some of the suggestions and moved this to the appendix.
After discussing with editors, we agreed that this was a reasonable interpretation of existing text. We do agree that it would be worth discussing Mirja's views on ECN reliability and possibly changing the algorithm to reflect that, but it would be a design change.
In , NAME suggested that a different algorithm might be better to recommend enabling ECN and only disabling it if a failure is detected. That algorithm adopts the same posture as the draft: that ECN is optional and that endpoints are permitted to be cautious in enabling it. If we want to adopt the view that ECN works and endpoints are required to use it unless it breaks, that's a bigger change. I open this issue, while being aware that this is re-opening something we discussed and agreed previously, without there being new information to present. Chairs, if you do think we should discuss this, it's a design issue.
I would not be in favor of reopening this.
Just to clarify the proposal was that if you decide to enable ECN, you should just do it and only disable if you notice a failure, instead of having the more complicated probing logic that we have right now (in the appendix I think)
The shows that out of 14 implementations doing active tests, only 3 demonstrate ECN support. No ill will, but major places like AWS or the Windows OS do not support ECN, so it is not clear what more text in the spec would change.
This is just about this one paragraph: The concrete proposal would be to remove this paragraph.
Discussed in ZRH. Proposed resolution is to close with no action.
I will make a proposal for an editorial PR for the paragraph mention above to make it sounds less scary that this risk exists.
ECN-capable is not a constant condition, but we don't have any algorithm that governs it. I don't think that we can just say "mark until validation of ECN counts fails".


Question: Endpoints validate ECN for packets sent on each network path independently.  An endpoint thus validates ECN on new connection establishment, when switching to a new server preferred address, and <del> on active connection migration to a new path. </del> <ins> on active connection migration to a new path.  ecn-alg describes one possible algorithm for testing paths for ECN support. </ins> Even if an endpoint does not use ECN markings on packets it transmits, the endpoint MUST provide feedback about ECN markings

Maybe the following algorithm is OK: When starting a new path: set ECN state to "testing" after N packets or M round trips, set ECN state to "unknown" on every ACK, check ECN counts if ECN validation fails set ECN state to "failed". if ECN validation passes and ECN state is "uncertain", set it to "capable". when sending packets, mark with ECT(0) if state is "testing" or "capable" (I know that this is unchanged text, but I just realized that we could be clearer.) Gorry pointed out that we can add an extra thing: if a path is marked as "failed", you MAY choose to occasionally switch back to "testing". Mirja pointed out that we need to deal with bleaching more than we need to worry about black holes. We should negotiate that. Originally posted by NAME in URL
I also would suggest one more intro sentence could please some to say "When a path supports ECN, this enables ECN marking and uses ECN for a new path" - to effectively say that the validation is about how to detect and react to problems with a path that is not ECN capable.
Discussed in Cupertino.
Presumably this is just another section in Section 13.4? That would be useful.


Question: of the selector entries in the list and yields the concatenation of the lists (in the order of the selector entries) of nodes selected by the selector entries.  Note that any node selected in more than one <del> of the selector entries is kept as many times in the node list. </del> <ins> of the selector entries is kept as many times in the nodelist. </ins> To be valid, integer values in the "element-index" and "slice-index" components MUST be in the I-JSON range of exact values, see synsem-

The index selector (but not the index wildcard selector) selects no elements from non-arrays. See URL for background.
This seems implicit since JSON objects cannot be numerically accessed.
Yes, but making it explicit is clearer.
This looks okay, and it aligns the text with the previous paragraph.


Question: 2. <del> Application servers that wish to self-identity generate and maintain </del> <ins> Application servers that wish to self-identify generate and maintain </ins> a signing key pair.  This key pair MUST be usable with elliptic curve digital signature (ECDSA) over the P-256 curve FIPS186.  Use of this key when sending push messages establishes an identity for the

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


Question: packetization defines models for the transmission, retransmission, and acknowledgement of data, and <del> packet-size specifies rules for managing the size of packets. </del> <ins> datagram-size specifies rules for managing the size of datagrams carrying QUIC packets. </ins> Finally, encoding details of QUIC protocol elements are described in:

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


Question: packetization defines models for the transmission, retransmission, and acknowledgement of data, and <del> packet-size specifies rules for managing the size of packets. </del> <ins> datagram-size specifies rules for managing the size of datagrams carrying QUIC packets. </ins> Finally, encoding details of QUIC protocol elements are described in:

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


Question: The alert level of all TLS alerts is "fatal"; a TLS stack MUST NOT generate alerts at the "warning" level. <ins> QUIC permits the use of a generic code in place of a specific error code; see Section 11 of QUIC-TRANSPORT.  For TLS alerts, this includes replacing any alert with a generic alert, such as handshake_failure (0x128 in QUIC).  Endpoints MAY use a generic error code to avoid possibly exposing confidential information. </ins> 4.11. After QUIC moves to a new encryption level, packet protection keys

This defines a limit on the number of packets that can fail authentication before you have to use new keys. There is a big hole here in that AES-CCM (that is, the AEAD based on CBC-MAC) is currently permitted, but we have no analysis to support either the confidentiality limits in TLS 1.3 or the integrity limits in this document. It is probably OK, but that is not the standard we apply here. So this might have to remain open until we get some sort of resolution on that issue. My initial opinion is to cut CCM from the draft until/unless an analysis is produced.
In the interest of transparency, I have added one more commit here. When I did the same for DTLS, ekr observed that if you have updated, you might safely stop trying to accept packets with the old keys rather than killing the connection. That results in loss for any packets that genuinely did want to use the exhausted keys, but that is probably less disruptive than having the connection drop. Of course, you can't always update, so closure is still likely necessary in some cases.
For what it's worth, Martin, Felix, and I put together a document which might help users do this themselves: URL
NAME Could you use that to come up with 2^16 limits and put them in the doc? I’m really wary of letting implementors roll their own
Sure! Can you please file an issue with that request? Noting anything else you'd like spelled out in detail would be helpful, too.
tl;dr We need to recommend limits on the number of failed decryptions. At one of the side discussions concentrated on the quality of the analysis of the and the applicability of that analysis to QUIC. Felix Günther, along with Marc Fischlin, Christian Janson, and Kenny Paterson have done a little analysis, based on and the we used to set limits in TLS. There are two relevant limits in this analysis: The confidentiality bound, which is usually expressed in terms of advantage an attacker gains in being able to break confidentiality of records/packets as they get more data from valid packets.


Question: The alert level of all TLS alerts is "fatal"; a TLS stack MUST NOT generate alerts at the "warning" level. <ins> QUIC permits the use of a generic code in place of a specific error code; see Section 11 of QUIC-TRANSPORT.  For TLS alerts, this includes replacing any alert with a generic alert, such as handshake_failure (0x128 in QUIC).  Endpoints MAY use a generic error code to avoid possibly exposing confidential information. </ins> 4.11. After QUIC moves to a new encryption level, packet protection keys

For instance, in AES-GCM, the analysis shows that after seeing 2^24.5 packets (almost 24 million) the attacker has a 2^-60 better chance than pure chance of winning the IND-CPA game. The forgery bound, which is again expressed as an probably of an attacker successfully creating a forged record/packet. Thanks to the analysis done previously, we know that AES-GCM and ChaCha20+Poly1305 have a forgery chance of 2^-57 after 2^60 and 2^36 forgery attempts respectively. The current text just points to TLS 1.3, which recommends the use of key updates to protect confidentiality. But TLS has a forgery tolerance of 0: a single failed forgery attempt causes the connection to break. QUIC (and DTLS) allow for multiple forgeries to be ignored, so we need to factor that in. As discussed in if we want to maintain security, we need to consider both confidentiality and integrity. For that we need two independent limits: The number of packets that are successfully encrypted and decrypted. The number of packets that are unsuccessfully decrypted. We have the former already. The latter is what this issue tracks. Once the limit is at risk of being exceeded, updating keys will force the attacker to start over. Based on Felix's recommendation I am going to suggest that we limit forgery attempts to 2^36. I have confirmed this with a close reading of the paper and concur. There is a significant difference here between AES-GCM and ChaCha20+Poly1305 but we believe that setting a single limit is the best approach. I will create a pull request to document this approach shortly. We could split the recommendation and allow a larger limit for AES-GCM, but I don't believe that 2^36 (~68 billion) is a significant barrier. For reference, if you were able to saturate a 10Gbps link with 50 byte IP packets that contained plausible QUIC packets, and the recipient didn't treat this as DoS traffic, it would take 5 minutes. If we assume that are more likely representative of potential packet rates, then the limit goes up to 10s of hours.


Question: The alert level of all TLS alerts is "fatal"; a TLS stack MUST NOT generate alerts at the "warning" level. <ins> QUIC permits the use of a generic code in place of a specific error code; see Section 11 of QUIC-TRANSPORT.  For TLS alerts, this includes replacing any alert with a generic alert, such as handshake_failure (0x128 in QUIC).  Endpoints MAY use a generic error code to avoid possibly exposing confidential information. </ins> 4.11. After QUIC moves to a new encryption level, packet protection keys

I would point out that that volume of unproductive traffic is probably a good reason to use something other than a key update to deal with the sender. A reminder that the underlying analysis assumes that packets are all 2^14 in size, which is the record size in TLS. This is ~10 times larger than typical MTU on the Internet and many QUIC packets might be smaller than that, so - at least for AES-GCM - recommending a 2^36 limit is more conservative than necessary. However, if we were to allow for different limits, we'd have to address the question of packet size, as a 2^16 byte packet will be used by some deployments. For ChaCha20+Poly1305, the only value that matters is the number of packets, so we avoid that question. Quoting from Felix's email for reference (with permission):
NAME Can I request that you review this analysis for correctness? I know that you had reservations about the claims here.
Another (simplier?) option could be to just update keys much more often. I've done performance tests with msquic on the effect of updating the key ~once per round trip. There was no noticeable effect on performance. In fact, more often than not, the key update perf tests happen to perform slightly better (within noise tolerance) than without key update. I'm not suggesting we advocate once a round trip or anything near that; more like every 2^20 packets (or 2^30 bytes?) sent or received (including failed decryptions). As I understand it, this is an ultra conservative number as far as protecting from any kind of attacks, and should be free as far as any performance impact on the connection. This also has the added benefit of exercising the key update scenario more often, which should hopefully improve interoperability of the feature.
I support a change like this, but I am not qualified to say what the thresholds should be. There certainly isn't a reason to push it to very high limits. This change would not break interoperability, so it's a good one. Banning CCM might break interoperability for someone, but I'm not too concerned, particularly if we can update all the browsers to not offer it.


Question: The alert level of all TLS alerts is "fatal"; a TLS stack MUST NOT generate alerts at the "warning" level. <ins> QUIC permits the use of a generic code in place of a specific error code; see Section 11 of QUIC-TRANSPORT.  For TLS alerts, this includes replacing any alert with a generic alert, such as handshake_failure (0x128 in QUIC).  Endpoints MAY use a generic error code to avoid possibly exposing confidential information. </ins> 4.11. After QUIC moves to a new encryption level, packet protection keys

A somewhat bigger concern is the lack of key update support in a lot of implementations: I read 9 of 15 servers as supporting it.
(Tentative) good news on CCM: Kenny identified a security analysis paper and it seems relatively simple to go from that to numbers. I am not personally concerned about support for key update. 9/15 isn't 15, but that doesn't bother me. It turns out to be a little fiddly to implement, so if people decide to drop connections that hit these limits instead, the effect isn't that bad. Of course, if you want to follow Nick's suggestion, that works too (I remember Dan Bernstein seriously suggesting a cipher that updated every record, back when I first proposed this scheme for TLS).
If we're looking for a new bound to initiate a key update, there's precedent in the SSH RFC to rekey after every 1 GB of data transferred. See
I should point out that my "9 of 15" figure is based on the interop matrix, where the client initiates an early update and the server responds. That is a different thing than a server initiating an update when required by the spec, which fewer than 9 servers might do.
Based on by Jonsson, I have calculated the bounds on the number of forgeries and encryptions for CCM. The numbers aren't great, but that probably doesn't matter much for the purposes to which CCM is generally put. (I'm using the notation from the here because that is easier to type than some of what is being used in other papers. For reference, q is the number of genuine encryptions, l is the length of each in 16 byte blocks, v is the number of forgeries, n is the key length in bits, t is the tag length in bits.) Jonsson puts the advantage an attacker has over a generic PRF at . If we assume the same numbers in the AEBounds paper for record/packet size, (this is for consistency, most QUIC packets will be much smaller, in the order of 2^7, but we might also go as high as 2^12; this being dictated by the MTU). For AES, .


Question: The alert level of all TLS alerts is "fatal"; a TLS stack MUST NOT generate alerts at the "warning" level. <ins> QUIC permits the use of a generic code in place of a specific error code; see Section 11 of QUIC-TRANSPORT.  For TLS alerts, this includes replacing any alert with a generic alert, such as handshake_failure (0x128 in QUIC).  Endpoints MAY use a generic error code to avoid possibly exposing confidential information. </ins> 4.11. After QUIC moves to a new encryption level, packet protection keys

To keep the advantage an attacker has to 2^-60 (to match the analysis in TLS), we therefore need to keep q to below 2^24.5. Somewhat unsurprisingly, that matches the numbers we have for AES-GCM. Jonsson puts the advantage for an attacker over a generic PRF at . As the first term is negligible even for large v (up to 2^64), we consider the second term alone and aim for a bound on the advantage of 2^-57 to match the analysis for other ciphers. That leaves us with . As q is already established to be 2^24.5, we can say that v should be limited to 2^25 (or if you want to be precise). (As a side note, for t=64, as in AEADAES128CCM8, the first term becomes relevant and our security bound limits the number of forgeries to 2^7, which is probably a bit limiting in practice. That's good justification for not enabling AEADAES128CCM_8 by default; though different applications might use a different target bound than 2^-57.) I'm an not a cryptographer. These papers all read like chicken-chicken-chicken. My calculations are not infallible either.
The shape of the bound seems plausible but I'll start a thread with the cryptographers to check everything
I reproduced Martin's analysis of CCM based on of the bounds by . (Myself not being an expert in producing such bounds, I found the second-level confirmation by Rogaway to be helpful.) I essentially agree with the numbers, except that --when following the same metric as the -- the advantage over an ideal PRP (instead of PRF) should be considered. This simply means losing a 1/2 factor in the bound: Confidentiality bound: yields an advantage of . I'd hence say it's fine to keep TLS 1.3's recommendation on sending max. full-sized records. Integrity bound: , hence yields an advantage of (matching the other analyses). Most importantly, I concur with Martin that AEADAES128CCM8 would need either much lower bounds or a different risk assessment: applying the same limit of would bring the advantage incurred through the bound up to .


Question: The alert level of all TLS alerts is "fatal"; a TLS stack MUST NOT generate alerts at the "warning" level. <ins> QUIC permits the use of a generic code in place of a specific error code; see Section 11 of QUIC-TRANSPORT.  For TLS alerts, this includes replacing any alert with a generic alert, such as handshake_failure (0x128 in QUIC).  Endpoints MAY use a generic error code to avoid possibly exposing confidential information. </ins> 4.11. After QUIC moves to a new encryption level, packet protection keys

Would it still be the best approach to define the same anti-forgery limit across all cipher suites, even if this means going down to ? Of course, I'm happy to discuss more with NAME !
Thanks for checking this NAME I was a little concerned about the PRP/PRF split, so I'm glad to have you correct me. I ultimately went with per-AEAD recommendations, and a lower limit for CCM. That's mainly to establish some sort of uniformity around 2^-60 and 2^-57. Even if those are basically arbitrary choices, at least they are defensible (I think!) and using them uniformly establishes the right expectations about what the standard is. I'm comfortable with specifying different limits for each AEAD in specifications. In practice, however, I expect that a far lower tolerance for forgery attempts. Assuming that these numbers work out, a review of the pull request would be greatly appreciated. If there are other relevant papers, I'm always happy to pull those in as well.
I realize that I didn't respond to NAME That advice applies to the limits that TLS specifies already; this issue is primarily about responding to forgeries. That said, 1G is pretty good advice. However what we've seen from this analysis that 1G results in a lower safety margin than TLS aims for. But it's close enough that if the AEAD is as good as the set we have here, you are probably OK. However, this does depend a lot on the specific AEAD. I'd be uncomfortable using so simple a guide in the general case.
NAME points out an error in my calculation. I had based my calculations on direct mapping of in the CCM analysis to in our calculations. That is, was the number of blocks in the message. But the analysis by Jonsson defines this as: ! The definition of Beta is the CCM function, so this function really reduces to 2 times the length of the message (in blocks), plus 1 (to account for the additional encryption). We can ignore the extra 1 as that is absorbed by the tag length. I'm updating the numbers in the PR. The result is another halving of the number of packets. NAME NAME it's pretty clear that I'm out of my depth here, so your input would be highly valued.


Question: The alert level of all TLS alerts is "fatal"; a TLS stack MUST NOT generate alerts at the "warning" level. <ins> QUIC permits the use of a generic code in place of a specific error code; see Section 11 of QUIC-TRANSPORT.  For TLS alerts, this includes replacing any alert with a generic alert, such as handshake_failure (0x128 in QUIC).  Endpoints MAY use a generic error code to avoid possibly exposing confidential information. </ins> 4.11. After QUIC moves to a new encryption level, packet protection keys

Good catch, yes, the double passing over the message requires a factor 2 here. (The AD a may also be up to 3 blocks if I understand the header format correctly, but I guess that's negligible compared to the conservative 2^10 message size.)
Good point about the AD. The AD - at least for QUIC - is always sent, so that fits in the same space. We don't necessarily need to double count the tiny number of blocks, but as you say, counting that only once yields a negligible difference. If we had a large AD that wasn't also transmitted, that would be different.
Agreed. To be precise: if I'm not mistaken the AD isn't counted at all right now ( accounts for the max. payload blocks), but of course the difference is still negligible as long as the AD is small.
Thanks for the edits!


Question: Decompose group operations into Proposals and Commits (*) <ins> Enable Add and Remove proposals from outside the group (*) </ins> draft-07 Initial version of the Tree based Application Key Schedule (*)

Depends on
Here's the Weekly Digest for : - - Last week 9 issues were created. Of these, 6 issues have been closed and 3 issues are still open. :greenheart: , by :greenheart: , by :greenheart: , by :heart: , by :heart: , by :heart: , by :heart: , by :heart: , by :heart: , by :speaker: , by It received 2 comments. - - Last week, 13 pull requests were created, updated or merged. Last week, 3 pull requests were updated. :yellowheart: , by :yellowheart: , by :yellowheart: , by Last week, 10 pull requests were merged. :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by - - Last week there were 38 commits.


Question: Decompose group operations into Proposals and Commits (*) <ins> Enable Add and Remove proposals from outside the group (*) </ins> draft-07 Initial version of the Tree based Application Key Schedule (*)

:hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by - - Last week there were 2 contributors. :bustinsilhouette: :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 .*
Long-term inactive users undermine the FS and PCS properties of the protocol. Obviously, users can remove each other if they notice that a participant is inactive. We should consider whether we want to allow the server to do such a removal.
Discussion at interim 2019-01: Could do this as "server-instructed" vs. "server done" i.e., server instructs a client to do a remove But this causes some ambiguity w.r.t.


Question: Decompose group operations into Proposals and Commits (*) <ins> Enable Add and Remove proposals from outside the group (*) </ins> draft-07 Initial version of the Tree based Application Key Schedule (*)

the rest of the group The only difference between Remove and a server-initiated variant would be signature Other use cases: User deletes account User is no longer authorized to be in group Application would need to set policy about whether / when server-initiated actions would be allowed
I'm assigning this to draft-04 under the theory that the signature changes that will come about as a result of will make it straightforward to have an additional key for the server that can be used to sign Adds / Removes. If that doesn't turn out to be the case, this might get deferred.
After discussion with NAME and NAME There will be a need to signal that a non-member key is being used, e.g., with some reserved values Do the participants in the group need to agree the set of allowed non-member signers? If some members accept a signer, others don't, then you can get partition -04 will focus on Remove, not Add, and punt on the agreement question; we assume the application maintains consistency of the view of authorized signers.
We should push some of this to the application layer in order to not introduce a new handshake message with problematic authenticity (agreement on the list of non-members who can sign handshake messages). The server could publish an "intent to remove" that will be honored by the first client to come online. The actual Remove HS message will be issued by a member of the group. It can additionally be attached to the server intent to remove, so that clients can convey more contextual information to users. Example: Server issues the intent to remove Alice from the group. Bob comes online first after that and send a regular Remove HS message to remove Alice and links it to the sever intent. Other members of the group can now display "Alice was removed" instead of "Bob removed Alice" to the user. In this example Bob is the first member to come online, but it could really be any other member. This has the advantage that the protocol remains unaffected as such, while the desired behavior is still achieved.
Currently, in order for a new member to join a group, an existing member needs to add them to the group. Certain use cases work more naturally if a new joiner can initiate the add process. I think that broadly speaking we want a process here where someone outside the group can (1) request to be added and (2) send to the group, but cannot receive from the group until added.


Question: Decompose group operations into Proposals and Commits (*) <ins> Enable Add and Remove proposals from outside the group (*) </ins> draft-07 Initial version of the Tree based Application Key Schedule (*)

Some things to consider here: Anything that is revealed to a joiner that joins this way is effectively public. Should they be able to see, e.g., the roster? How should these interactions relate to the key schedule? Assuming there's some message, should it be included into the transcript at Add time? What happens if there are multiple parallel requests?
At the 2019-01 interim, we discussed a "reversed Add" flow, where: Group publishes an InitKey The new joiner sends a UIK to the group and establishes a shared secret with the group This initiates a period where the new joiner can send, but nobody in the group can Before anyone in the group can send, they have to send a Welcome for the new joiner ... which initiates an epoch where they are fully joined
In certain use cases, such as enterprise messaging there may/could/might be a problem if "Any member of the group can download an ClientInitKey for a new client and broadcast an Add message". An enterprise may wish to enforce access restrictions for certain information such as ClientInitKey. Just thinking about security related issues that may be most easily noticed by corp IT types. On the other hand this may be best dealt with outside the protocol scope.
NAME I think this is fixed by correct? A user can propose to Add herself.
Partly addressed by . To complete the story, we need a "send-to-group-from-outside" mechanism. Leaving this open until we have that.
I don't think a "send-to-group-from-outside" mechanism will be possible, given that we try quite hard to prevent any key material from inside the group from ever being published.
The signing key of external actors will be contained in the leaf in the case it is a CIK.


Question: The First-Come-First-Remembered policy is added as an example and a potential default behavior. <ins> RD discovery: Drop the previously stated assumption that RDAO and any DHCP options would only be used together with SLAAC and DHCP for address configuration, respectivly. </ins> changes from -24 to -25 Large rework of section 7 (Security policies)

See-Also: URL This is quite literally from my notes on URL A bit of uncertainty remains whether this change should be two-sided. Should the line above say "When SLAAC is in use," (or "When ND is in use,"?) as well? Can RA options be used in presence of DHCP or static address configuration?
Updated to a more plain and not SLAAC related statement about the RDAO as per last interim. Thank you for the work put into this document. As you can noticed, I have cleared my 2 DISCUSS points (kept below for archive) thank you also for replying to my comments over email. BTW, I appreciated the use of ASCII art to represent an entity-relationship diagram ! I hope that this helps to improve the document, -- Section 4.1 -- It will be trivial to fix, in IPv6 address configuration (SLAAC vs. DHCP) is orthogonal to DHCP 'other-information'. E.g., even if address is configured via SLAAC, DHCPv6 other-information can be used to configure the Recursive DNS Server (or possibly the RD). -- Section 4.1.1 -- Another trivial DISCUSS to fix: in which message is this RDAO sent ? I guess unicast Router Advertisement but this MUST be specified. In general, I wonder how much interactions and exchanges of ideas have happened in the long history of this document with the DNSSD (DNS Service Discovery) Working Group that has very similar constraints (sleeping nodes) and same objectives. -- Section 2 -- To be honest: I am not too much an APP person; therefore, I was surprised to see "source address (URI)" used to identify the "anchor="... I do not mind too much the use of "destination address (URI)" as it is really a destination but the anchor does not appear to me as a "source address". Is it common terminology ? If so, then ignore my COMMENT, else I suggest to change to "destination URI" and simply "anchor" ? -- Section 3.3 -- Should the lifetime be specified in seconds at first use in the text? -- Section 3.6 -- Is the use of "M2M" still current? I would suggest to use the word "IoT" esp when 6LBR (assuming it is 6LO Border Router) is cited later.


Question: The First-Come-First-Remembered policy is added as an example and a potential default behavior. <ins> RD discovery: Drop the previously stated assumption that RDAO and any DHCP options would only be used together with SLAAC and DHCP for address configuration, respectivly. </ins> changes from -24 to -25 Large rework of section 7 (Security policies)

Please expand and add reference for 6LBR. Using 'modern' technologies (cfr LP-WAN WG) could also add justification to section 3.5. -- Section 4.1 -- About "coap://[MCD1]/.well-known/core?rt=core.rd*", what is the value of MCD1 ? The IANA section discuss about it but it may help the reader to give a hint before (or simply use TBDx that is common in I-D). Any reason to use "address" rather than "group" in "When answering a multicast request directed at a link-local address" ? Later "to use one of their own routable addresses for registration." but there can be multiple configured prefixes... Which one should the RD select ? Should this be specified ? As a co-author of RFC 8801, I would have appreciated to read PvD option mentionned to discover the RD. Any reason why PvD Option cannot be used ? -- Section 4.1.1 -- I suggest to swap the reserved and lifetime fields in order to be able to use a lifetime in units of seconds (to be consistent with other NDP options). -- Section 5 -- May be I missed it, but, can an end-point register multiple base URI ? E.g., multiple IPv6 addresses. -- Section 9.2 -- For information, value 38 is already assigned to RFC 8781. -- Section 2 -- The extra new lines when defining "Sector" are slighly confusing. Same applies to "Target" and "Context". This is cosmetic only.


Question: process, by performing normal ACME transactions and providing a validation response for his own account key.  The risks due to hosting providers noted above are a particular case.  For identifiers <del> where the server already has some credential associated with the domain this attack can be prevented by requiring the client to complete a proof-of-possession challenge. </del> <ins> where the server already has some public key associated with the domain this attack can be prevented by requiring the client to prove control of the corresponding private key. </ins> 10.3.

There has been no implementer interest in the proof-of-possession challenge, and it makes the document more complex by having a completely different structure than the other challenges. If it is decided later that such a challenge is necessary, it can be added in a follow-on extension specificiation.
Generally this seems fine, and I wholeheartedly agree with the purpose of the removal (for now). One problem I can't open a comment for: Line 2099, the last paragraph before "Preventing Authorization Hijacking", still refers to the PoP Challenge. Without the PoP Challenge wording, a new reader may take that this to be referring to the implicit Proof of Possession of the ACME Account Key and thus be confused. Since it's non-normative, perhaps you could simply modify that paragraph into something more like:


Question: 2.2.1. This YANG module imports modules from RFC6991, RFC8348, I-D.ietf- <del> netconf-crypto-types, ietf-asymmetric-algs.yang. </del> <ins> netconf-keystore, ietf-tcg-algs.yang. </ins> <del> 2.3. </del> <ins> 2.2.1.1. This module supports the following types of attestation event logs: <ima>, <bios>, and <netequip_boot>. 2.2.1.2. <tpm12-challenge-response-attestation> - Allows a Verifier to request a quote of PCRs from a TPM1.2 compliant cryptoprocessor.  When one or more <certificate-name> is not provided, all TPM1.2 compliant cryptoprocessors will respond. <tpm20-challenge-response-attestation> - Allows a Verifier to request a quote of PCRs from a TPM2.0 compliant cryptoprocessor.  When one or more <certificate-name> is not provided, all TPM2.0 compliant cryptoprocessors will respond. <log-retrieval> - Allows a Verifier to acquire the evidence which was extended into specific PCRs. 2.2.1.3. container <rats-support-structures> - This exists when there are more than one TPM for a particular Attester.  This allows each specific TPM to identify on which <compute-node> it belongs. container <tpms> - Provides configuration and operational details for each supported TPM, including the tpm-firmware-version, PCRs which may be quoted, certificates which are associated with that TPM, and the current operational status.  Of note is the certificates which are associated with that TPM.  As a certificate is associated with a single Attestation key, knowledge of the certificate allows a specific TPM to be identified. container <attester-supported-algos> - Identifies which TCG algorithms are available for use the Attesting platform.  This allows an operator to limit algorithms available for use by RPCs to just a desired set from the universe of all allowed by TCG. 2.2.1.4. 2.2.2. </ins> Cryptographic algorithm types were initially included within -v14 NETCONF's iana-crypto-types.yang.  Unfortunately all this content including the algorithms needed here failed to make the -v15 used <del> WGLC.  Therefore a modified version of this draft is included here. Perhaps someone will steward this list as a separate draft. </del> <ins> WGLC.  As a result this document has encoded the TCG Algorithm definitions of TCG-Algos, revision 1.32.  By including this full table as a separate YANG file within this document, it is possible for other YANG models to leverage the contents of this model. 2.2.2.1. There are two types of features supported <TPM12> and <TPM20>. Support for either of these features indicates that a cryptoprocessor supporting the corresponding type of TCG API is present on an Attester.  Most commonly, only one type of cryptoprocessor will be available on an Attester. 2.2.2.2. There are three types of identities in this model. The first are the cryptographic functions supportable by a TPM algorithm, these include: <asymmetric>, <symmetric>, <hash>, <signing>, <anonymous_signing>, <encryption_mode>, <method>, and <object_type>.  The definitions of each of these are in Table 2 of TCG-Algos. The second are API specifications for tpms: <tpm12> and <tpm2>. The third are specific algorithm types.  Each algorithm type defines what cryptographic functions may be supported, and on which type of API specification.  It is not required that an implementation of a specific TPM will support all algorithm types.  The contents of each specific algorithm mirrors what is in Table 3 of TCG-Algos. 2.2.2.3. Note that not all cryptographic functions are required for use by ietf-tpm-remote-attestation.yang.  However the full definition of Table 3 of TCG-Algos will allow use by additional YANG specifications. </ins> 3. This document will include requests to IANA: <del> To be defined yet. </del> <ins> To be defined yet.  But keeping up with changes to ietf-tcg-algs.yang will be necessary. </ins> 4. <del> There are always some. </del> <ins> The YANG module specified in this document defines a schema for data that is designed to be accessed via network management protocols such as NETCONF RFC6241 or RESTCONF RFC8040.  The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) RFC6242.  The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS RFC5246. There are a number of data nodes defined in this YANG module that are writable/creatable/deletable (i.e., config true, which is the default).  These data nodes may be considered sensitive or vulnerable in some network environments.  Write operations (e.g., edit-config) to these data nodes without proper protection can have a negative effect on network operations.  These are the subtrees and data nodes and their sensitivity/vulnerability: Container: </rats-support-structures/attester-supported-algos> <tpm12-asymmetric-signing>, <tpm12-hash>, <tpm20-asymmetric- signing>, and <tpm20-hash> all could be populated with algorithms which are not supported by the underlying physical TPM installed by the equipment vendor. Container: </rats-support-structures/tpms> <tpm-name> - Although shown as 'rw', it is system generated <tpm20-pcr-bank> - It is possible to configure PCRs for extraction which are not being extended by system software.  This could unnecessarily use TPM resources. <certificates> - It is possible to provision a certificate which does not correspond to a Attestation Identity Key (AIK) within the TPM. RPC: <tpm12-challenge-response-attestation> - Need to verify that the certificate is for an active AIK. RPC: <tpm20-challenge-response-attestation> - Need to verify that the certificate is for an active AIK. RPC: <log-retrieval> - Pulling lots of logs can chew up system resources. </ins> 5. <ins> Changes from version 02 to version 03: moved to tcg-algs cleaned up model to eliminate sources of errors removed key establishment RPC added lots of XPATH which must all be scrubbed still Descriptive text added on model contents. </ins> Changes from version 01 to version 02: Extracted Crypto-types into a separate YANG file

Provides more context around the various elements of the model
Thanks a lot for your stab at Security Considerations! Also the I-D was in dire need for some expositional english text. Reads straight forward and comprehensive.


Question: (2001:db8::3456), scoped to SCTP.  The client can send and recieve SCTP IP packets to the remote host. <del> 6.3. </del> <ins> 7.3. </ins> The following example shows a setup where a client is proxying UDP packets through a CONNECT-IP proxy in order to control connection

Aligning CONNECT-IP with the changes in HTTP datagrams and CONNECT-UDP.
NAME when do you plan to merge the other PRs?
NAME I plan on merging the other PRs as soon as we have WG consensus, which (assuming no objections) should happen at the end of the month (see ) Hi folks, During today's interim call, there was strong support to proceed with the output of the Design Team. This email begins a call to confirm that consensus. As a reminder, this consists of the following changes to draft-ietf-masque-h3-datagram and draft-ietf-masque-connect-udp: URL URL Please review these changes and send your comments to the list. This consensus call will conclude on February 28. Thanks, Chris and Eric


Question: The messageData object provides access to the bytes that were received for this Message, along with the length of the byte array. The messageContext is provided to enable retrieving metadata about <del> the message and referring to the message, e.g., to send replies and map responses to their requests.  See msg-ctx for details. </del> <ins> the message and referring to the message.  The messageContext object ist described in msg-ctx. </ins> See framing for handling Message framing in situations where the Protocol Stack only provides a byte-stream transport.

The text below is a bit confusing as there are no details about how to to send replies and map responses to their requests in Section 7.1.1. This can be easily fixed by clarifying what Section 7.1.1 provides details on. But I was also wondering if there should be some more details on how to send replies and map responses to their requests somewhere?
Note: this will be in §9.3.2.1. after merge.
Is seems the concept of mapping requests/replies has been fully eliminated. So just removing this part of the example.
Thanks Philipp, LGTM.


Question: 6. When bundling, associating incoming RTP/RTCP with the proper "m=" <del> section is defined in RFC8843.  When not bundling, the proper "m=" section is clear from the ICE component over which the RTP/RTCP is received. </del> <ins> section is defined in I-D.ietf-mmusic-rfc8843-bis.  When not bundling, the proper "m=" section is clear from the ICE component over which the RTP/RTCP is received. </ins> Once the proper "m=" section or sections are known, RTP/RTCP is delivered to the RtpTransceiver(s) associated with the "m="

and
To resolve WGLC comments: URL it was agreed to incorporate a reference to this text in 8843bis: URL That text ended up in s7.6.
When draft-8843bis is given an RFC number, this draft should reference the new RFC. Hi, Eventhough I would not like to make more changes than necessary, I am fine with "3PCC Considerations". However, your suggested text is very difficult to understand in some places, so let me give it a try. (The first paragraph is generic, the second SIP specific, and the third BUNDLE specific.) 3PCC Considerations In some 3PCC scenarios a new session will be established between an endpoint that is currently part of an ongoing session and an endpoint that is currently not part of an ongoing session. The endpoint that is part of a session will generate a subsequent offer that will be forwarded to the other endpoint by a 3PCC controller. The endpoint that is not part of a session will process the offer as an initial offer. The Session Initiation Protocol (SIP) [RFC3261] allows a User Agent Client (UAC) to send a re-INVITE request without an SDP body (sometimes referred to as an empty re-INVITE). In such cases, the User Agent Server (UAS) will include an SDP offer in the associated 200 OK response. If the UAS is a part of an ongoing session, it will include a subsequent offer in the 200 OK response. The offer will be received by a 3PCC controller (UAC) and then forwarded to another User Agent (UA). If the UA is not part of an ongoing session, it will process the offer as an initial offer. When the BUNDLE mechanism is used, an initial BUNDLE offer is constructed using different rules than subsequent BUNDLE offers, and it cannot be assumed that a UA is able to correctly process a subsequent offer as an initial offer. Therefore, the 3PCC controller SHOULD rewrite the subsequent offer into a valid initial offer, following the procedures in (Section 7.2), before it forwards the offer to a UA.