jiebi/CodeConvo huggingface dataset:
Change:
routability.  Therefore changing these information will also cause the connection to fail. <ins> QUIC is expected to evolve rapidly, so new versions, both experimental and IETF standard versions, will be deployed in the Internet more often than with traditional Internet- and transport- layer protocols.  Using a particular version number to recognize valid QUIC traffic is likely to persistently miss a fraction of QUIC flows and completely fail in the multi-year timeframe so therefore not recommended. </ins> 3. This section addresses the different kinds of observations and

Discussion:
when merged.
See also issue quicwg/base-drafts
Good Strategy probably is to move quickly to new version and/or deploy draft versions in order to keep the version number field as dynamic as possible. However, if there will be ossification there is probably still a possibility to implement some kind of alternate version negotiation in the encrypted part of the packet and pretend on the outside to use the supported version (similar as TLS1.3 does); of course there is a performance/overhead trade-off. With the uncertainty about what will happen in respect to ossification, it might not be worth is to try and solve the problem now and pay the complexity up front.
does not appear as though the discussion on the list has converged yet; will wait to see at happens in the base drafts before addressing this one in ops.
Consensus to handle "weak" version ossification via a mechanism in the transport; holding this issue open until that converges, but probably not useful to have text in manageability.
This converged in Singapore to no-action in v1.
Fixed by
My comments left the lines >80 characters, but otherwise LGI'm wondering if we should use even stronger language; not that anything can really enforce it.
Change:
Array slice selector "[<start>:<end>:<step>]", where the optional values "<start>", "<end>", and "<step>" are integer literals <del> Descendants selectors starting with a double dot ".." </del> List selector "[<sel1>,<sel2>,...,<selN>]", holding a comma separated list of index and slice selectors Filter selector "[?(<expr>)]" Current item selector "@" (used in expressions) <ins> Descendants selectors starting with a double dot ".." </ins> Note that processing the dot selector, string-valued index selector, and filter selector all potentially require matching strings against strings, with those strings coming from the JSONPath and from member

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:
a pair of CoAP options, Block1 and Block2, pertaining to the request and response payload, respectively.  The blockwise functionality does not support the detection of interchanged blocks between different <del> message bodies to the same endpoint having the same block number. </del> <ins> message bodies to the same resource having the same block number. </ins> This remains true even when CoAP is used together with a security protocol such as DTLS or OSCORE, within the replay window (I- D.mattsson-core-coap-actuators), which is a vulnerability of CoAP

Discussion:
I did quite a lot of changes to the Echo parts as discussed earlier. The Echo parts are now clearer updated in requirements and general processing, and example implementations for Token Option Values. I wrote a reasonably long security consideration chapter and added the missing IANA section. I added updated Token handling which requires some changes to abstract and introduction. Removed some definitions that were not used. I have not touched the Request-Tag parts except for maybe some editorials.
I think you should already have write access to the repository; if you can't just push your changes, I'm afraid you'll have to ask Carsten to add you to the team at URL I'm merging this now to get things on, and am trying to add some fixes today still to upload this evening's state before the cut-off. A suggestion w/rt the pull request branches: could you just add commits rather than appending them (unless you're changing around in the same place)? That'd make it much easier to update one's mental model of the document.
The terms "blockwise request operation" and "blockwise response operation" are used (the former frequently, the latter only once), so I've reverted the line that drops them to their previous state in 382c308f3.
Change:
Calling "AbortGroup" on a UDP Connection (ABORT.UDP(-Lite)) is identical to calling "Close" on this Connection and on all <del> Connections in the same ConnectionGroup.  ## UDP-Lite </del> <ins> Connections in the same ConnectionGroup. 10.4. </ins> Connectedness: Connectionless

