jiebi/CodeConvo huggingface dataset:
Change:
8.2. <del> IANA is requested to create a sub-registry for signaling options similar to the CoAP Option Numbers Registry (Section 12.2 of RFC7252), with the single change that a fourth column is added to the sub-registry that is one of the codes in the Signaling Codes subregistry (message-codes). The name of this sub-registry is "CoAP Signaling Option Numbers". </del> <ins> IANA is requested to create a sub-registry for Options Numbers used in CoAP signaling options within the "CoRE Parameters" registry.  The name of this sub-registry is "CoAP Signaling Option Numbers". Each entry in the sub-registry must include one or more of the codes in the Signaling Codes subregistry (message-codes), the option number, the name of the option, and a reference to the option's documentation. </ins> Initial entries in this sub-registry are as follows:

Discussion:
URL The table 2 below isn't correct as it includes names not the signal codes from Table 1
URL Cl.8.2: I wonder if the first column in Table 3 should be "Applies to"? It seems more natural to look up the Signal Code to find the option, instead of the options which could have the same number.
URL 8.2. CoAP Signaling Option Numbers Registry s/one/one or more/
Change:
These functions have the property that D(K, E(K, P)) = ( P concatenated with optional padding) for all values of K and P.  Each cipher also has a limit T on the number of times that it can be used <del> with any fixed key value.  The EKTKey MUST NOT be used more that T times. </del> <ins> with any fixed key value.  The EKTKey MUST NOT be used for encryption more that T times.  Note that if the same EKT packet is retransmitted 3 times, that only counts as 1 encryption. </ins> Security requirements for EKT ciphers are discussed in sec. <del> 2.3.1. </del> <ins> 2.4.1. </ins> The default EKT Cipher is the Advanced Encryption Standard (AES) Key Wrap with Padding RFC5649 algorithm.  It requires a plaintext length

Discussion:
,
Changes look good , except for few typos .
Nothing to add beyond Suhas' comments.
Section 4 Each EKT cipher specifies a value T that is the maximum number of times a given key can be used. An endpoint MUST NOT send more than T Full EKT Field using the same EKTKey. In addition, the EKTKey MUST NOT be used beyond the lifetime provided by the TTL described in Section 3.2.
ektttl: The maximum amount of time, in seconds, that this ektkeyvalue can be used. The ektkey_value in this message MUST NOT be used for encrypting or decrypting information after the TTL expires.
These functions have the property that D(K, E(K, P)) = ( P concatenated with optional padding) for all values of K and P. Each cipher also has a limit T on the number of times that it can be used with any fixed key value. The EKTKey MUST NOT be used more that T times.
Change:
"token_key_id" is the least significant byte of the "key_id". <del> "blinded_request" is the Ne-octet blinded message defined above, computed as "SerializeElement(blinded_msg)".  Ne is as defined in OPRF, Section 4. </del> <ins> "blinded_msg" is the Ne-octet blinded message defined above, computed as "SerializeElement(blinded_element)".  Ne is as defined in OPRF, Section 4. </ins> <del> The value "tweaked_key" is stored locally and used later as described in finalization.  The Client then generates an HTTP POST request to send to the Issuer, with the TokenRequest as the body.  The media type for this request is "message/token-request".  An example request is shown below. </del> <ins> The values "token_input" and "blinded_element" are stored locally and used later as described in finalization.  The Client then generates an HTTP POST request to send to the Issuer, with the TokenRequest as the body.  The media type for this request is "message/token- request".  An example request is shown below. </ins> Upon receipt of the request, the Issuer validates the following conditions:

Discussion:
Since metadata can be bound to tokens via TokenChallenge.redemptioncontext, and the origin is ultimately the one who determines what metadata is supported, there's no more real need for the issuer_ to supply this metadata. So let's go with the simpler VOPRF protocol instead! Test vectors generated from the code here: URL cc NAME NAME NAME
LGTM
Change:
RFC EDITOR PLEASE DELETE THIS SECTION. <ins> draft-15 Include ciphersuite in group context (*) Add new new_proposal_member SenderType (*) Always use a full tree (*) Change KeyPackage identifier extension to be LeafNode identifier (*) Use new tree for context in path secret encryption (*) Use a hash function for hash identifiers (*) Add a marker byte to tree hash input structs (*) Recommend that group ids are generated randomly (*) Update external senders extension to have SignaturePublicKey and Credential (*) Replace LeafNodeRef with leaf index (*) Remove AppAck proposal (*) Make padding arbitrary-size and all-zero (*) Require that unmerged_leaves be ordered Derive the commit secret from the end of the UpdatePath, not the root Specify the precise points in the protocol where credential validation must be done Make PSK provisions more uniform, e.g., always generating a fresh random nonce Improve parent hash guarantees with stricter checks on tree correctness Streamline some structs, e.g., folding GroupContext into GroupInfo Provide clearer rules for validating and applying commits Clarify tree hash and parent hash, and correct examples Clean up struct names and references to outdated structs Cite AEAD limits draft </ins> draft-14 Ensure that a signature public key is always intelligible (*)

Discussion:
Constructed from the highlights of PR titles, with breaking changes indicated with as usual.
Just filing this so that I don't forget it before posting the draft.
Fixed by
Change:
BUNDLEd must use unique ICE credentials and candidates.  Each m= section MUST include the following: <del> If present in the offer, an "a=mid" line, as specified in RFC5888, Section 9.1.  The "mid" value MUST match that specified in the offer. </del> <ins> If and only if present in the offer, an "a=mid" line, as specified in RFC5888, Section 9.1.  The "mid" value MUST match that specified in the offer. </ins> An "a=rtcp" line, as specified in RFC3605, Section 2.1, containing the dummy value "9 IN IP4 0.0.0.0", because no candidates have yet

Discussion:
It goes something like and so on. But it is not clear if the answer can contain an line if there was none in the offer.
Quoth RFC 5888: Mid Value in Answers The "mid" attribute is an identifier for a particular media stream. Therefore, the "mid" value in the offer MUST be the same as the "mid" value in the answer. Besides, subsequent offers (e.g., in a re-INVITE) SHOULD use the same "mid" value for the already existing media streams. So the answer seems to be "no"
Given the quote from 5888, is it fair to conclude that URL should be resolved with "null" for the mid property on the transceiver if there has been no mid in the SDP? .mid was just an example, the same text is present for e.g. rtcp-mux, ice-option:trickle, rtcp-size.
Change:
The two low bits (0x03) include the low order two bits of the epoch. <del> Variable length CID.  The CID concept is described in DTLS-CID. An example can be found in connection-id-example. </del> <ins> Variable length CID.  The CID concept is described in I-D.ietf- tls-dtls-connection-id.  An example can be found in connection-id- example. </ins> The low order 8 or 16 bits of the record sequence number.  This value is 16 bits if the S bit is set to 1, and 8 bits if the S bit

Discussion:
I-D.ietf-tls-dtls-connection-id became a normative reference Removed duplicate reference to I-D.ietf-tls-dtls-connection-id.
Change:
To limit ACK Blocks to those that have not yet been received by the sender, the receiver SHOULD track which ACK frames have been <del> acknowledged by its peer.  Once an ACK frame has been acknowledged, the packets it acknowledges SHOULD NOT be acknowledged again. </del> <ins> acknowledged.  The receiver SHOULD exclude already acknowledged packets from future ACK frames whenever these packets would unnecessarily contribute to the ACK frame size. </ins> Because ACK frames are not sent in response to ACK-only packets, a receiver that is only sending ACK frames will only receive

