jiebi/CodeConvo huggingface dataset:
Change:
Binding (SVCB) records for DNS Servers, defined by I-D.schwartz-svcb- dns. <del> The following is an example of an SVCB record describing a DoH server: </del> <ins> The following is an example of an SVCB record describing a DoH server discovered by querying for "_dns.example.net": </ins> <del> The following is an example of an SVCB record describing a DoT server: </del> <ins> The following is an example of an SVCB record describing a DoT server discovered by querying for "_dns.example.net": </ins> If multiple Designated Resolvers are available, using one or more encrypted DNS protocols, the resolver deployment can indicate a preference using the priority fields in each SVCB record I-D.ietf- dnsop-svcb-https. <ins> To avoid name lookup deadlock, Designated Resolvers SHOULD follow the guidance in Section 10 of RFC8484 regarding the avoidance of DNS- based references that block the completion of the TLS handshake. </ins> This document focuses on discovering DoH and DoT Designated Resolvers.  Other protocols can also use the format defined by I- D.schwartz-svcb-dns.  However, if any protocol does not involve some

Discussion:
This PR addresses issues and to ensure smoother implementation and deployment (avoid name resolution deadlock and clearly illustrate why "." cannot be used for target names when discovering Designated Resolvers using the URL SUDN).
The existing examples in the document all use the "." for the SvcDomainName. Per the SVCB draft section 2.5.2, this would mean that queries for the SUDN that contain this value (".") would mean that the DoH template should use the SUDN as the domain name. While the examples do not query the SUDN, meaning the examples themselves are not erroneous, there is no useful example of the SUDN case. We need to add some examples showing an SUDN query response that carries the DoH domain name in the SvcDomainName field instead of the ".".
RFC8484 section 10, para 3 talks about the need for servers to ensure client do not need DNS lookups to validate the server's certificate to avoid deadlocks. DDR should reference this and reaffirm the need to have resolvers help clients avoid this deadlock.
Thanks! These examples are very useful!
Change:
value: 0 (default) for disabled. Endpoints use 2-bits in the value field for negotiating one or more <del> PN spaces, available option value for client and server are listed in </del> <ins> PN spaces, available option values are listed in </ins> param_value_definition : <del> If the parameter is absent or set to 0, the endpoints MUST fallback to QUIC-TRANSPORT with single path and MUST NOT use any frame or mechanism defined in this document. </del> <ins> If for any one of the endpoints the parameter is absent or set to 0, or if the two endpoints select incompatible values, one proposing 0x1 and the other proposing 0x2, the endpoints MUST fallback to QUIC- TRANSPORT with single path and MUST NOT use any frame or mechanism defined in this document. If an endpoint proposes the value 0x3, the value proposed by the other is accepted.  If both endpoints propose the value 0x3, the value 0x2 is negotiated. </ins> If endpoint receives unexpected value for the transport parameter "enable_multipath", it MUST treat this as a connection error of type

Discussion:
The current text assumes that the server transport parameters are composed after seeing the client's proposal. As pointed out in issue , this is a deviation from standard QUIC practice. The proposed text fixes that and specifies what happens if both endpoints select option 3, "support both". In that case, option 2 "multiple number spaces" is selected.
In Section 2 you define a transport parameter and set of values. These are presented in a table with a column header "Allowed server responses", what does that mean? One way to read this is that it implies servers would tailor their Transport Parameters to the value sent by the client but that's conflicting with our philosophy that TPs are unilateral declarations, not active negotiation. So the question for me is, is this just a wording issue or a design one?
I think this mainly means that server are not allow to send 0x3. However, if the client sends 0x3, the server's reply will impact the client behaviour for 1-RTT packets. Is that a negotiation? However, keep in mind that the intention is not to publish this as it.
unilateral negotiation is ok by me. If that's the intent then maybe just rewording of the table to be clariy it is a matrix of combinations is ok, and state somewhere that server 0x3 is illegal. do you mean not to adopt the draft with this type of TP, or the final RFC? I think better clarity is needed for implementation and experiementation as we try and answer the PN question
NAME that's my fault. I wrote that table based on my implementation, in which the server response does depend on the client proposal. We should replace it by a matrix showing what is expected if the client proposes 0-1-2-3 and the server 0-1-2-3. The only problematic case is "3 and 3", and we should simply state what happens there.
NAME please review PR
NAME thanks for the clarification, the new text makes the intent much more clear IMO.
Just to clarify, we are not intending to have this in the final RFC. We would like to have it adopted as it to enable more experimentation.
thanks NAME that also works for me!
LTGTM just 2 nits
Change:
usable by setLocalDescription; like createOffer, the returned description should reflect the current state of the system. <del> Calling this method may do things such as generate new ICE credentials, but does not trigger candidate gathering or change media state. </del> <ins> Calling this method may do things such as generating new ICE credentials, but does not trigger candidate gathering or cause a media state change.  Specifically, the answer is not applied, and does not become the pending local description, until setLocalDescription is called. </ins> 4.1.8.

