jiebi/CodeConvo huggingface dataset:
Change:
sent by the application and the tradeoffs the application is prepared to make in path and protocol selection to receive that desired treatment.  When the capacity profile is set to a value other than <del> Default, z Transport Services system SHOULD select paths and </del> <ins> Default, the Transport Services system SHOULD select paths and </ins> configure protocols to optimize the tradeoff between delay, delay variation, and efficient use of the available capacity based on the capacity profile specified.  How this is realized is implementation-

Discussion:
This is my attempt to address items 2, 3 and 4. My suggestion is not to do anything about item 1 (referencing -arch), because we already do this so often and IMO it won't improve the document to add yet another reference. See also the discussion in .
These are some minor comments (mostly editorial) /nits, that would be best to address before going for IETF Last call but can be taken care during or after the IETF LC. Section 3 should reference architecture document. We are using concepts and definitions from the architecture document and lets be specific about it. Of we can mention this in the terminology section. Section 8.1.1: the description of Full Coverage is given in section 9.1.3.6. Either forward ref that section where it is explained or move the text in section 8.1.1. Section 8.1.6 : says - >When the capacity profile is set to a value other than Default, z Transport Services system SHOULD select paths and configure protocols to optimize the tradeoff between delay, delay variation, and efficient use of the available capacity based on the capacity profile specified. here "z" ?? Section 9.1.3.1 : says - >The Lifetime specifies how long a particular Message can wait to be sent to the Remote Endpoint before it is irrelevant and no longer needs to be (re-)transmitted. can we describe whether this wait till the Message is sent out of the TAPS system or will the wire (which might include other processing delay by the system)?
Regarding the first item: I think this is overkill. Section 1 begins with: "This document specifies an abstract application programming interface (API) that specifies the interface component of the high-level Transport Services architecture defined in [I-D.ietf-taps-arch]." Section 2 begins with "The design of the API specified in this document is based on a set of principles, themselves an elaboration on the architectural design principles defined in [I-D.ietf-taps-arch]. " - adding something like this to section 3 or section 1.1 too is not making anything clearer, IMO.
The problem I see is that in section 3 we are describing the Connection and Preconnection again.

Note that I am using the word "describing" as those are already defined and described in the Arch doc we just need to ref them or say see there in the Interface doc. I would like to avoid the situation that readers are confused and any future update to the Interface doc is problematic to decide which definition/description to preserve. I think just adding a sentence in the terminology section saying things are defined in Arch document make sense. But hej, this is a minor comment so...
Change:
QUIC version 1, that connection closure MUST use a transport error of type "VERSION_NEGOTIATION_ERROR". <del> If a client has reacted to a Version Negotiation packet, it MUST validate that the server's "Other Versions" field does not contain the client's original version, and that the client would have selected the same negotiated version if it had received a Version Negotiation packet whose Supported Versions field had the same contents as the server's "Other Versions" field.  If any of these checks fail, the client MUST close the connection; if the connection was using QUIC version 1, that connection closure MUST use a transport error of type "VERSION_NEGOTIATION_ERROR".  This connection closure prevents an attacker from being able to use forged Version Negotiation packets to force a version downgrade. </del> <ins> If the client received and acted on a Version Negotiation packet, the client MUST validate the server's "Other Versions" field.  The "Other Versions" field is validated by confirming that the client would have attempted the same version with knowledge of the versions the server supports.  That is, the client would have selected the same version if it received a Version Negotiation packet that listed the versions in the server's "Other Versions" field, plus the negotiated version. If the client would have selected a different version, the client MUST close the connection; if the connection was using QUIC version 1, that connection closure MUST use a transport error of type "VERSION_NEGOTIATION_ERROR".  This connection closure prevents an attacker from being able to use forged Version Negotiation packets to force a version downgrade. This validation of "Other Versions" is not sufficient to prevent downgrade.  Downgrade prevention also depends on the client ignoring Version Negotiation packets that contain the original version; see incompat-vn. </ins> After the process of version negotiation in this document completes, the version in use for the connection is the version that the server