Discussion:
(More out of curiosity, with no expectation that this would find its way into the text unless you think I've hit a bug): In UDP Multicast Receive, which kind of ICMP notifications can come in there that would constitute a ConnectionError -- given that this transport does not send (and would thus usually not trigger any)?
Section 10.4 for multicast receive mentions ICMP errors. You could have errors on initiate for joining a multicast group, etc, but it likely doesn't make sense to have ICMP errors mentioned here.
Suggest we can close this issue.
LGTMSeems like we do not loose anything by removing this. The change WFM.
Change:
8. <del> This protocol MUST use RFC2818.  This includes any communications between user agent and push service, plus communications between the application and the push service.  All URIs therefore use the "https" scheme.  This provides confidentiality and integrity protection for subscriptions and push messages from external parties. </del> <ins> This protocol MUST use RFC2818 following the recommendations in RFC7525.  This includes any communications between user agent and push service, plus communications between the application and the push service.  All URIs therefore use the "https" scheme.  This provides confidentiality and integrity protection for subscriptions and push messages from external parties. </ins> Applications using this protocol MUST use mechanisms that provide confidentiality, integrity and data origin authentication.  The

Discussion:
This attempts to address all of the issues identified during AD review: URL I have reviewed this document in preparation for IETF last call. It is almost ready to go. I have a few comments below. Once these are resolved and a rev published, I will request publication. = Shepherd write-up = RFC 2818 is in the downref registry already. That is the only explanation necessary for the downref. = Section 5.3 = I'm assuming the application scenarios listed in the table are illustrative since they do not cover every possible application. It would be good to note that. = Section 5.4 = "Delivery receipts for the deleted message SHOULD be suppressed." Why is this a SHOULD rather than a MUST? It seems incorrect in all cases to send a delivery receipt for a message that never gets delivered. = Section 8 = I think the first paragraph should include a normative recommendation to follow the guidance in RFC 7525 for use of TLS. = Section 8.2 = I think it would be useful to acknowledge in this section that while correlation using push URIs can be limited in the various ways described, correlation based on other information exposed by user agents may still be possible. = Section 9.3 = The Contact should be IETF Chair (per RFC 6335).
Change:
member flows, and each member flow will require the provisioning of their own UDP and IP header information.  The headers for each outgoing packet MUST be formatted according to the configuration <del> information and as defined in RFC7510, with one exception.  Note that the UDP Source Port value MUST be set to uniquely identify the DetNet flow.  The packet MUST then be handed as a DetNet IP packet, per I- D.ietf-detnet-ip.  This includes QoS related traffic treatment. To support receive processing an implementation MUST also support the provisioning of received UDP and IP header information.  The provisioned information MUST be used to identify incoming app-flows based on the combination of S-Label and incoming encapsulation header information.  Normal receive processing as defined in I-D.ietf- detnet-mpls, including PEF and POF, can then take place. </del> <ins> information and as defined in RFC7510, and the UDP Source Port value MUST be set to uniquely identify the DetNet flow.  The packet MUST then be handled as a DetNet IP packet, per I-D.ietf-detnet-ip.  This includes QoS related traffic treatment. To support the receive processing defined in this document, an implementation MUST also support the provisioning of received UDP and IP header information.  The provisioned information MUST be used to identify incoming app-flows based on the combination of S-Label and incoming encapsulation header information.  Normal receive processing as defined in I-D.ietf-detnet-mpls, including PEF and POF, can then take place. </ins> 5. The following summarizes the set of information that is needed to configure DetNet MPLS over UDP/IP: <del> Label information (S-label or F-label) to be mapped to UDP/IP flow.  Note that a single S-Label can map to multiple sets of UPD/ IP information when PREOF is used. </del> <ins> Label information (A-labels, S-labels and F-labels) to be mapped to UDP/IP flow.  Note that for example, a single S-Label can map to multiple sets of UDP/IP information when PREOF is used. </ins> IPv4 or IPv6 source address field. IPv4 or IPv6 destination address field. <del> IPv4 Type of Service or IPv6 Traffic Class Fields. </del> <ins> DSCP Field in either IPv4 Type of Service or IPv6 Traffic Class Fields. </ins> UDP Source Port. UDP Destination Port. This information MUST be provisioned per DetNet flow via <del> configuration, e.g., via the controller or management plane. </del> <ins> configuration, e.g., via the controller RFC8655 or management plane. </ins> It is the responsibility of the DetNet controller plane to properly provision both flow identification information and the flow specific <del> resources needed to provided the traffic treatment needed to meet each flow's service requirements.  This applies for aggregated and </del> <ins> resources needed to provide the traffic treatment needed to meet each flow's service requirements.  This applies for aggregated and </ins> individual flows. 6.

Discussion:
IESG review comments resolved in this version
MPLSoUDP
MPLSoUDP: all 01-27 changes done.
can be merged once comments integrater, per Jan 27th meeting
Change:
If certificates are used as trust anchors, Verifiers and Relying Parties are also responsible for validating the entire certificate path up to the trust anchor, which includes checking for certificate <del> revocation.  See Section 6 of RFC5280 for details. </del> <ins> revocation.  For an example of such a proceedure see Section 6 of RFC5280. </ins> 13.

Discussion:
Document says: If certificates are used as trust anchors, Verifiers and Relying Parties are also responsible for validating the entire certificate path up to the trust anchor, which includes checking for certificate revocation. See Section 6 of [RFC5280] for details.
The situation is very much use case dependant. If one is going to rely upon certificates and paths and trust anchors, then a profile should say this. It might be wise to do that. Whole document is non-normative.
Are there some other documents that we can cite that are more prescriptive? There are NIST documents that explain the issues, but are reluctant to be prescriptive.
If certificates are used as trust anchors, Verifiers and Relying Parties are also responsible for validating the entire certificate path up to the trust anchor, which may include checking for certificate revocation.
Change:
This parameter SHALL be present in requests.  The Partial IV SHALL be present in responses to Observe registrations (see observe-registration), otherwise the Partial IV will not <del> typically be present in responses. </del> <ins> typically be present in responses (for one exception, see reboot-replay). </ins> The 'kid' parameter.  The value is set to the Sender ID.  This parameter SHALL be present in requests and will not typically

Discussion:
Addressing issue : Reverting to previous method of updating replay window (section B.1.2, text was previously in 7.5) Removing item 2 in section 7.5
Hi, I do not think that the new suggested Echo procedure specified in 7.5 and B.1.2 is secure with GCM. The procedure intentionally reuses a nonce. As the Plaintext and/or AAD changes, I think the nonce reuse will allow an attacker to calculate the GCM authentication key H, therefore compromising integrity for all following messages the server receives. I don't think we want a procedure that is dependant on the AEAD algorithm. Are there any ways to fix this or should we revert to the previous procedure where the server first need to make sure that it uses a fresh nonce and then send Echo? What do you think NAME ? In Section 7.5, bullet 2 The endpoints can update the server’s Replay Window by using the Echo option [I-D.ietf-core-echo-request-tag], see Appendix B.1.2 for an example. This method only updates the Replay Window and does not update the server’s Sender Sequence Number, so it MUST be complemented by a method for updating the Sender Sequence Number (e.g. by using Appendix B.1.1) if the application allows for the server to encode the AEAD nonce using its Sender Sequence Number in responses to regular requests, or if the server supports Observe. This method MUST NOT be used unless the client can guarantee that its own Sender Sequence Numbers are not reused (e.g. by using Appendix B.1.1). In Appendix B.1.2
Yes you are correct. I was only thinking of the use of CCM which does not have this problem.
I merged PR - reverting to the processing in -15.
I close this issue now, if there are still comments we can reopen it.
Change:
server.  Clients need to know the intended use of services based on their context. <ins> Not all features of this specification will be applicable or effective in all contexts: If the authentication name is received over an insecure channel (e.g., a glue NS record), this specification cannot prevent the client from connecting to an attacker. Different transports might prove to be popular for different purposes (e.g., stub resolution vs. iterative resolution). Implementors are not obligated to implement all the defined transports, although doing so is beneficial for compatibility. Where resolution speed is a high priority, the SVCB TargetName SHOULD follow the convention described in Section 11.2 of SVCB, and the use of AliasMode records (Section 2.4.2 of SVCB) is NOT RECOMMENDED. </ins> 7. A resolver known as "simple.example" that supports DNS over TLS on

Discussion:
See URL
LGTM I have read the draft. It aims to be agnostic as to whether the DNS server that is the subject of the SVCB record is a recursive resolver or an authoritative nameserver for some zone (typically delegated by its parent). It also aims to facilitate the establishment of an authenticated transport. It should be noted that with authoritative delegations from a parent zone, the "service name" for each delegated to nameserver is always obtained from the unsigned parent-side NS RRset. Consequently unless the transport to the parent zone nameserver is authenticated, there is an unavoidable MiTM exposure even when the zone with the SVCB qname is DNSSEC-signed, because an on-path attacker can tamper with the returned NS records. And of course if the transport to the parent nameserver is not encrypted, the name of the desired child zone is leaked in the clear, defeating some or most of the privacy gains from subsequent use of an encrypted transport with the child zone nameservers. So perhaps the document should note using SVCB to signal transport security for nameservers derived from NS records is predicated on a suitably secure connection to the parent zone. The use of SVCB RRs for authoritative nameservers introduces the possibility that the SVCB target name is different from the "service name" in the NS record. Such additional indirection is perhaps surprising or even undesirable. Also, likely DoH would not be a supported transport for authoritative servers, with DoT or DoQ being the available options. If this draft is to be adopted for use with authoritative nameservers these topics would warrant some further discussion, and perhaps some minimal text is warranted to say as much. Viktor.
Change:
3.3. <ins> The "yaml" filename extension is the preferred one; it is the most popular and widely used on the web.  The "yml" filename extension is still used.  The simultaneous usage of two filename extensions in the same context might cause interoperability issues (e.g. when both a "config.yaml" and a "config.yml" are present). 3.4. </ins> When using flow collection styles (see Section 7.4 of YAML) a YAML document could look like JSON JSON, thus similar interoperability considerations apply.

Discussion:
looks good to me (with one minor editorial note i left as a comment).
Would it be valuable to express a preference for over for file extensions? I'm assuming 3 character extensions are legacy from DOS file systems that had a 3 character limit. I reviewed the YAML 1.2 spec and there is no mention of using as a file extensions, so this might be a good opportunity to steer the community away from having two extensions.
Pls let's annihilate the DOS zombie!
NAME let's summon NAME and the YAML folks on that. IMHO: agree on expressing a preference disagree on removing references to .yml, since it's used in the wild. My2¢, R.
Discussed with YAML folks. Ok for indicating a preference without normative implications.
Change:
privacy impacts of the protocol, why these impacts are justified, and guidelines on changes to the parametrization in parametrization. <del> The mechanism by which clients obtain the Issuer public key is not specified.  Clients may be configured with this key or they may discover it via some other form.  See CONSISTENCY. </del> <ins> Clients obtain the Issuer public key directly from the Origin using the process described in HTTP-Authentication.  Clients MAY apply some form of key consistency check to determine if this public key is consistency and correct for the specified Issuer.  See CONSISTENCY for example mechanisms.  Depending on the deployment, the Attester may be able to assist the Client in applying these consistency checks across clients. </ins> Depending on the use case, issuance may require some form of Client anonymization service similar to an IP-hiding proxy so that Issuers

Discussion:
cc NAME
draft-ietf-privacypass-architecture says in section 3.2: Is that correct? Isn't the 'token-key' in draft-ietf-privacypass-auth-scheme providing the pub key? Or do I misunderstand something here?
Oops, yep, good catch! We'll fix this.
Change:
not confirmed (see Section 4.1.2 of QUIC-TLS), even if there are no packets in flight.  When the PTO fires, the client MUST send a Handshake packet if it has Handshake keys, otherwise it MUST send an <del> Initial packet in a UDP datagram of at least 1200 bytes. </del> <ins> Initial packet in a UDP datagram with a payload of at least 1200 bytes. </ins> 6.2.3.

Discussion:
This PR is also a good spot to comment on my accidental commit() to master. I can make any changes to that in this PR.
This was filed a while ago (before WGLC ended), didn't want to drop it.
Editorial, design?
There is a design issue here regarding the initial congestion window that I would like to see split out into a new issue (which can be marked design). The rest appear to be things we can address with editorial changes.
NAME I moved the IW text into , though I'm not sure I think it's worth revisiting.
Thanks :) I agree that it isn't worth re-opening, but we did sign on to at least discuss whether it is worth discussing.
Do we have a plan for this one?
So, is there a plan? (Is there even anything left to do?)
Some of these are addressed already, others are in an accidental commit(), and for some there's no need to address them in the text. The rest are in
Some suggestions only.One nit, but LGTM.
Change:
To verify a token, a verifier checks that Token.authenticator is a valid signature over the remainder of the token input as described <del> below.  The function "RSA-Verify(msg, pk, sig)" is a procedure to verify a signature "sig" over message "msg" using the public key "pk".  Its implementation is not specified in this document. </del> <ins> below.  The function "RSASSA-PSS-VERIFY" is defined in Section 8.1.2 of RFC8017, using SHA-384 as the Hash function, MGF1 with SHA-384 as the PSS mask generation function (MGF), and a 48-byte salt length (sLen). </ins> 6.5.

