jiebi/CodeConvo huggingface dataset:
Change:
For each node in the list, the selector selects zero or more nodes, each of which is a descendant of the node or the node itself. <del> Discussion (D4): Is that a common requirement?  Or can a selector also go up, or to the query argument? </del> For instance, with the argument "{"a":[{"b":0},{"b":1},{"c":2}]}", the query "$.a[*].b" selects the following list of nodes: "0", "1" (denoted here by their value).  Let's walk through this in detail.

Discussion:
Here's a chance to actually have the discussion if anyone wants to.
One related question is whether the selector can use $ internally (still returning nodes within the current node).
I am in favour of supporting inside filter expressions as a way to access the root node of the argument, but I don't think that should block this PR as the context of the discussion seems to be which nodes are selected. As you point out, using in a filter expression doesn't select the root node - it selects nodes within the current node as usual.
I agree. Paths like should be allowed, but wouldn't select anything that is not a descendent of . Here the provides a basis for comparison used to select the current node in the iteration. I see no value (for an initial release anyway) in allowing selection of ancestor nodes. If a use case and syntax for it are later defined, I'm happy to release that as a follow-up version.
yes ... using in a logical expression is valid and does no harm.
NAME yes, but the issue at hand here is whether there is a mechanism that can select ancestor or cousin nodes. I think we're in agreement that that there is no such mechanism.
Indeed, we seem to be in agreement.
Change:
it MUST include the base parameter in the registration to provide a valid network path. <del> A registrant that can not be reached by potential lookup clients at the address it registers from (e.g. because it is behind some form of Network Address Translation (NAT)) MUST provide a reachable base address with its registration. </del> <ins> A registrant that cannot be reached by potential lookup clients at the address it registers from (e.g. because it is behind some form of Network Address Translation (NAT)) MUST provide a reachable base address with its registration. </ins> If the Base URI contains a link-local IP literal, it MUST NOT contain a Zone Identifier, and MUST be local to the link on which the registration request is received. Endpoints that register with a base that contains a path <del> component can not meaningfully use RFC6690 Link Format due to </del> <ins> component cannot meaningfully use RFC6690 Link Format due to </ins> its prevalence of the Origin concept in relative reference resolution.  Those applications should use different representations of links to which limitedlinkformat is not

Discussion:
Will merge before the interim to have a discussion on the big stuff with the small stuff out of the way.
Change:
However, these mechanisms cannot tunnel other IP protocols IANA-PN nor convey fields of the IP header. <del> This document describes a protocol for tunnelling IP to an HTTP </del> <ins> This document describes a protocol for tunnelling IP through an HTTP </ins> server acting as an IP-specific proxy over HTTP.  This can be used for various use cases such as point-to-network VPN, secure point-to- point communication, or general-purpose packet tunnelling.

Discussion:
This adds some additional security considerations, touching on privacy considerations at the same time. Do we want to say anything about IP fragmentation, or at least point to some existing guidance around how to avoid sharp edges there? Please feel free to reframe or modify the text as you see fit!
Change:
line in the SDP sent by the entity which sent the IceCandidate.  The MID uses the "media stream identification" attribute, as defined in RFC5888, Section 4, to identify the m= line.  JSEP implementations <del> creating an ICE Candidate object MUST populate both of these fields. Implementations receiving an ICE Candidate object MUST use the MID if present, or the m= line index, if not (as it could have come from a non-JSEP endpoint). </del> <ins> creating an ICE Candidate object MUST populate both of these fields, using the MID of the associated RtpTransceiver object (which may be locally generated by the answerer when interacting with a non-JSEP remote endpoint that does not support the MID attribute, as discussed in sec.applying-a-remote-desc below).  Implementations receiving an ICE Candidate object MUST use the MID if present, or the m= line index, if not (the non-JSEP remote endpoint case). </ins> 3.5.3.

