This was prompted by .
LGTM. Nice and tight. URL Erik Kline has entered the following ballot position for draft-ietf-masque-connect-udp-14: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to URL for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: URL COMMENT: CC NAME Should the 2xx discussion here include additional reference to the extended commentary in masque-h3-datagram#section-3.2? I really wish there could be more said about tunnel security. I was tempted to try to formulate some DISCUSS on the matter, but I cannot seem to see where any more extensive text was ever written for the CONNECT method. Nevertheless, there are plenty of concerns that could be mentioned, like what should a proxy do if the target_host is one if its own IP addresses, or a link-local address, and so on. I'm not entirely convinced that it suffices to claim that because the tunnel is not an IP-in-IP tunnel certain considerations don't apply. Anything and everything can be tunneled over UDP, especially if RFC 8086 GRE-in-UDP is what the payloads carry (or ESP, of course). It seems like most of the points raised in RFC 6169 apply; perhaps worth a mention. But as I said, I think all these concerns apply equally to CONNECT (in principle, anyway), and the text here is commensurate with the text for its TCP cousin (that I could find, anyway).


We incorrectly put a normative reference on the RRC draft in the DTLS 1.2 CID draft.
I lost somehow the track on that RRC and the discussion around it. The referred document mentions: and I would assume, that a on-path adversary could black hole traffic in both directions, even without CID. Not only message sent to a peer could be dropped, it would also be easy to drop a message sent back from that peer (at least, if the route back is on the same path). I would also assume, that a on-path adversary, which is able to change the source address, would also be able to change the destination address. So a simple traffic redirect will also be possible even without CID. In my opinion, the only threat left, which is caused by the usage of a CID, would be a DDoS attack using amplified traffic towards third party. For that it seems to be most important to throttle the traffic by limiting the number and size of messages until the address is verified. Though such a DDoS will be naturally less efficient, because the adversary has to wait for messages to change the sources-address, throttling would make it even more unattractive.


This text in is incorrect. An endpoint can abruptly close (reset) egress data, but it can only request that its peer abruptly close ingress (using STOP_SENDING).
is there a missing "not"? Do you mean: s/An endpoint can abruptly close (reset) egress data/An endpoint cannot abruptly close (reset) egress data/ ? Anyway, yes, we need to fix that!


4492bis includes some values we were marking as reserved and that's wrong. We also have 224-255 that we might also mark as reserved. Effectively, this closes these two registries.
NAME PTAL
NAME -- This looks good. I have a quick comment on: I presume this will or won't happen as the result of conversations in the WG? Also, I'll note -- for the (only) -- that only 224-253 are necessary to mark as reserved (or, really, since they were previously okay for private use, I think the term to use is "deprecated"), since 254 and 255 are in the TLS 1.3 "reserved for private use" range of 0xfe00-0xffff
I'm planning to forward the PR to the WG after I heard from you. I'll add in "deprecated" for those other values before sending it along.


This decides the open question of how to match the in a query in favor of client simplicity. Closes: URL NAME NAME would that change be OK with you and solve the issue?
I know what an absolute form is, where do I find out what a path absolute form is
path-absolute is an ABNF in RFC3986, described as "begins with a '/' but not '//'".
I agree with the addition. This means that one can match against an absolute registration target as well.
Jim in :
It's a trade-off between not being a surprise to the RD implementation (with b, it needs to compare values that it has not seen in that form) versus not being a surprise to the lookup client (with a, it queries for something it does not see in that form in the query result). I think that the latter is preferable. Here are some more questions on the document. The registration text in section 5.3 says that the interface is idempotent, however it is not clear to me just how idempotent this is supposed to be. It is obvious that the goal is to make sure that a different resource is not created, however I am not clear what is supposed to happen with some of the parameters such as the 'lt' parameter. One way to implement this is to just make it a POST to the previously existing resource which would inherit old attributes on the endpoint. The other way is to say we are going to create a new resource, it just has the same address. It is not clear which, if any, of these two methods is to be used. Never mind I found the answer to this one. Need to think if I want clearer language. When doing an endpoint lookup, I assume that the 'lt' parameter would be the same as the one registered at creation. Is there/should there be a parameter which is a TTL value? How are href comparisons done. a) compare against what was registered b) Resolve what was registered and the href in the current context and compare c) something I did not think of compare on group for remote endpoint. Should this do the remote lookup or can it just be ignored for attribute comparison Value of lt = should it be the set parameter or the time left - how would time left be represented outherwise - should it be represented. Inferred context based on source IP when an update is done.


If no con is provided, is that supposed to be checked again to see if it is "right"? Only if we did the infer to begin with? I don't understand the presence of the content-format for the empty message posted for simple registration. This seems to be odd if the content is empty. 8 Is there supposed to be a way for simple registration to return an error message? As written this is not necessarily done. Specifically, the response to the post can be executed before the query to /.well-known/core is done and the registration is attempted.


Previously there was some notion of being able to hint to the server whether you wanted to reuse authorizations. This was removed from the spec but the pre-authorization flow still made a reference to it. This commit removes that obsolete reference. Thanks to NAME for pointing out the error. Resolves URL
Hi in the section on pre-authz there is this sentence: To request authorization for an identifier, the client sends a POST request to the new-authorization resource specifying the identifier for which authorization is being requested and how the server should behave with respect to existing authorizations for this identifier. the part "and how the server should behave with respect to existing authorizations for this identifier" probably is obsoleted
Hi NAME I submitted URL to fix this. Thanks for spotting & reporting :-)


The draft currently states: However in PR , NAME points out that this "state" is not well defined. I agree, we should fix it. Thinking about this more, I don't think we need the concept of related state. We can instead just say that received datagrams MUST be silently dropped if the stream receive side is closed.
I agree with removing the concept of state is better. I don't want to be overly nitty and the proposed sentence is better but there also nothing like "the stream receive side", as there can be multiple streams (open and closed), that's why I proposed Or if we don't want state, then it would be:
That's not quite right: there cannot be multiple streams, as datagrams are strongly associated with a client-initiated bidirectional stream. I'd phrase the paragraph as: open. If a datagram is received after the receive side of the corresponding stream is closed, the received datagrams MUST be silently dropped.
That works. Thanks!
This answer is necessary because QUIC doesn't guarantee ordering, but is this necessarily true indefinitely? But can I regard a datagram that arrives an hour after the stream closes as an error?
If you keep track of QUIC packet numbers, you can see that the peer closed the stream before it sent the datagram which means they violated a MUST. You're welcome to error if you detect that, but I don't think we should mandate this level of tracking.
I'm not sure that that is a good strategy given how some deployments manage their packet numbers. I'm talking about maybe running a really long timer.
That introduces a way for an attacker to cause connection closure by delaying a specific packet. What problem are you trying to solve?
Good point. I thought that we did similar in a few places in QUIC. As you say, it's possible to enforce, but tricky. The concern I'd have is that this effectively forbids enforcement, but maybe that's OK.


