jiebi/CodeConvo huggingface dataset:
Code change:
If the Protocol Stack includes a transport protocol that supports multipath connectivity, an update to the available paths should inform the Protocol Instance of the new set of paths that are <del> permissible based on the Path Selection Properties passed by the </del> <ins> permissible based on the Selection Properties passed by the </ins> application.  A multipath protocol can establish new subflows over new paths, and should tear down subflows over paths that are no longer available.  If the Protocol Stack includes a transport

Related discussion:
text: Connection properties really are about configuring something, but I still say that being able to use them as early input is good. I agree that the implementation isn't super clear as they don't come with a require/prefer/... etc. qualifier, but then we just offer some freedom to implementers.
NAME I just pushed a commit that updates the selection and connection properties text, removing "connection" almost everywhere, but adding a disclaimer in the beginning that says that connection properties should be configured as early as possible because they can influence decisions made by the implementation, and "In the remainder of this document, we only refer to Selection Properties because they are the more typical case." Frankly I'm not sure this is better... but it does remove most of the "selection and connection" double mentions that you pointed out.
Fixed up branch building and resolved merge conflicts. I'll merge this in later today before the posting deadline.
Cool thanks! Sorry if I messed something up
As discussed in
Thank you for updating this – looks good! just needs s/send-params/msg-properties/ and merging
Code change:
defined. The protocol must use a secure transport that meets the <del> requirements for modern https://. </del> <ins> requirements for modern HTTPS. </ins> 4.1.

Related discussion:
text: I think that we should specify behaviour for truncated responses with the TC bit more clearly. Right now the text is a little vague. There seem to be three options: mandate the generation of an HTTP error mandate the forwarding of the truncated response explicitly allow either forbid the use of truncated responses and recommend fallback to TCP if the DNS API server is just making DNS requests to another server I think that the draft current vacilates in the direction of 3, but I tend to like 1 or 4. Choosing 4 wouldn't be consistent with the dnsop DNS-over-HTTP draft using DOH though.
is the right answer, so the text should just be stronger about it. If DOH requires or , that means that the DNS server code will need to be heavily reworked to capture these from going out, which seems pointless. DOH clients can act like normal stubs: either they do or don't know about truncation and TC.
I agree - I don't think doh needs to behave differently here than any other datagram based client - i.e. its not a transport error. NAME can you do a pr to clarify?
Will do.
Code change:
Additionally to the previous section, the following applies when Observe is supported. <del> Observe allows re-registration of observations (see 3.3.1 of RFC7641).  A server receiving an Observe registration identical to a previously stored one (including Partial IV and Token) SHALL treat it as valid and reply with the last notification sent. </del> <ins> 7.4.1.1. </ins> A client receiving a notification SHALL compare the Partial IV of a received notification with the Notification Number associated to that <del> Observe registration.  Observe reordering MUST be linked to OSCORE's ordering of notifications.  The client MAY do so by copying the least significant bytes of the Partial IV into the Observe option, before passing it to CoAP processing.  If the verification of the response succeeds, and the received Partial IV was greater than the </del> <ins> Observe registration.  The ordering of notifications after OSCORE processing MUST be aligned with the Partial IV.  The client MAY do so by copying the least significant bytes of the Partial IV into the Observe option, before passing it to CoAP processing.  The client MAY ignore an Outer Observe option value.  If the verification of the response succeeds, and the received Partial IV was greater than the </ins> Notification Number, then the client SHALL update the corresponding Notification Number with the received Partial IV.  The client MUST stop processing notifications with a Partial IV which has been

