jiebi/CodeConvo huggingface dataset:
Change:
Before an implementation marks a Message Framer as ready, it can also dynamically add a protocol or framer above it in the stack.  This <del> allows protocols like STARTTLS, that need to add TLS conditionally, to modify the Protocol Stack based on a handshake result. </del> <ins> allows protocols that need to add TLS conditionally, like STARTTLS RFC3207, to modify the Protocol Stack based on a handshake result. A Message Framer might also choose to go into a passthrough mode once an initial exchange or handshake has been completed, such as the STARTTLS case mentioned above.  This can also be useful for proxy protocols like SOCKS RFC1928 or HTTP CONNECT RFC7230.  In such cases, a Message Framer implementation can intercept sending and receiving of messages at first, but then indicate that no more processing is needed. </ins> 6.2.

Discussion:
The implementation draft should explain that a framer can go into a passthrough/inactive mode once it has finished (like SOCKS, STARTTLS, CONNECT).
Change:
from an RS, this can be used to derive information about the resources being protected without releasing the resources themselves. <del> 8.  References </del> <ins> 9.  References </ins> <del> 8.1.  URIs </del> <ins> 9.1.  URIs </ins> [1] https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/115

Discussion:
Deploy Preview for gnap-resource-servers-editors-draft ready! Explore the source changes: 94d11a4362aaea79f357583969d87ec4955655a9 Inspect the deploy log: Browse the preview:
Change:
If a QUIC receiver has opened the maximum allowed concurrent streams, and the sender indicates that more streams are needed, it does not automatically lead to an increase of the maximum number of streams by <del> the receiver.  Therefore it can be valuable to expose the maximum number of allowed, currently open, and currently used streams to the application to make the mapping of data to streams dependent on this information. </del> <ins> the receiver.  Therefore, an application can use the maximum number of allowed, currently open, and currently used streams when determining how to map data to streams. </ins> QUIC assigns a numerical identifier to each stream, called the Stream ID.  While the relationship between these identifiers and stream

Discussion:
The proposed wording makes sentence stronger, more list a SHOULD requirement. Therefore we wanted to check with others before we merge.
Seems simpler and clearer. I don't see this as normative.
Change:
13.3. <del> QUIC endpoints use Explicit Congestion Notification (ECN) RFC3168 to detect and respond to network congestion.  ECN allows a network node to indicate congestion in the network by setting a codepoint in the IP header of a packet instead of dropping it.  Endpoints react to </del> <ins> QUIC endpoints can use Explicit Congestion Notification (ECN) RFC3168 to detect and respond to network congestion.  ECN allows a network node to indicate congestion in the network by setting a codepoint in the IP header of a packet instead of dropping it.  Endpoints react to </ins> congestion by reducing their sending rate in response, as described in QUIC-RECOVERY.

Discussion:
Implementations are free to enable sending or not. 2, Implementations MAY read the ECN code points if they can and send ECN ACKs. Implementations MUST accept the 0x03 ACK type and if they are sending ECN SHOULD use the ECN section. I recognize that some people want to have stronger language here, based on this discussion I think this is where we are. I'll defer to the chairs to judge whether more is needed here and can change the PR as required.
I took the discussion to be "MAY" but obviously this is easily changed if the chairs judge consensus otherwise.
Change:
7.3. When registrants publish information in the RD that is not available <del> to any client that would query the registrant's .well-known/core </del> <ins> to any client that would query the registrant's /.well-known/core </ins> interface, or when lookups to that interface are subject so stricter firewalling than lookups to the RD, the RD may need to limit which lookup clients may access the information.

