jiebi/CodeConvo huggingface dataset:
Change:
can use multiple IP addresses, multiple protocols, multiple paths, and provide multiple application streams. <del> 1.2. </del> <ins> 2.1. </ins> Originally, sockets presented a blocking interface for establishing connections and transferring data.  However, most modern applications

Discussion:
Based on discussion with NAME rearrange things to put a proper document overview in the intro, and split out the API Model discussion into its own section outside of the introduction.
LGTM (modulo one nit)Thank you NAME to do this - really improves the structure.
Change:
The Application Server then encrypts the payload.  Header fields are populated with URL-safe base-64 encoded RFC4648 values: <del> the "keyid" from the User Agent is added to both the Encryption- Key and Encryption header fields; </del> the salt is added to the "salt" parameter of the Encryption header field; and

Discussion:
NAME was unhappy about the freedom we offered. This doesn't remove the header field separation, but it removes most of it.
Thank you, Martin! This looks good to me.
Change:
The string "http-01" <del> A serialized authorized key object, base64-encoded.  The "key" field in this object MUST match the client's account key. </del> <ins> A random value that uniquely identifies the challenge.  This value MUST have at least 128 bits of entropy, in order to prevent an attacker from guessing it.  It MUST NOT contain any characters outside the URL-safe Base64 alphabet. </ins> <del> A client responds to this challenge by base64-decoding and parsing the authorized key object, verifying that its "key" field contains the client's account key, and provisioning it as a resource on the HTTP server for the domain in question.  That is, the server provisions a JSON object that is equivalent to the object encoded in the "authorizedKey" field sent by the server.  (Note: The provisioned object need not be a byte-exact copy of the authorized keys object in the challenge.) </del> <ins> A client responds to this challenge by constructing a key authorization from the "token" value provided in the challenge and the client's account key.  The client then provisions the key authorization as a resource on the HTTP server for the domain in question. </ins> The path at which the resource is provisioned is comprised of the fixed prefix ".well-known/acme-challenge/", followed by the "token" value in the challenge. The client's response to this challenge indicates its agreement to <del> this challenge: </del> <ins> this challenge by sending the server the key authorization covering the challenge's token and the client's account key: </ins> <del> The string "http-01" </del> <ins> The key authorization for this challenge.  This value MUST match the token from the challenge and the client's account key. </ins> <del> The "token" value from the authorized key object in the challenge. On receiving a response, the server MUST verify that the "token" value in the response matches the "token" field in the authorized key object in the challenge.  If they do not match, then the server MUST return an HTTP error in response to the POST request in which the client sent the challenge </del> <ins> On receiving a response, the server MUST verify that the key authorization in the response matches the "token" value in the challenge and the client's account key.  If they do not match, then the server MUST return an HTTP error in response to the POST request in which the client sent the challenge. </ins> Given a Challenge/Response pair, the server verifies the client's control of the domain by verifying that the resource was provisioned