Fixed
also tagging NAME (who might be unhappy with 'default' which matches Chrome behaviour but not Firefox behaviour (it generates a uuid)
ping NAME NAME
NAME NAME PTAL - Barring any objections this one ought to get merged.
Folks, I think this one is pretty uncontroversial - planning to land this next week if there are no objections.
Take this simplified SDP offer from a remote endpoint (in parts taken from : A single audio and video stream. No a=mid (there is quite some text taking care of that) but no a=msid line either. URL shows a live example. Both Chrome (without unified-plan) and Firefox will fire the ontrack event (or legacy onaddstream) with a single mediastream containing an audio and video track. This has been like that since... 2012-ish? Unified plan support in Chrome changes this behaviour: URL ontrack is fired with an empty set of media streams. onaddstream is not fired. This is quite a change in behaviour. And unexpected, I didn't expect any issues for this trivial case of a single audio/video track. As NAME webrtc-pc assumes/requires a=msid to be present and . In particular this says which means firing with no streams is technically correct. JSEP seems to assume it is present as well, but has this text about a=msid in Note the "If present". What if it is not present? The closest I could find in terms of guidance was this from the and its section about handling a=msid is supposed to be present in initial offer so we are talking about dealing with non-webrtc entities send an offer. Given that there is plenty of support for entities that do not support a=mid (an RFC published in 2010) in JSEP do we need backward compability for the case of a single audio/video track each but no msid? Interop between browsers is probably not affected, due to Chrome still interpreting and sending a=ssrc:123 msid:...
note that a proper webrtc client will include "no streams" as (maybe with a track) which allows differentiating between "no streams because I do not use any" and "msid???"


Thanks NAME for another
aside: the interesting case you have trouble distinguishing between is "no msid because I haven't started sending a track yet" and "no msid because I don't support msid". It's one case where we still have trouble if RTP packets arrive ahead of signalling. But - yes, I think we are better off sticking with the 2012 behavior, default stream and all. We can handle the case above by changing the stream associations of the receiver if a new SDP (with msid) arrives after the RTP packets.
there used to be a a=msid-semantic line that would allow determining whether a party wants its offer to be treated assuming msid support. Browsers still send it :-)
How are non-signaled tracks supposed to be handled anyway? There's JSEP language about creating a track for it, but what about webrtc-pc? (If a track exists in the forest, and nobody is around to surface it to JavaScript, does it still exist?) "Run the following steps for each media description in description" means no ontrack will fire until we do have something signaled. If the track (and/or stream) only exists in some inaccessible way they're almost conceptual until the signaling does arrive. And when it does arrive, we know whether or not MediaStreams were signaled. So we should know what to do, same things as if we didn't receive early RTP packets? Does the distinction matter? I love that we can tell the difference between "no streams because I do not use any" and "no msid signaled" whether or not "a=msid:-" was present. I had not thought about that! Unless I'm confused about something, I suggest: If is present, do what Chrome does: don't create any stream. If the line is completely missing, do what Firefox (or Chrome Plan B) does: create a MediaStream with a random id. Does that work for people?
By the way I thought this was a webrtc-pc issue when I replied above, so I was thinking about what to do in JavaScript rather than talking about any JSEP change.
I suppose we need some JSEP language to handle the lack of any a=msid but i agree with what you propose above. We do have have a=msid:- and we need to handle that in webrtc-pc too.


Will file an issue there.
All webrtc-pc says is "let msids be a list of the MSIDs that the media description indicates transceiver.[[Receiver]].[[ReceiverTrack]] is to be associated with. Otherwise, let msids be an empty list" And says "The special value "-" indicates "no MediaStream"." So that already takes care of the case correctly, I claim. I agree. We need to solve what the media description (JSEP) says about this. Right now : "If present, "a=msid" attributes MUST be parsed as specified in [I-D.ietf-mmusic-msid], Section 3.2, and their values stored." I think it needs to say what happens when it is not present. Something like: "If no a=msid is present, then in place of "msid-id", create a single "id" unique to this end-point, if one hasn't already been created for this connection."
"if one hasn't already been created for this connection"; so future tracks will share the same stream? There is always at most a single "default stream"?
NAME says he observed this is how Firefox and Chrome work. URL
See URL
LGTMreason I asked is that chrome generates a MediaStream with id "default" -- see URL while Firefox does not. (I do not see any reason to change the legacy behaviour of chrome even though it seems a bit odd that the RNG always emits the right bytes for "default")


Just realized that, this section may also apply to the case of initial provisioning of Portal URI if multiple ways are used, such as: DHCPv4/DHCPv6/RA could be used at the same time, and they return different values; to quote 7710bis: However, if the URIs learned are not in fact all identical the captive device MUST prioritize URIs learned from network provisioning or configuration mechanisms before all other URIs. Specifically, URIs learned via any of the options in Section 2 should take precedence over any URI learned via some other mechanism, such as a redirect. Shall we mention anything on the initial provisioning case too here? or that will only in 7710bis?
Probably not a lot, except that future requests might go there. Because we don't hold any state for these resources, that's probably OK.
NAME do you think that you could take a swing at this?
By portal URI, you meant the URL to the json file? If so, it seems the ways how it could be changed are: In the case of DHCPv4/v6,in a renewal/rebind of DHCPv4/v6 lease, the end user equipment could receive a new portal URI in the DHCP renew/rebind response. In the case of RA, the end user device may receive a new portal URI in a new RA message. (In RA case, is it possible that there are multiple RA servers sending out different portal URI?) Is there any other possibilities? Do I understand correctly that you are suggesting add something like the following? If a new Portal URI is provided via DHCPv4/v6 renew/rebind or RA, use the new one. Where shall we add this section please? a new paragraph under 2.2.1. DHCP or Router Advertisements? or a new sub section 4.3 under 4 Solution Workflow?
Right. I forget whether this was about the API URL (the JSON) or the user portal URL. In either case, they can change and I think that's OK. The RA case is interesting in the sense that it might imply a different router advertising different coordinates, as you say, but if it is the same router, then that should be regarded as a change. This came up in discussion and some people felt that it needed to be acknowledged.


Your suggested outcome is probably the only sensible one: if you need to contact the API, use the most recent value you have. As for location in the document, a new Section 4.x describing how updated details can be acquired seems right.
Fixed in
Thanks for doing this. I have a few small suggestions.Looks good. Thanks!


NAME -- you mentioned wanting to have a more balanced view of zero RTT in the applicability draft: is this something like what you had in mind?
I'll go ahead and merge this to have one less editor's note in the ietf-00 submission; file an issue if this doesn't address the "thinking in 0rtt" point adequately.
Jana noted at the interim in Paris that we should point out that applications need to be re-thought slightly to get the benefits of zero RTT. Add a little text to discuss this and why it's worth the effort, before we go straight into the dragons.


We weren't very concrete in saying how endpoints generate packets with CONNECTIONCLOSE, particularly those that throw away keys. We have a rather vague requirement. In short, follow the same rules we established for the handshake. Wording this as an aggregate number allows for stochastic reactions and larger CONNECTIONCLOSE frames. This way, if you get a 25-byte packet and respond with a 200-byte packet, you can do that, but you have to respond to 3 in 8 or fewer in that way. Note that this limit only applies if the endpoint throws away decryption keys. Endpoints with keys aren't blind amplifiers.
closing period ({{draining}}) and send a packet containing a CONNECTIONCLOSE in response to any UDP datagram that is received. However, an endpoint without the packet protection keys cannot identify and discard invalid packets. To avoid creating an unwitting amplification attack, such endpoints MUST reduce the frequency with which it sends packets containing a CONNECTIONCLOSE frame. To This seems like a pretty vague requirement for a 2119 MUST. Like, I could only send it 9999/10000 packets and that would be compliant.
I think that it would be good to follow the 3x rule here also, but that's a non-editorial change.
Do folks agree the PR resolves this?
I think the PR resolves this and is a sensible choice.
Yup, the PR resolves this.
OK, labelling as such.


closenotify has always used a warning alert level, but this is not actually written down anywhere. It seems to have gotten lost as early as RFC 4346 (TLS 1.1!). In RFC 2246, there is some text that mentions the correct level is warning as an aside in describing something else. I wasn't able to find any other text that discussed this. Then, RFC 4346 dropped the session termination behavior: But in doing so, it dropped any mention of which alert level to use. That text has carried over to RFC 8446 as: In RFC 8446, we said alert levels no longer matter and can be "safely ignored", but this still leaves unspecified what the sender should do. Skimming implementations, both BoringSSL and NSS will treat "fatal" closenotify as an error, so using "warning" is also necessary for interop.


URL Assuming there would be more protocols in the future and the minset functionalities will expand via extension or amendments. It would important to indicate if this architecture should is also extensible or it only supports on the minimum set referred. Definitely we haven't seen the future yet, but it would be important to express if we have considered such expansion of minimum functionalities.
To me, the current spec is based on minset that describes the common functions. So, the addition I would expect here is to say that there can be extensions and protocol-specific features.
I expect that if a common feature is added to the minset, then the architecture and API surface would also be extended to match.
LGTM modulo a nit


"Here we assume a bidirectional observer", let's also state that there is no section about unidirectional observer ?
Not sure if we add something because I think it okay to state assumptions...
"unless noted" states that we'll note when something is unidirectionally observable, I'm reviewing the language now to see if we missed any...


As per Adam's comment, clarify that only the element() scheme of the XPointer Framework is supported (as that is the one that is required by RFC 7303).
LGTM


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


This should resolve some parts of .
NAME If you wish, I will split this PR into small ones.
I have dropped the commit of "in flight".
I also changed into .
NAME The commit for "towards" has been dropped.
Thanks. BTW, that thing is an another odd English quirk.
Unfortunately, this PR bundles a bunch of unrelated changes. Some of them I like, some of them I don't.Thanks for the PR, NAME !


Feel free to approve or propose changes to improve this sentence in Arch.
BT: "I’m not convinced of the value of the glossary of terms, as it forwardrefs basically the entire document, and some of the definitions are so generic as to be potentially confusing (e.g. Event), so I think putting these up front reduces the document’s approachability and readability. I understand that some people like these (and other standards orgs make them mandatory, hi ETSI), so I won’t fight it." "Adding a sentence making it clear it’s safe to skip the glossary if you’re going to read the rest of the document would address my approachability concern completely. "


This one slipped the net.
Either way is fine by me. Just ship it already :PThanks, Martin!


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


The first strikes "TLS" from encryption level The second removes misleading text about coalescing I'm suggesting that we replace it with explanatory language about encryption levels and packet number spaces. This context is now missing as a result of moving the referenced text to -transport.
Roman Danyliw said:
I'm going to suggest that the text I propose in addresses this first part of this. The higher/lower stuff seems like it could be better, but it's a lot of work to do carefully. I'm going to suggest that we could live with this, but I might leave this issue open and try to find a fix once other more pressing issues are dealt with.
NAME said:
This is really two comments, but I think we can dispense with both at the same time as the first is really trivial: The use of "TLS encryption level" is an unnecessary redundancy and inconsistent with other usage, so we can easily remove "TLS" there. The start of that paragraph is cruft. I'm going to suggest we only keep the last sentence, which was unquoted in this issue. But then I see that we are missing important context, so I'm going to suggest a little bit of text to replace it.
one suggestion, but lgtm


I went with "Default" because that and "Initial Value" now have specific, related (but distinct) usages in the context of pre-SETTINGS settings. Swapping them seems like it would create unnecessary confusion.
Yeah that makes sense on a reread of section 7.2.5.2
Not a new issue but: RFC 7540 has a column for . I think it makes sense that HTTP/3 does similar. Originally posted by NAME in URL


Also add some general advice from URL See also . Ref: URL
Recursion is not really the problem, stack depth is (or any other uncontrolled resource usage triggered by queries into deeply nested structures). Grüße, Carsten
NAME Are you comfortable with this now, or would you perhaps like to suggest some other way to address the concerns of URL
Thank you.Looks good and informative to me.


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


By enabling a PSK derived from a previous epoch during which Alice was part of the group to be injected with the external commit, Alice provides some proof of prior group membership and we avoid the total reset. This is not quite PCS in that the attacker is active following compromise, but it is a linked case. As such it is important that a conscious decision is made regarding this (either as a slight change before the feature-freeze in line with the other changes that the editors have proposed, or as a working group decision to close the issue as out-of-scope).
Just to think this with what has been discussed on the mailing list: will give members a way to do the distinction mentioned above.
NAME - I don't think that's actually the case; it would only allow the members a way to recognize that Alice is replacing herself. I think the right answer here is what Britta suggests, plus a little: We should enumerate a few specific constraints on the proposals that can be carried inline in an external Commit: There MUST be an Add proposal for the signer There MUST be an ExternalInit proposal There MUST NOT be any Update proposals If a Remove proposal is present, then: The identity of the removed node MUST be the same as the identity in the Add KeyPackage There MUST be a PSK proposal of type , referencing an earlier epoch of this group In other words, you can commit things that existing members sent (by reference), but the joiner-initiated proposals must only (a) add the joiner, and (b) optionally remove the old instance of the joiner, with the PSK assurance NAME suggests.
Coming back to this after a few weeks, I'm actually not sure this is a problem worth solving. The attack scenario (2) exists whether or not a member can resync without proving prior membership. As long as (a) the group allows external Commits, and (b) the group does not require a new appearance of an existing identity to present a PSK from an earlier epoch, then the attacker can still do the attack by first joining, and then removing the old Alice. The only difference in the case where the external commit also does the resync is that the two happen together. It also doesn't seem unreasonable to regard the ability to resync from loss of all state except the signature key as a feature, not a bug.


Of course, that position would entail accepting that compromise of signature keys would be sufficient to impersonate the user, but that doesn't seem all that surprising, at least to me. So this seems like a question of group policy to me. Either the group requires ReInit PSKs on resync (and you can't recover from all-but-signature-key state loss), or it doesn't (and signature keys are the last resort). This can be documented in the Security Considerations, in a new PR. As far as , I think it's probably still worth adding the precision, but I would change the PSK part to MAY if not remove it entirely.
There is also a practical issue with using PSKs to prove past membership, in that if there have been joins since Alice lost state, the new joiners won't have the PSK. This is of course a general issue with the proof-of-past-membership PSK, but it is particularly salient here.


