jiebi/CodeConvo huggingface dataset:
Change:
was received, the initiator MUST perform a return routability check on the observed new address, as described in regular. <del> If T expires, or the address confirmation fails, the peer address binding is not updated.  In this case, the initiator MUST perform a return routability check on the observed new address, as described in regular. After the path validation procedure is completed, any pending send operation is resumed to the bound peer address. path-challenge-reqs and path-response-reqs list the requirements for the initiator and responder roles, broken down per protocol phase. </del> <ins> If T expires the peer address binding is not updated.  In this case, the initiator MUST perform a return routability check on the observed new address, as described in regular. </ins> 7.3.

Discussion:
factor out common text remove the spurious "address confirmation failure": path validation only fails on timeout provide further rationale for choosing between basic and enhanced
We probably need to tell implementers why/when they should choose the basic algorithm vs the enhanced. For example, avoid enhanced if: you need to minimise implementation complexity you have privacy concerns -- i.e., to avoid providing a clear correlation signal off-path attackers are not in your threat model and/or you want to reduce the time it takes to switch path
In the path validation algorithm (both base and enhanced) we say "[...] or the address confirmation fails [...]", but we don't say precisely what we mean by that. If it refers to failure in validating the received Cookie value, than there's a potential out-of-sync with the requirement: "[...] the initiator MUST silently discard any invalid path_response it receives." If not, we should say what we mean by "address confirmation failure."
Change:
such as ASCII and MUST support the Unicode character property set in character classes. <del> : The ABNF has been automatically generated and maybe could use some further polishing.  The ABNF has been verified against rfcs, but a wider corpus of regular expressions will need to be examined.  Note that about a third of the complexity of this ABNF grammar comes from going into details on the Unicode IsCategory classes.  Additional complexity stems from the way hyphens can be used inside character classes to denote ranges; the grammar deliberately excludes questionable usage such as "/[a-z-A-Z]/". </del> 4. This syntax is a subset of that of XSD-2.  Implementations which

Discussion:
Implemented the changes as suggested in Issue
The purpose of this issue is to start discussion about how to turn this into a completed draft to send to the IESG. Perhaps the most important issue is how much of the explanatory and motivational material to leave in. There is a case to be made for taking all of it out, so you get a nice short RFC that just says what I-Regexp is. So here's my initial straw-person proposal on what should be removed and changed: Remove the "issues" para in Section 3. Section 5.2, 5.3, remove the trailing note about improving performance. This is an implementation artifact, no? Section 6. Replace with a single short paragraph somewhat as follows: "While regular expressions originally were intended to describe a formal language, i.e., to provide a Boolean matching function, they have turned into parsing functions for many applications. With this accretion of features, parsing regexp libraries have become susceptible to bugs and performance degradation, in particular those that can be exploited in Denial of Service (DoS) attacks in the case where an attacker controls the regex submitted for processing. I-Regexp is designed to offer interoperability, and to be less vulnerable to such attacks, with the trade-off that its only function is to offer a boolean response as to whether a character sequence is matched by a regex. [ If we really feel that other parts of this discussion add value, they could migrate into an appendix.] 6.1 - cut this down, retaining the first para of the first bullet point, the first sentence of the second bullet point, and that's all. The Unicode discussion can migrate into Appendix A.
Resolved by
Change:
and management plane capabilities.  The YANG data model defined in this draft is providing sufficient information to enable optical impairment aware path computation. Optical data plane interoperability is outside the scope of this draft.

Discussion:
draft-ietf-ccamp-optical-impairment-topology-URL for IETF 115 submission --> draft-ietf-ccamp-optical-impairment-topology-yang-URL Related to pull request URL Addressing and resolving .
Change:
the definition here also applies to systems other than the DNS. RFC1034 defines the "domain name space" using mathematical trees and their nodes in graph theory, and this definition has the same <del> practical result as the definition here.  Using graph theory, a domain name is a list of labels identifying a portion along one edge of a directed acyclic graph.  A domain name can be relative to parts of the tree, or it can be fully qualified (in which case, it begins at the common root of the graph). </del> <ins> practical result as the definition here.  Any path of a directed acyclic graph can be represented by a domain name consisting of the labels of its nodes, ordered by decreasing distance from the root(s) (which is the normal convention within the DNS, including this document).  A domain name whose last label identifies a root of the graph is fully qualified; other domain names whose labels form a strict prefix of a fully qualified domain name are relative to its first omitted node. </ins> Also note that different IETF and non-IETF documents have used the term "domain name" in many different ways.  It is common for

