jiebi/CodeConvo huggingface dataset:
Change:
example, if an application indicates a preference for a specific path by specifying an interface, but also a preference for a protocol, a situation might occur in which the preferred protocol is not <del> available on the preferred path.  In such cases, implementations SHOULD prioritize Selection Properties that select paths over those that select protocols.  Therefore, the transport system SHOULD race the path first, ignoring the protocol preference if a specific protocol does not work on the path. </del> <ins> available on the preferred path.  In such cases, applications can expect properties that determine path selection to be prioritized over properties that determine protocol selection.  The transport system SHOULD determine the preferred path first, regardless of protocol preferences.  This ordering is chosen to provide consistency across implementations, based on the fact that it is more common for the use of a given network path to determine cost to the user (i.e., an interface type preference might be based on a user's preference to avoid being charged more for a cellular data plan). </ins> Selection and Connection Properties, as well as defaults for Message Properties, can be added to a Preconnection to configure the

Discussion:
Section 4.2: " In such cases, implementations SHOULD prioritize Selection Properties that select paths over those that select protocols." I think I agree to this recommendation but it comes a little out of nowhere and we should probably provide some reasoning, especially as this is normative.
Proposing to change text to address the application developer: to expect that the path selection properties would be preferred over protocol selection properties. We should also explain a bit of the rationale, to explain that path properties are generally more sensitive around policy/expense.
Change:
protocol is similar to UDP proxying in HTTP, but allows transmitting arbitrary IP packets.  More specifically, this document defines a protocol that allows an HTTP client to create an IP tunnel through an <del> HTTP server that acts as a proxy.  This document updates RFC 9298. </del> <ins> HTTP server that acts as an IP proxy.  This document updates RFC 9298. </ins> 1.

Discussion:
In the abstract, the word 'proxy' is used without qualification. It would be better to use the term 'IP proxy'. In 4.3. HTTP/1.1 Response, 'abort the connection' is not typical usage (e.g., in RFC9112); suggest 'close the connection'.
Change:
15. This document requests the creation of the following new IANA <del> registries: MLS Ciphersuites (mls-ciphersuites).  All of these registries should be under a heading of "Messaging Layer Security", and assignments are made via the Specification Required policy RFC8126.  See de for additional information about the MLS Designated Experts (DEs). </del> <ins> registries: MLS Ciphersuites (mls-ciphersuites) MLS Extension Types (mls-extension-types) MLS Credential Types (mls-credential-types) All of these registries should be under a heading of "Messaging Layer Security", and assignments are made via the Specification Required policy RFC8126.  See de for additional information about the MLS Designated Experts (DEs). [[ RFC EDITOR: Please replace XXXX throughout with the RFC number assigned to this document ]] </ins> 15.1.

Discussion:
This started off just fixing , then grew a bit. Defines an IANA registry for ExtensionType values Defines an IANA registry for CredentialType values Updates the Ciphersuites registry to share formatting with the other two, and to be more explicit about its ties to HPKE algorithms Removes the unnecessary field from ... and as a result removes the definition of (which is used nowhere else)
Now that we have a more robust extension mechanism, we need to have an IANA registry to manage extensions, including: Registry structure Registry policy and (probably) designated experts Reserved vendor space
Change:
supply them to its ICE Agent.  This triggers the ICE Agent to start using the new remote candidates for connectivity checks. <del> When BUNDLE is in use, candidates (both in-SDP and trickle) are only exchanged for and associated with the m= section referenced by the sender's BUNDLE-tag, as described in I-D.ietf-mmusic-sdp-bundle- negotiation </del> 3.4.2.1. As with session descriptions, the syntax of the IceCandidate object

Discussion:
Change position of initial paragraph on handling of bundled m= sections; simplify some text; remove discussion of ICE restart option in answers.
NAME FYI
Change:
timer expires.  This is more aggressive than TCP's RTO mechanism when application-limited, but identical when not application-limited. <del> A single packet loss at the tail does not indicate persistent congestion, so QUIC specifies a time-based definition to ensure one or more packets are sent prior to a dramatic decrease in congestion window; see persistent-congestion. </del> <ins> QUIC allows probe packets to temporarily exceed the congestion window whenever the timer expires. </ins> 4.8.

Discussion:
and part of
Alissa Cooper said:
NAME said:
Good point, also 4.7 currently has TLP in the title, but doesn't use it anywhere else in the section, so I'll add some text on TLP too. URL
Please also update the RACK reference to version 14. draft-ietf-tcpm-rack-14
The version update is part of the toolchain we use, so the newest version of RACK should be referenced automatically.
Change:
value, it has exactly the same value as the original Number.  For the version number, only an unsigned integer is allowed. <ins> Characters in the String Value are encoded using a definite length text string (type 3).  Octets in the Data Value are encoded using a definite length byte string (type 2) . </ins> For compactness, the CBOR representation uses integers for the map keys defined in tbl-cbor-labels.  This table is conclusive, i.e., there is no intention to define any additional integer map keys;

Discussion:
I think that the current SenML draft is missing a note on JSON/CBOR differences in Data Value: While it is explicitly stated that vd is a base64 string in JSON and a binary-value in CBOR, the supposedly exhaustive list of differences in 6. fails to mention that no base64 encoding is done in CBOR. Suggested addition: o For Data Values, no base64url-encoding is done, as the data can be directly expressed as binary-value. Furthermore, I suggest that "Characters in the Data Value are base64 encoded" be expressed as "Bytes [...]" or "Octets are encoded [...]", to make the distinction to the character-based strings and binary data clearer. (The only context in which I'd name bytes of binary data "Character" are when speaking of a "char" in C). Best regards Christian
Indeed, characters should be called characters, and bytes should be called bytes. (In C, bytes are represented as uint8_t :-). s/can be/are/ (they are!)
Have a read of the PR I put in for this. I think it resolves the issue
Looks good to me (with the one typo fix)
typo fix
Change:
the certificate) as long as the IP address of the Encrypted DNS Resolver does not differ from the IP address of the Unencrypted DNS Resolver.  Clients SHOULD use this mode only for resolvers using <del> private or local IP addresses. </del> <ins> private or local IP addresses, since resolvers that use other addresses are able to provision TLS certificates for their addresses. </ins> 5.

Discussion:
NAME please check!
I think there are way too many bald SHOULDs in this document. Since SHOULD presents an implementer with a choice, it's usually a good idea to describe that choice rather than presenting something that looks like "you really should do this, but it's probably fine if you don't" and moves on. To wit: An example of one that could use improvement is the first one in Section 4, as I've no idea why you would not always do what it says. An example of one that does provide such guidance is the second one in Section 4, where I understand the consequences of not doing what it says.
LGTM!
Change:
zero.  Whether or not it implements this method, the server MUST NOT reuse a nonce until it switches to a configuration with new keys. <del> Both the Plaintext CID and Block Cipher CID algorithms send parts of their nonce in plaintext.  Servers MUST generate nonces so that the plaintext portion appears to be random.  Observable correlations </del> <ins> Both the Plaintext CID and Encrypted Long CID algorithms send parts of their nonce in plaintext.  Servers MUST generate nonces so that the plaintext portion appears to be random.  Observable correlations </ins> between plaintext nonces would provide trivial linkability between individual connections, rather than just to a common server.

Discussion:
Some have noted that "Stream Cipher" is now a misnomer. So this PR renames them.
Change:
The delivery service will return one or more client init key bundles, one for each member. <del> OPEN QUESTION: What if different clients have different cipher suites? </del> 6. 6.1.

Discussion:
This should give you the same GitHub pages website as mls-protocol. One this is merged, someone with push access to the repo will need to run: It doesn't look like Pages it on. You can try turning it off and back on in the Settings tab and that will trigger a new deploy. Leave the domain for Pages as the default, not "URL" or something similar
NAME Do you mind reviewing?
NAME Can you follow the instructions in the PR description please
Change:
11. <del> Please update the "Media Types" registry at </del> <ins> IANA are request to update the "Media Types" registry at </ins> https://www.iana.org/assignments/media-types [1] with the registration information in media-types for the media types "message/ ohttp-req", "message/ohttp-res", and "application/ohttp-keys". <ins> IANA are requested to create a new entry in the "HTTP Problem Type" registry established by PROBLEM. </ins> 12.  References 12.1.  URIs

Discussion:
This includes the time correction piece. I'm interested in whether people think that it is OK to include that. The section could be removed along with the corresponding IANA piece, but given the prevalence of clock skew, I'm inclined to leave it in.
The picture might help, but it is also a lot of vertical real estate to dedicate to this. Let's see if I can't compress it a little.
Maybe an alternative style is to just list the happy path actions in a list? Client sends request, gets back response with 4xx and date header, retires request with new HPKE context, and then stops based on response, or something. These four simple steps are just spread across a lot of lines right now. But this is purely editorial, so I trust your judgement here.
There is a bunch of stuff that we normatively depend on regarding the use of Date. As it seems like request-date isn't going anywhere, we should pull in the relevant pieces instead.
That sounds reasonable like a reasonable way to unblock us and make forward progress.
Addressed by .
This LGTM. I wonder if it would be helpful to show the retry dance in a picture. Something like:
Change:
Handshake state updates <del> Additional functions might be needed to configure TLS. </del> <ins> Additional functions might be needed to configure TLS.  In particular, QUIC and TLS need to agree on which is responsible for validation of peer credentials, such as certificate validation (RFC5280). </ins> 4.1.1.

Discussion:
Important enough to call out in this section.
Roman Danyliw said:
I think that we're OK, and the text added in should help avoid any need for this point.
NAME said:
Should we split this bit out into a separate issue? per §4.8 TLS alerts are translated into QUIC connection errors and are not sent natively. (The prose also says "TLS Handshake and Alert messages are carried directly over the QUIC transport".)
I don't think we need to do anything in response to that. Those messages are carried by QUIC.
I will defer to your preference, but I do not agree that "those messages" are carried by QUIC; QUIC does not carry TLS Alert structures.
a nit but lgtm
Change:
(Section 8.7 of I-D.ietf-httpbis-semantics), which holds a URL.  This is also known as the representation's URL. <del> Multiple representations within a bundle can have the same URL, in which case they are distinguished by the content negotiation information contained in their "Variants" and "Variant-Key" headers (I-D.ietf-httpbis-variants). </del> This identifying information for each representation is stored in an index (index-section) rather than in that representation's HTTP response message.

Discussion:
This PR removes content negotiation from the spec. It is more efficient to use content negotiation on the server to select which bundle to send, rather than including several variants in the bundle and having that negotiation happen on the client's side. Issue: URL Adapted from URL
Now that the working group has adopted the document, we actually need them to approve significant changes like this one, not me. We can check on this one during the IETF meeting .
Moved from NAME URL It's more efficient to use content negotiation to select which bundle to serve, rather than including several variants of a resource inside a bundle. Even most use cases around re-sharing bundles while offline can get away with including a single least-common-denominator resource. I only know of the case of translations that concretely need several variants of the same resource. Can we simplify the design by omitting content negotiation? We'd lose some fidelity in representing HTTP, but that might be acceptable.
I"m fine to remove the variants support from the bundle format, however, I'm wondering how removing the variants support impacts on the chromium's implementation. We should align somehow. NAME NAME Do you know any use case of variants? Can we remove variants support from the bundle format without any impacts on the chromium?
Chromium supports variants in Navigation to Web Bundles (URL), but not in Subresource loading with Web Bundles. Since Navigation to Web Bundles hasn't shipped yet, I think it's fine to remove it from Chromium.
If we remove the content negotiation, it may become difficult to support new data formats like WebP in future. But removing it from the bundle format now and re-thinking when it will be more important sounds acceptable.
The idea here is that you would negotiate for the whole bundle, not for resources within the bundle. I think this could permit upgrade to new image formats over time, without shipping all the different options redundantly to the client.
I think we can close this issue. Content negotiation was already dropped.
Thanks for making a PR! Per the discussion URL, the chromium side is okay to remove content negotiation. We probably have to change parser's behavior by checking a bundle's version. That should not be a significant issue for us. We might want to wait for NAME 's approval before merge.
Change:
object.  The set of parameters for RTCAnswerOptions is different than those supported in RTCOfferOptions; the IceRestart option is unnecessary, as ICE credentials will automatically be changed for all <del> m= lines where the offerer chose to perform ICE restart. </del> <ins> m= sections where the offerer chose to perform ICE restart. </ins> The following options are supported in RTCAnswerOptions.

Discussion:
S 5.2.1 says: Attributes that are common between all m= sections MAY be moved to session-level, if explicitly defined to be valid at session-level. This seems like it would be better as a should
Discussed in DC: Some concerns that things that appear at the session level have, in the past, missed by bad implementations.
Dc - decdie to change to SHOULD NOT and for things that are big, like idientiy, will put MUST
Change:
"pto_expired" // draft-23 section 5.3.1, MAY <del> 5.4.7. </del> <ins> 5.4.6. </ins> Importance: Extra

Discussion:
Not 100% sure this is enough for all the latest draft-27(+) changes though, added a TODO in the draft for that purpose. Also added a packetnumberspace field to metrics_updated to be flexible for implementations that don't want to implement all types of events. It's not a great fit at that location, but it seemed the most synergistic without having a completely new event type. PTAL NAME
Currently, we log in . However, we can have multiple PTO's running across multiple PN spaces and there is no proper way to correlate them with a PN space in metricsupdated. This also impacts the event types. Possible resolutions: Add pnspace attribute to Split PTO count into a separate event (potentially merge with loss_timer?) TODO: reason more about how these metrics are tied to PN spaces in general (are there others than PTO that are duplicated) cc NAME
Most other metrics in the event are independent of the PN space, so that would be weird. I'd prefer to do that. Not sure if it makes sense to merge is with the loss timer events, since we also need to be able to log a reset of the PTO count to 0 (which doesn't require setting of a timer).
Change:
5. <del> (TBD; these mappings need to be further verified in implementation work.) </del> <ins> The material in this section is non-normative, provided as guidance to developers who want to use I-Regexps in the context of other regular expression dialects. </ins> 5.1. <ins> Common multi-character escapes (MCEs), and character classes built around them, which are not supported in I-Regexp, can usually be replaced as shown in tbl-sub. Note that the semantics of "d" in XSD regular expressions is that of "p{Nd}"; however, this would include all Unicode characters that are digits in various writing systems, which is almost certainly not what is required in IETF publications. The construct "p{IsBasicLatin}" is essentially a reference to legacy ASCII, it can be replaced by the character class "[u0000-u007f]". 5.2. </ins> Any I-Regexp also is an XSD Regexp XSD-2, so the mapping is an identity function.