Discussion:
Even disregarding the examples that necessarily have the slash, this (vs. plain .well-known/core) version was the more common in the text so far. Closes: URL
This actually
Current master branch text is really unclear: What does it mean : "used to find the identification" ? Can we say intead "used to identify the components" ? How can the URI discovery process identify client-server incompatibilities? CoAP doesn't let you discover supported protocol versions, options, etc. as far as I know, by default. For those implementations not supporting I-D.bormann-t2trg-rel-impl , it is really unclear what to do with this paragraph.
Oups, wrong link in the commit -- sorry for the noise
The intention behind this paragraph is merely to point those who want versioning and more RD metadata that is immaterial to the regular operation to a place where they can safely do so. I see, however, how the "it is necessary to" makes this sound like more than there really is to it. Accordingly, the incompatibilities part is not about finding that something can't work in the first place (that works on a positive-list base using rt and that like), but more for understanding later why things don't work (say, client X produces a document that upsets RD implementation Y in versions earlier than 0.4.1). The address is in section 4 of 6690 (ie. just .well-known/core); now referred to by the name it has there.
A couple of places has ".well-known/core" as resource name, while in most places it says "/.well-known/core". Proposal is to update all occurrences to the latter form. (Maybe this is already addressed in the pull requests with nits, but there are so many - hard to check...)
Change:
simplifies for the RS to keep track of authorization information for a given client. <del> As specified in section 5.8.3 of I-D.ietf-ace-oauth-authz, the RS must notify the client with an error response with code 4.01 (Unauthorized) for any long running request before terminating the session, when the access token expires. </del> 4.2.1. This parameter MUST be sent from the RS to the Client if the ace

Discussion:
OCF comments.
check that re-sending token triggers nonces exchange and new security context derived.
add a implementation note about namespaces for identifiers in case several methods are used (EDHOC, ACE, others)
Change:
or received. Path Identifier Content: A variable-length integer specifying the <del> path identifier. </del> <ins> path identifier.  If Identifier Type is 2, the Path Identifier Content MUST be empty. </ins> Note: If the receiver of the PATH_ABANDON frame is using non-zero length Connection ID on that path, endpoint SHOULD use type 0x00 for

Discussion:
Fix issue .
In the "path abandon" frame, the path identifier is defined as: But in the identifier type 2, the "path identifier content" is empty. We should fix that.
Submitted PR for this issue.
Yes, perfect.
Change:
new streams, reading only from the encoder stream, or closing the connection. <del> 7.7. </del> <ins> 7.4. </ins> An implementation of QPACK needs to ensure that large values for integers, long encoding for integers, or long string literals do not

Discussion:
Magnus Nystrom : not be able (based on no current known attack against static Huffman encodings) to mount the previously described "probing" attack? If so, adding a sentence at the end of the section along the lines of "Thus, the previously mentioned probing attack is not known to be applicable for any fields where static Huffman encoding is used."
This section is not related to the probing attack. I think some of the confusion here is lost formatting when importing from RFC 7541. The TOC should be:
Change:
entirety of, see search below) a given string matches a given regular expression, which is in I-D.draft-ietf-jsonpath-iregexp form. <del> Its arguments are instances of "ValueType".  If the first argument is not a string or the second argument is not a string conforming to I- D.draft-ietf-jsonpath-iregexp, the result is "LogicalFalse". Otherwise, the string that is the first argument is matched against the iregexp contained in the string that is the second argument; the result is "LogicalTrue" if the string matches the iregexp and "LogicalFalse" otherwise. </del> <ins> Its arguments are instances of "ValueType" (possibly taken from a singular query, as for the first argument in the example above).  If the first argument is not a string or the second argument is not a string conforming to I-D.draft-ietf-jsonpath-iregexp, the result is "LogicalFalse".  Otherwise, the string that is the first argument is matched against the iregexp contained in the string that is the second argument; the result is "LogicalTrue" if the string matches the iregexp and "LogicalFalse" otherwise. </ins> 2.6.7.

