jiebi/CodeConvo huggingface dataset:
Change:
PATH_ABANDON frames SHOULD be acknowledged.  If a packet containing a PATH_ABANDON frame is considered lost, the peer SHOULD repeat it. <del> PATH_ABANDON frames MAY be sent on any path, not only the path on which the referenced Destination Connection ID is used. 8.2. </del> <ins> 8.3. </ins> PATH_STATUS Frame are used by endpoints to inform the peer of the current status of one path, and the peer should send packets

Discussion:
The ACKMP text does not change, it just comes before PATHABANDON and PATHSTATUS. The rationale is that 1) the new order follows the encoding numbering (lowest to highest), and 2) the ACKMP is a critical frame, the PATHABANDON is an important one yet still "indicative" (it suggests the peer to abandon this path) and the PATHSTATUS frame is an indicative one.
Just to not forget this, but this is mostly editorial. Probably present first the ACKMP frame, and then PATHABANDON and PATHSTATUS Drop reference to I-D.liu-multipath-quic as the PATHSTATUS frame is now integrated in the draft. Based on and , and If we agree on , we could also drop the text in PATh_ABANDON stating that on any path, not only the path on which the referenced Destination Connection ID is used.
OK. It's reasonable.
Change:
have been generated at boot, and then used in claims as long as the signer can guarantee that they cannot have changed since boot. <del> 11. </del> <ins> 10. </ins> The conveyance of Evidence and the resulting Attestation Results reveal a great deal of information about the internal state of a

Discussion:
Addresses issue There's no text changes in this PR, text is just moved without modification. Signed-off-by: Dave Thaler
otherwise, the section 4.1 including a lot of content about attester, attesting enviroment and target enviroment are not easy to understand. Or, at least, have some general introduction or reference to section 6 about what is relation between them.
Agree, Section 6 "Two Types of Environments of an Attester" gives the introduction to these terms, but they are used back in section 4.1 "Composite Attester". Something needs to change either move section 6 up, or section 4.1 down.
Change:
DNS API clients using the DNS wire format MAY have one or more EDNS extensions RFC6891 in the request. <ins> The media type is "application/dns-udpwireformat". </ins> 4.2. These examples use HTTP/2 style formatting from RFC7540.

Discussion:
Make clear here that it doesn't intrinsically come with a content-length limit, despite traditional DNS message length limits?
I merged this in a race condition with NAME 's comments. I support that change, but its a little different than the bug that drove this. NAME can you just make the change directly and minimally in this same text?
it could use a preview to help the reader orient herself
See
Change:
most preferred cipher suite of those (note that error messages are not authenticated and may be forged). <del> Generate an ephemeral ECDH key pair as specified in Section 5 of SP-800-56A using the curve in the selected cipher suite and format it as a COSE_Key.  Let G_X be the 'x' parameter of the COSE_Key. </del> <ins> Generate an ephemeral ECDH key pair using the curve in the selected cipher suite and format it as a COSE_Key.  Let G_X be the 'x' parameter of the COSE_Key. </ins> Choose a connection identifier C_I and store it for the length of the protocol.

Discussion:
This was suggested in CFRG during the discussion on HPKE Elliptic-Curve-Point-to-Octet-String Conversion. The compact representation used in EDHOC can be used whenever compact output is used in ECDH (which it almost always is). Important to differenctiate between the wire format, the validation done, and the algorithm for multiplication. EDHOC only touch the wire format, and do not loosen any validation requirements or recommend any particular algorithms form multiplication. Suggestion oflline that it might be better to specify that the "y-bit" is set to 0 instead of giving the implementor an option. Suggestion offline that the draft should refer to SECG in addition or instead of NIST.
I made a PR trying to capture the suggestion from CFRG. I think the PR is ready to merge.
on page 14 would it not be suitable to add that IDCREDx = { x5chain : certificate in DER }, for x = I or R,
Very timely comment. I just made an update to this effect, see b5346fb. I didn't want to include this kind of notation as it requires explanation. Is it good enough?
Suggest to give it a bullet as well. Göran Selander schreef op 2021-02-22 11:26: Links: [1] URL [2] URL [3] URL
Change:
%%% Key Exchange Messages <del> X and Y respectively are the binary representations of the X and Y </del> <ins> X and Y respectively are the binary representations of the x and y </ins> values in network byte order.  There are no internal length markers, so each number representation occupies as many octets as implied by the curve parameters.  For P-256 this means that each of X and Y use