This binds the spin-bit state to a network path, which aligns with intent better than the existing language. It's more words, but it is far less ambiguous.
NAME sanity check please? I'll merge this soon either way.
This is likely a case of "we know what we meant," but.... Section 17.3.1 says that the spin bit can be enabled/disabled on a per-connection or per-CID basis, and that: However, a literal reading of this suggests that a client which sets the spin bit on a per-connection basis will revert the spin bit on the main path to zero whenever it uses a new CID to probe on an alternate path. It also has implications for an implementation that uses many active CIDs at once. One resolution is that the current state of the spin bit is maintained on a per-CID basis, and that the CID begins at zero for each CID. However, for the client using many CIDs at once, that then begs the question of which of the peer's CIDs are being reflected back to it. I think that what we actually mean here is two-fold: The current state of the spin bit is maintained on a per-path basis, and is initialized to zero for each path. The current state of the spin bit is reset to zero whenever the CID being used on a path changes, no matter how frequently that is.
I think what you summarize in the bullets is indeed what was intended. NAME


Update the draft to use the same spelling as TLS RFC uses. Relates to issue
While reading draft-ietf-emu-eap-tls13-15 I noticed that section now uses which is the named used in but not in RFC 8446 itself. I first thought this was a typo, before a further look showed that this change was mentioned in IETF 110 . Suggestion: make clear which parts need to be looked up from RFC 8446bis. In addition to exporter terminology, the meeting slides above also discuss about usercancelled behavior on slide 10. For clarity, any updates from RFC 8446bis should be marked clearly.
It would be best not to have normative references that block on RFC 8446bis. Perhaps we can just reference that it is renamed from "exportermastersecret"
Sounds good. That should make clear where it comes from and that there's no need to file errata about unknown term and/or RFC 8446bis dependency. Taking another look at my comment about usercancelled behavior on slide 10; to clarify what I was meaning: The slides hint that clarifications in 8446bis are needed by EAP-TLS too. If so, this looks like a reference to RFC 8446bis too. Finally, one nit: the alert name in RFC 8446 is "usercanceled", not "user_cancelled" as in draft -15.
I made a PR with explaining that the document use the terminology from RFC8446bis. URL Do we need to say anything about usercancelled? RFC8446bis might do several clarifications and corrections. I think we should only mention things that are directly relevant for EAP-TLS 1.3 URL Current plan for RFC8446bis seems to be to ignore closenotify and I assume require close_notify after. This does not seem directly relevant for EAP-TLS 1.3. Or?
close issue?
Yes, please close this. I think it's now clear where exportersecret comes from. Also, thanks for the pointer to TLSv1.3 discussion. I agree usercanceled followed by close_notify discussion is not relevant for EAP-TLS 1.3. It's seems to be TLSv1.3 specification and implementation level detail as opposed to something that EAP-TLS 1.3 needs to directly react on.
This looks good to merge


The text says: "The media codecs used in older protocols do not always match those being used in WebRTC, mandating transcoding on the ingest node," I don't understand this sentence. If I use an "older protocol", e.g, RTMP, why do I need to care about WebRTC codecs?
That refers if you use RTMP for ingest and WebRTC for viewing.
rewriten the editorial in
The text says: "These protocols are much older than webrtc and lack by default some important security and resilience features provided by webrtc with minimal delay." I assume you refer to RTMP, which is mentioned in the previous Section. Doesn't RTMPS solve some of the security issues? But in general, if you want to put up WHIP against RTMP, I think you need a little more text. Also, as WHIP is supposed to be an "easy to implement" protocol, I think it would be fair to also list some of the functions NOT supported compared to e.g., RTMP. As I have mentioned before, there is no command for start the ingestion - it is assumed to have begun when the connection has been established. Also, there is no PAUSE/RESUME.
It is more referring to RTSP which lacks DTLS support. no command for start the ingestion - it is assumed to have begun when the connection has been established. Also, there is no PAUSE/RESUME. RTMP protocol was intended as an RPC mechanism between the flash player and server. It allowed to create custom apps both on client and server side, which supported a wide range of methods using AMF. However, current "RTMP protocol" implemented for ingesting is a reversed engineered version of the implementation done by the FMS and it lacks support for PAUSE/RESUME and the publication is started from the start of the RTMP connection (same as whip).
rewriten the editorial in


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


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


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


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