Discussion:
Signed-off-by: Tim Bray Based on our email thread with James, and a couple of minor editorial touch-ups.
LGTM, thanks.
Change:
4. <del> Note to RFC Editor: Please remove this section before publication TBD: suggestion from mic at IETF 106 (Mark Nottingham): dive into the different constraints coming from different parts of the network or distribution channels. (regarding questions about how to describe the disconnect between demand vs. capacity, while keeping good archival value.) https://www.youtube.com/watch?v=4_k340xT2jM&t=13m TBD: suggestion from mic at IETF 106 (Dave Oran + Glenn Deen responding): pre-placement for many use cases is useful-distinguish between live vs.  cacheable.  "People assume high-demand == live, but not always true" with popular netflix example. (Glenn): something about latency requirements for cached vs. streaming on live vs.  pre-recorded content, and breaking requirements into 2 separate charts.  also: "Standardized ladder" for adaptive bit rate rates suggested, declined as out of scope. https://www.youtube.com/watch?v=4_k340xT2jM&t=14m15s TBD: suggestion at the mic from IETF 106 (Aaron Falk): include industry standard metrics from citations, some standard scoping metrics may be already defined.  https://www.youtube.com/ watch?v=4_k340xT2jM&t=19m15s </del> <ins> Note to RFC Editor: Please remove this section and its subsections before publication. This section is to provide references to make it easier to review the development and discussion on the draft so far. 4.1. (To the editor: check this repository URL after the draft is adopted. The working group may create its own repository) This document is in the Github repository at https://github.com/GrumpyOldTroll/ietf-mops-drafts.  Readers are welcome to open issues and send pull requests for this document. Substantial discussion of this document should take place on the MOPS working group mailing list (mops@ietf.org). 4.2. Presentations: IETF 105 BOF: https://www.youtube.com/watch?v=4G3YBVmn9Eo&t=47m21s IETF 106 Mops meeting: https://www.youtube.com/ watch?v=4_k340xT2jM&t=7m23s List archive search for doc mentions: https://mailarchive.ietf.org/arch/browse/mops/?q=draft-ietf-mops- streaming-opcons </ins> 5.

