jiebi/CodeConvo huggingface dataset:
Change:
D.ietf-suit-manifest, the SUIT information model RFC9124 and the SUIT architecture RFC9019. <del> The terms sender and recipient are defined in I-D.irtf-cfrg-hpke and have the following meaning: </del> <ins> The terms sender and recipient are defined in RFC9180 and have the following meaning: </ins> Sender: Role of entity which sends an encrypted message.

Discussion:
Based on discussions with Russ, I have updated the text in Section 7 about CEK Verification. Text about the parameters used for encryption were missing.
Change:
described in RFC9146.  Specifically, when both CID RFC9146 and RRC have been successfully negotiated for the session, if a record with CID is received that has the source address of the enclosing UDP <del> datagram different from the one previously associated with that CID </del> <ins> datagram different from the one currently associated with that CID </ins> value, the receiver SHOULD perform a return routability check as described in path-validation, unless an application layer specific address validation mechanism can be triggered instead.

Discussion:
Signed-off-by: Thomas Fossati
cc NAME
works for me
For me the is misleading. My understanding was, that RFC9146 recommend to not update the association before passing the address check. So, for me "currently" may be the better choice.
Change:
The "https" scheme associates authority with possession of a certificate that the client considers to be trustworthy for the host <del> identified by the authority component of the URL.  If a server presents a certificate and proof that it controls the corresponding private key, then a client will accept a secured TLS session with that server as being authoritative for all origins with the "https" scheme and a host identified in the certificate. </del> <ins> identified by the authority component of the URL. If a server presents a valid certificate and proof that it controls the corresponding private key, then a client will accept a secured TLS session with that server as being authoritative for all origins with the "https" scheme and a host identified in the certificate. The host must be listed either as the CN field of the certificate subject or as a dNSName in the subjectAltName field of the certificate; see RFC6125.  For a host that is an IP address, the client MUST verify that the address appears as an iPAddress in the subjectAltName field of the certificate. If the hostname or address is not present in the certificate, the client MUST NOT consider the server authoritative for origins containing that hostname or address.  See Section 4.3 of SEMANTICS for more detail on authoritative access. </ins> A client MAY attempt access to a resource with an "https" URI by resolving the host identifier to an IP address, establishing a QUIC

Discussion:
The definition of how you determine a certificate matches an origin isn't specific to reuse, so it belongs in the description of establishing a connection. 3.4 now just says that the certificate needs to also be authoritative for any other origins you want to reuse the connection for. The issue also suggested making this easier to understand, so I'd appreciate suggestions for greater clarity without losing the specifics.
Hilarie Orman wrote: >The only problem that I have is that the authentication model for QUIC-HTTP is not explicitly spelled out. The only discussion is in section 3.4 Connection Reuse, and although that section may be technically correct, I find it hard to understand.
For server authentication, which I think is what you're getting at here, 3.2 also mentions the concept of establishing authority, but doesn't go into much detail. I suspect the specifics of comparing a certificate should move to 3.2. I'd appreciate suggestions for making it easier to understand.
Seems fine.This LGTM. It's clear.
Change:
The payload of a CoAP message that is affected by a BERT Option in descriptive usage (Section 2.1 of RFC7959). <ins> For simplicity, a Payload Marker (0xFF) is present in all examples for message formats: The Payload Marker indicates the start of the optional payload and is absent for zero-length payloads (see section 3 of RFC7252). </ins> 2. The request/response interaction model of CoAP over TCP is the same