Discussion:
LGTM
PTAL
In the WebRTC 1.0 spec we have text talking about generating a mid if the remote description is missing one. That text has a faulty link to a JSEP (as described in issue w3c/webrtc-pc/issues/698). I can't seem to find any text in JSEP about this. Should there be such text? I did find text that said that an answer only should have a mid if the offer did.
OK, I agree we need some additional text in 3.5.2.1 to indicate that if a MID is not negotiated in SDP, a MID is locally generated (but not included in SDP).
Fixed by
Thank you!
Change:
Record or datagram confidentiality and integrity. <ins> Application dependency: None. </ins> Forward-secure key establishment. <ins> Application dependency: None. </ins> Public-key certificate based authentication. <ins> Application dependency: Application providing trust information.  Note that most systems provide default trust stores used to authenticate peers based on certificates.  In such systems, applications need not provide any trust information. </ins> Unilateral responder authentication. <del> Note that most systems provide defailt trust stores used to authenticate peers based on certificates.  In such systems, applications need not provide any trust information.  Applications running on systems without such a feature must necessary depend on applications for this information so as to authenticate peers. </del> <ins> Application dependency: Application providing trust information, see above. </ins> 5.2.

Discussion:
As promised at IETF 103, here's a suggested definition of application dependency, to make it clearer what I'm talking about. I have also added dependencies for the mandatory features, so that it's clear for all features whether they have any application dependencies. In addition, I changed the heading of the section because the section does not actually talk about transport dependencies anymore. What do you think?
Yep, I agree. This change looks good. Thank you, NAME good with these changes.
Change:
BitTorrent Schoen-2007, this later led to a US Federal Communications Commission ruling against Comcast VonLohmann-2008.  China has also been known to use RST Packet Injection for censorship purposes.  This <del> prevention is especially evident in the interruption of encrypted/ </del> <ins> interference is especially evident in the interruption of encrypted/ </ins> obfuscated protocols, such as those used by Tor Winter-2012. 4.3.

Discussion:
…nce. defines censorship. fixes definition of identification in intro.
First, one thing that isn’t clear immediately from the introduction is who/what is a “censor”. I find it a little strange, actually, to suggest that a censor performs "aggregation". Is the censor an ISP? A government? Something else? For example, a government may have loose policies about what kind of content to censor (e.g., "hate speech"). An ISP might in turn implement these loose policies in different ways. Policies can also differ across a country, etc. The other terms---identification and prevention---are similarly confusing, although I think the term "identification" isn't as problematic as its (incorrect?) definition in the introduction. "Identification is the process by which censors determine whether content is blocked" - NO. I think it is the process by which a censor might classify traffic to determine whether to block a traffic flow or now. I would suggest something like: prescription, identification, and interference.
Wondering what you think about "design, identification, and interference"? I think for the purposes of todays 20:00 ET IETF drafts deadline, I'll change the terminology throughout to match prescription, identification, and interference and I'll correct the other things mentioned here (define censor, fix definition of identification in intro).
That seems a bit more clear, indeed! Ah, I didn't realize there was a deadline of today 2000h. Not sure I can get you a pull request by then, but will try.
I'll leave this open. You by no means need to get a pull request by 20:00! I just want to do my best to make changes responsive to your feedback. I'll leave this open and you can see what I've done (I'll be working on trying to clear out issues until then), and feel free to submit changes as you think are needed.
Change:
needs to trust the API server, server authentication will be performed using TLS mechanisms. <ins> The Captive Portal API URI might change during the Captive Portal Session.  The User Equipment can apply the same trust mechanisms to the new URI as it did to the URI it received initially from the network provisioning service. </ins> 7.3. The solution described here requires that the API be secured using