Not sure if this is enough, but it enacts Brad's suggested fix.
Yup, that's what I had in mind.
Why is this limited to being prior to the push stream being created, given that you specify how the server handles it if it has created the stream.
I don't read this as saying that you have to avoid it. The point is that you also have to reset/STOPSENDING on the stream if it exists, so there is no real point to using CANCELPUSH in addition.
Sounds like the intent is that CANCELPUSH should be used between the client receiving a PUSHPROMISE and before receiving the stream (i.e. when it is ambiguous as to whether the stream has been created by the server from the clients perspective). I think replacing "created" with "received" would make this more clear.


In URL, it was suggested that 403 status code should be used when Origin verification fails.
Thank you for suggestions! Applied.
Thank you for reviews! If this looks good can someone merge this?
Looking good, thank you! Added a few suggestions to cause it to generate links to the actual sections referenced, even if it makes it a little more repetitive.Approved modulo one small change


This PR adds a short paragraph referencing the various academic works that has gone into MLS. The references to the various works still need to be cleaned up, which I will do once the list is complete. In particular, each reference needs to be checked for correctness (eprint version vs. publicized version) and then included as informal reference in the yaml header of the document.
Is there another RFC you can point to that links academic papers on the protocol? I'd expect TLS 1.3 to be a good example of this, but I don't see them do this. The references should be cited properly if we do include it (ie, added as citations at the top of the file)
The references are in the appendices. For instance URL The reader should refer to the following references for analysis of the TLS handshake: [DFGS15], [CHSV16], [DFGS16], [KW16], [Kraw16], [FGSW16], [LXZFH16], [FG17], and [BBK17].
TLS 1.3 as cited by NAME was indeed the inspiration for this. The idea was to just have a small paragraph to point the reader in the right direction and then have the full bibliographic entry in the "Informal References" section. As noted above, I intend to properly format all the references once we agree on what references to include, as formatting them into the right yaml is a bit of a pain.
Thanks Konrad!


process assumes that the set of versions that a server supports is fixed. This complicates the process for deploying new QUIC versions or disabling old versions when servers operate in clusters. This functionality was removed from -transport, and appears to refer to text in draft-ietf-quic-version-negotiation, but that draft isn't referenced at all.
I can add a reference to draft-ietf-quic-version-negotiation and make clear that this is an extension and not part of the base spec.


Now I feel like I'm shaving the yak. This is more than what we talked about in the interim, but it felt like the following sentence required additional clarity. Let me know if I misunderstood the intended meaning, in which case I will rephrase.


Fixes URL
Thanks for your comments NAME and NAME I feel I should explain. The current draft defines the orderings and using the same text. For strings, the text talks about "less than" but not "greater than". So the current text implicitly assumes that for strings and , if and only if . Non-mathematicians would tend to say this is patently obvious. But this PR avoids that assumption by only defining using the same text and then defining in terms of . However, I take the point about the standalone definitions and the arbitrariness of defining one in terms of the other. So my question is: is the current draft text sufficiently precise? If not, I'll rework this PR to make it more precise. (When I started out doing that, it began to get quite wordy, so I changed tack.)
Despite the fact, that Glyn's approach is mathematically clean, I would favour the symmetric approach by defining , ,. I am quite sure, that nobody will cry "redundancy" then.
Yes. Is that a problem? comes before ...
Actually, on the symmetry point, we were comfortable defining in terms of and that was asymmetric.
In what system of mathematics are operations ordered? This is completely arbitrary. I'm not convinced this needs to change. I prefer defining both and . And for symmetry, I'd change strings to match.
Applying editorial discretion here. Merging.
The current spec defines string comparison using one of the operators , , , or in terms of when one string is less than another. That's fine for , but: for it effectively assumes is fixed (i.e. that for strings and if or ) for and it leaves quite a lot to the reader's imagination. Once we've settled on , the above should be addressed. ~We should also adopt a similar approach for ordered comparisons () of arrays if is adopted.~ (It wasn't.) (I labelled this issue as because I don't believe it will change the intended semantics in either case.)
I propose to let URL land before addressing this issue.
I personally prefer the previous version, with standalone definitions, but think this is a matter of editorial discretion.I agree with Tim. It's fine and correct to define in terms of other operators, but I feel and should both be equally defined.


Defining one in terms of the other means you have to make an arbitrary choice of which is directly defined and which is indirectly defined.This PR is exactly the right way to do this.


Not sure to understand why the last part of the sentence is an issue. The use of zero-length connection IDs is problematic anyway in setups with NATs, for example.
I agree that in many deployments you want at least one CID from the client to server. Multiple packet numbers as currently defined however requires CIDs in both direction; there is separate issue to discuss that. The next sentence also further explains that there might be other deployments though, e.g. in constraint networks, that might also benefit from saving the bits of the CID. This one sentence is of course only a very brief summary of the pros and cons of the different approach and more discussion is needed in the group. So I don't expect to have this part in the draft like this when we finally publish it as RFC. Is there anything in the issue that we need to address now? Or can we close this issue?
Thanks, Mirja. That's what I expected, but I do still think more elaboration is needed for this text to be useful. I would suggest to make this modification and leave the discussion of pros/cons to be adequately documented in Section 7: OLD: This proposal supports the negotiation of either the use of one packet number space for all paths or the use of separate packet number spaces per path. While separate packet number spaces allow for more efficient ACK encoding, especially when paths have highly different latencies, this approach requires the use of a connection ID. Therefore use of a single number space can be beneficial in highly constrained networks that do not benefit from exposing the connection ID in the header. While both approaches are supported by the specification in this version of the document, the intention for the final publication of a multipath extension for QUIC is to choose one option in order to avoid incompatibility. More evaluation and implementation experience is needed to select one approach before final publication. Some discussion about pros and cons can be found here: URL URL NEW: This proposal supports the negotiation of either the use of one packet number space for all paths or the use of separate packet number spaces per path. While both approaches are supported by the specification in this version of the document, the intention for the final publication of a multipath extension for QUIC is to choose one option in order to avoid incompatibility. More evaluation and implementation experience is needed to select one approach before final publication.


Some discussion about pros and cons can be found here: URL URL
You are suggesting to strike out the sentences that try to summarize the differences, "While separate packet number spaces allow for more efficient ACK encoding, especially when paths have highly different latencies, this approach requires the use of a connectionID. Therefore use of a single number space can be beneficial in highly constrained networks that do not benefit from exposing the connection ID in the header." I think that's a good idea. The sentences are a short summary of the arguments presented in the powerpoint, which are not limited to "highly constrained networks". For example, the Chrome browser, by default, uses NULL CID. I may be placing words in the mouth of Google developers, but I believe their goal is to reduce the overhead of the QUIC header compared to TCP/TLS. This is related to a general quest for performance, not to network constraints.


From Vinny Parla on the :
I don't think we need to make normative changes to the protocol, but adding a note for implementers that they might want to treat extension headers differently that other IP protocols sounds like a good change. Some additional review comments from an internal review that I wanted to share with you. Section 4.6 has a minor issue as the IANA registry mixes IPv6 extension header with layer-4 headers. It should also specify the use of RFC 5952 for representing IPv6 addresses. However, this can be ignored for now. Section 4.7.1 unsure whether "IP Version" field is useful as it can be derived from "IP Address" length/notation, also not critical but perhaps this would reduce unnecessary information. There is also a minimum 68-byte MTU for IPv4 ;-) - not sure that is important, but wanted to share. The recursive DNS server info (found in RA and DHCP), is not present. Was this an intentional decision or perhaps something that was not considered for some reason? There is no discussion of link-local addresses / ULA (I would expect both end of the 'tunnel' to have link-local addresses), or link-local multicast (e.g., ff02::1). Or perhaps the IP proxy send an IPv6 RA ? or should be prevented from sending one ? Should IP proxy reply to ff02::2 (all link-local routers), ... -Vinny


Following up from URL It seems like the key configuration lists a set of potential HPKE algorithms that the client can use. The section URL does say "a selected combination of KDF, identified by kdfid, and AEAD, identified by aeadid", but it's easy to miss the selected word and even then its not apparent as to what the selection is from. I think it could be made clearer that the client can choose from a list of HPKE algorithms specified in the Key Configuration.


URL Unless there is a description the figure, with directed and non-directed lines it is very hard to interpret the figure. I would recommend to at least add some reading guidance for the lines.
LGTM, thanks!Looks fine.


draft-08 is the latest HPKE draft, which should be stable. It is also what's being used for interop testing right now.
Discussed 20210526 Interim: Merge.


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


If one is using IPPROTO to select a particular protocol to be tunneled, one may still received ICMP in the context of this request. To my understanding there are two reasons for this. a) ICMP generated by the Connect-IP peer endpoint b) ICMP sent back by node beyond the Connect-IP that is directly related to forward traffic sent by this endpoint and which the tunnel endpoint maps back to the Connect-IP request. I think we could add a clarification of this in , or we could do it later.
Totally agree. I added fb1578626de4d3073ac31f5cb89c06efae2ebc51 to address this as part of .
Based on the discussion in issue we recommend to use ICMP for error signal. ICMP works for MTU issue or destination unreachable, however, there is no appropriate message type if the IP header of the packet provided by the client contains an IP that wasn't assigned to the client. So we need a different kind of error handling for this case?
I think ICMP works for this, I'd send See . Would that work?
I guess that could do it. Should we be more specific in the draft? Also, we probably would need to be more explicit in the draft that you should request a scope for your CONNECT request that allows you to received ICMP messages.
Can you write a PR for this please?
IETF 114: Recommend including ICMP if providing routes to the peer, and clients should always be prepared to receive ICMP. Also add note that ICMP may have other source/destination addresses so as to not surprise endpoints.
Also look at RFC 4301 for some potentially helpful text.
Where is the ICMPv4 detail?