Discussion:
And changed Len to Len=0 for websocket message format in Figure 14.
URL Figure 4: CoAP frame with 8-bit Extended Length field. This (and neither does the text) does not make clear that the payload marker is sent only if there is a non-zero-length payload. (Same for other below.) Please cf. text from Section 3 of RFC 7252: Figure 14: CoAP Message Format over WebSockets Maybe show 0, not Len here. (This also does not make clear that the payload marker is sent only if there is a non-zero-length payload.)
It's a bit awkward to insert text about the Payload Marker, since other fields are not re-introduced from RFC7252. In RFC8030, we used the Conventions and Terminology section to also provide more context for examples based on feedback from the reviewers. One possibility is to use a similar approach here and indicate that all framing examples have the Payload Marker set. And of course, the "(if any)" would need to be removed. And then there's still the need to clarify the WS case due to the requirement to set the Len to 0 and rely on the WS frame.
Change:
a name, that do not exist in any existing Record in the Pack, the given Record, with all the fields it contains, is added to the Pack. <del> If a Patch Record has a value field with value null, the matched Record (if any) is removed from the Pack. </del> <ins> If a Patch Record has a value ("v") field with value null, the matched Record (if any) is removed from the Pack. </ins> <del> For example, the following document could be given as (i)PATCH </del> <ins> For example, the following document could be given as an (i)PATCH </ins> payload to change/set values of two SenML Records for the example in intro: If the request is successful, the resulting representation of the example SenML Pack would be as follows: <ins> As another example, the following document could be given as an (i)PATCH payload to remove the two SenML Records: </ins> 4. The security and privacy considerations of SenML apply also with the

Discussion:
“Are show”
Should clarify that null value for deleting records should always be in "v" field regardless of the value type used in the Record.
Also example of deleting would be useful
Change:
The ":path" and ":scheme" pseudo-header fields SHALL NOT be empty. Their values SHALL contain the scheme and path from the URI <del> template after the URI template expansion process has been </del> <ins> Template after the URI template expansion process has been </ins> completed. A UDP proxying request that does not conform to these restrictions is malformed (see H2). <del> For example, if the client is configured with URI template </del> <ins> For example, if the client is configured with URI Template </ins> "https://proxy.example.org/{target_host}/{target_port}/" and wishes to open a UDP proxying tunnel to target 192.0.2.42:443, it could send the following request:

Discussion:
-> a URI Template
but also is it "URI Template" or "URI template"? this seems inconsistent through the document
Change:
The discovery response is a JSON document RFC8259 consisting of a single JSON object with the following fields: <del> OPTIONAL.  The URL of the endpoint offering introspection.  The location MUST be a URL RFC3986 with a scheme component that MUST be https, a host component, and optionally, port, path and query components and no fragment components. A list of token formats supported by this AS.  The values in this list MUST be registered in the GNAP Token Format Registry. The URL of the endpoint offering resource registration.  The location MUST be a URL RFC3986 with a scheme component that MUST be https, a host component, and optionally, port, path and query components and no fragment components. REQUIRED.  The location of the AS's grant request endpoint, used by the RS to derive downstream access tokens.  The location MUST be a URL RFC3986 with a scheme component that MUST be https, a host component, and optionally, port, path and query components and no fragment components.  This URL MUST be the same URL used by client instances in support of GNAP requests. OPTIONAL.  A list of the AS's supported key proofing mechanisms. The values of this list correspond to possible values of the "proof" field of the key section of the request. </del> 3.2. Unless otherwise specified, the RS MUST protect its calls to the AS

Discussion:
Deploy Preview for gnap-resource-servers-editors-draft ready! Explore the source changes: 94d11a4362aaea79f357583969d87ec4955655a9 Inspect the deploy log: Browse the preview:
Change:
used for ICE restarts, it will contain a new ICE ufrag/pwd pair. Trickle ICE and ICE restart support is OPTIONAL for a WHIP resource. <del> If Trickle ICE or ICE restarts are not supported by the WHIP </del> <ins> If both Trickle ICE or ICE restarts are not supported by the WHIP </ins> resource, it MUST return a 405 Method Not Allowed response for any <del> HTTP PATCH request. </del> <ins> HTTP PATCH request.  If the WHIP resource supports either Trickle ICE or ICE restarts, but not both, it MUST return a 501 Not Implemented for the HTTP PATCH requests that are not supported. </ins> As the HTTP PATCH request sent by a WHIP client may be received out- of-order by the WHIP resource, the WHIP resource MUST generate a

