jiebi/CodeConvo huggingface dataset:
Change:
"WithIPv6Address" with an unscoped address and "WithInterface " together. <del> An Endpoint MUST NOT be configured with multiple identifiers of the same type.  For example, an endpoint cannot have two IP addresses specified.  Two separate IP addresses are represented as two Endpoint Objects.  If a Preconnection specifies a Remote Endpoint with a specific IP address set, it will only establish Connections to that IP address.  If, on the other hand, the Remote Endpoint specifies a hostname but no addresses, the Connection can perform name resolution and attempt using any address derived from the original hostname of the Remote Endpoint.  Note that multiple Remote Endpoints can be added to a Preconnection, as discussed in add-endpoints. </del> <ins> The design of the API MUST NOT permit an Endpoint to be configured with multiple identifiers of the same type.  For example, an endpoint cannot have two IP addresses specified.  Two separate IP addresses are represented as two Endpoint Objects.  If a Preconnection specifies a Remote Endpoint with a specific IP address set, it will only establish Connections to that IP address.  If, on the other hand, the Remote Endpoint specifies a hostname but no addresses, the Connection can perform name resolution and attempt using any address derived from the original hostname of the Remote Endpoint.  Note that multiple Remote Endpoints can be added to a Preconnection, as discussed in add-endpoints. </ins> The Transport Services system resolves names internally, when the Initiate(), Listen(), or Rendezvous() method is called to establish a

Discussion:
According to: URL As a small change to Gorry's second proposal, this uses: "The design of the API MUST NOT permit an Endpoint to be configured with multiple identifiers of the same type." instead of: "The design of the API MUST NOT permit an Endpoint to set multiple identifiers of the same type." because it's not the Endpoint itself that is actually doing anything.
looks fine to me On 14/03/2023 10:24, Mirja Kuehlewind wrote: I'm unsure that I precisely understand the diference between /rely upon/ and /depend upon/, in this sentence I'd be happy either with either word "rely" would be fine for me. I think (if I understand your argument) that you say a design will prevent this because that is how we define Endpoint. I'd agree a design of system cannot allow this, but then thenis it any better to state the design requirement as "The design of the API MUST NOT permit an Endpoint to set multiple identifiers of the same type." Gorry
Change:
associate the QUIC DATAGRAM frame with a stream.  If an intermediary receives a QUIC DATAGRAM frame whose payload is too short to allow parsing the Quarter Stream ID field, the intermediary MUST treat it <del> as an HTTP/3 connection error of type H3_GENERAL_PROTOCOL_ERROR. Intermediaries MUST ignore any HTTP/3 Datagram fields after the Quarter Stream ID. </del> <ins> as an HTTP/3 connection error of type H3_GENERAL_PROTOCOL_ERROR.  The Context ID field is optional and its use is negotiated end-to-end, see register-no-context-capsule.  Therefore intermediaries cannot know whether the Context ID field is present or absent and they MUST ignore any HTTP/3 Datagram fields after the Quarter Stream ID. </ins> Endpoints parse both the Quarter Stream ID field and the Context ID field in order to associate the QUIC DATAGRAM frame with a stream and

Discussion:
Contexts are end-to-end, and intermediaries MUST NOT parse them.
In , capsules, contexts and context IDs are explicitly defined as end-to-end and there are requirements for intermediaries to not modify them, and to not even parse them. The motivation for this was to ensure that we retain the ability to deploy extensions end-to-end without having to modify intermediaries. NAME mentioned that these requirements might be too strict, as he would like to have his intermediary be able to parse the context ID, for logging purposes.
Part of the comment from the PR is also about consistency of interface for generic HTTP libraries that can be used to build either endpoints or intermediaries. If the context ID is always present, it's overly prescriptive to say that an intermediary can't parse it, and such a requirement couldn't be enforced anyways. If context IDs are negotiated on/off, whether this is possible depends on the negotiation mechanism.
I think its fine for a component that has bytes passing through it to look at those bytes. The import thing to do is set expectations on what that means for the protocol behaviour we are defining. We don't expect intermediaries to do anything with a context ID; they should not enforce the protocol semantic rules (odd, even, reuse etc). H2 and H3 somewhat solve this problem by decoupling frame parsing from frame payload interpretation. E.g. if the form of a request or response is invalid, an intermediary shouldn't pass it on. DATAGRAM is different because it isn't defined as an actual HTTP/3 frame with frame headers and frame payload. Something that might work is to formalise that quarter stream ID is part of the envelope that intermediaries have to be able to handle the syntax of, but context ID is part of content and separate.
Unless you encrypt capsules end-to-end, I don't think any text in the spec can in practice prevent intermediaries from inspecting and modifying capsules. You can send something like GREASE capsules, though.
LGTM! :shipit:
Change:
The API MUST be extensible to support future use-cases by allowing extensible information elements. <del> The API MUST use TLS for privacy and server authentication.  The implementation of the API MUST ensure both privacy and integrity of any information provided by or required by it. </del> <ins> The API MUST use TLS to ensure server authentication.  The implementation of the API MUST ensure both confidentiality and integrity of any information provided by or required by it. </ins> This document does not specify the details of the API. 2.4. <del> The Captive Portal Enforcement component restricts network access to User Equipment according to site-specific policy.  Typically User </del> <ins> The Captive Portal Enforcement component restrict the network access of User Equipment according to site-specific policy.  Typically User </ins> Equipment is permitted access to a small number of services and is <del> denied general network access until it has performed some action. </del> <ins> denied general network access until it satisfies the Captive Portal Conditions. </ins> The Captive Portal Enforcement component:

Discussion:
Happy to elaborate on them if the motivation is not clear from the changes, let me know!
Thanks NAME b1dc7ba4e26ab17ed12d8a5a2408fe8063b1177a accepts the suggestion. 509d855e5ddba7dd1c5db58646c85516d0b40987 corrects the mistake I had made, which your question was about.
Looks great. Thanks for the PR!
Change:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP <del> 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. </del> <ins> 14 RFC8174 when, and only when, they appear in all capitals, as shown here. </ins> 3.

Discussion:
Sure - happy to add text of this sort if we think it would be valuable. OK. :-) OK.
S 3. That said, I could get behind switching 'will' to 'can', as is used in S3, category . S 6.2. This seems like a good addition.
When I say "local" here, I am referring to the fact that the IP address is local to the machine, rather than an address for a remote party. To avoid confusion, I probably could just omit the word altogether here. Regarding NATing, your observation is often correct, but NAT64 is becoming increasingly common. I could just clarify and say that overall IPv6 avoids the issue through use of 4941 addresses.
The most obvious case is a NAT64 scenario, where the IPv6 address is never seen by the outside world, and therefore exposing said address to the web site presents a potential leakage concern. This concern is significantly mitigated if the IPv6 address is a RFC4941 ephemeral address.
Change:
All implementations MUST send and use these extensions when offering applicable features: <del> "supported_versions" is REQUIRED for all ClientHello messages. </del> <ins> "supported_versions" is REQUIRED for all ClientHello, ServerHello and HelloRetryRequest messages. </ins> "signature_algorithms" is REQUIRED for certificate authentication.

Discussion:
This is mentioned throughout the document, but not in the "Mandatory-to-Implement" section.
This is the same as , just without the extra new line additions, etc
In the section it states: In the section we have: However, this is not mentioned in the "Mandatory-to-Implement" extensions section.
Change:
When a non-default port number is part of a service identifier, Port- Prefix Naming places the port number in an additional a prefix on the name.  For example, SVCB records for a DNS service identified as <del> "dns1.example.com:9953" would be located at "_9953._dns.dns1.example.com".  If two DNS services operating on </del> <ins> ""dns1.example.com:9953"" would be located at ""_9953._dns.dns1.example.com"".  If two DNS services operating on </ins> different port numbers provide different behaviors, this arrangement allows them to preserve the distinction when specifying alternative endpoints.

Discussion:
The lack of quoting in some of the examples might make it harder to see what constitutes example and what is punctuation. Highlighting and fonts in the HTML rendering are subtle and not present in text renderings (any more). I've also changed some section references. I'm happy to split that off into a different change or use the form if you prefer that.
Change:
The _direct path_ of a root is the empty list, and of any other node is the concatenation of that node with the direct path of its parent. The _copath_ of a node is the list of siblings of nodes in its direct <del> path, excluding the root, which has no sibling.  The _frontier_ of a tree is the list of heads of the maximal full subtrees of the tree, ordered from left to right. </del> <ins> path.  The _frontier_ of a tree is the list of heads of the maximal full subtrees of the tree, ordered from left to right. </ins> For example, in the below tree:

Discussion:
NAME Hi Brendan ! Would you mind please revert the last of the 3 changes. Even though the sentence is not amazing and your change correct, I find it better to keep explicit the fact that the root should not be included, instead of having to infer it from the fact it has no siblings :) Thanks !
You don't have to infer it -- direct paths are defined to never include the root node in the sentence just before.
Change:
be https, a host component, and optionally, port, path and query components and no fragment components. <del> A list of token formats supported by this AS. </del> <ins> A list of token formats supported by this AS.  The values in this list MUST be registered in the GNAP Token Format Registry. </ins> The URL of the endpoint offering resource registration.  The location MUST be a URL RFC3986 with a scheme component that MUST