Related discussion:
text: This PR should (hopefully) conclude the main rewrite of Observe which was triggered by the security analysis and additional reviews of Observe. It should (hopefully) now be clear what part of the Observe related processing can be omitted in case Observe is not supported or in case intermediaries are not used. A new appendix E is covering the latter case.
Code change:
one way; all other characters are unescaped. Note: Normalized Paths are Singular Queries, but not all Singular <del> Queries are Normalized Paths.  For example, "$[-3]" is a Singular Query, but is not a Normalized Path.  The Normalized Path equivalent </del> <ins> Queries are Normalized Paths.  For example, "$[-3]" is a singular query, but is not a Normalized Path.  The Normalized Path equivalent </ins> to "$[-3]" would have an index equal to the array length minus "3". (The array length must be at least "3" if "$[-3]" is to identify a node.)

Related discussion:
text: Also, delete a term which is used only in the definition of the next term. Fixes URL
I only found the two occurrences you suggested changing. If there are others, please let me know!
Sometimes the spec uses "Singular Query" and sometimes "singular query". We should be consistent. (If we decide to use lower case, it's probably best to address this issue after PR has been merged, since that PR adds some usages of "Singular Query".) Also, there is one instance of "Logical context", which I think would be better uncapitalised ("logical context").
Thanks.
Code change:
obtains a token at time T2, a colluding issuer and origin can link this to the same client if T2 is unique to the client.  This linkability is less feasible as the number of issuance events at time <del> T2 increases.  Depending on the "max-age" token challenge attribute, </del> <ins> T2 increases.  Depending on the "max-age" token challenge parameter, </ins> clients MAY try to augment the time between getting challenged then redeeming a token so as to make this sort of linkability more difficult.  For more discussion on correlation risks between token

Related discussion:
text: The document refers to authentication scheme attributes throughout; the term from HTTP is 'parameters'. Also, both the challenge and credentials definitions should say what to do with unrecognised parameters.
Code change:
Defaults are 0x01 for the endpoint initially being client, and 0x00 for the endpoint initially being server <ins> Master Salt Default is the empty string </ins> Key Derivation Function (KDF) Default is HKDF SHA-256

Related discussion:
text: , and
This goes against Jim's wish to have things in bits rather than bytes... But HKDF uses octets and to combine the two parameters as wanted by Ludwig, they need the same unit.
Fixed in branch v-02
OSCOAP refers to HKDF [RFC5869], but it not clearly defined how the parameters map to HKDF-Extract and HKDF-Expand. E.g. IKM. Salt should be made optional.
In section 3.2.1. outlen is defined as "the key/IV size of the AEAD algorithm" and outputlength as "is the size of the AEAD key/IV in bytes encoded as an 8-bit unsigned integer" Isn't that essentially the same?
I just created a v-02 branch for the next update. I'll make an update as soon as possible trying to address this.
Fixed in brach v-02
Code change:
ODCIL: The original destination connection ID length.  Tokens in NEW_TOKEN frames MUST set this field to zero. <del> Original Destination Connection ID: This is copied from the field in the client Initial packet. </del> <ins> RSCIL: The retry source connection ID length.  Tokens in NEW_TOKEN frames MUST set this field to zero. Original Destination Connection ID: The server or Retry Service copies this from the field in the client Initial packet. Retry Source Connection ID: The server or Retry service copies this from the Source Connection ID of the Retry packet. </ins> Client IP Address: The source IP address from the triggering Initial packet.  The client IP address is 16 octets.  If an IPv4 address, the

Related discussion:
text: After thinking it through, various XOR schemes were extremely vulnerable to manipulation, so I went with a brute force approach.
The server now needs to include this field. For the no-shared state service, we just need language that the Retry service needs to encode enough information validate the packet DCID as well and drop if it fails validation. If it does, the server MUST use the packet DCID in the retrysourceconnection_id TP. For the shared state service, the retry source connection ID is going to have to be in the token. We might be able to compress this by xoring some fields; I'll think about it.
Code change:
type in RFC5280), but has the keyEncipherment and dataEncipherment usages are disabled. <ins> The extension MAY be marked crititcal.  (See Section 4.2 of RFC5280.) If the strict boolean is set to true, then the server MUST use delegated credential in the handshake; if no delegated credential is offered, then the client MUST abort the handshake with an "illegal_parameter" alert. </ins> 5. TBD