Discussion:
NAME has given his thumbs up as well.
Originally raised by Christer Section 3.2 says: "To support this, the JSEP media layer can provide an offer via the createOffer() method whenever the Javascript application needs one for the signaling. The answerer can send back zero or more provisional answers, and finally end the offer-answer exchange by sending a final answer. The state machine for this is as follows:" 1) I would like to explicitly note that the generated offer is not applied (and any previously applied offer is not removed) until setLocalDescription() is called.
OK. In this case, we should note this for the provisional answers as well.
I thought about this for a while and came to the conclusion that this is the wrong place for such text; spelling everything out makes the overall message less clear. If we need to be super-prescriptive about the fact that the offer does not take effect until after setLD is called, we should state this in the createOffer/Answer sections (4.1.5/4.1.6), not here. NAME PTAL.
Will update document according to my last comment.
See PR
PR looks ok.
Change:
block traffic, and some method to alert the user.  Common methods of alerting the user involve modifying HTTP or DNS traffic. <del> This document standardizes an architecture for implementing captive </del> <ins> This document describes an architecture for implementing captive </ins> portals while addressing most of the problems arising for current captive portal mechanisms.  The architecture is guided by these principles:

Discussion:
The document is informational. We had some language implying that it intended to be standards-track. Rephrase.
S. Moonesamy writes:
Joel Halpern also pointed this out in the genart review.
Change:
proposals to use in describing how new technologies address or avoid these existing observed problems. <del> 1.1. Note to RFC Editor: Please remove this section before publication (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). </del> 2. 2.1.

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:
models must adhere to and comply with the SACM information model. The requirements for the SACM information model include: <del> Extensible Attribute Vocabulary: the information model MUST define </del> <ins> Extensible Attribute Vocabulary: The information model MUST define </ins> a minimum set of attributes for communicating Posture Information, to ensure interoperability between data models.  (Individual data models may define attributes beyond the mandatory-to-implement

Discussion:
Updates to address 3 of four open issues
Version -09 The document is not consistent if the character following the pithy title is capitalized. A pass needs to be made to fix this.
Hi Jim, I only found 1 straggler in IM-URL there are others please let me know so I can fold it into the -10 draft. Thanks, Nancy
Fixed in Pull request
-version 09 There are two nits that needs to be resolved. Missing 2119 boilerplate Reference to RFC 3444 exists, but is not referred to.
Hi Jim, Will fix in -10 draft..... Thanks, Nancy
Fixed in Pull request
Change:
This section is to provide references to make it easier to review the development and discussion on the draft so far. <del> 1.2.1. </del> <ins> 1.3.1. </ins> This document is in the GitHub repository at:

Discussion:
Also move some expansions and references to first use.
From NAME -
Hi, NAME - We've been focused on what endpoints could do to improve streaming media performance, but it does seem helpful to point that out more clearly. Please see if is helpful.
Change:
association between each endpoint and the Key Distributor as shown the following figure.  The DTLS association between endpoints and the Key Distributor will enable each endpoint to receive E2E key <del> information, Key Encryption Key (KEK) information (i.e., EKTKey), and HBH key information.  At the same time, the Key Distributor can </del> <ins> information, Key Encryption Key (KEK) information (i.e., EKT Key), and HBH key information.  At the same time, the Key Distributor can </ins> securely provide the HBH key information to the Media Distributor. The key information summarized here may include the SRTP master key, SRTP master salt, and the negotiated cryptographic transform.

Discussion:
This is a first-draft at sections to help clarify key usage and packetization format.
Overall this looks like pretty good and I think much of what I don't like could be fixed simply by deleting two sub sections.
Impressive you were able to put "Overall this looks like pretty good" and "much of what I don't like" into the same sentence. :) OK, I'll remove the section(s) with the steps. It gets a bit into the weeds, though it might be useful to figure out how to replace this. The issue is I hear people getting confused over how to use the keys. That's why I thought that an informative section might help. A library hides all this, but if you're writing the library, you need to understand these steps. I'll leave this here until the weekend (or later this week), as I have other stuff to get done. But, I'll come back to it.
I just pushed a set of changes, squashing the changes into a single PR. Otherwise, the changes look to be even larger than they really are since I removed many additions from the first commit.
LGTM
Change:
Initial contents: The fields and descriptions defined in account- objects. <ins> | Field Name | Field Type | Requests | Reference | |:-----------------|:-----------|:---------|:-------| ======= | status | string | new, account | RFC 8555 | | contact | array of string | new, account | RFC 8555 | | externalAccountBinding | object | new | RFC 8555 | | termsOfServiceAgreed | boolean | new | RFC 8555 | | onlyReturnExisting | boolean | new | RFC 8555 | | orders | string | none | RFC 8555 | </ins> 9.7.2. The "ACME Order Object Fields" registry lists field names that are