Discussion:
Adds registry and discussion for access token formats and where they could be used in the protocol, particularly as part of discovery from the AS. Addresses
:heavycheckmark: Deploy Preview for gnap-resource-servers-editors-draft ready! :hammer: Explore the source changes: 99546a7caad92bf2495cb9416f5e4604f9fcc7c0 :mag: Inspect the deploy log: :sunglasses: Browse the preview:
Section 3.1 mentions: A sub-section describing the structure of this list of token formats is currently missing.
In section 2. Access Token Formats, the text states: Token formats can be the topic of agreements between the AS and RS , if the AS has prior relationships with every RS. However, it should be mentioned that the access token format can also be negotiated. Add:
The negotiation is between the AS and RS, not the client. This spec is about negotiation between the AS and RS.
Change:
token, it MUST attempt to validate the token, unless it has already completed address validation.  If the token is invalid then the server SHOULD proceed as if the client did not have a validated <del> address, including potentially sending a Retry.  If the validation succeeds, the server SHOULD then allow the handshake to proceed. </del> <ins> address, including potentially sending a Retry.  A server SHOULD encode tokens provided with NEW_TOKEN frames and Retry packets differently, and validate the latter more strictly.  If the validation succeeds, the server SHOULD then allow the handshake to proceed. </ins> The rationale for treating the client as unvalidated rather than discarding the packet is that the client might have received the token in a previous connection using the NEW_TOKEN frame, and if the server has lost state, it might be unable to validate the token at all, leading to connection failure if the packet is <del> discarded.  A server SHOULD encode tokens provided with NEW_TOKEN frames and Retry packets differently, and validate the latter more strictly. </del> <ins> discarded. </ins> In a stateless design, a server can use encrypted and authenticated tokens to pass information to clients that the server can later

Discussion:
I think that this can be this simple.
section: Address Validation for Future Connections The following RFC2119 keyword appears within a note, which seems wrong, could the RFC2119 recommendation be moved outside of the note?: /A server SHOULD encode tokens provided with NEW_TOKEN frames and Retry packets differently, and validate the latter more strictly./
Change:
BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. <ins> This document contains non-normative examples of partial and complete HTTP messages, JSON structures, URLs, query components, keys, and other elements.  Some examples use a single trailing backslash '' to indicate line wrapping for long values, as per RFC8792.  The "" character and leading spaces on wrapped lines are not part of the value. </ins> 2. When the AS issues an access token for use at an RS, the RS needs to

Discussion:
Deploy preview for gnap-resource-servers-editors-draft ready! Built with commit 24fa4dc27f079697512f5eb15ca85b15f1c7ec62 https://deploy-preview-1--gnap-resource-servers-editors-URL
Change:
4.3.7. The location where a target should find a payload MUST be <del> authenticated. </del> <ins> authenticated.  Remote resources need to receive an equal amount of cryptographic protection as the manifest itself, when dereferencing URIs.  The security considerations of Uniform Resource Identifiers (URIs) are applicable RFC3986. </ins> Mitigates: threat-net-redirect,

Discussion:
Section 4 We should probably mention the URI security considerations (RFC 3986) somewhere, as well as that remote resources need to receive an equal amount of cryptographic protection as the manifest itself, when dereferencing URIs.
Addressed in URL
Addressed in draft-ietf-suit-information-model-11
It might also be worth reiterating the topic that came up during one of the other review threads: firmware update is by definition remote code execution, so if you trust an entity to provide your firmware, you are trusting them to do the right thing. Many classes of attack involving malicious or modified payloads then become irrelevant, so we are left with just needing to verify that it did come from a trusted party and is not going backwards, topics that are covered quite well already (including TOCTOU).
Addressed in URL
Addressed in draft-ietf-suit-information-model-11
Change:
This limit does act as an additional constraint on datagram size in the same way as the path MTU, but it is a property of the <del> endpoint and not the path.  It is expected that this is the space an endpoint dedicates to holding incoming packets. </del> <ins> endpoint and not the path; see packet-size.  It is expected that this is the space an endpoint dedicates to holding incoming packets. </ins> The initial maximum data parameter is an integer value that contains the initial value for the maximum amount of data that can