Discussion:
This PR updates the new challenges so that they no longer use a JSON object dictated by the server. Instead, they use a "key authorization" string that is canonically generated from the token and key for a given challenge. (And also, while we're here, changes "authorized key object" to "key authorization".)
Change:
specific usage for each media type is outlined in Sections 4 and 5. <del> "a=ice-ufrag" and "a=ice-pwd" lines, as specified in RFC5245, Section 15.4. One or more "a=fingerprint" line(s) for each of the endpoint's certificates, as specified in I-D.ietf-mmusic-4572-update. An "a=setup" line, as specified in RFC4145, Section 4, and clarified for use in DTLS-SRTP scenarios in RFC5763, Section 5. The role value in the offer MUST be "actpass". An "a=rtcp-mux" line, as specified in RFC5761, Section 5.1.1. An "a=rtcp-mux-only" line, as specified in I-D.ietf-mmusic-mux- exclusive Section 4, if and only if the RTP/RTCP multiplexing policy is "require". An "a=rtcp-rsize" line, as specified in RFC5506, Section 5. </del> For each supported RTP header extension, an "a=extmap" line, as specified in RFC5285, Section 5.  The list of header extensions that SHOULD/MUST be supported is specified in I-D.ietf-rtcweb-rtp-

Discussion:
NAME NAME Is this approximately right?
Looks close enough to me - lets land this then tune with future PRs
LG with nits
Change:
4. The WebRTC prioritization model is that the application tells the <del> WebRTC implementation about the priority of media and data flows through an API. </del> <ins> WebRTC implementation about the priority of media and data that is controlled from the API. In this context, a "flow" is used for the units that are given a specific priority through the WebRTC API. For media, a "media flow", which can be an "audio flow" or a "video flow", is what RFC7656 calls a "media source", which results in a "source RTP stream" and one or more "redundancy RTP streams".  This specification does not describe prioritization between the RTP streams that come from a single "media source". A "data flow" is the outgoing data on a single WebRTC data channel. </ins> <del> The priority associated with a media or data flow is classified as "normal", "below normal", "high" or "very high".  There are only four </del> <ins> The priority associated with a media flow or data flow is classified as "very-low", "low", "medium or "high".  There are only four </ins> priority levels at the API. The priority settings affect two pieces of behavior: Packet send

Discussion:
Updated terminology.
On reading the document, I find that the term "media flow" is used where draft-ietf-avtext-rtp-grouping-taxonomy suggests "source stream". Still open what to use instead of "data flow". "Data stream"?
After reconsidering, I added a definition for "flow" instead. Let's see how that scans.
rtcweb-transport: "normal", "below normal", "high" or "very high". tsvwg-rtcweb-qos: “very low”, “low”, “medium”, “high”. WEBRTC-PC: enum RTCPriorityType { "very-low", "low", "medium", "high" }; The majority should win.
Change:
If any of these requirements are not met, the client MUST treat this proxying attempt as failed and abort the connection. <ins> For example, the IP proxy could respond with: </ins> 4.3. When using HTTP/2 H2 or HTTP/3 H3, IP proxying requests use HTTP

Discussion:
Our cousin, CONNECT-UDP, has simple examples about how the requests and responses look in HTTP/1.1, 2 and 3. I appreciate the appendix has complicated examples. Would it be worth providing simple examples in Section 4, or at least forward referencing to them so people can get a feel?
That would be nice, if someone's willing to volunteer to do the editorial work of writing that PR. In other words, I'll happily review and merge it, but I don't have time to write it personally.
there's 5 authors on the draft, maybe one of the other 4 can spare the 10 minutes it would take?
Simple enough to add =)
Thanks for writing this!
Change:
information may be inferred from the underlying layer. Normal DTLS does not provide a mechanism for suppressing the sequence <del> number field entirely.  In cases where a sequence number is not required (e.g., when a reliable transport is in use), a cTLS implementation may suppress it by setting the "suppressSequenceNumber" flag in the compression profile being used (see template-based-specialization).  When this flag is enabled, the S bit in the configuration octet MUST be cleared. </del> <ins> number field entirely.  When a reliable, ordered transport (e.g., TCP) is in use, the S bit in the configuration octet MUST be cleared and the sequence number MUST be omitted.  When an unreliable transport is in use, the S bit has its usual meaning and the sequence number MUST be included. </ins> 2.3.

Discussion:
I'm slightly concerned about the fact that we have two different wire behaviors with the same transcript, but because the integrity tag includes the header, I think it's OK. NAME would welcome your thoughts.
I think I have addressed this aspect already in PR URL
Correct. I thought Ben's suggestion to tie it to transport made more sense, but I'm not hard over on it.
Fine for me too.
S = "sequence number"
Change:
to prove or deny the existence of the insecure delegations. (Adapted from RFC7129, Section 5.1) <ins> "A signed name containing a delegation (NS RRset), but lacking a DS RRset, signifying a delegation to an unsigned subzone." (Quoted from RFC4956, Section 2.) </ins> "The practice of discovering the full content of a zone via successive queries."  (Quoted from RFC5155, Section 1.3.)  This is also sometimes called "zone walking".  Zone enumeration is

Discussion:
I have been unable to find a definition of "insecure delegation", but it is a term in common use. The closest I found was some handwaving in the NSEC3 doc. Perhaps worth adding? [ Feel free to close issue if inappropriate, etc. ]
We should define it. It appears starting in RFC 4956. The definition there is: That seems fine to me
Fixed in URL
Change:
connections, rather, it means that cached state is used by the Transport Services architecture to inform functions such as choosing the candidates to be raced, selecting appropriate <del> transport parameters, etc.  An application SHOULD NOT depend on </del> <ins> transport parameters, etc.  An application SHOULD NOT rely on </ins> specific caching behaviour, instead it ought to explicitly request any required or desired properties via the Transport Services API.

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:
construct the RTP packets and encrypt it using SRTP keys for the HBH encryption to the media server. <del> 4.3.3. </del> <ins> 4.3.4. </ins> The receiving clients buffer all packets that belongs to the same frame using the frame beginning and ending marks in the generic RTP frame header extension, and once all packets are available, it passes <del> it to SFrame for decryption.  SFrame maintains multiple decryptor objects, one for each client in the call.  Initially the client might not have the mapping between the incoming streams the user's keys, in this case SFrame tries all unmapped keys until it finds one that passes the authentication verification and use it to decrypt the frame.  If the client has the mapping ready, it can push it down to SFrame later. The KeyId field in the SFrame header is used to find the right key for that user, which is incremented by the sender when they switch to a new key. For frames that are failed to decrypt because there is not key available yet, SFrame will buffer them and retries to decrypt them once a key is received. </del> <ins> it to SFrame for decryption.  The KID field in the SFrame header is used to find the right key for the encrypted frame. </ins> <del> 4.3.4. </del> <ins> For frames that are failed to decrypt because there is key available for the KID in the SFrame header, the client MAY buffer the frame and retry decryption once a key with that KID is received. 4.3.5. </ins> Unlike messaging application, in video calls, receiving a duplicate frame doesn't necessary mean the client is under a replay attack,