Discussion:
From Section 7.3: "MUST URL account bodies sent by the URL other fields that it does not recognize" in the first paragraph seems to be unnecessarily repeated by "MUST ignore any fields in the request object that it does not recognize" in the second paragraph. This PR merges these two paragraphs and discards the duplicated text. Also, "account bodies" isn't used anywhere else in the document, so this PR changes it to "account objects".
This looks reasonable to handle in AUTH48.
the last part isn't purely editorial, but okay.
Change:
and/or pending remote description according to the rules defined for Trickle ICE.  The pair of MID and ufrag is used to determine the m= section and ICE candidate generation to which the candidate belongs. <del> If the MID is not present, the m= line index is used to look up the locally generated MID (see sec.applying-a-remote-desc), which is used in place of a supplied MID.  If these values or the candidate string are invalid, an error is generated. </del> <ins> If the MID is not present, the m= section index is used to look up the locally generated MID (see sec.applying-a-remote-desc), which is used in place of a supplied MID.  If these values or the candidate string are invalid, an error is generated. </ins> The purpose of the ufrag is to resolve ambiguities when trickle ICE is in progress during an ICE restart.  If the ufrag is absent, the

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:
inform a peer of the maximum amount of data that can be sent on a stream. <del> An endpoint that receives a MAX_STREAM_DATA frame for a receive-only </del> <ins> A MAX_STREAM_DATA frame can be sent for streams in the Recv state (see stream-send-states).  Receiving a MAX_STREAM_DATA frame for a locally-initiated stream that has not yet been created MUST be treated as a connection error of type STREAM_STATE_ERROR.  An endpoint that receives a MAX_STREAM_DATA frame for a receive-only </ins> stream MUST terminate the connection with error STREAM_STATE_ERROR. <del> An endpoint that receives a MAX_STREAM_DATA frame for a send-only stream it has not opened MUST terminate the connection with error STREAM_STATE_ERROR. Note that an endpoint may legally receive a MAX_STREAM_DATA frame on a bidirectional stream it has not opened. </del> The MAX_STREAM_DATA frame is as follows: MAX_STREAM_DATA frames contain the following fields:

Discussion:
URL the case where those streams are implicitly created. There's probably another state here if we were being entirely honest with ourselves to distinguish between a stream that has been created and one that has had frames sent for it, but this is already more complex than it needs to be.
NAME does this sound normal to you?
To clarify, I +1'd your suggestion. More clearly: "Looks good, but I would like you to accept Dimitri's suggestion before submitting this PR."
Ah, alright. I thought it was the other way around.
This LGTM. I was just about to file a similar issue when I saw this.
MAXSTREAMDATA should not be able to be transmitted on uni-directional until frames have been received on the same or a higher numbered stream of same type. Or until the stream is created for bidi streams. If this is not the case, a peer can force the initiator to track unbounded state and frames or risk frames being received when an endpoint is not ready to handle them. See discussion here URL
As I said in that discussion, I don't think there's an unresolved issue here. :
Sorry if that is the case. My impression was that you used it as an example to where we did not have such protection, and didn't care. I'll leave it open for now since the term "has not opened" is also a bit vague. Exactly what state must the sender be in for this to count? And what must the peer observe to conclude this?
This is a non-issue, with the clarifications in the PRs incoming. That is, you can only receive MAXSTREAMDATA for a stream that you have decided to open. At that point you have decided to track considerably more state than a flow control limit. We can leave this until or similar lands.
Thanks
LG minus Dimitri's suggestion
Change:
Association (CTA) who owns the Web Application Video Ecosystem (WAVE) project has published two important specifications. <del> 4.4.1. </del> <ins> 4.5.1. </ins> CTA-2066 specifies a set of media player events, properties, quality of experience (QoE) metrics and associated terminology for