Discussion:
consolidated venue and history sections, moved TBDs to issues list and removed from draft, added a few links to help reviewers Any changes anyone would like to see, or does this work? I propose that any of us other than the pull-requester should feel free to merge it if they're happy with it and nobody has objected in a reasonably short time, or of course to suggest improvements.
Change:
3.2. <del> RFC8441 defines an extended CONNECT method in Section 4, enabled by </del> <ins> RFC8441 defines an extended CONNECT method in features, enabled by </ins> the SETTINGS_ENABLE_CONNECT_PROTOCOL parameter.  An endpoint does not need to send both SETTINGS_ENABLE_CONNECT_PROTOCOL and SETTINGS_ENABLE_WEBTRANSPORT; the SETTINGS_ENABLE_WEBTRANSPORT

Discussion:
There was a local reference that was just typed out. The references to other documents cargo-culted from QUIC, but that only works if the documents are in the same repo. You have to pull references from the datatracker. Use the nice reference format in a few places.
Change:
Endpoint name (optional).  Used for endpoint, group and resource lookups. <del> Domain (optional).  Used for domain, group, endpoint and resource lookups. </del> <ins> Domain (optional).  Used for group, endpoint and resource lookups. </ins> gp := Group name (optional).  Used for endpoint, group and resource lookups.