Discussion:
Thanks everyone, this is much better.
From NAME I think that the advice here is that ranges are dropped when all ACKs for all packets in that range have been acknowledged. Or something along those lines. Maybe: Though that seems clumsy. Better words would be appreciated.
Maybe "Endpoints SHOULD not acknowledge packets for which it has already received acknowledgement of acknowledgements, except where this would create unnecessary gaps in the encoded ACK frame." Not ideal, I know/
I think this is connected to in an interesting way. The question that arises is if one MUST include all ACK state between highest received, and the lower PN that needs to be ACKed (as it is newly arrived due to reordering). An alternative would be to explicitly allow GAPs for packets that has been received and where the reception's ACKs has been ACKed. But, I guess that results in interesting bookkeeping chores in the implementations.
Agreed the wording is too strong. Take a look at PR
Change:
the AS's resource registration endpoint along with information about what the RS will need to validate the request. <del> REQUIRED.  The list of access rights associated with the request in the format described in the "Resource Access Rights" section of I-D.ietf-gnap-core-protocol. REQUIRED.  The identification used to authenticate the resource server making this call, either by value or by reference as described in authentication. OPTIONAL.  The token format required to access the identified resource.  If the field is omitted, the token format is at the discretion of the AS.  If the AS does not support the requested token format, the AS MUST return an error to the RS. OPTIONAL.  If present and set to "true", the RS expects to make a token introspection request as described in introspection.  If absent or set to "false", the RS does not anticipate needing to make an introspection request for tokens relating to this resource set. </del> The RS MUST identify itself with its own key and sign the request. The AS responds with a reference appropriate to represent the resources list that the RS presented in its request as well as any additional information the RS might need in future requests. <del> REQUIRED.  A single string representing the list of resources registered in the request.  The RS MAY make this handle available to a client instance as part of a discovery response as described in I-D.ietf-gnap-core-protocol or as documentation to client software developers. OPTIONAL.  An instance identifier that the RS can use to refer to itself in future calls to the AS, in lieu of sending its key by value. OPTIONAL.  The introspection endpoint of this AS, used to allow the RS to perform token introspection. </del> 4. Some architectures require an RS to act as a client instance and use

Discussion:
Deploy Preview for gnap-resource-servers-editors-draft ready! Explore the source changes: 94d11a4362aaea79f357583969d87ec4955655a9 Inspect the deploy log: Browse the preview:
Change:
Template TEMPLATE with the variables "target_host" and "target_port". Examples are shown below: <del> The URI Template MUST be a level 3 template or lower.  The URI Template MUST be in absolute form, and MUST include non-empty scheme, authority and path components.  The path component of the URI Template MUST start with a slash "/".  All template variables MUST be within the path component of the URI.  The URI template MUST contain the two variables "target_host" and "target_port" and MAY contain other variables.  The URI Template MUST NOT contain any non-ASCII unicode characters and MUST only contain ASCII characters in the range 0x21-0x7E inclusive (note that percent-encoding is allowed). The URI Template MUST NOT use Reserved Expansion ("+" operator), Fragment Expansion ("#" operator), Label Expansion with Dot-Prefix, Path Segment Expansion with Slash-Prefix, nor Path-Style Parameter Expansion with Semicolon-Prefix.  If any of the requirements above are not met by a URI Template, the client MUST reject its configuration and fail the request without sending it to the proxy. </del> <ins> The following requirements apply to the URI Template: The URI Template MUST be a level 3 template or lower. The URI Template MUST be in absolute form, and MUST include non- empty scheme, authority and path components. The path component of the URI Template MUST start with a slash "/". All template variables MUST be within the path component of the URI. The URI template MUST contain the two variables "target_host" and "target_port" and MAY contain other variables. The URI Template MUST NOT contain any non-ASCII unicode characters and MUST only contain ASCII characters in the range 0x21-0x7E inclusive (note that percent-encoding is allowed). The URI Template MUST NOT use Reserved Expansion ("+" operator), Fragment Expansion ("#" operator), Label Expansion with Dot- Prefix, Path Segment Expansion with Slash-Prefix, nor Path-Style Parameter Expansion with Semicolon-Prefix. If any of the requirements above are not met by a URI Template, the client MUST reject its configuration and fail the request without sending it to the proxy. </ins> Since the original HTTP CONNECT method allowed conveying the target host and port but not the scheme, proxy authority, path, nor query,

Discussion:
This single paragraph has ~150 words and about 10 normative requirements of the MUST / MUST NOT variety. Personally I find this quite a dense presentation of information. But I'll leave it up to your editorial discretion to fix or not.
Change:
Each Message Context may contain metadata from protocols in the Protocol Stack; which metadata is available is Protocol Stack <del> dependent.  These are exposed though additional read-only Message </del> <ins> dependent.  These are exposed through additional read-only Message </ins> Properties that can be queried from the MessageContext object (see msg-ctx) passed by the receive event.  The following metadata values are supported:

Discussion:
Also spotted some further small nits while reviewing the document, will create a pull request for those.
Change:
This document defines the RateLimit-Limit, RateLimit-Remaining, RateLimit-Reset fields for HTTP, thus allowing servers to publish <del> current request quotas and clients to shape their request policy and </del> <ins> current service limits and clients to shape their request policy and </ins> avoid being throttled out. Note to Readers

Discussion:
Improves terminology replacing with . cc: NAME NAME
It seems in the context of this design limit and quota terminology mean the same thing, however the header name to represent quota is RateLimit-Limit, which stutters. Would RateLimit-Quota not be better because it seems to mean the same thing and avoids stuttering?
Well, conveys the , which is expressed in terms of . The name makes me think more to a than to or . Since implementers already use , with NAME we decided not to change field names. WDYT to rename instead?
One potential issue with is that the quota can be not directly related to the amount of requests. For example it could be time based, just to name a simple criteria, but there are multiple other potential factors that could affect the units returned that could be confused when using that name. could arguably make for a better name.
Not sure this should be closed by the PR, so feel free to reopen if that's not the case.
NAME thanks for your feedback! You're welcome to provide more! NAME to me it's fine! Good merge and good idea about the new name is cool :)
Thanks both! I think this is more clear.
:+1:Thanks! I think this is more clear.
Change:
namely TCP RFC0793, in some situations secured by TLS RFC5246. In addition, some corporate networks only allow Internet access via a <del> HTTP proxy.  In this case, the best transport for CoAP would be the </del> <ins> HTTP proxy.  In this case, the best transport for CoAP might be the </ins> RFC6455.  The WebSocket protocol provides two-way communication between a client and a server after upgrading an RFC7230 connection and may be available in an environment that blocks CoAP over UDP.

Discussion:
The draft header indicates that this document updates RFC7641, but the abstract doesn't seem to mention this, which it should.
URL Appendix A. Updates to RFC7641 Observing Resources in the Constrained Application Protocol (CoAP) This needs to be referenced from the main body in some form.
Change:
The semantics of the other CoAP header fields are left unchanged. <del> 4.1. One observation is that, over a reliable byte stream transport, the message size limitations defined in Section 4.6 of RFC7252 are no longer strictly necessary.  Consenting [[how: There is currently no defined way to arrive at this consent. --cabo]] implementations may want to interchange messages with payload sizes larger than 1024 bytes, potentially also obviating the need for the Block protocol I- D.ietf-core-block.  It must be noted that entirely getting rid of the block protocol is not a generally applicable solution, as: a UDP-to-TCP gateway may simply not have the context to convert a message with a Block option into the equivalent exchange without any use of a Block option; large messages might also cause undesired head-of-line blocking; the 2-byte message length field causes another, larger upper bound to the message length. I-D.bormann-core-block-bert proposes to extend the block-wise transfer protocol to allow for larger block sizes as are possible over TCP and TLS. </del> <ins> 2.2. </ins> <del> The general assumption is therefore that the block protocol will continue to be used over TCP, even if TCP-based applications occasionally do exchange messages with payload sizes larger than desirable in UDP. 5. </del> <ins> EDITOR: This is extremely similar to the WebSocket section of the same name. </ins> As CoAP exchanges messages asynchronously over the TCP connection, the client can send multiple requests without waiting for responses.