Discussion:
I might do "both integers x and y" but I can see how it would be okay as-is.
Change:
IANA [SHALL update/has updated] this registry to include the "key_share", "pre_shared_key", "psk_key_exchange_modes", "early_data", "cookie", "supported_versions", <del> "certificate_authorities", "oid_filters", and "post_handshake_auth" extensions with the values defined in this document and the Recommended value of "Yes". </del> <ins> "certificate_authorities", "oid_filters", "post_handshake_auth", and "signature_algorithms_certs", extensions with the values defined in this document and the Recommended value of "Yes". </ins> IANA [SHALL update/has updated] this registry to include a "TLS 1.3" column which lists the messages in which the extension may

Discussion:
The only thing that might need text (though I'm not certain) is that this doesn't describe what it means to have signaturealgorithmscert and not signaturealgorithms. I assume that it means that a signature isn't possible. However, in previous versions it would be interpreted to mean something else based on default values for signaturealgorithms.
Change:
seeing the details of the model. This typically works by having some protected environment in the <del> device attest to some manufacturer service.  If remote attestation succeeds, then the manufacturer service releases either the model, or a key to decrypt a model the Attester already has in encrypted form, to the requester. </del> <ins> device go through a remote attestation with some manufacturer service that can assess its trustworthiness.  If remote attestation succeeds, then the manufacturer service releases either the model, or a key to decrypt a model the Attester already has in encrypted form, to the requester. </ins> A device desiring to run an ML model to do inferencing

Discussion:
Diffs look longer than they really are just because text was moved around due to the ordering point raised on the design team call. Also, I found that "Verifying Relying Party" was used in this section without actually being defined so I defined it in context in that sentence (line 686). Also added subsection headings for each role to make it easier to read and refer to. The "recursion" aspect is dealt with by example in the new text starting at line 692, which was the simplest way I could find to do it, where I found that trying to use the term "recurse" or similar just made it harder for me to understand. Other places just refer back to that example. Signed-off-by: Dave Thaler
Change:
by their account keys, so this overall goal breaks down into two more precise goals: <del> Only an entity that controls a identifier can get an account key </del> <ins> Only an entity that controls an identifier can get an account key </ins> authorized for that identifier Once authorized, an account key's authorizations cannot be

Discussion:
editorial change
These LGTM as editorial. I note that the inclusion of "revoked" in URL is on the edge, but I think it was intended and could be merged as a result.
I did think the mentioned change might be an edge case, too, but came to the same conclusion. Happy to be of any help.
LGTM as well. Thanks NAME
Change:
Pass AD_1 to the security application. <del> If any verification step fails, the Initiator MUST send an EDHOC </del> <ins> If any verification step fails, the Responder MUST send an EDHOC </ins> error message back, formatted as defined in error, and the protocol MUST be discontinued.  If the Responder does not support the selected cipher suite, then SUITES_R MUST include one or more supported cipher

Discussion:
When the responder is processing message 1, section 4.4.3 reads: If any verification step fails, the Initiator MUST send an EDHOC error message back, formatted as defined in Section 5, and the protocol MUST be discontinued. I think this should be: If any verification step fails, the MUST send an EDHOC error message back, formatted as defined in Section 5, and the protocol MUST be discontinued. PR: URL
Change:
records, there MUST NOT be any other records between them. Handshake messages MUST NOT span key changes.  Because the <del> ServerHello, Finished, and KeyUpdate messages signal a key change, upon receiving these messages a receiver MUST verify that the end of these messages aligns with a record boundary; if not, then it MUST terminate the connection with an "unexpected_message" alert. </del> <ins> ClientHello, EndOfEarlyData, ServerHello, Finished, and KeyUpdate messages can arrive immediately prior to a key change, upon receiving these messages a receiver MUST verify that the end of these messages aligns with a record boundary; if not, then it MUST terminate the connection with an "unexpected_message" alert. </ins> Implementations MUST NOT send zero-length fragments of Handshake types, even if those fragments contain padding.

Discussion:
An EndOfEarlyData message signals a key change. A ClientHello can be the last message read before a key is changed, and it never makes sense for a ClientHello to have more data after it in the record.
Change:
have some means of understanding what the access token is for in order to determine how to respond to the request.  The core GNAP protocol makes no assumptions or demands on the format or contents of <del> the access token, but such token formats can be the topic of agreements between the AS and RS. </del> <ins> the access token, and in fact the token format and contents are opaque to the client instance.  However, such token formats can be the topic of agreements between the AS and RS. </ins> Self-contained structured token formats allow for the conveyance of information between the AS and RS without requiring the RS to call <del> the AS at runtime as described in introspection. </del> <ins> the AS at runtime as described in introspection.  Structured tokens can also be used in combination with introspection, allowing the token itself to carry one class of information and the introspection response to carry another. </ins> Some token formats, such as Macaroons and Biscuits, allow for the RS to derive sub-tokens without having to call the AS as described in token-chaining. <ins> The supported token formats can be communicated dynamically at runtime between the AS and RS in several places. The AS can declare its supported token formats as part of RS- facing discovery The RS can require a specific token format be used to access a registered resource set The AS can return the token's format in an introspection response In all places where the token format is listed explicitly, it MUST be one of the registered values in the GNAP Token Formats Registry iana- token-format. </ins> 3. To facilitate runtime and dynamic connections, the AS can offer an

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:
4.3. <del> A Composite Attester is an entity composed of multiple sub-entities </del> <ins> A Composite Device is an entity composed of multiple sub-entities </ins> such that its trustworthiness has to be determined by the appraisal <del> of all these sub-entities.  Each sub-entity has at least one Attesting Environment collecting the claims from at least one Target Environment, then this sub-entity generates Evidence about its trustworthiness.  Therefore each sub-entity can be called an Attester.  Among these Attesters, there may be only some, which can be called Lead Attesters, that have the ability to communicate with the Verifier.  Other Attesters don't have this ability, but they are connected to the Lead Attesters via internal links or network connections, and they are appraised by the Lead Attester's. For example, a carrier-grade router is a composite device consisting of a chassis and multiple slots.  The trustworthiness of the router depends on all its slots' trustworthiness.  Each slot has an Attesting Environment such as a TEE collecting the claims of its boot process, after which it generates Evidence from the claims.  Among these slots, only a main slot can communicate with the Verifier while other slots cannot.  But other slots can communicate with the main slot by the links between them inside the router.  So the main slot collects the Evidence of other slots, produces the final Evidence of the whole router and conveys the final Evidence to the Verifier. Therefore the router is a Composite Attester, each slot is an Attester, and the main slot is the Lead Attester. </del> <ins> of all these sub-entities. Each sub-entity has at least one Attesting Environment collecting the claims from at least one Target Environment, then this sub-entity generates Evidence about its trustworthiness.  Therefore each sub- entity can be called an Attester.  Among all the Attesters, there may be only some which have the ability to communicate with the Verifier while others do not. For example, a carrier-grade router is consists of a chassis and multiple slots.  The trustworthiness of the router depends on all its slots' trustworthiness.  Each slot has an Attesting Environment such as a TEE collecting the claims of its boot process, after which it generates Evidence from the claims.  Among these slots, only a main slot can communicate with the Verifier while other slots cannot.  But other slots can communicate with the main slot by the links between them inside the router.  So the main slot collects the Evidence of other slots, produces the final Evidence of the whole router and conveys the final Evidence to the Verifier.  Therefore the router is a Composite Device, each slot is an Attester, and the main slot is the transiting Attester. </ins> Another example is a multi-chassis router composed of multiple single carrier-grade routers.  The multi-chassis router provides higher

Discussion:
This changes may of the Composite Attester->Composite Device. It updates the diagram a bit, but it does not go as far as . The terms "lead Attester" are retained, but not as new term ("lead", not "Lead"). The Attesting Environment is not pluralized.
Change:
See the Retry Packet Integrity section of QUIC-TLS. <ins> 17.2.5.1. </ins> The server populates the Destination Connection ID with the connection ID that the client included in the Source Connection ID of the Initial packet.

Discussion:
This was getting a little long. You could get lost in there. The text was fine, it was mostly well structured. All it needed was one small move and some headers.
Change:
MTUs can vary.  TODO: Describe how the path MTU can be computed, specifically propagation across HTTP proxies. <del> 4.4. </del> <ins> 4.5. </ins> In WebTransport over HTTP/3, the client MAY send its SETTINGS frame, as well as multiple WebTransport CONNECT requests, WebTransport data

Discussion:
NAME NAME NAME Updated the PR; please take another look.
I think I addressed all issues; please tell me if I'm missing anything, if not, I'll merge this soon. cc NAME NAME NAME
Since the API was based off QuicTransport, the API document currently has a method to close the session, with both an error code and a reason string (modeled off QUIC CONNECTION_CLOSE): . We could attempt to reset the CONNECT stream, but that would imply that it's always reset, and will not let us supply a reason string. I think the easiest way would be to send trailers on the CONNECT stream.
If we want to allow trailers (or any non DATA frames) on the CONNECT stream, we need to add text allowing that. From the H3 spec: Once the CONNECT method has completed, only DATA frames are permitted to be sent on the stream. Extension frames MAY be used if specifically permitted by the definition of the extension.
Issue also discusses adding a GOAWAY-type frame on the CONNECT stream. If we did that we could add an error and reason there as an alternative to trailers.
Just minor nits, looking good!
Change:
7.1.5. <ins> Final is a boolean property.  If true, this Message is the last one that the application will send on a Connection.  This allows underlying protocols to indicate to the Remote Endpoint that the Connection has been effectively closed in the sending direction.  For example, TCP-based Connections can send a FIN once a Message marked as Final has been completely sent.  Protocols that do not support signalling the end of a Connection in a given direction will ignore this property. Note that a Final Message must always be sorted to the end of a list of Messages.  The Final property overrides Niceness and any other property that would re-order Messages.  If another Message is sent after a Message marked as Final has already been sent on a Connection, the new Message will report an error. 7.1.6. </ins> This numeric property specifies the length of the section of the Message, starting from byte 0, that the application assumes will be received without corruption due to lower layer errors.  It is used to

Discussion:
Satisfies
Okay, addressed capitalization and took Brian's suggested paragraph (with one tiny change).
Fine with me - go ahead
NAME NAME any further comments on this one?
ship it
Sorry, seems I should have clicked "approve" earlier. Still being clumsy in github :(
Change:
said library would implement a given signaling protocol along with its state machine and serialization code, presenting a higher-level call-oriented interface to the application developer.  For example, <del> libraries exist to adapt the JSEP API into an API suitable for a SIP interface or an Extensible Messaging and Presence Protocol (XMPP) interface RFC6120.  Thus, JSEP provides greater control for the experienced developer without forcing any additional complexity on the novice developer. </del> <ins> libraries exist to provide implementations of the SIP RFC3261 and Extensible Messaging and Presence Protocol (XMPP) RFC6120 signaling protocols atop the JSEP API.  Thus, JSEP provides greater control for the experienced developer without forcing any additional complexity on the novice developer. </ins> 1.2.

Discussion:
Updated a few sentences in Section 1 regarding XMPP and SIP libraries and the API surface. Removed comments. issue 5 and issue 6.
6) [rfced] Section 1.2: We had trouble parsing this sentence. If the suggested text is not correct, please clarify "as well as creating ..." Original (the previous sentence is included for context): A second approach that was considered but not chosen was to decouple the management of the media control objects from session descriptions, instead offering APIs that would control each component directly. This was rejected based on the argument that requiring exposure of this level of complexity to the application programmer would not be beneficial; it would result in an API where even a simple example would require a significant amount of code to orchestrate all the needed interactions, as well as creating a large API surface that needed to be agreed upon and documented. Suggested: This was rejected based on the argument that requiring exposure of this level of complexity to the application programmer would not be beneficial; it would (1) result in an API where even a simple example would require a significant amount of code to orchestrate all the needed interactions and (2) create a large API surface that needed to be agreed upon and documented.
This mostly LGTM, but the final sentence reads a bit oddly now - perhaps
Change:
It is expected that any QoS handling in the network, e.g. based on use of DiffServ Code Points (DSCPs) RFC2475 as well as Equal-Cost Multi-Path (ECMP) routing, is applied on a per flow-basis (and not <del> per-packet) and as such that all packets belonging to the same QUIC connection get uniform treatment. </del> <ins> per-packet) and as such that all packets belonging to the same active QUIC connection get uniform treatment. </ins> Using ECMP to distribute packets from a single flow across multiple network paths or any other non-uniform treatment of packets belong to