Discussion:
This is the documenting text to the changes worked out first on the examples in . It does not (yet) contain explaining overall text, but updates the various smaller mentions of the parameter to fit together. It does change the semantics of using on a registration update, but I believe that the previous wording was not what the original authors had intended. (Previously, an endpoint registering over TCP would need to explicitly repeat its con on every update).
Change:
Reference, which is a link to the document defining this flag. The policy for this shall be "Specification Required" as described in <del> RFC8126. </del> <ins> RFC8126 with the exception of flags numbered from 0-15, which follow the "Standards Action" policy (RFC8126).  Designated expert(s) are advised to follow the advice in RFC8447 when reviewing registration requests. </ins> The initial contents of the registry shall be one entry, as follows:

Discussion:
No other advice is needed.
My interpretation of these is that these reduce to something like: 0-31 - standards action 32-63 - ??? (something like RFC Required or maybe Specification Required) 64-79 - might as well burn these for all the good they will do 80+ - open season (FCFS?) I can see the rationale for standards action here, but the rest of this should just be expert review (or specification required) along with guidance to experts. As this requires judgment, and the proponents of a new flag will lack the necessary perspective to have good judgment, a lot does depend on the nature of the guidance to experts. The document will need to provide experts with support that they can rely on: right now, the text does not do that. It relies too heavily on good judgment. If there is concrete advice that can be given about how to pick a value, then the document should do that. If it can't, as I suspect is the case, then it should either give experts the power to pick or just let authors grab for short values.
All TLS registries are "expert review" with no FCFS. I don't think we want this one to be the outlier. So how about making the segmentation in section 4, something like Then I can reduce the content of section 4.1 and just advise the expert to assign the first 7 bits only with a specific request from the WG. I don't want to specify the TLS working group, because something like this could potentially (though not likely) come from UTA or some such.
I don't think that sequential assignment has worked well for us. I would remove that part and maybe change the assignment rule to be "at the discretion of the expert" across the board, with a reminder that small values are more valuable and so should be reserved for things that are going to be used more often.
Fixed by .