The draft says explicitly that receiving Version Negotiation terminates a connection attempt. This isn't consistent with that. This probably needs to say something like this instead:
That sounds good to me, can you make this a PR?


text for proxy security cases
Reverse proxy may act as origin server and hence client doesn't use e2e security to server group. However, in other cases a reverse proxy may assume the client uses e2e OSCORE security and not add any security by itself. To consider all the different, possible/valid cases for this. And see if it's different for forward proxies.
One particular example is a client that connects over CoAP+TLS+TCP (or CoAP+DTLS) to the reverse-proxy, where the proxy uses OSCORE security for the multicast request. The client is not aware of the (group) security material which the proxy and servers have.
At high level, there are 4 different potential cases of "proxying with security". Forward proxy with e2e security [=Group oscore e2e via proxy] Forward proxy with two-leg security [=unicast OSCORE or DTLS on 1st leg, with group OSCORE on 2nd leg] Reverse proxy with e2e security [=Group oscore e2e via proxy] Reverse proxy with two-leg security [=unicast OSCORE or DTLS on 1st leg, with group OSCORE on 2nd leg] Currently the draft doesn't say anything about these combinations, which are valid, which not, and where to find the security solution to them (e.g. a pointer to draft-groupcomm-proxy for covering most of these cases) This text/analysis could be a new Section 5.3 "Proxy Security" or so. Note: cases 2 and 4 depend on a 100% trusted proxy so no e2e security model. The client in this case is not even aware necessarily of the existence of Group-OSCORE. The proxy stores the "group member identity" to be used to make the Group OSCORE protected request. This may be a single identity, or a separate identity for each authorized user of the Proxy service. Case 1 and 3 most likely means OSCORE-in-OSCORE is needed?
It seems like a good idea. Intermediaries are usually considered non-trusted, hence the interest for an actual e2e security model between origin client and origin servers. How would the proxy store and use a "group member identity" ?


Even if the proxy somehow obtains multiple different Sender IDs from the Group Manager (i.e., one for each authorized user of the proxy service), the proxy would have to sign a Group OSCORE protected request with a private key of its own (possibly one per corresponding Sender ID), which is not in control of the actual origin client. With such a level of trust on the proxy, and with a client not interested in e2e security anyway, it would be just easier to think of the proxy simply as another single member of the same OSCORE group including the servers, thus sacrificing verifiable data authorship/origin. Maybe this might be useful/applicable for case 4, with a client anyway likely unaware of what happens beyond the reverse-proxy and to be actually reaching a group of servers. Not sure about case 2, where the client would be aware of an actual group of servers it tries to reach. Yes, when exactly OSCORE is also conveniently used between Client and Proxy, to fulfill REQ2 from URL : REQ2. The CoAP proxy MUST identify a client sending a CoAP group request, in order to verify whether the client is allowed-listed to do so. For example, this can rely on one of the following ... Note that this requirement applies even in case end-to-end security is not enforced between client and servers.
Agree, in the two-legs security case it seems sufficient that the proxy has one "identity" within the group. And I agree that this proxy would most likely be a reverse proxy Case 4 i.e. it operates like a (trusted!) origin server. By definition of a reverse proxy , it has to be trusted just like a client trusts an origin server with being able to know and manipulate the served content.
This issue was addressed in Section 5.3 of version -04. NAME , can we close it?
Yes!
Looks good! See inline some proposed rephrasing.


This allows registration without endpoint names, which is important for clients that only keep their absolutely essential cryptographic state (see URL, which this closes). The wording in simple registration was changed to not repeat the individual parameters of registration but to only refer there.
Currently, we prescribe that the registering endpoint needs to identify itself with at least an endpoint name, while we allow the RD to be configured to assign a domain based on its configuration. We could allow the endpoint identifier to be absent as well, at least in principle (eg. make it a "SHOULD be set" but no syntactical requirement on its presence), and the RD's configuration then would need to set an endpoint name (like it can now do with a domain), or the RD would refuse the registration like it can now do for unauthenticated hosts. (The RD interface right now doesn't allow a 4.01 Unauthorized response, even though the security considerations indicate that that can happen.) This would allow endpoints that have just enough persistent state to have their cryptographic identity in form of a PSK to register at the RD. Note that for those cases (and PSK seems not to be too uncommon in the CoRE security scenarios), the RD already needs to have received (or have a way to fetch) configuration about that key, which easily can contain a default (or the only permissible) endpoint name for that key. I'd write a pull request to that respect unless controversial discussion about this starts here. (This was fleshed out from in a discussion with Pekka Nikander during ACM ICN about very constrained devices).
First, domain is optional. The RD should not invent a domain for registrations that did not include a domain parameter. If the RD sets the endpoint name, then a client should be able to learn it from the registration resource, which will then depend on the implementation of read from the rd resource returning the registration parameters in the link for the registration resource, and/or the inclusion of a "self" link in the registration resource that includes "ep" as a link attribute.
Currently, we say that "When this parameter is elided, the RD MAY associate the endpoint with a configured default domain." (And it doesn't say that that default would be the absent domain).


It'd need to learn it from the registration resource's metadata (because the registration resource contains right what the host posted, and a self-link would be semantically ambiguous there), but it can be looked up like that: POST /rd: ;rt="temp" Created, Location: /registration/42 GET /rd-lookup/ep?href=/registration/42 Content: ;con="coaps://your-address";ep="what-i-decided" I doubt that those nodes would be really interested in doing that (I reckon they'd even tend to do simple registrations which won't even tell them their registration resource), but they can. Best regards Christian
To add to my example, the client could just as well have asked to get the same result, although I'd recommend that a client in that situation should use the query instead. NAME would that lookup interface address your concerns? Unless not, I'd go ahead and write a patch that allows such behavior (but makes it clear that this can only be used where explicitly configured or allowed in a given setting).
The changes in implement the proposed. With many things now using registration resources rather than names (cf. ), I frankly don't see a reason to mandate names anywhere (Why would a group need a name? The operations don't require it, and we sure can store one if the user desires; same for the end point…), but I won't stir that any further (we should finish rather than starting such discussions; I'd be game for it, but milestones says hurry), as just allowing the name to be configured is sufficient for the ACM ICN use case.