Discussion:
cc NAME NAME Ref 92efaf05a13690953c3123bef664fcd96d2b07c7 Ref URL :
This is an improvement over the existing text and is formally more correct, I think. That means, however, that it is technically a substantive change. I think it is not a substantive change that would make any difference to any DNSOP participant so I think this is ok without going back to the WG.
Change:
If a data channel m= section has been offered, a m= section MUST also be generated for data.  The <media> field MUST be set to <del> "application" and the <proto> field MUST be set to "DTLS/SCTP", as specified in I-D.ietf-mmusic-sctp-sdp, Section 3; the "fmt" value MUST be set to the SCTP port number, as specified in Section 4.1. </del> <ins> "application" and the <proto> field MUST be set to "DTLS/SCTP" [TODO: fix this when fixing profiles], as specified in I-D.ietf-mmusic-sctp- sdp, Section 3; the "fmt" value MUST be set to the SCTP port number, as specified in Section 4.1.  [TODO: update this to use a=sctp-port, as indicated in the latest data channel docs] </ins> Within the data m= section, the "a=mid", "a=ice-ufrag", "a=ice- passwd", "a=ice-options", "a=candidate", "a=fingerprint", and

Discussion:
Update of ekr's PR . Details: Initial offers/answers have no candidates Add canTrickle property Add text regarding a=end-of-candidates Clarify dummy/null address/port stuff
lgtm
NAME can you review this before Friday?
I'll try and carefully read this tomorrow morning but I'm running out of time for today. It looked good on my quick skim of it but I want to read it carefully but don't expect to have issues with it.
On this morning's Editor's Call we discussed the topic of what trickle indicators should appear in the SDP. The trickle draft prescribes two indicators: a=ice-options:trickle a=end-of-candidates However, as agreed at the interim, JSEP agents always do trickle and just expose a canTrickle property. Accordingly, the conclusion was to interpret a=ice-options:trickle as "I can do trickle" (this is consistent with half-trickle) and thus JSEP agents always send it, even if canTrickle=false. So, we should insert a=end-of-candidates when gathering is done to mean "I am done trickling". This means that JSEP agents will generate a=ice-options:trickle in response even to offers which do not contain it. However, offerers should already ignore that. As before, it's up to the app to wait for all the candidates before sending the offer if canTrickle=false
Agreed
Sounds good!
Fixed by
Change:
4.4. <del> Datagrams can be sent using the DATAGRAM frame as defined in QUIC- DATAGRAM and HTTP3-DATAGRAM.  For all HTTP/3 connections in which the SETTINGS_ENABLE_WEBTRANSPORT option is negotiated, the Flow Identifier is set to the session ID.  In other words, the format of datagrams SHALL be the session ID, followed by the user-specified payload (fig-datagram). </del> <ins> Datagrams can be sent using HTTP Datagrams, using the WEB_TRANSPORT HTTP Datagram Format Type (see value in iana-format-type).  When using the WEB_TRANSPORT HTTP Datagram Format Type, the WebTransport datagram payload is sent unmodified in the "HTTP Datagram Payload" field of an HTTP Datagram.  When sending a registration capsule using the "Datagram Format Type" set to WEB_TRANSPORT, the "Datagram Format Additional Data" field SHALL be empty. </ins> In QUIC, a datagram frame can span at most one packet.  Because of that, the applications have to know the maximum size of the datagram

Discussion:
This PR keeps WebTransport in sync with the latest changes in draft-ietf-masque-h3-datagram.
Change:
The parent hash of P changes whenever an "UpdatePath" object is applied to the ratchet tree along a path from a leaf U traversing <del> node V (and hence also P).  The new "Parent Hash of P (with Co-Path Child S)" is obtained by hashing P's "ParentHashInput" struct. </del> <ins> node V (and hence also P).  The new "Parent hash of P (with copath child S)" is obtained by hashing P's "ParentHashInput" struct. </ins> The field "public_key" contains the HPKE public key of P.  If P is the root, then the "parent_hash" field is set to a zero-length octet

Discussion:
The co-path is written both as 'co-path' and 'copath'. As a formality check, this should be unified.
Change:
An asymmetric public key <del> The private key and public key for a node are derived from its secret value using the Derive-Key-Pair operation. </del> <ins> The private key for a node is derived from its secret value using the KDF.  The public key is then derived from the private key using the Derive-Public-Key function. </ins> The contents of a parent node are computed from one of its children as follows:

Discussion:
For now, I've only touched the sections until the "Cryptographic Objects" section, which seems to be outdated anyway. Once those are updated at some point, I'm happy to help moving from hashing to KDF-derivation there as well.
Thanks Konrad ! : )
Change:
and has gotten two separate values as a result, a temperature and humidity measurement. <ins> 5.1.7. The following example show the SenML that could be used to set the current set point of a typical residential thermostat which has a temperature set point, a switch to turn on and off the heat, and a switch to turn on the fan override. In the following example two different lights are turned on.  It is assumed that the lights are on a 802.1BA network that can guarantee delivery of the messages to the two lights within 15 ms and uses 802.1AS for time synchronization.  The controller has set the time of the lights coming on to 20 ms in the future from the current time. This allows both lights to receive the message, wait till that time, then apply the switch command so that both lights come on at the same time. The following shows two lights being turned off using a non deterministic network that has a high odds of delivering a message in less than 100 ms and uses NTP for time synchronization.  The curent time is 1320078429.  The user has just turned off a light switch which is turning off two lights.  Both lights are dimmed to 50% brightness immediately to give the user instant feedback that something is changing.  However given the network, the lights will probably dim at somewhat different times.  Then 100 ms in the future, both lights will go off at the same time.  The instant but not synchronized dimming gives the user the sensation of quick responses and the timed off 100 ms in the future gives the perception of both lights going off at the same time. </ins> 6. The CBOR RFC7049 representation is equivalent to the JSON

Discussion:
Current text hints that you can use SenML also with actuators, but there is not much details about this yet.
+1 For actuators. But the ability to set any arbitrary value would be preferred - for example the coefficients of an analog sensor, or a flag to initiate a sensor update.
I did not get this into the -03 update but still plan to add it.
I did not get this into the -03 update but still plan to add it.
Comments on the examples
Change:
For application-layer protocols where the Connection initiator also sends the first message, the InitiateWithSend() action combines <del> Connection initiation with a first Message sent. Without a message context (as in send-basic): With a message context (as in message-props): </del> <ins> Connection initiation with a first Message sent: </ins> Whenever possible, a messageContext should be provided to declare the message passed to InitiateWithSend as idempotent.  This allows the

Discussion:
Even though all the languages we want to support don't have convenient syntax for optional parameters to functions/methods, it would be nice to note that we intend for some parameters to not be mandatory on every call.
Looks good! This approach certainly clarifies things.LGTM except for the paragraph that I commented on; I'd just delete that.Fine withe mit (with some minor knit)
Change:
3.1. The EDHOC protocol consists of three mandatory messages (message_1, <del> message_2, message_3) between an Initiator and a Responder, an optional fourth message (message_4), and an error message.  The roles have slightly different security properties which should be considered when the roles are assigned, see sec-prop.  All EDHOC messages are CBOR Sequences RFC8742, and are deterministically encoded. fig-flow illustrates an EDHOC message flow with the optional fourth message as well as the content of each message.  The protocol elements in the figure are introduced in overview and asym.  Message formatting and processing are specified in asym and error. </del> <ins> message_2, message_3), an optional fourth message (message_4), and an error message, between an Initiator (I) and a Responder (R).  The odd messages are sent by I, the even by R.  Both I and R can send error messages.  The roles have slightly different security properties which should be considered when the roles are assigned, see sec-prop. All EDHOC messages are CBOR Sequences RFC8742, and are deterministically encoded. fig-flow illustrates an EDHOC message flow with the optional fourth message as well as the content of each message.  The protocol elements in the figure are introduced in overview and asym.  Message formatting and processing are specified in asym and error. </ins> Application data may be protected using the agreed application algorithms (AEAD, hash) in the selected cipher suite (see cs) and the

Discussion:
Addresses
Q1: The document talks about the Initiator and Responder roles, what messages they send etc. But I can't find a definition of what the roles. I assume the Initiator initiates something, but unless I have missed it it would be good to have a few word of role definitions. URL
Yes, we will add that
Closing this as PR is merged. Reviewer: Christer Holmberg Review result: Almost Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-lake-edhoc-18 Reviewer: Christer Holmberg Review Date: 2022-12-20 IETF LC End Date: None IESG Telechat date: Not scheduled for a telechat Summary: The document is well written, and easy to read. I do have one minor issue that I would like the authors to address. Major issues: N/A Minor issues: Q1: The document talks about the Initiator and Responder roles, what messages they send etc. But I can't find a definition of what the roles. I assume the Initiator initiates something, but unless I have missed it it would be good to have a few word of role definitions. Nits/editorial comments: N/A
Change:
A resource server may be configured to introspect the access token <del> by including it in a request to the /introspect resource at that </del> <ins> by including it in a request to the /introspect endpoint at that </ins> AS.  Token introspection over CoAP is defined in introspectionResource and for HTTP in RFC7662.