Discussion:
This is in existing text, but I'd put a paragraph break after "Some receive-side ABR algorithms such as {{ELASTIC}} are designed to try to avoid this effect." and before "Another way to mitigate this effect is by the help of two simultaneous TCP connections, as explained in {{MMSys11}} for Microsoft Smooth Streaming. In some cases, the system-level TCP slow-start restart can also be disabled, for example as described in {{OReilly-HPBN}}."
Works for me. Updated...
The editors are 2:1 in favor of dropping ECN. Spencer is graciously in the rough. We should be talking more broadly about what happens when you lose any packets, If ECN belongs in the draft, it belongs somewhere else. "Coming improvements in transport behaviors" more broadly - we're talking about BBR and about end-to-end transport encryption now. Maybe we should talk about things like edge computing, etc ... but NAME will talk to the working group about this before we start a major refactor.
The point of these sections (4.3.1 Idle Time Between Segments and 4.3.2 Head of Line Blocking) was to explain how and why your bandwidth measurements can go wrong when you're trying to do ABR things with your bandwidth measurements. By name this seems like perhaps a better fit in the 4.4 Measurement Collection section, there might be a reason to merge some of the discussion there or reorganize the 2 sections together.
We maybe should also add a section along these lines on the wide variability in bitrates as things move, both for wi-fi and LTE and 5g. (or paths in general, with those as examples?)
Note also: "Refactor" here means provide a coherent story for why your ABR measurements can go wrong and what you can do about it.
Change:
3.1. A JSONPath query is a string which selects zero or more nodes of a <del> piece of JSON. </del> <ins> JSON value. </ins> A query MUST be encoded using UTF-8.  The grammar for queries given in this document assumes that its UTF-8 form is first decoded into

Discussion:
Fixes URL
NAME :
It depends. For example, the APIs of some JSONPath implementations take a rich type which represents a valid JSON value. In that case, handling invalid JSON happens before the API is called and is not a concern of the API. But other implementations could have an API which takes a string, which may or may not represent valid JSON. So, to be clear, we probably need some words in the spec which says the spec does not prescribe how invalid JSON is handled. This is better than silence. Or we could require that invalid JSON cannot result in a non-empty nodelist from a JSONPath query.
NAME But "brokenness" would apply to JSON texts, wouldn't it? As NAME noted in (URL), "JSON text is a sequence of characters, an unparsed piece of JSON for interchange, with newlines and backslashes and all that. JSONPath never looks at JSON texts. JSON value is the RFC 8259 term for what JSONPath looks at." The parser would care about "broken" JSON texts, but JSONPath should never see them.
Agree with last two points. The spec describes the application of a JSONPath expression to parsed JSON, so JSON texts are out-of-scope. As NAME says, we should make that explicit.
JSON Schema simply that it operates on the JSON data model. This section covers a range of issues that we've found in our history, including handling whitespace differences, duplicate keys, etc. I think this is a great approach.
Thanks!
Change:
identifying the interfaces between these protocols and both transport protocols and applications.  It examines Transport Layer Security (TLS), Datagram Transport Layer Security (DTLS), IETF QUIC, Google <del> QUIC (gQUIC), tcpcrypt, Internet Key Exchange with Encapsulating Security Protocol (IKEv2 + ESP), SRTP (with DTLS), WireGuard, CurveCP, and MinimaLT.  For each protocol, this document provides a brief description.  Then, it describes the interfaces between these protocols and transports in transport-interface and the interfaces between these protocols and applications in application-interface. </del> <ins> QUIC (gQUIC), tcpcrypt, Internet Protocol Security (IPsec), SRTP (with DTLS), WireGuard, CurveCP, and MinimaLT.  For each protocol, this document provides a brief description.  Then, it describes the interfaces between these protocols and transports in transport- interface and the interfaces between these protocols and applications in application-interface. </ins> Selected protocols represent a superset of functionality and features a Transport Services system may need to support, both internally and

Discussion:
Address
URL Hi, I concur. However, I'd suggest changing the title of the section from "IKEv2 with ESP" to "IPsec". Regards, Valery.
Change:
described property actually a property of the endpoint and not a property of a particular resource, in which case it should go into the payload of the registration and need not be registered?), and the <del> potential for conflict with commonly used link attributes (For </del> <ins> potential for conflict with commonly used target attributes (For </ins> example, "if" could be used as a parameter for conditional registration if it were not to be used in lookup or attributes, but would make a bad parameter for lookup, because a resource lookup with an "if" query parameter could ambiguously filter by the registered <del> endpoint property or the RFC6690 link attribute).  It is expected </del> <ins> endpoint property or the RFC6690 target attribute).  It is expected </ins> that the registry will receive between 5 and 50 registrations in total over the next years.

Discussion:
None of those meant any of (anchor,rel,rev), and all the other attributes that come from serializations should be called by what they are. Closes: URL
Working with RFC8288 in CoRAL I noticed that we're a bit sloppy on some concepts of web linking. This manifests in two related issues: We're talking of link attributes, where that's a term nowhere defined. (Used by RFC6690, but possibly they mean "attributes of CoRE links" and not "Core's use of link attributes", and even there only in the chapter name.) The information model we describe is more the model of the serialized data; the data model makes no distinction, for example, between and . The latter is something we can IMO let slide on account of practical readers having both in mind. The former poses the danger of aggravating the careless use of "link attributes" that'd describe the link-as-a-whole (something not covered by the data model, and thus incompatible with different serializations), but can easily be fixed in a search-and-replace PR coming right up.