Discussion:
There was some concern that section 4 could be seen as normative. To make matters worse, there was some normative text in there. Rework things a bit to address that. Explicitly call out that section 4 is not normative to avoid confusion Move normative text out of 4.3 into 2.1 Add some more description to 4.3 Describe trust for new URIs
Roman writes, It's meant to be informative. Move it Section 2.1 (User Equipment)
We did this in
Benjamin writes, This should be the same as the initial one we received when first accessing the network(e.g. via DHCP, RAs, etc). Perhaps we don't properly indicate elsewhere that this should be supported. I thought we did, but I can't find it... I think we should add a point to Section 2.1 that the UE SHOULD support updates to the captive portal URI from the network provisioning service, and then mention here that that service is what did it. The same trust as mentioned in section 7.1 still applies.
Benjamin writes, Do it.
Change:
record type (64) I-D.ietf-dnsop-svcb-https. Because this query is for an SUDN, which no entity can claim <del> ownership over, the SVCB response MUST NOT use the "." value for the TargetName.  Instead, the domain name used for DoT or used to construct the DoH template MUST be provided. </del> <ins> ownership over, the ServiceMode SVCB response MUST NOT use the "." value for the TargetName.  Instead, the domain name used for DoT or used to construct the DoH template MUST be provided. </ins> The following is an example of an SVCB record describing a DoH server discovered by querying for "_dns.resolver.arpa":

Discussion:
Addressing
We should be explicit about AliasMode DDR records and give an example of where they are used. We should also mention the additional client complexity here, and we may wish to require that the unencrypted resolver include both the AliasMode and ServiceMode records in its response (with the latter in the additional section). A common use-case here will be if a network operator is using a managed service to provide a designated resolver service. In these cases it may be preferable to have URL be an AliasMode record to a ServiceMode record managed by the manage service operator.
One small nit, to avoid quasi normative language (may/MAY -> can).
Change:
5.2. Issuer key rotation is important to hedge against long-term private <del> key compromise.  However, key rotation can also be used to segment Client anonymity sets.  In particular, when an Issuer rotates their key, any Client that invokes the issuance protocol in this key cycle will be part of a group of possible Clients owning valid tokens for this key.  To mechanize this attack strategy, an Issuer could introduce a key rotation policy that forces Clients into small key cycles, reducing the size of the anonymity set for these Clients. </del> <ins> key compromise.  If an Issuer realizes that a key compromise has occurred then the Issuer should generate a new key and make it available to Clients.  If possible, it should invoke any revocation procedures that may apply for the old key. Key rotation can also be used to segment Client anonymity sets.  In particular, when an Issuer rotates their key, any Client that invokes the issuance protocol in this key cycle will be part of a group of possible Clients owning valid tokens for this key.  To mechanize this attack strategy, an Issuer could introduce a key rotation policy that forces Clients into small key cycles, reducing the size of the anonymity set for these Clients. </ins> In general, key rotations represent a trade-off between Client <del> privacy and continued Issuer security.  Therefore, it is still important that key rotations occur on a regular cycle to reduce the harmfulness of an Issuer key compromise. With a large number of Clients, a minimum of one week gives a large enough window for Clients to participate in the issuance protocol and thus enjoy the anonymity guarantees of being part of a larger group. A maximum of 12 weeks limits the damage caused by a key compromise. If an Issuer realizes that a key compromise has occurred then the Issuer should generate a new key and make it available to Clients. If possible, it should invoke any revocation procedures that may apply for the old key. </del> <ins> privacy and Issuer security.  Therefore, it is still important that key rotations occur on a regular cycle to reduce the harmfulness of an Issuer key compromise.  If there are multiple Issuer keys in rotation, Clients can apply some form of consistency mechanism CONSISTENCY to ensure that they receive the same key as other Clients.  Likewise, Origins can use one or more public keys for redemption to support Issuer key rotation. </ins> 5.3.

