jiebi/CodeConvo huggingface dataset:
Change:
3. <ins> This specification uses the tls_flags extension defined in I-D.-ietf- tls-tlsflags to allow a client and a server to negotiate support for this extension. The RRC flag is assigned the value (TBD1) and is used in the ClientHello (CH) and the ServerHello (SH). 4. </ins> When a record with CID is received that has the source address of the enclosing UDP datagram different from the one previously associated with that CID, the receiver MUST NOT update its view of the peer's IP

Discussion:
Updated draft based on feedback from the working group. The following changes have been made: Usage of the TLS flags extension Enhanced IANA consideration section Expanded example section
added a few inline suggestions
Change:
version: 0, 2").  When sent by the proxy, it contains a single draft number selected by the proxy from the list provided by the client (e.g., "connect-udp-version: 2").  Sending this header is RECOMMENDED <del> but not required. </del> <ins> but not required.  Its ABNF is: </ins> 4.

Discussion:
The doc has a development versioning header but it omits the ABNF. The format is described as a list of values on request headers and a single item on response headers. I'm going to assume this is an sf-list, can we state that to avoid uncertainty?
Change:
Oblivious Relay Resource forwards the response according to the rules of an HTTP proxy; see HTTP. <ins> In order to achieve the privacy and security goals of the protocol an Oblivious Relay Resource also needs to observe the guidance in relay- responsibilities. </ins> An Oblivious Gateway Resource, if it receives any response from the Target Resource, sends a single 200 response containing the encapsulated response.  Like the request from the client, this

Discussion:
So add some forward references.
Sections 6.1, 6.2 and 6.3 detail normative requirements that seem to apply to the actors duties outlined in section 5. Consider forward references to each respective section to aid implementers in discovery applicable considerations.
Change:
be configured to present the appropriate TLS certificate when no SNI is present for both DoT and DoH. <ins> 6.4. Discovery of network-designated resolvers (DNR, I-D.ietf-add-dnr) allows a network to provide designation of resolvers directly through DHCP RFC2132 RFC8415 and IPv6 Router Advertisement (RA) RFC4861 options.  When such indications are present, clients can suppress queries for "resolver.arpa" to the unencrypted DNS server indicated by the network over DHCP or RAs, and the DNR indications SHOULD take precedence over those discovered using "resolver.arpa" for the same resolver if there is a conflict. The designated resolver information in DNR might not contain a full set of SvcParams needed to connect to an encrypted resolver.  In such a case, the client can use an SVCB query using a resolver name, as described in encrypted, to the authentication-domain-name (ADN). </ins> 7. Since clients can receive DNS SVCB answers over unencrypted DNS, on-

Discussion:
From WGLC, Med wrote:
Also, a suggestion to say: use DDR to discover details about all supported encrypted DNS protocols. This situation can arise if a client has been configured to use a given Encrypted Resolver, or if a network provisioning protocol (such as DHCP or IPv6 Router Advertisements) provides a name for an Encrypted Resolver alongside the resolver IP address.
Change:
bounds, or cannot be applied, processing MUST stop and an error MUST be returned. <del> TODO </del> <ins> If this media section is new, begin gathering candidates for it, as defined in RFC5245, Section 4.1.1, unless it has been marked as bundle-only. Or, if the ICE ufrag and password values have changed, trigger the ICE Agent to start an ICE restart and begin gathering new candidates for the media section, as defined in RFC5245, Section 9.1.1.1, unless it has been marked as bundle-only. If the media section proto value indicates use of RTP: If RTCP mux is indicated, prepare to demux RTP and RTCP from the RTP ICE component, as specified in RFC5761, Section 5.1.1. If RTCP mux is not indicated, but was indicated in a previous description, this MUST result in an error. For each specified RTP header extension, establish a mapping between the extension ID and URI.  If any indicated RTP header extension is unknown, this MUST result in an error.  [TODO: ref] If the MID header extension is supported, prepare to demux RTP data intended for this media section based on the MID header extension.  [TODO: ref] For each specified payload type, establish a mapping between the payload type ID and the actual media format.  [TODO: ref] If any indicated payload type is unknown, this MUST result in an error. For each specified "rtx" media format, establish a mapping between the RTX payload type and its associated primary payload type.  [TODO: ref] If any referenced primary payload types are not present, this MUST result in an error. If the directional attribute is of type "sendrecv" or "recvonly", enable receipt and decoding of media. </ins> Finally, if this description is of type "pranswer" or "answer", follow the processing defined in the sec.applying-an-answer section