Discussion:
This PR attempts to capture the spirit of the original key management provisions with a little more clarity about assumptions. It also adds a more more explicit construction for connecting SFrame to MLS.
Change:
TLS version 1.2 or higher is mandatory-to-implement and MUST be enabled by default.  An endpoint MAY immediately abort a CoAP over <del> TLS connection that does not meet this requirement (see sec-abort) and SHOULD include a diagnostic payload. </del> <ins> TLS connection that does not meet this requirement (see sec-abort). </ins> The TLS usage guidance in RFC7925 SHOULD be followed.

Discussion:
One more 7.01 change to 7.00. Removed redundant requirement for references to abort: MAY immediately abort the connection (see Section 4.6) . since the Abort section already has the SHOULD.
URL Signaling s/Share/Relate/ (the nodes do not "share these characteristics") Shut down s/Ordered/Orderly/ Provide diagnostic information when terminating a connection in ... 4.3. Capability and Settings Messages (CSM) Hmm, should this be "Capabilities and Settings Messages"? (Need to change throughout.) s/A/One/ s/Capability and Settings message/CSM/ s/and/. Further CSM/ s/settings/setting/ 4.3.2. Max-Message-Size Capability Option (above 1152?)
URL Appendix B. Negotiating Protocol Versions s/Capability and Settings/Capabilities and Settings Messages (CSM)/
URL Cl.4.5/4.6: The text mentions a "diagnostic payload", is some standard envisaged for this or is it implementation dependent? This is implementation dependent, although it might be helpful to adapt or reference - URL
Reviewed in more detail. There is a reference to RFC7252 in an earlier section URL
Perhaps the RFC7252 references needs to be emphasized more. Options: Blockquote related RFC7252 Section 5.5.2 in section 4.1 to call more attention to it Include an xref with each related normative statement The simplest mitigation is the xref: A Release message indicates that the sender does not want to continue maintaining the connection and opts for an orderly shutdown. The details are in the options. A diagnostic payload (see Section 5.5.2 of [RFC7252]) MAY be included.
Change:
The format provides a generalized way to attach any additional information to the timestamp. <del> 2. </del> <ins> This document does not address extensions to the format where the semantic result no longer is a fixed timestamp that is referenced to a (past or future) UTC time.  For instance, it does not address: Future time given as a local time in some specified time zone, where changes to the definition of that time zone (e.g., a political decision to enact or rescind daylight savings time) changes the actual time in UTC time. Time given as a "floating time", i.e., a local time without information as to which time zone this local time refers to. The use of time scales different from UTC, such as TAI. However, the additional information provided that augments a fixed timestamp may be sufficient to detect an inconsistency between intention and the actual information given in the timestamp, e.g., between the additional timezone information given and the timezone offset recorded in the timestamp.  For instance, such an inconsistency might arise because of: Political decisions as discussed above, or errors in the applications producing and consuming such a timestamp. While the information available is not generally sufficient to resolve the inconsistency, it may be used to initiate some out of band processing to obtain sufficient information for such a resolution. In order to address some of the requirements implied here, future related specifications might define syntax and semantics of strings similar to RFC3339.  Note that the extension syntax defined in the present document is designed in such a way that it can be useful for such specifications as well. 1.2. </ins> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and

Discussion:
The current draft does not say what it actually means when a timezone name is added to a timestamp. Is the combination of the timezone name and the timezone offset an assertion that the offset was correct for the named timezone at the time? What if that assertion is not true? What about future times? Does the timezone name take precedence over the offset given (i.e., the timestamp changes its meaning with political decisions) or does the offset win?
(From the SEDATE meeting: "encode the intention"?)
(From the SEDATE meeting: "don't encode the timezone if that is not the overriding information".) One use case is documenting the time zone name, though.
We now have a clarified scope ( as published in -02). This makes the underlying issue out of scope -- the RFC 3339 semantics prevail. Discuss.
essentially is the continuation of this issue with a revised question. The resolution of the question in this PR remains in place.
As a description of one path forward, this is good - and it's sufficient for the proposal that I made. Good threading of the potential needle here.
Change:
to a push service allows the push service to better distinguish between legitimate and bogus requests. <ins> Additionally, this design also relies on endpoint secrecy as any application server in possession of the endpoint is able to send messages, albeit without payloads.  In situations where usage of a subscription can be limited to a single application server, the ability to associate said subscription with the application server provides could reduce the impact of a data leak. </ins> This document describes a system whereby an application server can volunteer information about itself to a push service.  At a minimum, this provides a stable identity for the application server, though