Discussion:
fix for
Unsure if trickle ICE is mandatory for webrtc or not, but it is optional for the APP point of view: as per rfc8829, 3.5.2. ICE Candidate Trickling: However I think it would not harm to point it out in Section 4.2
PR available here: URL
Is it legal for a server to support Trickle ICE but not ICE Restarts? If that's the case, then the use of 405 is somewhat misleading, since the PATCH method is allowed, just not for ICE Restarts.
I think you are correct, if patch request is not supported the server must return a 405 response, if only ice restarts are not supported it should return a 501 Not Implemented.
Does WebRTC mandate support of ICE restart and trickle ICE? If so, should the WHIP optional support be mentioned in Section 4.2 (WebRTC Constraints)?
Change:
designed to hide.  The use of registered mDNS hostnames SHOULD be scoped by origin, and SHOULD have the lifetime of the page. <del> 3.3. </del> <ins> 4.3. </ins> As noted in IPHandling, privacy may be breached if a web application running in two browsing contexts can determine whether it is running

Discussion:
PR of
Added a 'good' example as well, and put them all in an examples section. PTAL.
Will merge once I get a second approval.
Some of this stuff is complicated, example diagrams can help.
Great to have examples. Regenerating the html, the examples do not show up in full on the html version, probably not a big deal, the txt version is fine.
LGTM
Change:
backward-compatibility. Implementations MUST NOT send zero-length fragments of Handshake or <del> Alert types.  Zero-length fragments of Application data MAY be sent as they are potentially useful as a traffic analysis countermeasure. </del> <ins> Alert types, even if those fragments contain padding.  Zero-length fragments of Application data MAY be sent as they are potentially useful as a traffic analysis countermeasure. </ins> 5.2.2.

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.
Change:
and 'ietf-tcg-algs.yang' ref-ietf-tcg-algs with prefix 'taa'. Additionally, references are made to RFC8032, RFC8017, RFC6933, TPM1.2-Commands, TPM2.0-Arch, TPM2.0-Structures, TPM2.0-Key, <del> TPM1.2-Structures, bios-log, ima-log, BIOS-Log-Event-Type and netequip-boot-log. </del> <ins> TPM1.2-Structures, bios-log, ima-log, BIOS-Log-Event-Type, as well as ima and netequip-boot-log. </ins> 2.1.1.1.

Discussion:
Self-approved
Thanks, this does a good job bridging the gap between what we say in the body of the document and what is available in external references.
Change:
acknowledgement is received, a new RTT is computed and the timer SHOULD be set for twice the newly computed smoothed RTT. <del> When crypto packets are sent, the sender MUST set a timer for the crypto timeout period.  Upon timeout, the sender MUST retransmit all </del> <ins> When a crypto packet is sent, the sender MUST set a timer for the crypto timeout period.  This timer MUST be updated when a new crypto packet is sent.  Upon timeout, the sender MUST retransmit all </ins> unacknowledged CRYPTO data if possible. Until the server has validated the client's address on the path, the

Discussion:
From reading the text, it was not clear that the timer is set based on the last (and not the first) crypto packet sent.
LGTM. I've reworded a bit.
Change:
<del> The application will offer BUNDLE, but mark none of its streams as bundle-only.  This policy will allow all streams to be received by non-BUNDLE-aware endpoints, but require separate candidates to be gathered for each media stream. </del> <ins> Similar to max-bundle, but RTCP candidates are not gathered.  This policy reduces the candidates that must be gathered to the absolute minimum, but will not be compatible with legacy endpoints that do not support RTCP mux. </ins> As it provides the best tradeoff between performance and compatibility with legacy endpoints, the default BUNDLE policy MUST

Discussion:
LGTM
lgtm
If you know the remote side is going to use BUNDLE and RTCP mux, it's desirable to only gather a single set of ports, since the RTCP ports won't be used. Since max-bundle is already trying to minimize port gathering, it should probably assume rtcp mux. If there is a need to keep max-bundle as is, we could also add a fourth policy, e.g. force-bundle, that differs from max-bundle in that it forces use of RTCP mux.
I think we need another one, since currently max-bundle is minimally compatible with old endpoints and if you force rtcp-mux, then you will have ann interop problem. That's what I have on my slides now. Feel free to comment.
I can go with whatever the WG decides.
WG decision is to add an additional policy. Name will be force-bundle unless someone comes up with a better one.
Change:
message.  The first CRYPTO frame sent always begins at an offset of 0; see handshake. <del> Note that if the server sends a HelloRetryRequest, the client will send another series of Initial packets.  These Initial packets will continue the cryptographic handshake and will contain CRYPTO frames starting at an offset matching the size of the CRYPTO frames sent in the first flight of Initial packets. </del> <ins> Note that if the server sends a TLS HelloRetryRequest (see Section 4.7 of QUIC-TLS), the client will send another series of Initial packets.  These Initial packets will continue the cryptographic handshake and will contain CRYPTO frames starting at an offset matching the size of the CRYPTO frames sent in the first flight of Initial packets. </ins> 17.2.2.1.