Discussion:
Still have a bunch of stuff to flesh out, but wanted to get this out for initial review. NAME NAME
Looks like good stuff to me. - The text in start of section 5 seem fine for making it clear that this does not override the referenced specs.
Thanks for the comments. Ran out of time to resolve them today but will take another shot at it Saturday.
Updated based on comments. I'd like to go ahead and merge this ASAP, and then hopefully still get another rev in before the deadline.
I'm fine with merging what we have here right now.
The text relies on the phrase "most recent gathering phase" to describe which candidates are present in SDP. Justin enumerated a few cases where the browser gathers a completely new set of candidates for an m= section (or component thereof): when a new m= section is added (which happens for a new RTCPeerConnection obviously) when an m= section did have a port of 0, but is repurposed for new media (basically the same scenario as above) ICE restart This needs a clearer definition, or maybe just a single clear description of what it means to do this. This can probably tie into the whole process of describing when candidate events fire and the interaction between that and setLocalDescription.
Martin, could you give us a PR that would satisfy you
Change:
3. <del> During pre-establishment the application specifies the Endpoints to be used for communication as well as its preferences via Selection Properties and, if desired, also Connection Properties.  Generally, Connection Properties should be configured as early as possible, because they can serve as input to decisions that are made by the implementation (e.g., the Capacity Profile can guide usage of a protocol offering scavenger-type congestion control). </del> <ins> During pre-establishment the application specifies one or more Endpoints to be used for communication as well as protocol preferences and constraints via Selection Properties and, if desired, also Connection Properties.  Generally, Connection Properties should be configured as early as possible, because they can serve as input to decisions that are made by the implementation (e.g., the Capacity Profile can guide usage of a protocol offering scavenger-type congestion control). </ins> The implementation stores these properties as a part of the Preconnection object for use during connection establishment.  For

Discussion:
These are mostly wording changes for clarification. Feel free to cherry pick.
Can't find any problems here - this looks good.
This LGTM, many thanks!
Change:
This is "like a slave server except not listed in an NS RR for the zone."  (Quoted from RFC1996, Section 2.1) <del> A stealth server that is a master for zone transfers.  "In this arrangement, the master name server that processes the updates is unavailable to general hosts on the Internet; it is not listed in the NS RRset."  (Quoted from RFC6781, Section 3.4.3.)  An earlier RFC, RFC4641, said that the hidden master's name appears in the SOA RRs MNAME field, although in some setups, the name does not appear at all in the public DNS.  A hidden master can be either a secondary or a primary master. </del> <ins> A stealth server that is a primary server for zone transfers.  "In this arrangement, the master name server that processes the updates is unavailable to general hosts on the Internet; it is not listed in the NS RRset."  (Quoted from RFC6781, Section 3.4.3). An earlier RFC, RFC4641, said that the hidden master's name "appears in the SOA RRs MNAME field", although in some setups, the name does not appear at all in the public DNS.  A hidden master can also be a secondary server itself. </ins> The process of one server sending a DNS query with the RD bit set to 1 to another server to resolve that query.  Forwarding is a

Discussion:
Split into two pairs of commits (each first changing content and then line lengths) for easy partial acceptance, should that be desired: Improve grammar and diction Be consistent about ordering domain name labels from the root The second pair attempts to provide a consistent treatment of "domain name" as an abstract sequence of labels in directed graph order starting at the root, while maintaining clarity about wire, presentation, and common display formats rendering domain names in reverse.
Change:
state, the client instance can repeat the interaction process by sending a continue-modify with new request-interact methods. <ins> The AS SHOULD handle any interact request as a one-time-use mechanism and SHOULD apply suitable timeouts to any interaction start methods provided, including user codes and redirection URIs.  The client instance SHOULD apply suitable timeouts to any interaction finish method. </ins> 4.1. When a grant request is in the