Discussion:
I welcome any level of feedback. One specific question is how to specify the association token when creating a new subscription. I used my beloved header, but the token may be something other than a DH public value. Do you know of appropriate headers that could be used for this purpose?
I think that this is pretty good. I would want to tighten this a little more, but until we decide on an approach, we're somewhat constrained in what we can say.
My understanding is that this is just a proposal, the formal draft (either separately or merged with the main draft) would not mention the alternative options either, right?
Yeah, this is just input for discussion. If we decide on an approach, it's probably something we can merge into one of the other drafts. Or, it could remain separate and we could either remove the alternatives or move them to an appendix.
Change:
to a push service allows the push service to better distinguish between legitimate and bogus requests. <ins> Additionally, this design also relies on endpoint secrecy as any application server in possession of the endpoint is able to send messages, albeit without payloads.  In situations where usage of a subscription can be limited to a single application server, the ability to associate said subscription with the application server provides could reduce the impact of a data leak. </ins> This document describes a system whereby an application server can volunteer information about itself to a push service.  At a minimum, this provides a stable identity for the application server, though

Discussion:
NAME can you check that this is all OK with you? I've made you an author :)
SG, thanks. The only difference with my PR seems to be removal of details, which I guess are too specific for the proposal phase.
Change:
has received its Commit message back from the server does it update its state to reflect the new member's addition. <del> Upon receiving the Welcome message and the corresponding Commit, the new member will be able to read and send new messages to the group. Messages received before the client has joined the group are ignored. </del> <ins> Upon receiving the Welcome message, the new member will be able to read and send new messages to the group.  Messages received before the client has joined the group are ignored. </ins> Subsequent additions of group members proceed in the same way.  Any member of the group can download a KeyPackage for a new client and broadcast an Add message that the current group can use to update their state, and a Welcome message that the new client can use to <del> initialize its state. </del> <ins> initialize its state and join the group. </ins> To enforce the forward secrecy and post-compromise security of messages, each member periodically updates their leaf secret.  Any

Discussion:
(see issue for details).
Currently section "4. Protocol Overview" states: I think this is a legacy from before the propose/commit scheme and got carried over. New members no longer need the Commit. The subsequent diagram also needs to be adapted.
Change:
[28] https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/97 <del> [29] https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/101 [30] https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/102 [31] https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/103 </del> <ins> [29] https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/103 </ins> <del> [32] https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/104 </del> <ins> [30] https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/104 </ins> <del> [33] https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/105 </del> <ins> [31] https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/105 </ins> <del> [34] https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/109 </del> <ins> [32] https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/109 </ins>

Discussion:
update token rotation response and requirements add considerations for the difficulties of rotating and revoking stateless tokens add considerations on rotation in unreliable networks
Deploy Preview for gnap-core-protocol-editors-draft ready! Explore the source changes: 2284ffefdc540b8743400e9463fb65fc99070d4a Inspect the deploy log: Browse the preview:
Rotation the Access Token: Editor's note: The net result is that the client's always going to use the management URL that comes back. But should we let the server omit it from the response if it doesn't change? That seems like an odd optimization that doesn't help the client.
Close by making inclusion of URI REQUIRED.
Rotating the Access Token: Editor's note: We could also use different verbs to signal whether or not the old token should be kept around or not, instead of using a token flag to do this.
Keep "MUST if possible" here. If you want two access tokens, use the grant API not the token rotation API. The rotation mechanism should be for getting a new value for an existing token and replacing it, not for minting entirely new separate tokens (which is what the grant continuation/update API is for). We need to keep "if possible" for the case of using stateless tokens (fully self-contained JWTs), and add a discussion on when it might not be possible.
a few minor comments
Change:
epoch and sequence number fields in the DTLSCiphertext structure have been reduced. <del> The DTLSCiphertext structure is a variable length header. </del> <ins> The DTLSCiphertext structure has a variable length header. </ins> Note that the DTLS 1.3 record layer is different from the DTLS 1.2 record layer.

Discussion:
This pull request aims to address the open issues regarding sequence number encryption. The approach chosen follows the design used in QUIC.