Discussion:
cc NAME
S3.2.2.2 states "Issuers MUST only use one private key for issuing tokens at any given time." The next section (3.2.3), however, suggests that multiple keys could be used to encode metadata, and indeed, I believe the latest draft of rate-limited tokens uses different issuance keys. These seem to be in conflict.
Change:
independently retransmit the same data.  To avoid this, HTTP/3 datagrams SHOULD be used. <del> 5.1. </del> <ins> 6.1. </ins> When using HTTP/3 with the QUIC Datagram extension DGRAM, UDP payloads are transmitted in QUIC DATAGRAM frames.  Since those cannot

Discussion:
This is one potential design for the identifier at the start of the CONNECT-UDP datagram payload. Note that this PR is against the design team consensus branch, not main. . .
During the HTTP Datagrams Design Team meeting on 2022-01-20, we reached consensus to move forward with the dynamic approach, so I'm merging this PR.
Change:
A component is a piece of a data stream.  A data stream may require multiple components, each of which has to work in order <del> for the data stream as a while for work.  For media data streams based on RTP, unless RTP and RTCP are multiplexed in the same port, there are two components per media data stream -- one for RTP, and one for RTCP.  A component has a candidate pair, which cannot be used by other components </del> <ins> for the data stream as a whole to work.  For RTP/RTCP data streams, unless RTP and RTCP are multiplexed in the same port, there are two components per data stream -- one for RTP, and one for RTCP.  A component has a candidate pair, which cannot be used by other components </ins> A candidate obtained by binding to a specific port from an IP address on the host.  This includes IP addresses on physical

Discussion:
Fix spelling: Replace “fulfil” with “fulfill” Fix grammar: “agent sets the state…is set to Completed“ with “agent sets the state…to Completed” Make consistent with recent changes: Replace “candidate is equal to the transport address” with “candidate has the transport address” Replace “multimedia session” with “data session” Replace “media data stream” with “RTP/RTCP data stream” or just “data stream” Replace “media data” with “data”
Change:
1.1. <del> This API is described in terms of Objects with which an application can interact; Actions the application can perform on these Objects; Events, which an Object can send to an application asynchronously; and Parameters associated with these Actions and Events. </del> <ins> This API is described in terms of Objects with which an application can interact; Actions the application can perform on these Objects; Events, which an Object can send to an application to be processed aynchronously; and Parameters associated with these Actions and Events. </ins> The following notations, which can be combined, are used in this document:

Discussion:
Interface, section 4.1.2: Why the limitation to aliases? Specifying a protocol might limit the utility of connection racing, so should perhaps be discouraged, but does it break anything to specify a protocol for a non-alias Endpoint?
Interim: suggest to remove the second sentence.
They are currently just called "Table"
In the interface draft, Section 1.1: Where is the event sent? Perhaps ?
Interim: add "to the application" (but double check, related to framers)
Could alternatively say the same another way around: "Applications can use these events..." (i.e. avoid saying only applications do this).
Section 6 in impl-draft has the parts where the framer objects receive events. There is no terminology section in implementation, so not sure if the terminology section in API should cover it as well.
We already say this in the intro text to this section, but I can tweak the structure and add some additional text to make this more clear.
The appendix text about convenience functions talks about "implementations should" provide various things. This reads strangely to me. I think these are not requirements and the text should be more in the form of it can be useful for implementations to provide various things.
How about: " implementations can provide special actions for adding each preference level i.e, TransportProperties.Set(someproperty, avoid) would be equivalent to TransportProperties.Avoid(someproperty):..."
EstablishmentError. Fixed in an upcoming PR.
Change:
17.2. Long headers are used for packets that are sent prior to the <del> establishment of 1-RTT keys.  Once both conditions are met, a sender </del> <ins> establishment of 1-RTT keys.  Once 1-RTT keys are available, a sender </ins> switches to sending packets using the short header (short-header). The long form allows for special packets - such as the Version Negotiation packet - to be represented in this uniform fixed-length