Discussion:
I have reviewed the protocol section and have made some minor edits. I believe the section is looking good. There were only two items that I believe are worthwhile to discuss: I prefer to use the term endpoint for the /token and /introspect rather than calling them resource. The term endpoint is used in the terminology section and aligns with OAuth. The client token is mentioned in this section and even after looking at the text later in the document I didn't really understood the concept.
Looks good to me. Does anyone else have a strong opinion on the use of "endpoint" vs "resource"? We might need to put a note into the text somewhere to clarify, since CoAP IMHO uses "endpoint" with a slightly different meaning.
Change:
Before a new entry is added to the dynamic table, entries are evicted from the end of the dynamic table until the size of the dynamic table is less than or equal to (table capacity - size of new entry).  The <del> encoder MUST NOT cause a blocking dynamic table entry to be evicted (see blocked-insertion).  The new entry is then added to the table. It is an error if the encoder attempts to add an entry that is larger than the dynamic table capacity; the decoder MUST treat this as a connection error of type "HTTP_QPACK_ENCODER_STREAM_ERROR". </del> <ins> encoder MUST NOT cause a dynamic table entry to be evicted unless that entry is evictable (see blocked-insertion).  The new entry is then added to the table.  It is an error if the encoder attempts to add an entry that is larger than the dynamic table capacity; the decoder MUST treat this as a connection error of type "HTTP_QPACK_ENCODER_STREAM_ERROR". </ins> A new entry can reference an entry in the dynamic table that will be evicted when adding this new entry into the dynamic table.

Discussion:
Acting on NAME suggestion.
Thank you, this greatly improves clarity.
Technically, all reviews request rather than require. Those are good suggestions, though.
Incorporated, though the parenthetical reads even more awkwardly now. Suggestions on improving that (or consensus to drop it) are welcome.
This review suggests changes, not "requires" them.
Change:
The following terms are used: <del> This document uses the protocol definition language of RFC8446. </del> <ins> This document uses the presentation language of RFC8446. </ins> 2.

Discussion:
Here are a few small editorial changes: Refer to TLS's "presentation language", per section 3 of the RFC. The output from the HPKE setup function is an encapsulated key, not an encapsulated context. The term context is defined as "A context is an implementation-specific structure...", whereas is alternately described as "an encapsulated KEM shared secret", an "encapsulated key", or a "KEM encapsulated key". Remove stray whitespace from a hyphenated word.
One non-blocking comment.
Change:
7.1. <del> For protocols that employ request/response pairs and do not require in-order delivery of the responses, like HTTP, the transport implementation may distribute interactions across several underlying transport connections.  For these kinds of protocols, implementations may hide the connection management and only expose a single Connection object and the individual requests/responses as messages. These Pooled Connections can use multiple connections or multiple streams of multi-streaming connections between endpoints, as long as all of these satisfy the requirements, and prohibitions specified in the Selection Properties of the Pooled Connection.  This enables implementations to realize transparent connection coalescing, connection migration, and to perform per-message endpoint and path selection by choosing among these underlying connections. </del> <ins> For applications that do not need in-order delivery of Messages, the Transport Services implementation may distribute Messages of a single Connection across several underlying transport connections or multiple streams of multi-streaming connections between endpoints, as long as all of these satisfy the Selection Properties.  The Transport Services implementation will then hide this connection management and only expose a single Connection object, which we here call a "Pooled Connection".  This is in contrast to Connection Groups, which explicitly expose combined treatment of Connections, giving the application control over multiplexing, for example. Pooled Connections can be useful when the application using the Transport Services system implements a protocol such as HTTP, which employs request/response pairs and does not require in-order delivery of responses.  This enables implementations of Transport Services systems to realize transparent connection coalescing, connection migration, and to perform per-message endpoint and path selection by choosing among multiple underlying connections. </ins> 7.2.

Discussion:
So implementation talks about pooled connections - I must have blinked and missed that, obviously it is different to a connection group - or is it? If I am asking a silly question then I suspect we need just a few lines of text to demuddle me.
LGTM, thanks!
Change:
Strategies and implications of the frequency of generating acknowledgments are discussed in more detail in QUIC-RECOVERY. <del> To limit the ranges of acknowledged packet numbers to those that have not yet been received by the sender, the receiver SHOULD track which ACK frames have been acknowledged by its peer.  The receiver SHOULD exclude already acknowledged packets from future ACK frames whenever these packets would unnecessarily contribute to the ACK frame size. </del> <ins> To limit ACK Ranges (see ack-ranges) to those that have not yet been received by the sender, the receiver SHOULD track which ACK frames have been acknowledged by its peer.  The receiver SHOULD exclude already acknowledged packets from future ACK frames whenever these packets would unnecessarily contribute to the ACK frame size. </ins> Because ACK frames are not sent in response to ACK-only packets, a receiver that is only sending ACK frames will only receive

Discussion:
Packets are acknowledged, though packet numbers are communicated to acknowledge them.
One high-level comment. I believe the intent was to move most of the text about sending ACKs from recovery to transport. Also, if we defined ack-eliciting in transport, I think this PR and some other text would read more clearly. I can do that in a follow up PR.
Thanks for cleaning this up. One more TODO down.