Some applications might want to send messages, and not care about the order of delivery, but still get reliability. QUIC streams give them reliability, but within a stream it enforces order of delivery. This datagram proposal gives unordered delivery of messages, but without reliability. Why not provide datagrams with optional (opt-in) reliability? It shouldn't be a lot of extra work for QUIC implementors to provide reliable datagrams as well as unreliable, given that retransmission is already there for QUIC streams. (I guess an application could create a separate QUIC stream for each unordered reliable message. That might work, but seems ugly and may have some overhead.)
What you describe can already be accomplished using streams: each “reliable datagram” is its own stream. That provides reliable delivery without ordering between independent datagrams. I don’t think we need to add optional reliability to the datagram spec.
Streams are very lightweight, and well suited to this task. Beware applying intuition from TCP too heavily.
So, here's a suggestion then: since I'm sure I'm not the only person who is going to think of this, maybe add some verbiage to the spec explaining why supporting reliable datagrams is unnecessary?
Sounds good. We can keep this issue open as requesting an editorial change.


End of section 3.5 () says: First of all this paragraph seems to be in the wrong section because it's more generally about the capsule protocol and not the datagram capsule. However, it's also confusing. I believe if you negotiate http datagram with the H3DATAGRAM SETTINGS parameter, you always need to also support capsules even if QUIC datagrams are supported, as the other end (e.g. an intermediary) could send you anyway a capsule. Or is this text meant to say that new extensions that use the http datagram but have a new settings parameter for negotiation may not need to support the capsule protocol? I think it would be good to clarify both: what this sentence/paragraph means and what is required if you negotiate http datagrams using the H3DATAGRAM SETTINGS parameter.
I want to extended on this issue a bit more. A lot about the implementation requirement on different nodes are implied rather than being explicit. "Secondly, I will note that the above text combined with what is written in Section 3.4: Intermediaries MAY use this header field to allow processing of HTTP Datagrams for unknown HTTP Upgrade Tokens; note that this is only possible for HTTP Upgrade or Extended CONNECT." If an intermediary is doing this unaware re-encoding and the HTTP extension is an extended connect version it can result in interoperability failure when a Datagram capsule arrives at the endpoint that only supports HTTP/3 Datagrams over QUIC Datagram.
If we build off the notion that H3DATAGRAM setting communicates a willingness to receive the HTTP/3 datagrams (in QUIC datagrams), they still require some request to bootstrap the association, otherwise those datagrams would be ignored. In theory, I could define a new method called "ALWAYSUNRELIABLE" that can be used to bootstrap a request stream and it be defined to never use a capsule protocol. If a server sends me data on that stream, I could ignore it or throw an error. I don't need a new setting to caveat this behaviour.
NAME but then you can't have "blind" re-encoding of HTTP/3 Datagram to Datagram capsules, I think it is that simple.


So we need to choose if HTTP Intermediaries can re-encode when they don't know the Upgrade Token or if they can't and must be aware and thus enable cases where some have different behaviors. See
There is no such thing as "blind re-encoding". Intermediaries can only perform re-encoding when they know that the capsule protocol is in use. Intermediaries can learn that by knowing the HTTP Upgrade Token, or by watching for the Capsule-Protocol header. But I think we can make that clearer by spelling out in the "DATAGRAM Capsule" section that intermediaries MUST NOT re-encode to capsules unless they know for sure that the capsule protocol is in use.
PR did not address the editorial point that this paragraph is in the wrong section.
I don't agree with that editorial point. The paragraph is about the interaction between HTTP datagrams and the capsule protocol, so having in the DATAGRAM capsule section makes sense to me.
It about the interaction about http datagrams (section 2) and the capsule protocol (section 3). There is nothing related to datagram capsules (section 3.5) in this paragraph. I guess you could just add a new subsection 3.6 if you prefer to have it at the end.
LGTM


LGTM
S 5.2. I don't believe this is possible on UNIX. What system call do I use to generate RST? Neither close() nor shutdown() does it.
You set SO_LINGER to {1, 0}, then close.
I don't think there's a question here about the -http draft, is there?
The question is if it's possible on standard OSes. Sounds like it is on Unix. How about Windows? NAME
This is the same requirement as in HTTP/2. A "MUST (but we know you probably won't)" ?
Well, that was a joke in 6919, so probably we shouldn't do that.
This is not that. We know that some implementations use TCP half-closed in HTTP. Some even rely on it to the point that things break if you don't do it. Not that things don't break for those people, but they have a narrow set of peers that they interact with. Of course, whether that set of endpoints is ALSO the same set of endpoints using CONNECT is hard to know.
Note that this particular issue is not about half-closed. In half-closed, you generate a FIN and then keep receiving data. This is about sending an RST.
Perhaps the text should be "SHOULD", and if the platform doesn't allow it, to "close the connection".
There's risk with that too, though. We encountered issues where the TCP connection was closed cleanly instead of aborted, and the client interpreted a truncated response as the (cacheable) response. It gets ugly. If you can't force a RST on the other side, you perhaps shouldn't be implementing CONNECT.
Discussed in Tokyo; MUST close the connection, SHOULD close with a RST.


A couple of minor editorial changes to the current draft, namely: There was a missing grave accent in one of the paragraphs of the Commit section causing some formatting issues Before: ! After: ! Fix typo Pre-Shared Keys section [...], it does not necessarily provide the same [...] guarantees ~than~ as a Commit message. Resolve remaining reference to priorepoch In the Sequencing section there was a reference to a field that was introduced in 2fa6ed3c6afc7d308905255b4cabe154a48d1e4b. However, in 69e12cd61378aae4a81199c28a16e2802666b6e3, it was removed from the struct where it was added. That entire struct was then removed in 27c9c28f9634a06a9b7921ea9c15e276f8c9ff6f, after which the trail runs cold. So I wasn't able to figure out exactly what it must be based on what on what it originally was. Hence, I replaced it with something that makes sense in context. I based the new text on the following line found in the (current) Commit section: Rewrite paragraph on the new_member SenderType I found the phrase " In such cases" after the sentence "Proposals with types other than Add MUST NOT be sent with this sender type" slightly confusing and awkward. To improve this I rewrote the paragraph.
Couple of nits on your nits


LGTM
From NAME The very first sentence is mostly unparseable due to its length (7 lines). Please consider splitting it.
I added this, from NAME review: This section and the next one should be a list with 2 bullets rather than 2 sections to make the text more readable.


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


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


100 bytes? (Here again I'd remove the text about mesh networks.) mesh networks result in about 80 bytes of usable payload per packet without fragmentation. How about we say keeping it small is good and quote examples of 802.15.4 has about 80 byte payload and that LoRa has 51 byte of applications payload in long range mode and just remove any reference to "mesh"
I'm fine with suggestion above. I'm also fine with just leaving draft as is.
Addressed by PR


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


Tries to I resisted the urge to reference the QUIC-LB draft, which isn't adopted. The major substantive change is that I removed the prohibition on non-routing information in the CID. I'm happy to discuss this if people have object.
LGTM. will go ahead and land this, then fix up the lint issues.
NAME missed this during the inconsistency, will fix in working copy
(this is done)
BTW, this was meant to address
Moving URL to the ops repo.
see also -- in any case the text that is there now is not great.
NAME can you please review the existing text (orginially provided by NAME and state what else is needed? Please have also a look at issue
This is a bit OBE, but I think there might still be value in discussing how a server implementer should think about connection IDs. Fortunately, NAME has been doing a bunch of work on this in his load balancer draft. I would suggest that we leave this issue open, and either point to the LB draft or use text from it.
fixed this
Write section to provide guidance; maybe in the same section than guidance in port selection in general


From meeting minutes "SDP o= line increment [] While the proposed solution on the slide was accepted, it was noted that the proposal on the slide goes against what was agreed at last meeting. Emil Ivov also commented that Trickle ICE for SIP does exactly what is described on the slide. Jonathan Lennox said that we should make sure this is compatible with whatever is done in trickle ICE SIP stacks."
This algorithm becomes correct once we decide to not allow o= modification. Editorial comments follow.
Discussion in-room: 1) add example to make it clear that there is a separate counter (other than current o=) which is what increments. 2) change text about <session-version> to be more of a "note that" for an edge case, as opposed to normative text about a mainline case.
Updated this branch. PTAL
LGTM
2349: "might differ" is creepy. "differs" perhaps. 2359: "N + 2" -> must be greater than N + 1 This is basically OK modulo the above


the RFC 7250 semantics that both certificate types are globally negotiated. There is no support for mixed certificates.


NAME I'll leave that in your hands.
NAME said:
Seems reasonable. I took the opportunity to reword a little.
Perhaps this PR should also fix the text in 8.1 to simply state and point to 14.1 in -transport. That text is redundant.