Related discussion:
text: Based on The delegation certificate MAY have the DelegationUsage extension marked critical. This also adds a "strict" flag to the extension that, if set, requires the server to offer a DC. An alternative that was discussed is to add an optional TLS-feature extension (per RFC 7633) that would provide a "must-use-DC" feature, analogous to "must-staple-OCSP". Howver, it's possible for a certificate with such an extension to be used in a handshake without DCs if the client doesn't indicate support for DCs.
Code change:
security implications of HTTP caching for other protocols that use HTTP. <del> In the absence of information about the authenticity of responses, such as DNSSEC, a DNS API server can give a client invalid data in </del> <ins> In the absence of DNSSEC information about the authenticity of responses a DNS API server can give a client invalid data in </ins> responses.  A client MUST NOT use arbitrary DNS API servers. Instead, a client MUST only use DNS API servers specified using mechanisms such as explicit configuration.  This does not guarantee

Related discussion:
text: …raft-ietf-doh-dns-over-https/commit/3f74bd6e0760f96717ffd3e667a37e13b45839c4#commitcomment-28865666 and URL that this wording is much clearer.
Sara, making this pr was on my todo list - thanks for the time saver. Paul sent me an IM about it, so I'll ga and merge.
Code change:
provides several general-purpose packet schedulers depending on the application goals. <ins> Note that the receiver could use a different scheduling strategy to send ACK(_MP) frames.  The recommended default behaviour consists in sending ACK(_MP) frames on the path they acknowledge packets.  Other scheduling strategies, such as sending ACK(_MP) frames on the lowest latency path, might be considered, but they could impact the sender with side effects on, e.g., the RTT estimation or the congestion control scheme.  When adopting such asymetrical acknowledgment scheduling, the receiver should at least ensure that the sender negotiated one-way delay calculation mechanism (e.g., QUIC- Timestamp). </ins> 8. Simultaneous use of multiple paths enables different retransmission

Related discussion:
text: I believe we can merge this now as it is. If we want to add more guidance later we should open a separate issue and another PR.
This issue came up during the discussion of issue . We say that ACK or ACK_MP frames can be send over any path, however, maybe we should discuss some guidance and trade-offs. E.g. sending on the same path as the packets received also for RTT measurements; using the shortest delay path might have some performance benefits...?
I agree. We should add some guidance here. We did some experiment regarding this issue. Our finding is returning ACK on the shortest path is helpful. But the improvement is only more significant when the path rtt ratio is larger than 4:1.
Code change:
information through an identity API.  The definition of such an identity API is out of scope for this specification. <del> The AS MUST return the "subject" field only in cases where the AS is sure that the RO and the end-user are the same party.  This can be accomplished through some forms of authorization. </del> Subject identifiers returned by the AS SHOULD uniquely identify the RO at the AS.  Some forms of subject identifier are opaque to the client instance (such as the subject of an issuer and subject pair),