Discussion:
Allows interaction responses from the AS to have an explicit timeout, with instructions on how the client instance can recover (do a modification).
To edit notification comments on pull requests, go to your .
When an AS creates a set of of interaction artifacts, like a user code or interaction URI, these artifacts aren't likely to be available perpetually. The AS will likely want to purge these after some time. It might be useful for the AS to indicate to the client a timeout for the "interact" return block so that the client has some idea of how much time it has to use the interaction methods.
Change:
"!@.foo" (which yields false if "@.foo" selects a node, regardless of the node's value). <del> 3.4.8.2.2. </del> <ins> 3.4.7.2.2. </ins> When a path resulting in an empty nodelist appears on either side of a comparison, the comparison yields true if and only if:

Discussion:
I want to take the opportunity of there being no PRs in flight to make this purely editorial change to the order of the spec. It avoids unnecessary forward references to the filter and list selectors.
Another PR opened and merged in less than 8 hours...
Please note this PR was purely editorial. It moved some text around. but didn't change it. (I was planning to merge this later today after a bit more time.)
We should just have a flat policy of 24 hrs for a PR to ensure everyone gets to see it. It doesn't matter if it was a spelling change. Everyone should have a chance to review it.
It's one thing to agree to this policy, which I think we have, and quite another to remember to apply it when one is focussed on other things. I've raised a about automating this check.
Have we? It is not policy I would normally agree to. Editors need to be able to do their work. Github is here to help, not to hinder.
Ah, my mistake: I agreed.
We have a two-week policy for PRs in JSON Schema and it's very helpful to encourage cooperation. I don't think 24 hrs is too much to ask.
Please explain how you did not get a chance to review this change.
The PR opened at 3AM and merged at 10AM. This is an insufficient window. 24 hrs, please. It's not a big request.
You have had time to review after merge. How is a merge such an important event?
If I have objections to a PR, they should be voiced before it's merged. Reviewing after the fact is pointless. Any damage has been done. This particular PR is not one of those cases, but in general, everyone involved should get a chance to review. Why are you so opposed to this? It's one day. That's all I'm asking.
Thanks!
Change:
The RD is primarily a tool to make discovery operations more efficient than querying /.well-known/core on all connected devices, <del> or across boundaries that would be limiting those operations. </del> <ins> or across boundaries that would limit those operations. </ins> It provides information about resources hosted by other devices that could otherwise only be obtained by directly querying the /.well-

Discussion:
Will merge before the interim to have a discussion on the big stuff with the small stuff out of the way.
Change:
Local Endpoint sends a keep-alive packet to the Remote Endpoint. Adjusting this Property will only take effect when the underlying stack supports sending keep-alive packets.  Guidance on setting this <del> value for datagram transports is provided in RFC8085.  A value </del> <ins> value for connection-less transports is provided in RFC8085.  A value </ins> greater than the connection timeout (conn-timeout) or the enumerated value "Disabled" will disable the sending of keep-alive packets.

Discussion:
The guidance applies to any connectionless transport.
"Connection establishment is only a local operation for a Datagram transport (e.g., UDP(-Lite))": I think the criterion is not Datagram transports but "transports without a handshake" or "connectionless protocols" as it is used later in the document.
I wrote, and I suggest we use "connectionless protocols" explicitly mentioning examples of UDP and UDP-Lite when used as a transport without a handshake.
To whoever plans to address this: I checked occurrences of the word "datagram" in the architecture and API drafts, and I found (only) one sentence that needs fixing on similar grounds, I think, in the API draft: in Section 8.1.4 "Timeout for keep alive packets". Surely the guidance regarding this matter in the UDP usage RFC is related to the fact that UDP(-Lite) is connectionless, not that it's datagram based.
Starting to fix this.
LGTM
Change:
Root selector "$" (used at the start of a query and in expressions) <del> Dot selector ".<name>", used with object member names exclusively. </del> <ins> Dot selector ".<name>", used with object member names exclusively </ins> <del> Dot wildcard selector ".*". </del> <ins> Dot wildcard selector ".*" </ins> Index selector "[<index>]", where "<index>" is either a (possibly negative, see index-semantics) array index or an object member <del> name. </del> <ins> name </ins> <del> Index wildcard selector "[*]". </del> <ins> Index wildcard selector "[*]" </ins> Array slice selector "[<start>:<end>:<step>]", where the optional <del> values "<start>", "<end>", and "<step>" are integer literals. </del> <ins> values "<start>", "<end>", and "<step>" are integer literals </ins> <del> Descendants selector "..". </del> <ins> Descendants selector starting with a double dot ".." </ins> List selector "[<sel1>,<sel2>,...,<selN>]", holding a comma <del> separated list of index and slice selectors. </del> <ins> separated list of index and slice selectors </ins> Filter selector "[?(<expr>)]"

Discussion:
contains a bulleted list of the selector types. Each of the items in the list ends with a period. While it may (or may not) be grammatically correct, it leads to some confusing text, specifically when a selector contains, or completely comprises of, periods. For example: Because we only have plain text, it's really difficult to see what's going on here. Formatted, it would look like which is much clearer. If the spec is to continue being issued in a plain text format, I suggest we remove the ending periods from these lines.
Change:
5.5. Text strings can be associated with a RFC5646 and a base text <del> direction (right-to-left or left-to-right) by nesting links of types <http://coreapps.org/base#language> and <http://coreapps.org/ base#direction>, respectively: </del> <ins> direction (right-to-left or left-to-right) by using CBOR tag 38. </ins> <del> The link relation types <http://coreapps.org/base#language> and <http://coreapps.org/base#direction> are defined in core-vocabulary. </del> <ins> [ Maturity note: Whether direction will actually be expressed in an updated tag 38, how precisely that is done, or whether a new tag will be allocated for text with direction is currently still under discussion. ] </ins> 5.6.

Discussion:
With direction on its way into a tag (discussion pending -- will it be a dedicated one or inside 38), the only use case we had for properties on literals is gone. I think the whole model is better if we remove them -- anything that can be expressed with properties can also be expressed with tags, but the latter are well defined and understood whereas the former are not. (What does it mean if two properties are on a literal and both are defined but their interaction is not? Tags are clearer there). PR is incomplete, needs a few more alterations.
Change:
The examples in tbl-example use the expression mechanism to obtain the number of elements in an array, to test for the presence of a member in a object, and to perform numeric comparisons of member <del> values with a constant.  For further illustration, the table shows XPath expressions that would be used with a comparable XML document; see also xpath-overview. </del> <ins> values with a constant. </ins> 3.

Discussion:
XPath details are a distraction in the body of the spec. In the future, readers are increasingly likely to come to this spec with no exposure to XPath or, for that matter, XML.
Looks very good, with the one nit. Thanks!
Change:
field name might occur for shorter values more quickly or with higher probability than for longer values. <ins> This mitigation is most effective between two endpoints.  If messages are re-encoded by an intermediary without knowledge of which entity constructed a given message, the intermediary could inadvertently merge compression contexts that the original encoder had specifically kept separate. </ins> 7.1.3. Implementations can also choose to protect sensitive fields by not

Discussion:
NAME said
I think we can change to SHOULD NOT. I'd rather not be so prescriptive here, since a QPACK implementation might well cut this corner and ignore flow control constraints and rely on higher levels of the stack to ensure the necessary flow control is available? I guess I could be convinced otherwise.
NAME
NAME said
Even though newlines are not really allowed (unescaped) in field values, we can add a note to this effect.
NAME said
Yes, that's why they're not there.
Propose to close with no action then? Or is there a way to reformat the table to include the longer names?
I see a couple options in addition to "close with no change", namely to add a note below the table that the names are abbreviated, or to write out the IANA directives in prose without a table at all. I don't have a particular preference among those three options, though.
We need to come to a decision on this. Since this is from an IESG COMMENT (and not a DISCUSS), the editors can IMO go ahead with their preferred resolution.
NAME said
I agree it's not worth mitigating technically. I question whether it's worth documenting, personally, but it does no harm.
Maybe just a sentence that this mitigation has limits when traversing multiple intermediaries?
That seems like it would strike a reasonable balance.
NAME said
This table appears before the general discussion of indexing. One thought is to add something along the top of the table, like this: ?
Your proposal does improve the clarity of the figure, but I am hoping for more. While it is true that the dedicated sections that discuss indexing appear later in the document, the introductory text alongside the figure uses language such as "smallest absolute index", increases the draining index", and "with an absolute index lower than the draining index" that imply a numerical ordering and directionality of the indices. Interpreting the figure would be easier with the direction of that ordering stated explicitly, as might be done via "Newer Entries (larger index)"/etc..
We need to come to a decision on this. Since this is from an IESG COMMENT (and not a DISCUSS), the editors can IMO go ahead with their preferred resolution.
Change:
the client-facing server because the client validates the server certificate against the public name before retrying. <del> 10.8.7. </del> <ins> 10.9.7. </ins> This design has no impact on application layer protocol negotiation. It may affect connection routing, server certificate selection, and

Discussion:
One of the motivations for encrypting HRR in was the leaks from cookie values. If we don't go with such a construction (which seems likely) and instead do or , cookies will be in the clear. That means it is instead on the backend servers to construct cookie values without leaking information. This PR provides security considerations to that effect. Unfortunately the requirements on backend servers within a Split Mode deployment are a bit onerous. I suspect, in practice, the answer is that Split Mode deployments cannot even use cookies on the backend server. Between HRRs being rare and stateless HRR being unnecessary over TCP or QUIC, that's hopefully fine. (Note this is different from , which was about the client-facing server being stateless. This applies if the backend server is stateless.)