From Ben Campbell's review:
Second point is fixed by . I'm not sure the third point is an improvement.
SSL is used exactly once, as part of the acronym "TURN/SSL". This is also the first mention of TURN, but the second was much more convenient to attach the expansion to. Given that it was so awkward to attach them, I included a new section listing the "used protocols" instead.


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


Part of the responses. Will merge (and upload as part of a -26) if there is an ACK from authors or chairs.
Before the 2020-08-13 telechat, some reviews have come in: : Not Ready Minor: Clarification on "subject" -- my intention was to include anything "subject", but I don't really know what else to put in there. Minor: Why is the first attempt special? -- Can clarify, PR to come. [edit: ] Nits addressed in URL More nits (IDnits) do not require editing, but some explanation -- where would that go? Shepherd writeup? (that would be → NAME : Ready Notes that the DDOS mitigation section is a bit history heavy. I had similar comment in URL; should we use that comment to shorten here? [edit: If so, would want an ACK.] "It is my impression, that Security Considerations were mostly written having in mind that (D)TLS is always used, however it is only "SHOULD" in this draft (or even "MAY" if we look at RFC6690 which Security Considerations this draft refers to). I think that adding a few words describing which consequences for security not using (D)TLS would have and in which cases it is allowed will make the Security Considerations more consistent. " -- [edit: covered in ] I'll issue PRs for what I think we can do something about quickly, but won't merge them or create a -26 without an ACK on them (given we're late in the whole publication stage and my impression is that ill-coordinated uploads do more harm than good) and will follow up on this comment when they're ready for review.
With the additional reviews that have come in today, I see no point in addressing some of what has come in in a pre-telechat update (as we can't resolve all the discuss points) -- taking the urgency off this. I'll still file PRs for changes resulting from the reviewer comments. Procedurally (so this goes to NAME or NAME Is the general expectation with IESG comments that the text be further improved to answer all the points (especially when they are comments), or can a plain "we did it that way because" suffice?


In the latter case, would it make sense to collect point-to-point responses here so they get author or WG review before "we" answer them?
With URL and its follow-ups sent out, this is closed; any further comments will be opened as new issues. Hello Reviewers, CoRE and IESG members, thanks for your input to the Resource Directory document, and your patience while it was being processed. Before the individual point to point responses can go out, this mail is to address the general status, and answer a few points that were brought up by different reviewers (it will be referred back to in the point to point responses). In summary, the points raised in the reviews led to the changes of the recently uploaded [-26], and where no changes were made, the reasoning behind the choices in the document is outlined below or in the following mails. (Either way, short of aggregated nits paragraphs, all points are responded to in the following mails). A few larger issues evolved from the review comments being discussed in the interim meetings, so please expect a -27 at a later point (after IETF109) with the changes mentioned below. Kind regards Christian [-26]: URL Preface References into the issue tracker are primarily intended for bookkeeping and to give you access to the altered text if you're curious -- but for general review purposes, the responses are self-contained. Anticipated changes We have opted to submit a new version that should clear out all the other comments, so that the remaining work can be focused and swift: Replay and Freshness (OPEN-REPLAY-FRESHNESS) The comment on DTLS replay made us reevaluate the security properties of operations on the registration resource. While these are successively harder going from DTLS without replay protection to DTLS with replay protection and hardest with OSCORE, the text as it is is still vulnerable to an attacker stopping a reoccurring registration, or undoing alterations in registration attributes. Mitigation from a concurrent document (the Echo mechanism of I-D.ietf-core-echo-request-tag in event freshness mode) is planned, but the text is not complete yet. Necessity of the value in all responses The requirements around Limited Link Format and the necessity to express all looked up links in fully resolved form have stemmed from different ways RFC6690 has been read, both in the IETF community and by implementers.


A comment from Esko Dijk has shown a clear error in one of the readings. That reading is single-handedly responsible for most of the overhead in the wire format (savings can go up to 50%), which is of high importance to the CoRE field. Due to that, it is the WG's and authors' intention to remove the reading from the set of interpretations that led to the rules set forth. The change will not render any existing RD server implementation incompatible (older RDs would merely be needlessly verbose), and the known implementations of Link-Format parsers can easily be updated. The updates to the document could not be completed in time with the rest of the changes, because a) it requires revisiting the known implementations for confirmation and b) will affect almost every example that contains lookup results. Server authorization (OPEN-SERVER) The two areas of "how is the RD discovery secured" and "what do applications based on the RD need to consider" jointly opened up new questions about server authorization and the linkage between a client's intention and the server's promises that may easily not conclusde in timeframe reasonable for RD. While steps have been taken to address the issue both on the RD discovery and the applications side (URL), the ongoing discussions in the working group may turn up with a less cumbersome phrasing for these parts. There's a few small open issues Esko brought up on the issue tracker that could not be addressed in time; most of them are about enhancing the examples, which best happens after the anchor cleanup anyway. Repeated topics A few common topics came up in multiple reviews, and are addressed in the following section; the individual responses can be found in follow-up mails, and refer to the common topics as necesary. GENERIC-FFxxDB "Where do the ff35:30:2001:... addresses come from?" response: There's a coverage gap between RFC3849 (defining example unicast addresses) and RFC3306 (defining unicast-prefix-based multicast addresses). For lack of an agreed-on example multicast address, the used ones were created by applying the unicast-prefix derivation process to the example address. The results (ff35:30:2001:db8::1) should be intuitively recognizable both as a multicast address and as an example address.


The generated address did, however, fail to follow the guidance of RFC 3307 and set the first bit of the Group ID. Consequently, the addresses were changed from ff35:30:2001:db8::x to ff35:30:2001:db8::8000:x, which should finally be a legal choice of a group address for anyone operating the 2001:db8:: site. (The changes can be viewed at URL). GENERIC-6MAN "Whas this discussed with 6MAN?" response: Not yet; a request for feedback was sent out recently. (Mail at URL). GENERIC-WHOPICKSMODEL "How does the client know which security policies the RD supports?" response: The client can only expect any level of trustworthiness if there is a claim to that in the RD's credentials. Typically, though, that claim will not be encoded there, but implied. For example, when configuring an application that relies authenticated endpoint names, then telling the application to use the RD authenticated via PKI as URL should only be done if the configurator is sure that URL will do the required checks on endpoint names. Some clarification has been added in URL GENERIC-SUBJECT "Section 7.1 says: '... can be transported in the subject.' -- where precisely?" response: That text was only meant to illustrate to the reader what such a policy could contain, not to set one (which would require more precision). It has been made more explicit that this is merely setting the task for the policies. As an example, some more precision is given by referring to SubjectAltName dNSName entries. Changes in URL (If you have read up to this point, please continue reading the follow-up mails addressing the individual reviewer's points.)


For other parameters you have to pass in an empty object if you do not want to set anything but not for SecurityParameters. Unclear why the parameters are treated differently?
Make security parameters non-optional Remove "Transport Properties MUST always be specified while security parameters are OPTIONAL." Define that there is an implementation-specific security parameter to disable security
LGTM, thanks!


The unsigned PublicGroupState created by leads to an attack on the new joiner. The sender of a GroupPublicState can associate any HPKE it wants with the group, and thus learn the without being a member of the group. (The UpdatePath and the resulting partly defend against this attack, though they are subverted if the attacker has compromised any single key used in the Update Path.) To guard against this attack, this PR adds a signature over the HPKE public key in the PublicGroupState.
In light of the feedback on the mailing list from NAME re: deniability, I have upgraded this PR to sign the whole PublicGroupState.
Outstanding issue: One detail that is not fully covered by is the strategy new joiners should apply to determine who the latest committer is and make sure that both the and the last Commit are signed by the same member.
The last node to send an UpdatePath is the last one to set the root. So you can follow parent_hash to find which leaf it is. But like I said on the IETF meeting call, I don't think we should actually require that PublicGroupState be signed by the last updater. There are possible operational/sync issues if the PublicGroupState isn't fate-shared with the Commit, but that's a practical issue, not a security issue. And in any case, it's not a breaking change, so we can fix it post-draft-11 if we decide we need to.
Please fix the link on the repo page to display diffs between the current editor's draft and the WG draft. Now, it should PRs comparing back to the -00 version.
NAME Any change you could have a look at this when you have some time ? : )
Yeah, I'm gonna fix the CI and I can take a look at this as well. I tried to get it done before the interim but, well, excuses excuses
Ahah... ;) No problem!! Thanks !
NAME -- last call on this, or i'm just going to close it
Sorry. As you will have guessed, this fell through the cracks. I'll try this week to fix it out and close it out if I don't get to it this weekend :/