Related discussion:
text: Opaque identifiers provide a generic reference, so we can simplify the text. (mainly), and as a byproduct also and - removed userhandle from main response in section 3 changed title of section 3.4 (User -> Subject) and moved the text that requires RO = end-user at the top of the section, for clarity changed name (userhandle -> user) and wording in section 3.5. Maybe we could also simplify the title "Returning Dynamically-bound Reference Handles" into "Returning Reference Handles" (didn't do it yet).
Deploy Preview for gnap-core-protocol-editors-draft ready! Explore the source changes: 73de700ce82846ec5e09f8f60550fac7bee0dfb5 Inspect the deploy log: Browse the preview:
With the adoption of the subject identifier format, we no longer need to have a GNAP-specific value and can instead leverage this more standard field. Alternatively, we could have a GNAP-specific subject identifier format, instead of a separate field.
In section 2.4 (Requesting User Information), the first sentence starts with: If the client instance is requesting information about the RO from the AS, ... From the title, the acronym "RO" should be changed into "end-user". The case where the RO is also the end-user is a specific case. This leads to the following change: If the client instance is requesting information about the end-user from the AS, ... In the following sentences of this section, RO should be changed into end-user.
The current text really means RO, and generally considers the case end-user = RO. Any other case would even trigger an error: "If the identified end-user does not match the RO present at the AS during an interaction step, the AS SHOULD reject the request with an error." (section 2.4) Which makes sense because why would we return something about the RO to a potentially unknown end-user? (the only problem is that this wording is buried in the text, so it's hard to understand) Back to the general case: The RO is in control of policies at the AS. The end-user is in control of a client and a request to the AS. The end-user and client may or may not have any prior relationship with the AS.
Code change:
information through an identity API.  The definition of such an identity API is out of scope for this specification. <del> The AS MUST return the "subject" field only in cases where the AS is sure that the RO and the end-user are the same party.  This can be accomplished through some forms of authorization. </del> Subject identifiers returned by the AS SHOULD uniquely identify the RO at the AS.  Some forms of subject identifier are opaque to the client instance (such as the subject of an issuer and subject pair),

Related discussion:
text: The subject info is what is known by the AS (in theory could be RO and maybe end-user, but notice that in the terminology, we define the end-user as a natural person and the RO as a subject entity). I think we should clarify when we could have a remote RO too. Then do we even return a result if the AS knows something about the end-user? (different from RO in that case). Plus we need to keep in mind that we also use sub_ids for URL In general, we might want to avoid the term "user" as it is not specific enough.
The title has been changed into "Requesting Subject information". This title is incorrect as long as a subject can be also an organization or a device. An AS can hold information about an end-user or about RO when the RO is a human being. It does not hold information about organizations or devices. However, an end-user may belong to some organizations or/and use some devices. IMO, I would replace it by "Requesting end-user Information". If an AS holds information about an end-user, it seems logical that the end-user should have access to it. If it happens that the end-user has also a RO account on the AS, then it should also have access to it. In such a case, another section with the following title "Requesting RO Information" should be created. RO = end-user was a common case in OAuth. In GNAP and in the general case a RO is different from an end-user and an AS may have no relationship with any RO (e.g. when attributes only are being used).
I guess you refer to "2.2. Requesting Subject Information". We might have to harmonize a bit, but for instance "2.3. Identifying the Client Instance" might very well hold information about devices or at least the software running on it (that's the point of client software attestation to be discussed in ) We don't always know in advance whether it will be a RO or an end-user only, so the proposal isn't always applicable.
I was indeed referring to "2.2. Requesting Subject Information" which has no relationship with "2.3. Identifying the Client Instance".
Code change:
information through an identity API.  The definition of such an identity API is out of scope for this specification. <del> The AS MUST return the "subject" field only in cases where the AS is sure that the RO and the end-user are the same party.  This can be accomplished through some forms of authorization. </del> Subject identifiers returned by the AS SHOULD uniquely identify the RO at the AS.  Some forms of subject identifier are opaque to the client instance (such as the subject of an issuer and subject pair),

Related discussion:
text: This means that your arguments do not apply to section 2.2. and, by implication, that my argumentation currently remains valid.
Well, I take the point in consideration but I don't think we should base our reasoning on the structure of sections, which can change
Identifying the User by Reference: Editor's note: We might be able to fold this function into an unstructured user assertion reference issued by the AS to the RC. We could put it in as an assertion type of "gnap_reference" or something like that. Downside: it's more verbose and potentially confusing to the client developer to have an assertion-like thing that's internal to the AS and not an assertion.
Why an assertion? Is that reference supposed to be linked to a session (cf "represent the same end-user to the AS over subsequent requests") or can it be persistent? I would see that more as an opaque identifier, rather than an assertion. Something like: asref seems a bit specific to GNAP (reference managed by the AS) but it could always be read "as a reference" in a more general setting. There's a variety of generic names that we could choose if needed, localuid, internal_uid, etc. But that really asks what additional types we could define as part of secevents (section 7.1.2). Beyond the case mentioned here, it would be most useful as an opaque identifier when RO != end-user, to avoid leaking private info about the RO (although currently we don't seem to cover that case yet) It's indeed more verbose than "user": "XUT2MFM1XBIKJKSDU8QM" but at least it's always the same structure (doesn't depend whether it's a reference or not), and it also makes the type more explicit.
A subject identifier makes sense here, and I agree that it should be a new value to let us constrain it to the GNAP context.
Fixed by SECEVENT opaque identifiers
I don't think this goes far enough -- I am thinking that with the opaque identifiers we can now simply return a with a format of that the client can be allowed to send in a follow-up request if it wants to. This way they all get treated equally, there's no special field anymore.
Code change:
asymmetry of request/response message sizes. Additionally, an attacker able to observe the data traffic exchanged <del> between two DTLS peers is able to replay datagrams with modified IP address/port numbers. </del> <ins> between two DTLS peers is able to modify IP address/port numbers. When the optional DTLS replay detection is not in use, such an attacker can also replay the observed packets, and the multiple copies of each packet can have different IP address/port numbers as well. </ins> The topic of peer address updates is discussed in peer-address- update.

Related discussion:
text: This is supposed to all be editorial stuff, and I split a couple changes out into separate commits in case they're not actually desired.
Code change:
bounded end-to-end delivery latency.  General background and concepts of DetNet can be found in the DetNet Architecture RFC8655. <del> The DetNet Architecture models the DetNet related data plane functions decomposed into two sub-layers: a service sub-layer and a forwarding sub-layer.  The service sub-layer is used to provide DetNet service functions such as protection and reordering.  The </del> <ins> The purpose of this document is to describe the use of the MPLS data plane to establish and support DetNet flows.  The DetNet Architecture models the DetNet related data plane functions decomposed into two sub-layers: a service sub-layer and a forwarding sub-layer.  The service sub-layer is used to provide DetNet service functions such as protection and reordering.  At the DetNet data plane a new set of functions (PREOF) provide the service sub-layer specific tasks.  The </ins> forwarding sub-layer is used to provide forwarding assurance (low <del> loss, assured latency, and limited out-of-order delivery). </del> <ins> loss, assured latency, and limited out-of-order delivery) via already existing Traffic Engineering and queuing tools.  The use of the functionalities of the DetNet service sub-layer and the DetNet forwarding sub-layer require careful design and control by the controller plane in addition to the DetNet specific use of MPLS encapsulation as specified by this document. </ins> This document specifies the DetNet data plane operation and the on- wire encapsulation of DetNet flows over an MPLS-based Packet Switched

Related discussion:
text: Proposed changes: 0, fixing Roman Danyliw comment 1, change introduction to highlight additional functions of data plane and the focus of the draft 2, highlight that implementation of PREOF is out of scope, pointing to related IEEE work (i.e., 802.1CB) 3, fixing the POF section and its configuration via controller plane
Code change:
record is found in DTLSInnerPlaintext.real_type after decryption. The CID value, cid_length bytes long, as agreed at the time the <del> extension has been negotiated. </del> <ins> extension has been negotiated.  Recall that (as discussed previously) each peer chooses the CID value it will receive and use to identify the connection, so an implementation can choose to always recieve CIDs of a fixed length.  If, however, an implementation chooses to receive different lengths of CID, the assigned CID values must be self-delineating since there is no other mechanism available to determine what connection (and thus, what CID length) is in use. </ins> The encrypted form of the serialized DTLSInnerPlaintext structure.

Related discussion:
text: This is supposed to all be editorial stuff, and I split a couple changes out into separate commits in case they're not actually desired.