Discussion:
From NAME
This should probably just invoke from RFC8017 directly, since the named variants we allow for this token type must use PSS.
Change:
above, an m= section MUST be generated for it with the port set to zero and the "a=msid" line removed. <del> For RtpTransceivers that are not stopped, the "a=msid" line MUST </del> <ins> For RtpTransceivers that are not stopped, the "a=msid" lines MUST </ins> stay the same if they are present in the current description. Each "m=" and c=" line MUST be filled in with the port, protocol,

Discussion:
It's a transport attribute, so it should come at the end, like other transport attribs
just checking ... this is just a style thing right? the code would accept SDP with these in any order ?
Of course. This is just how we order things in Section 5.
For createoffer, createanswer ordering of attribs
So SDP has no requirement on the ordering of the a= lines. I don't see how a parser, even a JSEP one can expect to get the a= lines in any specific order. I fear that even a "it is recommended to generate them in this order" will be misinterpreted. I think this is one of SDPs warts that you will have to live with.
Right, there isn't any need to mandate an order, I just think that in the text for generating an offer, the places that talk about adding a=rtpmap should be adjacent. This should be a fairly trivial editorial change.
Change:
concatenating the resolution of its left child with the resolution of its right child, in that order <del> For example, consider the following tree, where the "_" character </del> <ins> For example, consider the following subtree, where the "_" character </ins> represents a blank node and unmerged leaves are indicated in square brackets:

Discussion:
This PR adds two clarifications suggested by NAME Clarifying some antecedents in UpdatePath processing Explaining how the example trees can come about in practice