Discussion:
This should address all of them at once; one per commit for those that I think need action. This is probably OK: This is not expressly forbidden. We do say : Which doesn't really contradict the other. FWIW, I'm not a fan of allowing frames to be copied, implementations really should do that, but it's a consequence of having frame idempotency. This is one I'm not sure about: What is the prevailing advice regarding MTU and tunnels? Clearly when you tunnel you get a smaller MTU, but I haven't seen what happens when IPv6 is tunneled over a network that has a minimum MTU. Most paths don't have that small an MTU, so it might be that things just fail.
I realized that there are some answers here in the description, but probably best to move them to the relevant issues anyways.
NAME said: >
NAME said: with TLS.
NAME said:
NAME said: this true for PATH_CHALLENGE? I thought this quite explicitly shouldn't be copied.
My recommendation is to answer the question, but not change anything. See for an answer.
Very well, please close this issue. Sorry for the confusion.
NAME said: RESET_RECVD.
NAME said:
NAME said:
This looks good to me, with NAME 's nit.
Change:
the JSON Web Token (JWT) format and the related JSON Object Signing And Encryption (JOSE) cryptography suite. <ins> 12.27. If a client instance can request tokens at multiple AS's, and the client instance uses the same keys to make its requests across those different AS's, then it is possible for an attacker to replay a stolen token issued by an honest AS from a compromised AS, thereby binding the stolen token to the client instance's key in a different context.  The attacker can manipulate the client instance into using the stolen token at an RS, particularly at an RS that is expecting a token from the honest AS.  Since the honest AS issued the token and the client instance presents the token with its expected bound key, the attack succeeds. This attack has several preconditions.  In this attack, the attacker does not need access to the client instance's key and cannot use the stolen token directly at the RS, but the attacker is able to get the access token value in some fashion.  The client instance also needs to be configured to talk to multiple AS's, including the attacker's controlled AS.  Finally, the client instance needs to be able to be manipulated by the attacker to call the RS while using a token issued from the stolen AS.  The RS does not need to be compromised or made to trust the attacker's AS. To protect against this attack, the client instance can use a different key for each AS that it talks to.  Since the replayed token will be bound to the key used at the honest AS, the uncompromised RS will reject the call since the client instance will be using the key used at the attacker's AS instead with the same token.  When the MTLS key proofing method is used, a client instance can use self-signed certificates to use a different key for each AS that it talks to, as discussed in security-mtls-patterns. Additionally, the client instance can keep a strong association between the RS and a specific AS that it trusts to issue tokens for that RS.  This strong binding also helps against some forms of security-mixup.  Managing this binding is outside the scope of GNAP core, but it can be managed either as a configuration element for the client instance or dynamically through rs-request-without-token. The details of this attack are available in HELMSCHMIDT2022 with additional discussion and considerations. </ins> 13. The privacy considerations in this section are modeled after the list