Discussion:
I did not add a citation for MAX_PLPMTU as that is subtly different and that seems like it would be more of a liability than a help in this case.
Text looks OK.
In maxudppayloadsize (0x03) the following text seems good: /This limit does act as an additional constraint on datagram size in the same way as the path MTU, but it is a property of the endpoint and not the path./ could it refer to the appropriate section in the QUIC spec? In DPLPMTUD the same value is known as “MAXPLPMTU”, Section 5.3.1 - in case you wish to cite that.
MAX_PLPMTU is slightly different as it refers to the IP layer, but you are right that it constrains the same underlying variable. I'll add a cross-reference though.
Change:
view. Switch from using a map to using an array at the message level. <del> While this change means that it is no longer possible to new named parameters to the top level message, it also means that there is not a need to define how older implementations are defined to behave when new fields are present.  Most of the reasons that a new field would need to be defined are adequately addressed by defining a new parameter instead. </del> <ins> While this change means that it is no longer possible to add new named parameters to the top level message, it also means that there is not a need to define how older implementations are defined to behave when new fields are present.  Most of the reasons that a new field would need to be defined are adequately addressed by defining a new parameter instead. </ins> Signed messages separate the concept of protected and unprotected attributes that are for the content and the signature.

Discussion:
The majority of changes prior to the examples section are to address typos or what I saw as inconsistencies. I will admit I wasn't as diligent as I should have been on those, but I need to take another pass on the document. The examples were reformatted to minimize side scrolling -- and likely fit within the TXT representation.
Change:
signature is a digital signature using that algorithm.  The signature scheme MUST be a valid signature scheme for TLS 1.3.  This excludes all RSASSA-PKCS1-v1_5 algorithms and ECDSA algorithms that are not <del> supported in TLS 1.3.  For servers, this signature scheme must match one of the signature and hash algorithms advertised in the signature_algorithms extension of the ClientHello.  The signature is computed using the over the concatenation of: </del> <ins> supported in TLS 1.3.  If an authenticator request is present, the signature algorithm MUST be chosen from one of the signature schemes in the authenticator request.  Otherwise, the signature algorithm used should be chosen from the "signature_algorithms" extension of the ClientHello used in the connection handshake. The signature is computed using the over the concatenation of: </ins> A string that consists of octet 32 (0x20) repeated 64 times

Discussion:
Add new "authenticator request" message Make Certificate selection more explicit (including extensions) Update API considerations accordingly
I update the draft in response to the comments.
Two small comments: Can you add text explaining why authenticator requests are not encrypted with handshake keys? (Are they encrypted at all?) It might help to include a sequence diagram or two showing intended uses of exported authenticators, e.g., for Mike's draft, and where requests fit into TLS connections.
NAME I'm not sure what purpose encrypting them would serve. The draft does say that "The application layer protocol used to send the authenticator SHOULD use TLS as its underlying transport." In other words, the messages have integrity built-in and any desire for confidentiality is the app's to solve.
NAME I was referring to the following sentence: "This message is not encrypted with a handshake key, which differs from how this message is used in TLS 1.3." Perhaps you could add text explaining why this choice was made?
By the time you use this, handshake keys might be long gone. I think that we could avoid this confusion by stating that this is only the handshake messages and not records that form the authenticator. And maybe add that because there are no records, there is no record protection.
Change:
sdp, Section 5.1, and, if appropriate, an "a=max-message-size" line, as defined in I-D.ietf-mmusic-sctp-sdp, Section 6.1. <del> As discussed above, the following attributes are included only if the m= section either has a unique address or is associated with the bundle-tag: "a=ice-ufrag", "a=ice-pwd", "a=fingerprint", "a=dtls-id", and "a=setup". </del> <ins> As discussed above, the following attributes of category IDENTICAL or TRANSPORT are included only if the data m= section either has a unique address or is associated with the bundle-tag (e.g., if it is the only m= section): "a=ice-ufrag" "a=ice-pwd" "a=fingerprint" "a=setup" "a=dtls-id" </ins> Once all m= sections have been generated, a session-level "a=group" attribute MUST be added as specified in RFC5888.  This attribute MUST

Discussion:
NAME PTAL at this. I realized the answer section also needed to be updated to match the new offer text, so I made some changes there which involved a bit of massaging of the text added in .
LGTM
Change:
payload. After verifying the authentication tag as described in aggregate- <del> message-auth, the helper handles the AggregateInitReq by computing the initial preparation state for each ReportShare in </del> <ins> message-auth, the helper first checks that the nonces in "AggregateInitReq.seq" are all distinct.  If two ReportShare messages have the same nonce, then the helper MUST abort with error "unrecognizedMessage".  Next, the helper handles the AggregateInitReq by computing the initial preparation state for each ReportShare in </ins> "AggregateInitReq.seq" as described in prep-start.  It then constructs an AggregateResp:

Discussion:
Minor changes/clarifications: Clarify how to handle empty Transition sequences Handle repeated nonces by aborting. While at it, this changes how the helper handles unrecognized nonces to be consistent with how the leader handles unrecognized nonces. Move task/job ID to top of AggregateReq