Discussion:
In light of discussion in slack, the problem here is that the validation is based on the negotiated version. Validation needs to be based on the client's selected version. I've also moved text about validating lack of support for the original version to the incompatible VN section, alongside a reminder to validate connection IDs. Security does depend on this, but the client ignores these bad VN packets. That provides more effective defense against attack than what was here originally.
Thanks! Approved modulo two nits
Change:
3.6.1. <del> The receiver will first intersect any known local limits (e.g., hardware decoder capabilities, local policy) to determine the </del> <ins> The receiver will first combine any known local limits (e.g., hardware decoder capabilities or local policy) to determine the </ins> absolute minimum and maximum sizes it can receive.  If there are no known local limits, the "a=imageattr" attribute SHOULD be omitted. If these local limits preclude receiving any video, i.e., the

Discussion:
…or already fixed. NAME Change in normative text (previous ART AD requested it), please review.
LGTM, approved.
eom
LGTMOne minor comment.
Change:
Update note on the recommended column with text in rec-note. <ins> update the note on the role of the expert reviewer as follows. </ins> 8. In order to refect the changes in the Recommended column allocation,

Discussion:
Update exporter
NAME minor nit, but this is what I remember being discussed in Philly.
I was recently surprised to learn that the uses . This is a problem for us - we have an internal use of an exporter that we cannot release a specification for at this time. This means that our only option is to "squat" on the value instead of registering it. Since we're already making changes to these repositories and we now have a Recommended column, I propose that we instead use . Note that Expert Review is exactly the same as Specification Required, with the exception that it doesn't require a specification. We could also add a requirement that entries with have a specification.
Change:
Shorthand notations are also provided for when there is a single wildcard or name selector. <del> The "dot-wildcard-shorthand" is shorthand for "[*]". </del> <ins> ".*", a "child-segment" directly built from a "wildcard-selector", is shorthand for "[*]". </ins> <del> A "dot-member-name-shorthand" of the form ".<member-name>" is shorthand for "['<member-name>']", but can only be used with member names that are composed of certain characters.  Thus, for example, "$.foo.bar" is shorthand for "$['foo']['bar']" (but not for "$['foo.bar']"). </del> <ins> ".<member-name>", a "child-segment" built from a "member-name- shorthand", is shorthand for "['<member-name>']".  Note that this can only be used with member names that are composed of certain characters, as specified in the ABNF rule "member-name-shorthand". Thus, for example, "$.foo.bar" is shorthand for "$['foo']['bar']" (but not for "$['foo.bar']"). </ins> 2.7.1.2.

Discussion:
Can you explain how the test scripts work and how to interpret the output, please?
I haven't done the work to make this a real CI script. You clone the JPC to a directory parallel to where you cloned the I-D repo. kdrfc draft-ietf-jsonpath-URL sh URL ruby scripts/test-abnf-URL > scripts/test-abnf-URL 2>&1 ruby scripts/test-abnf-URL > scripts/test-abnf-URL 2>&1 ruby scripts/test-abnf-URL > scripts/test-abnf-URL 2>&1 ruby scripts/test-URL > scripts/test-URL 2>&1 Compare the output with the checked-in output. (The output contains all parse failures, including the intentional ones. The word FAIL tells you about unexpected output.) An output that says "successfully completed" at the end has done exactly that.
~JPC?~ oh... json path comparison
Is this something that should be in the same repo as the spec? Seems like it should be with a test suite. Or do we plan to remove it before publication?
Indeed -- URL mentioned json-path-comparison (which I call JPC) and jsonpath-compliance-test-suite (which I call CTS). Of course I'd love to get more test data...
This repo contains everything that is needed to work on the spec document. Testing the ABNF in the spec document is a typical case for including tests with the code. It's testing the document. The information in there can possibly be used for building test suites, but I'd rather use the original data in JPC and CTS (which already is a test suite). The test data specifically collected (test-URL) could indeed be used for further testing, but it probably makes more sense to include sample documents and sample query results with that (which were not needed to test just the ABNF). We publish the spec (as an RFC). The repo that creates the spec is public, but not "published" in the stricter sense.
Two objectives: (1) aesthetic cleanup, e.g.: URL (2) more tests, e.g., to be built from query corpora we can find
Looks plausible. I haven't reviewed or run the Ruby code.
Change:
WebRTC implementations MUST support multiplexing of DTLS and RTP over the same port pair, as described in the DTLS-SRTP specification <del> RFC5764, section 5.1.2.  All application layer protocol payloads over this DTLS connection are SCTP packets. </del> <ins> RFC5764, section 5.1.2, with clarifications in I-D.ietf-avtcore- rfc5764-mux-fixes.  All application layer protocol payloads over this DTLS connection are SCTP packets. </ins> Protocol identification MUST be supplied as part of the DTLS handshake, as specified in I-D.ietf-rtcweb-alpn.