Clarifies why a client might send a Handshake packet, as well as improving the surrounding anti-deadlock text. Changes 2 SHOULDs to MUSTs to line up with recovery.
We don't provide examples of the weird cases where you need to send Handshake packets to prevent amplification deadlock. The strangest one is where the client has all Initial data (and therefore has Handshake keys), but never receives a Handshake packet from the server. In this case, the client needs to send a Handshake packet that won't contain ACK or CRYPTO frames. We should explain this in a note. See .
I think the logic in the recovery draft misses some of these cases entirely. The rule in draft 23 is: but in your example case there is not necessarily any unacknowledged data to transmit in a probe, and a is forbidden at Handshake level, leaving no reasonable options to compose an ACK-eliciting packet.
a few suggestions


This change replaces "shortly" in the normative language of Section 7.4, Applying for Certificate Issuance, with the more precise expectation that the server begin the issuance process, as discussed on the mailing list. URL We could say "MUST begin the issuance process" The main things on my mind that could delay issuance slightly: Submitting to CT Checking CAA Internal queuing for available capacity Manual vetting I think "MUST begin" covers for all of those, while allowing some vagueness as to how long they will take. On 03/22/2017 09:39 AM, Daniel McCarney wrote:


NAME thanks, good catch. should be fixed now.
Comment by NAME Algorithm entries use two octets (65535) but only allow 255 Private Use entries. I think that might be a little low. Maybe allow 0xf000 - 0xffff or something ?
I agree this should be changed. CCing NAME who I believe initially proposed this.


Discussion from editor conference call: NAME will update this PR with NAME comments
From NAME (URL) Section 7. Streaming Encrypted Media As far as I know, streaming users sometimes use encrypted tunnels such as OpenVPN or WireGuard (or IPsec) to access video content. I may miss something, but it is unclear to me how that fits into the categories presented in Section (Seems closely related to URL )
The purpose of such tunneling is to circumvent geoblocks and access content from other regions - not to protect the media content. Encrypting the content is done by the content owner for its protection.
So, looking at , I'm seeing this text: I think this means that the effect is that the "transport-level information is opaque to intermediaries" effect described in the document applies, with the additional consideration that intermediaries can't see the IP addresses used inside the tunnel, either. I think the same applies to any IPsec-encrypted tunnel. Do we need to say that? And, if so - can we describe this without using product names and descriptions which may age badly in an RFC?
isn't as easy to read, but I think this is also the rough equivalent of IPsec, from a media operator perspective - all of the transport information and the IP addresses used inside the tunnel are obscured.
Just for the record, definitely worth checking as it is related to this discussion: URL Reviewer: Michael Scharf Review result: Ready with Issues This document has been reviewed as part of the transport area review team's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors and WG to allow them to address any issues raised and also to the IETF discussion list for information. When done at the time of IETF Last Call, the authors should consider this review as part of the last-call comments they receive. Please always CC EMAIL if you reply to or forward this review. This informational document surveys network and transport protocol issues that affect quality of experience for streaming applications, in particular video. The overview covers many topics across different technologies. Readers may only be familiar with a subset of these topics and could therefore learn quite a bit from this kind of tutorial. Nonetheless, it remains somewhat unclear what the actual objective of some of the text is.


For some topics, quite a bit of technical background is provided, but the discussion is not really comprehensive. In many sections, the document neither derives technical challenges, nor system/protocol requirements, nor practical usage guidance. It is just a kind of tutorial. Quite a bit of text also presents ongoing IETF work, and an RFC with this scope may thus get outdated soon. Section 6.2 deals with topics owned by TCPM. In similar past documents, I have asked for a TCPM presentation prior to an IETF last call in order to ensure that owners of running code are in the loop. I believe this strategy has worked well in the past. Having said this, as TSV-ART reviewer I don't strongly disagree with a publication. All these issues may just be OK for an informational RFC. Some more specific comments: Section 3.2.1. Recognizing Changes from an Expected Baseline This section apparently assumes relatively static path properties, e.g., fixed network connectivity. It would be more useful to analyze the impact of Wifi and 4G/5G networks in one place. Some of this follows later in sections 3.2.1 and Yet, the split between these three sections is unclear. Having a discussion about today's Internet path characteristics and the dynamics at one place could be more useful. The text could also better distinguish between what matters to endpoints and considerations relevant only for middleboxes (such as passive monitors). Section 3.3 Path Requirements The statement "to find the bandwidth requirements for a router on the delivery path" may assume that the bottleneck on the path will be routers. Yet, on a path the bottlenecks could also be a link layer device (e.g., an Ethernet Switch, a Wifi access point, etc.). RFC 6077 (specifically Section 3.1.3) also explains that issue. A better wording may be "to find the bandwidth requirements for a delivery path". Section 3.6. Unpredictable Usage Profiles / Section 3.7. Extremely Unpredictable Usage Profiles I am not fully convinced by the distinction between "unpredictable" and "extremely unpredictable". To me, these two sections could be merged and maybe also be shortened. More specifically, Section 3.7 lists a lot of statistics from the past.


What is IMHO a bit missing in Section 3.7 are actual operational considerations. For instance, are there any lessons learnt for the future? Note that Section 3.6 has a reasonable conclusion at the end. Section 4. Latency Considerations and Section 4.1. Ultra Low-Latency I am surprised by the definition "ultra low-latency (less than 1 second)", as well as some of the other numbers. For other real-time communication use cases, "ultra low-latency" would probably imply a latency requirement of the order of one millisecond. For instance, isochronous traffic for motion control in industrial networks may require a latency of 1 ms, and such "ultra-low latency" requirements are discussed elsewhere, e.g., in the DetNet WG. The terminology in this section should be better explained to readers dealing with networked systems with much harder latency requirements. And a reference should be added for these definitions in the context of video streaming. Section 5.5.2 Head-of-Line Blocking If Head-of-Line Blocking is indeed a relevant operational problem, it would be useful to add a corresponding reference (e.g., with measurements). Section 5.5.3. Wide and Rapid Variation in Path Capacity The statement "As many end devices have moved to wireless connectivity for the final hop (Wi-Fi, 5G, or LTE), new problems in bandwidth detction have emerged from radio interference and signal strength effects." could be moved to earlier parts of the document. Quite a bit of new computers apparently only have Wifi connectivity and no Ethernet port, i.e., Wifi may just be their default. Also, wireless may not only be used on the last hop, for instance in meshed setups. This may make the problem even harder. Section 6. Evolution of Transport Protocols and Transport Protocol Behaviors I really wonder whether UDP vs. TCP vs. QUIC is actually the relevant distinction. What may actually matter are the transport services provided by the protocol stack (e.g., RFC 8095). I fully agree to a related comment in the INTDIR review. Section 6.1. UDP and Its Behavior UDP is also used for encrypted tunnels (OpenVPN, Wireguard, etc.).


Does encrypted tunneling really have no operational impact on streaming apps other than circuit breakers? (I am thinking about 4K streaming over OpenVPN and the like.) Section 6.2. TCP and Its Behavior This text should IMHO be presented and be discussed in TCPM. Personally, I am not convinced that this document is a good place for discussing the long history of TCP congestion control. If the objective of the document is to provide a tutorial, IMHO it would be more useful to briefly explain the state-of-the-art in year 2022. Some further specific comments on TCP congestion control: It is surprising that RFC 5681 is not referenced.793bis has normative statements regarding congestion control, and most stacks are compatible to what is written in 793bis. Several operating systems use CUBIC by default and support standard Reno. Another general good reference for TCP standards is RFC 7414.Does ECN, DCTCP, etc. really not matter at all, for instance, if a data center hosts video playout servers? Section 6.3. QUIC and Its Behavior As already noted, the discussion about head-of-line-blocking would really benefit from backing by a reference. Section 7. Streaming Encrypted Media As far as I know, streaming users sometimes use encrypted tunnels such as OpenVPN or WireGuard (or IPsec) to access video content. I may miss something, but it is unclear to me how that fits into the categories presented in Section


As naïve handling of external identities may cause the server to be vulnerable to identity enumeration attacks, refer the section that discusses that danger in the PSK section itself.