Discussion:
URL What are these "both conditions"? Also, can there be made a clear statement such that: all packets prior to Application PN space use long headers, and all packets in application PN space uses short headers? And, the table of frames with section references, would it make sense to add PN space columns with an X where a frame is applicable?
Multiple issues listed here. Please consider opening separate issues rather than lumping them all together. (1) This is old language we agreed to in Chicago. The requirement to shift to short headers was 1-RTT key availability and version agreement, to accommodate versions where the final keys might be available immediately (i.e. out-of-band agreement) but version negotiation still had to complete. However, that's a principle for the invariants or such a version, not a requirement of this QUIC version -- and the version negotiation language this referenced is gone now. (2) What is "Application PN space"? 0-RTT and 1-RTT? If so, then no -- 0-RTT packets carry application data but are long-header packets. (3) Unrelated editorial suggestion -- please open a separate issue.
(3) see
Change:
match all Protocol Selection Properties that the application specified on the Preconnection. <del> For Connections that are Established: Information concerning the </del> <ins> For Connections that are Established: information concerning the </ins> path(s) used by the Protocol Stack.  This can be derived from local PVD information, measurements by the Protocol Stack, or other sources.  For example, a TAPS system that is configured to

Discussion:
Rewording the path information with respect to PVD to reflect Info concerning the path(s) used by the Protocol Stack.
Addressed MW comments in this PR
At the last bullet before section 8.1, are you RFC7556 being pointed to as an example way one might derive properties? If so, adjust the language to make it clear that its an example.
I was thinking this was a useful example: a system that is configured to receive and process MPVD information, as described in RFC7556, can utilise this to inform the system policy that is later used by a transport system implementation, e.g. to provide additional information about paths when performing candidate gathering.
Gorry will write a PR for review.
Change:
where H() is the hash function in the selected cipher suite.  Example use of the EDHOC-Exporter is given in Sections oscore. <ins> To provide forward secrecy in an even more efficient way than re- running EDHOC, EDHOC provides the function EDHOC-Exporter-FS.  When EHDOC-Exporter-FS is called the old PRK_4x3m is deleted and the new PRk_4x3m is calculated as a "hash" of the old key using the Extract function as illustrated by the following pseudocode: </ins> 4. 4.1.

Discussion:
Should be discussed in LAKE if this is the right approch Should be discussed what the best way is to calculate the hash chain The nonce is included to make sure that the hash chain does not have short cycles. It should be discussed if the nonce is provided by the application (OSCORE) or by EDHOC itself. If provided by OSCOREbis it could be a random string or a counter. If the nonce is provided by EDHOC it has to be a deterministic. E.g. a counter (or theoretically a LFSR....)
Change:
3.1. <del> This document defines the following extension code point. </del> <ins> This document defines the following TLS extension code point. </ins> 3.1.1.

Discussion:
Updating x690 version to match TLS1.2 (2015) Expanding acronyms (avoid genart) removed "!" from some refs (unneded) r/LURK/KEYLESS (completes derference from earlier PR).
Change:
Use of connection IDs is specifically discouraged for NAT applications.  If a NAT hits an operational limit, it is recommended to rather drop the initial packets of a flow (see also sec- <del> filtering), which potentially triggers a fallback to TCP, than using the connection ID to muliplex mulitple connections on the same IP address port pair which risks connectivity breakage later, in case the connection ID changes. </del> <ins> filtering), which potentially triggers a fallback to TCP.  Use of the connection ID to multiplex multiple connections on the same IP address/port pair is not a viable solution as it risks connectivity breakage, in case the connection ID changes. </ins> 4.3.

Discussion:
NAME said in PR on section "Passive Network Performance Measurement and Troubleshooting": "I think the caution against using Connection ID needs to be a lot stronger. Things will break, users will notice. I realize that implementations have to use this to enforce that, but I believe some already are. See a comment below as well."
NAME is PR better? Note that you should also review the previous paragraphs as I believe the problems are described there clearly already.