Discussion:
Any parameter type works with
Indeed. We could make the example more general by not talking about the parameter type there.
Or by adding a bit variety. Done.
How does this work with a parameter?
It doesn't. Example needs to be fixed. Thanks.
Ref: URL Currently is not allowed. The argument is that we've not defined as resulting in a instance (an artifact of not extending the type system to the whole expression), but I don't really see a problem with allowing it. It's pretty intuitive. I can see applications where you'd want an argument to a function to be whether a location in a path is a certain value, e.g. . An function could work this way.
If we extend the use of the type system in this way (any would be of type , possibly after implicit conversion from ), we should also roll out the other types across the spec. Then any would have type and any would have type . This fixes a bug in the current spec which I've only just noticed. The and functions are assumed to be able to take Singular Queries, but as the spec is currently written, these would need converting to using the function.
Thanks. Updating jpt to the new semantics and running it over the spec to find inconsistencies was what I wanted to do over the weekend...
I can next work on implementing this issue on Saturday.
PR attempts to implement this issue using a point solution rather than attempting to roll out the type system across the whole spec.
Approving with several suggestions that I believe will complete the remaining editorial work. (I raised some editorial nits unrelated to this PR in issue URL)
Change:
DTLS session, a SCTP stream, a QUIC stream, or an HTTP/2 stream). The properties held by a Connection or Listener is independent of other connections that are not part of the same Connection Group. <del> Once Initate has been called, the Selection Properties and Endpoint </del> <ins> Connection establishment is only a local operation for a Datagram transport (e.g., UDP(-Lite)), which serves to simplify the local send/receive functions and to filter the traffic for the specified addresses and ports RFC8085. Once Initiate has been called, the Selection Properties and Endpoint </ins> information are immutable (i.e, an application is not able to later modify Selection Properties on the original Preconnection object). Listener objects are created with a Preconnection, at which point