Discussion:
Section 4.8 of manageability draft expects that a per-flow basis DSCP and ECMP routing policy is used to ensure same treatment for all the packets belonging to same QUIC connection. I was wondering how does path migration impacts this? As the new path ,potentially via another network, has no idea about QUIC connection insuring all packets belonging to the same QUIC connection get uniform treatment will be difficult. what am I missing here?
During path migration the congestion control is reset and therefore there is no assumption anymore that those packets need to be treated similarly.
Ok then packets belonging to same QUIC connection can be treated differently after path migration. I think it would be good to clarify it.
This is effectively already what the manageability draft says because it says QoS handling should be applied on a per flow basis where a flow is the 5 tuple. If there is a path migration event, the 5-tuple changes. The path does need to be QUIC aware and should not use the CID.
NAME can we close this issue?
Potentially yes, but would have been better to put a ref. here to the section where this "If there is a path migration event, the 5-tuple changes. The path does need to be QUIC aware and should not use the CID." is discussed. if things are not discussed or referred in one place then one has to infer the same reasoning/conclusion, which I think not always obvious.
Okay, I added another clarifying sentence and a reference to section 3.5 in PR
Change:
The Provisioning Service, API Server, and User Portal are described as discrete functions.  An implementation might provide the multiple <del> functions within a single entity. </del> <ins> functions within a single entity.  Furthermore, these functions, combined or not, as well as the Enforcement Device, could be replicated for redundancy or scale. </ins> 3.

Discussion:
It makes sense that in a network each component would have multiple replicas for redundancy and scale. Mention that.
Pointed out during review: we mention that components may be logically combined, but we don't talk about redundancy or scale.