Discussion:
NAME please review
From Magnus Westerlund in IETF LC: Section 3.5: WebRTC implementations MUST support multiplexing of DTLS and RTP over the same port pair, as described in the DTLS-SRTP specification [RFC5764], section 5.1.2. All application layer protocol payloads over this DTLS connection are SCTP packets. This text should reference also the update to RFC5764: URL That document is publication requested so even as normative reference it will hopefully have minimal impact on the publication progress of this document.
Looking at -mux-fixes, I think this is worth including. Adding.
Change:
Applications SHOULD provide a unique label to "MLS-Exporter" that identifies the secret's intended purpose.  This is to help prevent the same secret from being generated and used in two different <del> places. </del> <ins> places.  To help avoid the same label being used in different applications, an IANA registry for these labels has been defined in mls-exporter-labels. </ins> The exported values are bound to the group epoch from which the "exporter_secret" is derived, and hence reflect a particular state of

Discussion:
Also copies the "Recommended" field by reference, instead of reciting it in each registry. Note that this has a conflict with that will not catch -- "MLSContentTBS" will have to be changed to whatever new name is agreed in that PR.
The of absolutely needs to be unique for every signature happening in the protocol, for security and avoid signature ambiguity. That includes signatures happening in extensions. Should this be referenced in a IANA considerations to ensure there is no conflict in the future? Or at least say something about this somewhere? We have to think how to design things well here to be future-proof: the structure must be used for every signature done with the leaf signature keys, which includes what might happen in extensions but also in future versions of MLS. If future versions of MLS could avoid doing , that would be great!
This seems to come down to whether we expect the signature keys used for MLS authentication to be used outside of MLS (otherwise there's no risk of confusion) and if so, whether this spec has any influence on that usage. If you're using your MLS key to sign Bitcoin transactions, we can't do much to help that. Note that there is not an issue for future version of MLS here. The label is constructed as , so a future version could just increment the part of that. Given all that, I might prefer a recommendation that signature keys not be reused across contexts, rather than trying to accommodate reuse. If we do something here, we should do something analogous to the registry, which are similarly intended for domain separation between different use cases. We should probably consider making an exporter label registry anyway.
I agree, we shouldn't do anything about someone using the MLS signature key in another protocol. About future MLS versions: I agree, but note that there is a length tag before that. It means that we impose to all signature of future MLS versions to start with (including the quic integer) Is it something acceptable or not, I don't now. I just think we should have in mind that the decisions we make now on will have an impact on the design of future MLS versions. About extensions: in the extensions document, there is a signature computed with If two extensions were to use the same label then this could lead to security problems, this is why I think the labels should be in some registry to ensure they are all unique.

One other thing we could do is to separate all extensions signatures from the core MLS signatures, for exemple using the label "MLS 1.0 extension [label from extension]"? Like that a bogus extension can't introduce a security flaw in core MLS that way?
Change:
quality, in addition to any performance considerations associated with sending all WebRTC media through the proxy server. <del> Mode 1 MUST only be used when user consent has been provided.  The </del> <ins> Mode 1 MUST NOT be used unless user consent has been provided.  The </ins> details of this consent are left to the implementation; one potential mechanism is to tie this consent to getUserMedia consent. Alternatively, implementations can provide a specific mechanism to

Discussion:
(nit) §3: Please expand "RTMFP" on first mention. (nit) §5.2: "Mode 1 MUST only be used when user consent has been provided" Please consider "... MUST NOT be used unless user consent has been provided." : It seems like the references for STUN and TURN should be normative.
Change:
Verify that the resulting URI is well-formed. <del> Dereference the URI using an HTTP or HTTPS GET request.  If using HTTPS, the ACME server MUST ignore the certificate provided by the HTTPS server. </del> <ins> Dereference the URI using an HTTP GET request. </ins> Verify that the body of the response is well-formed key authorization.  The server SHOULD ignore whitespace characters at

Discussion:
vs. The spec doesn't seem to be consistent. And why does it have to be completed with HTTP? I honestly don't understand that.
LE's seems to give a choice. I'd really prefer that. This would make it possible to not even listen on port 80 for things like APIs, e.g. GitHub does that on .
As discussed on the list and in the document, the HTTP challenge needs to be HTTP-only in order to avoid the default-vhost issues. Thanks for catching the stray HTTPS text. I will remove it.
Do you have a link to the discussion?
See URL Is that example just bogus or what's the for? There are only two challenges, so it can't be an index there.
Good point. Left over from when we had three challenges in the example.
Contact information may have been misspelled during registration. Contact information such as phone numbers may also change. https://acme-URL exposes only the endpoint and that endpoint doesn't accept updates, because it has to respond with 409 Conflict for already existing keys. There should be a way to update that information. See also URL
thanks NAME yes updating the contact email for registered LE account is a must have feature otherwise an LE notifications/renew notices may end up going to invalid email addresses.
Right now, the spec says that you can update anything in the registration with a : Note that the request goes to the registration URL, not the new-registration URL. I'll add an example to the document to clarify.
Change:
Stop action is performed on the Listener object. The ConnectionReceived Event occurs when a Remote Endpoint has <del> established a transport-layer connection to this Listener (for Connection-oriented transport protocols), or when the first Message has been received from the Remote Endpoint (for Connectionless protocols), causing a new Connection to be created.  The resulting Connection is contained within the ConnectionReceived Event, and is ready to use as soon as it is passed to the application via the event. </del> <ins> established or cloned (e.g., by creating a new stream in a multi- stream transport; see groups) a transport-layer connection to this Listener (for Connection-oriented transport protocols), or when the first Message has been received from the Remote Endpoint (for Connectionless protocols or streams of a multi-streaming transport), causing a new Connection to be created.  The resulting Connection is contained within the ConnectionReceived Event, and is ready to use as soon as it is passed to the application via the event. </ins> If the caller wants to rate-limit the number of inbound Connections that will be delivered, it can set a cap using

Discussion:
I added text to ConnectionReceived about this. I didn't additionally explicitly state this in the text about clone to avoid complicating things - since similarly, the text describing Initiate() doesn't talk about ConnectionReceived.
If is called, is an unsolicited event generated at the peer? I assume so, but can't find it documented.
Do you want this to happen specifically upon calling clone(), or is it good enough if it happens upon the first arrival of data on the new Connection? The latter could be specified (and I'd have to check if it isn't already). However, in the first case, we could specify that this should happen if possible, but I don't think it's a behaviour that can be promised. For a multi-streaming protocol, URL() just means "from now on, we have a new Connection, for which we're going to use a new stream" - so I don't think that anything's immediately going to happen on the wire just due to clone() in this case.
I'd expect a event to be delivered before an event indicating arrival of data on the new connection. That could be immediately before, if there's no explicit on-the-wire signalling that the new connection has been created.
Ah, ok! I agree it should happen as you describe it, and I'll take care of this: I'll check if this is already covered (and if so, if the text should be more explicit about it). If it isn't covered, I'll add text to state this.
Change:
no update to the OHB is required. A Media Distributor that decrypts, modifies, and re-encrypts packets <del> in this way MUST use an independent key for each recipient, SHOULD use an independent salt for each recipient, and MUST NOT re-encrypt the packet using the sender's keys.  If the Media Distributor decrypts and re-encrypts with the same key and salt, it will result in the reuse of a (key, nonce) pair, undermining the security of AES- GCM. </del> <ins> in this way MUST use an independent key for each recipient, and MUST NOT re-encrypt the packet using the sender's keys.  If the Media Distributor decrypts and re-encrypts with the same key and salt, it will result in the reuse of a (key, nonce) pair, undermining the security of AES-GCM. </ins> 5.3.

Discussion:
This PR responds to IESG review comments from Magnus Westerlund, except for his comments on RED, which I haven't quite figured out how to address yet.
LGTM with nits
Change:
the client has advertised or a Push ID which has already been promised as a connection error of type HTTP_MALFORMED_FRAME. <ins> If a PUSH_PROMISE frame is received on either control stream, the recipient MUST respond with a connection error (errors) of type HTTP_WRONG_STREAM. </ins> See server-push for a description of the overall server push mechanism.

Discussion:
All other frame types in section 4 explicitly call out which stream types are allowed. For example DATA: If a DATA frame is received on either control stream, the recipient MUST respond with a connection error (Section 8) of type HTTPWRONGSTREAM.
FWIW this is explained in section 5. But I agree that conistency in the frame descriptions could help.
Change:
with this trust decision.  Some of the ones that are highlighted here are: <del> One area that has been getting exposure is traffic analysis of encrypted messages based on the length of the message.  This specification does not provide for a uniform method of providing padding as part of the message structure.  An observer can distinguish between two different messages (for example, 'YES' and 'NO') based on the length for all of the content encryption algorithms that are defined in I-D.ietf-cose-rfc8152bis-algs document.  This means that it is up to the applications to document how content padding is to be done in order to prevent or discourage such analysis.  (For example, the text strings could be defined as 'YES' and 'NO '.) </del> <ins> Analysis of the size of encrypted messages can provide information about the plaintext messages.  This specification does not provide a uniform method for padding messages prior to encryption.  An observer can distinguish between two different messages (for example, 'YES' and 'NO') based on the length for all of the content encryption algorithms that are defined in I-D.ietf-cose-rfc8152bis-algs.  This means that it is up to the applications to specify how content padding is to be done to prevent or discourage such analysis.  (For example, the text strings could be defined as 'YES' and 'NO '.) </ins> 7.

Discussion:
Remove the sections from the Examples Applenix that were blank, clean up the Security Considerations, and narrow the table in the IANA considerations.
Looks good to me! Thanks! Let us know if you want us to merge it or you plan to do that yourself.
Change:
an HTTP request. When HTTP Datagrams are conveyed on an HTTP/3 connection, the QUIC <del> DATAGRAM frame can be used to achieve these goals, including unreliable delivery; see format.  Negotiating the use of QUIC DATAGRAM frames for HTTP Datagrams is achieved via the exchange of HTTP/3 settings; see setting. </del> <ins> DATAGRAM frame can be used to provide demultiplexing and unreliable delivery; see format.  Negotiating the use of QUIC DATAGRAM frames for HTTP Datagrams is achieved via the exchange of HTTP/3 settings; see setting. </ins> When running over HTTP/2, demultiplexing is provided by the HTTP/2 framing layer, but unreliable delivery is unavailable.  HTTP

Discussion:
To what does "these goals" refer? Original: When HTTP Datagrams are conveyed on an HTTP/3 connection, the QUIC DATAGRAM frame can be used to achieve these goals, including unreliable delivery; see
yeah, this text seems weird. Perhaps
Or how about simply
I made typos in my suggestion that doesn't help, sorry. IIRC the original text is a roundabout way of saying - we use a special payload in QUIC datagrams in order to achieve unreliable datagram multiplexing. This makes more sense in the context of the next that then states HTTP/2 frames provide demultiplexing.
Right, how about