Discussion:
Added something directly from RFC8085 that UDP can be connected in a sense.
If this is any help, RFC8085 said: "Many operating systems also allow a UDP socket to be connected, i.e., to bind a UDP socket to a specific pair of addresses and ports. This is similar to the corresponding TCP sockets API functionality. However, for UDP, this is only a local operation that serves to simplify the local send/receive functions and to filter the traffic for the specified addresses and ports."
Added text in
Change:
"http-05" - but not one labeled "http-04", since challenge in version -04 was compatible with one in version -04. ]] <del> [[ Editor's Note: Operators SHOULD NOT issue "combinations" arrays in authorization objects that require the client to perform multiple challenges over the same type, e.g., ["http-03", "http-05"]. Challenges within a type are testing the same capability of the domain owner, and it may not be possible to satisfy both at once. ]] </del> 7.1. Several of the challenges in this document makes use of a key

Discussion:
This is a fairly complicated part of the protocol, and not used in practice. For instance, in Let's Encrypt's implementation, there are always three challenges, any one of which may be fulfilled by the client. After this change, all challenges are considered to be combined with an "OR." That is, any challenge within an authorization may be completed to make the authorization valid. Authorizations within the new-application object are considered to be combined with an "AND." That is, all of them must become valid before the certificate will be issued. The combination of the two means that we have similar expressiveness as before, even without the combinations array.
Change:
All transmissions in QUIC are sent with a packet-level header, which indicates the encryption level and includes a packet sequence number (referred to below as a packet number).  The encryption level <del> indicates the packet number space, as described in QUIC-TRANSPORT. Packet numbers never repeat within a packet number space for the lifetime of a connection.  Packet numbers are sent in monotonically increasing order within a space, preventing ambiguity. </del> <ins> indicates the packet number space, as described in Section 12.3 of QUIC-TRANSPORT.  Packet numbers never repeat within a packet number space for the lifetime of a connection.  Packet numbers are sent in monotonically increasing order within a space, preventing ambiguity. </ins> This design obviates the need for disambiguating between transmissions and retransmissions; this eliminates significant

Discussion:
Roman Danyliw said:
I believe the mapping from encryption level to PNS is detailed in section 12.3 of transport: URL
I can't find the text being commented on.
NAME text is in the first paragraph of URL
It might be useful to point to the specific section in -transport that NAME mentioned in his comment. Anyone care to propose a PR?
Change:
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, <del> as shown here. </del> <ins> as shown here.  All TLS notation comes from RFC8446; Section 3. </ins> 3.

Discussion:
I believe it will be helpful to understanding this document to either add "Presentation Language" to this document or link to Presentation Language elsewhere. The TLS/1.3 document has something similar in
Change:
is handled as described below. Check whether this IP address satisfies the ICE agent's policy <del> regarding whether an address is safe to expose.  If so, expose the candidate and abort this process. </del> <ins> regarding whether an address is safe to expose (typically, following the advice from address-privacy below).  If so, expose the candidate and abort this process. </ins> Check whether the ICE agent has previously generated, registered, and stored an mDNS hostname for this IP address as per steps 3 to

Discussion:
Nils reviewed the document at URL There are a number of clarification points that could be made from the draft Makes sense to me. Right, I would tend to go with private IP addresses given RFC1918. We could refer to section 3.1.2.2 and refer to IP handling modes as well. We might want to further clarify that generating mDNS candidates ahead of time is an optimization. Makes sense to me. Hello, I was asked to review URL Here are my comment and questions: Abstract: “To maximize the probability of a direct peer-to-peer connection, client private IP addresses are included in this candidate collection.” I think it would make sense to replace “client” with ICE agent here, as client and server in the pure ICE context doesn’t make too much sense. I would suggest to change it to “..., private IP addresses of the ICE agent are included…”. In the abstract the terms “private IP addresses” and “local IP addresses” are used. I would suggest sticking to just one term for consistency. Section 1. “Introduction” has the same mix of local vs private in it. Section 3.1.1 point 1 I think it would be helpful if this draft at least offers the suggestion to replace all RFC1918 addresses, or put a reference to section 3.1.2.2 as a recommendation on how to determine which addresses to replace. Section 3.1.2.2 3rd paragraph “Regardless of results, …” confuses me. The last sentence in the paragraph before talks about the case of a public candidate. If I’m not mistaken in the case of a public address there shouldn’t be a server reflexive candidate generated. Section 3.1.2.2 4th paragraph While I agree that caching the result might be useful it can become dangerous in case the set of STUN servers changes. As the new STUN servers might return different results, cached results should be invalidated. Would it be worth adding a warning about this? Section 6.4 I’m confused by the diagram showing that both agents send over their mDNS candidates before having checked with the STUN server if the interface IP addresses need to be filtered or not.

I understand that section 3.1.2.2 recommends to first wait for the STUN binding response from the STUN server before deciding which addresses should be filtered and which not. Why is this example showing it differently? Best regards Nils Ohlmeier
Change:
datagram SHALL be dropped.  It is up to an implementation to choose what stream or datagram to discard. <ins> 4.6. HTTP/3 defines a graceful shutdown mechanism (Section 5.2 of HTTP3) that allows a peer to send a GOAWAY frame indicating that it will no longer accept any new incoming requests or pushes.  This mechanism applies to the CONNECT requests for new WebTransport sessions.  A GOAWAY frame does not affect data streams for existing WebTransport sessions; those can continue to be opened even after the GOAWAY frame has been sent or received. </ins> 5. A WebTransport session over HTTP/3 is considered terminated when

Discussion:
If a connection carrying WebTransport sessions receives a GOAWAY, is the sender allowed to continue 1) sending datagrams 2) creating new WT streams 3) receiving new WT streams I assume it's ok to continue sending data on already open WT streams and the CONNECT stream, but clarification would be good. Also, are the rules any different after sending a GOAWAY? Can the sender continue doing the above?
I'll just note that because in H2 WT streams are contained to a single stream, they are implicitly allowed there unless we forbid them.
Chair: discussed at IETF 113, consensus to have GOAWAY not prevent opening new WT streams on existing WT sessions. NAME will write a PR
Change:
then it MUST consider the ClientInitKey invalid and not use it for any further processing. <del> Note that as an extension, it is not required that any given ClientInitKey have an expiration time.  In particular, applications that rely on "last resort" ClientInitKeys to ensure continued reachability may choose to omit the expiration extension from these keys, or give them much longer lifetimes than other ClientInitKeys. </del> <ins> Applications that rely on "last resort" ClientInitKeys MAY set the expiration to its maximum value even though this is NOT RECOMMENDED. It is RECOMMENDED to rotate last resort keys at a pace chosen by the application even though they can have much longer lifetimes than other ClientInitKeys. This extension MUST always be present in a ClientInitKey. </ins> 7.3.