Discussion:
Added security considerations for cuckoo token,
Deploy Preview for gnap-core-protocol-editors-draft ready! Explore the source changes: 31f2c2dc7998639fe7801edeaa8334eef14d0963 Inspect the deploy log: Browse the preview:
Client instance uses different keys with each AS Stolen token bound to different keys, RS will reject Client has strong binding between RS and AS used Attacker can’t convince client to use “wrong” AS
Change:
private curves can be used as well. contains the x coordinate for the EC point.  The integer is <del> converted to an octet string as defined in SEC1.  Zero octets MUST NOT be removed from the front of the octet string. </del> <ins> converted to an octet string as defined in SEC1.  Leading zero octets MUST be preserved. </ins> contains either the sign bit or the value of y coordinate for the EC point.  When encoding the value y, the integer is converted to an octet string (as defined in SEC1) and encoded as a CBOR bstr. <del> Leading zero octets MUST be preserved.  When encoding the sign of y, the expression 'y > 0' is evaluated and encoded a CBOR boolean. </del> <ins> Leading zero octets MUST be preserved.  The compressed point encoding is also supported.  Compute the sign bit as laid out in the Elliptic-Curve-Point-to-Octet-String Conversion function of SEC1.  If the sign bit is zero, then encode y as a CBOR false value, otherwise encode y as a CBOR true value.  The encoding of the infinity point is not supported. </ins> contains the private key.

Discussion:
The sign encoding function should deal with other types of curves as well. Make the text refer to the SEC1 encoding function.
Change:
required.  Port ranges can optionally be used. This information MUST be provisioned per DetNet flow via <del> configuration and the controller plane, see m-cp-considerations. </del> <ins> configuration, e.g., via the controller plane described in m-cp- considerations. </ins> Information identifying a DetNet flow is ordered and implementations use the first match.  This can, for example, be used to provide a

Discussion:
import IP over MPLS scenarios from mpls-dp doc, carify non-DetNet IP
Change:
Transport Properties are referred to by property names.  For the purposes of this document, these names are alphanumeric strings in <del> which words may be separated by hyphens.  These names serve two purposes: </del> <ins> which words may be separated by hyphens.  Specifically, the following characters are allowed: lowercase letters "a-z", uppercase letters "A-Z", digits "0-9", the hyphen "-", and the underscore "_".  These names serve two purposes: </ins> Allowing different components of a TAPS implementation to pass Transport Properties, e.g., between a language frontend and a

Discussion:
Note that this PR does not say only the following characters are allowed... it just lists some that are allowed.
At the discussion of Transport Property Names at 4.1, I think you need to be more specific than "alphanumeric". Explicitly list what characters are allowed.
Since we've overspecified already: [A-Za-z0-9_]
Or go back to underspecifying: say they're human-readable textual labels that have namespaces, and don't specify the syntax of exactly how that namespacing works.
Change:
When using HTTP/1.1, a UDP proxying request will meet the following requirements: <del> the method SHALL be "CONNECT". </del> <ins> the method SHALL be "GET". </ins> the request-target SHALL use absolute-form (see H1).

Discussion:
For HTTP/1.1, should the method be "GET" or "CONNECT"? WebSockets uses GET -- are there any uses of "Extended CONNECT" that use CONNECT rather than GET? (issue based on by NAME
In my experience, H1.1 CONNECT for anything but it's intended purpose of proxying will see some deployment problems. The last HTTP spec admits some origins might respect it, but I suspect many HTTP components won't like it. I think sticking with GET plus Upgrade header field is a good choice
At IETF 113, after lengthy discussion the consensus is the room appeared to be to switch to GET so I'm merging so we have a version of the draft ready for WGLC
Change:
as a connection error of type FRAME_ENCODING_ERROR. ACK_FREQUENCY frames are ack-eliciting.  However, their loss does not <del> require retransmission. </del> <ins> require retransmission if an ACK_FREQUENCY frame with a larger Sequence Number value has been sent. </ins> An endpoint MAY send ACK_FREQUENCY frames multiple times during a connection and with different values.

Discussion:
If there's a frame with a larger sequence number, there's no need to retransmit.
Thanks, looks good ;-)
Change:
data in the extensions field.  The actual "Extension" format is defined in extensions.  In TLS 1.3, use of certain extensions is mandatory, as functionality is moved into extensions to preserve <del> ClientHello compatibility with previous versions of TLS. </del> <ins> ClientHello compatibility with previous versions of TLS.  Servers MUST ignore unrecognized extensions. </ins> In the event that a client requests additional functionality using extensions, and this functionality is not supplied by the server, the

Discussion:
Per the recent thread. I could have sworn this was in here, but can't find it... The NewSessionTicket section explicitly says to ignore unknown extensions, so I've added the analogous text to ClientHello and CertificateRequest.