Discussion:
This is an extremely rough merge of core-coap-tcp-tls and core-coap-websockets. The main intent was to get all the material into one draft with a potential outline and next perform an overall editorial pass.
With the merge of websockets-07, the scope of coap-tcp-tls is extended to include CoAP over WebSockets. The draft title should reflect that change in scope.
I probably would stay explicit (but then I'm biased -- RFC 3095 :-) CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets
WFM.
Neglected to close with
Change:
Captive-Portal Identification in DHCP / RA <del> draft-ietf-capport-rfc7710bis-09 </del> <ins> draft-ietf-capport-rfc7710bis-10 </ins> Abstract

Discussion:
Ben suggested: "I was just thinking that if we have a whole sentence about how "you're going to have to do the old thing anyway, though", someone might read that and say "well, if I have to keep doing the old thing, why should I bother with this new thing". So, appending a "; nonetheless, the mechanism provided by this document provides a more reliable and performant way to do so, and is therefore the preferred mechanism for captive-portal detection" or similar is what I had in mind."
Will do, and just submit ('ain't nobody got time for nit PRs :-P)
Maybe de-hyphenate captive-portal
Change:
the access token associated with the context expires. the client receives a number of 4.01 Unauthorized responses to <del> OSCORE requests using the same security context.  The exact number </del> <ins> OSCORE requests using the same Security Context.  The exact number </ins> needs to be specified by the application. the client receives a new nonce in the 2.01 (Created) response (see rs-c) to a POST request to the authz-info endpoint, when re- posting a (non-expired) token associated to the existing context. <del> The RS MUST discard the current security context associated with a </del> <ins> The RS MUST discard the current Security Context associated with a </ins> client when: the Sequence Number space ends. the access token associated with the context expires. <ins> the client has successfully replaced the current security context with a newer one by posting an access token to the unprotected /authz-info endpoint at the RS, e.g., by re-posting the same token, as specified in c-rs. Whenever one more access token is successfully posted to the RS, and a new Security Context is derived between the client and RS, messages in transit that were protected with the previous Security Context might not pass verification, as the old context is discarded.  That means that messages sent shortly before the client posts one more access token to the RS might not successfully reach the destination. Analogously, implementations may want to cancel CoAP observations at the RS registered before the Security Context is replaced, or conversely they will need to implement a mechanism to ensure that those observation are to be protected with the newly derived Security Context. </ins> 7. This document specifies a profile for the Authentication and

Discussion:
OCF comments.
check that re-sending token triggers nonces exchange and new security context derived.
add a implementation note about namespaces for identifiers in case several methods are used (EDHOC, ACE, others)
Change:
equivalent parameters.  The two Connections are otherwise independent. <del> Calling "Send" on a UDP connection sends the data as the payload of a complete UDP datagram.  Marking Messages as Final does not change anything in the datagram's contents. </del> <ins> SEND.UDP(-Lite).  Calling "Send" on a UDP connection sends the data as the payload of a complete UDP datagram.  Marking Messages as Final does not change anything in the datagram's contents. Upon sending a UDP datagram, some relevant fields and flags in the IP header can be controlled: DSCP (SET_DSCP.UDP(-Lite)), DF in IPv4 (SET_DF.UDP(-Lite)) and ECN flag (SET_ECN.UDP(-Lite)). </ins> <del> UDP only delivers complete Messages to "Received", each of which represents a single datagram received in a UDP packet. </del> <ins> RECEIVE.UDP(-Lite).  UDP only delivers complete Messages to "Received", each of which represents a single datagram received in a UDP packet.  Upon receiving a UDP datagram, the ECN flag from the IP header can be obtained (GET_ECN.UDP(-Lite)). </ins> <del> Calling "Close" on a UDP Connection releases the local port reservation. </del> <ins> Calling "Close" on a UDP Connection (ABORT.UDP(-Lite)) releases the local port reservation. </ins> <del> Calling "Abort" on a UDP Connection is identical to calling "Close". </del> <ins> Calling "Abort" on a UDP Connection (ABORT.UDP(-Lite)) is identical to calling "Close". </ins> 9.3.

Discussion:
(SCTP mapping) This uses a new approach for such text for TCP, UDP and SCTP. Also: updates appendix D of interface.
We've updated Implementation mapping details for most protocols with , but we didn't tackle SCTP yet.
I'm fine with this being assigned to me. However, it's more than just writing the SCTP text. Here's the relevant part of what I wrote in PR : I don't suggest to delete much of the text that's there but definitely amend it with the RFC reference at least for what's covered in RFC 8303. There's a very direct line from this type of text in RFC 8303 to the original specs, so I do believe that should be helpful. That's (obviously) post-Montreal though!
NAME please send a PR along these lines.