Discussion:
Here's the Weekly Digest for : - - Last week 3 issues were created. Of these, 0 issues have been closed and 3 issues are still open. :greenheart: , by :greenheart: , by :greenheart: , by :speaker: , by It received 1 comments. - - Last week, 7 pull requests were created, updated or merged. Last week, 2 pull requests were opened. :greenheart: , by :greenheart: , by Last week, 4 pull requests were updated. :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by Last week, 1 pull request was merged. :purpleheart: , by - - Last week there were 3 commits. :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by - - Last week there were 2 contributors. :bustinsilhouette: :bustinsilhouette: - - Last week there were 2 stagazers. :star: :star: You all are the stars! :star2: - - Last week there were no releases. - - That's all for last week, please :eyes: Watch and :star: Star the repository to receive next weekly updates. :smiley: You can also .
Here's the Weekly Digest for : - - Last week 8 issues were created. Of these, 0 issues have been closed and 8 issues are still open. :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :speaker: , by It received 1 comments. - - Last week, 6 pull requests were created, updated or merged. Last week, 1 pull request was opened. :greenheart: , by Last week, 3 pull requests were updated. :yellowheart: , by :yellowheart: , by :yellowheart: , by Last week, 2 pull requests were merged. :purpleheart: , by :purpleheart: , by - - Last week there were 10 commits.

:hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by - - Last week there were 2 contributors. :bustinsilhouette: :bustin_silhouette: - - Last week there was 1 stargazer. :star: You are the star! :star2: - - Last week there were no releases. - - That's all for last week, please :eyes: Watch and :star: Star the repository to receive next weekly updates. :smiley: You can also .
Change:
4.04 "Not Found" or 404 "Not Found".  Registration does not exist (e.g. may have been removed). <del> If the registration fails in any way, including "Not Found" and request timeouts, or if the time indicated in a Service Unavailable Max-Age/Retry-After exceeds the remaining lifetime, the registering endpoint SHOULD attempt registration again. </del> <ins> If the registration update fails in any way, including "Not Found" and request timeouts, or if the time indicated in a Service Unavailable Max-Age/Retry-After exceeds the remaining lifetime, the registering endpoint SHOULD attempt registration again. </ins> The following example shows how the registering endpoint updates its registration resource at an RD using this interface with the example

Discussion:
Will still grow while I'm working through the latest discusses/comments; these are things not directly mentioned there but small errors that became obvious when working through the document to prepare responses and/or when preparing patches to address the issues.
Change:
application_data(23); /* see fragment.type _/ ProtocolVersion record_version = { 3, 1 }; /_ TLS v1.x */ uint16 length; aead- ciphered struct { opaque content[TLSPlaintext.length]; ContentType <del> type; } fragment; } TLSCiphertext; </del> <ins> type; uint8 zeros[length_of_padding]; } fragment; } TLSCiphertext; </ins> The outer opaque_type field of a TLSCiphertext record is always

Discussion:
This is a big improvement over the previous proposed methods, by the way. NAME I suggest filing a followup PR for your comments, as it looks like this has already merged.