jiebi/CodeConvo huggingface dataset:
Change:
prior-signed-voucher-request: PVR as in The RVR MUST be enhanced with the following parameter, when the <del> assertion "agent-proximity" is requested, as defined in voucher- request-prm-yang: </del> <ins> assertion "agent-proximity" is requested, as defined in RFC8366bis: </ins> agent-sign-cert: LDevID(RegAgt) certificate or the LDevID(RegAgt) certificate including certificate chain.  In the context of this

Discussion:
move YANG to RFC8366bis
Some corrections are necessary regarding the referenced fields defined. BRSKI-PRM specifies the agent-provided-registrar-certificate in contrast to the registar-proximity-certificate. Will be addressed in the next commit.
Change:
5.1. The transport services API uses the Local Endpoint and Remote <del> Endpoint types to refer to the endpoints of a transport connection. Subtypes of these represent various different types of endpoint identifiers, such as IP addresses, DNS names, and interface names, as well as port numbers and service names. </del> <ins> Endpoint Objects to refer to the endpoints of a transport connection. Actions on these Objects can be used to represent various different types of endpoint identifiers, such as IP addresses, DNS names, and interface names, as well as port numbers and service names. </ins> Specify a Remote Endpoint using a hostname and service name:

Discussion:
Agree, they're definitely objects. While an implementation might choose to implement different types of endpoint identifiers as subtypes of such objects, we don't want to be that specific here.LGTM
Change:
and the requesting party (= client owner) are not shown in fig:protocolFlow. <del> The ACE framework supports a wide variety of communication security between client, authorization server, and resource server.  We assume that the client has been registered to an AS.  Registration means that the two share credentials, configuration parameters and that some form of authorization has taken place.  These credentials are used to protect the token request by the client and the token response from AS to the client. It is also assumed that the RS has been registered with the AS. Established keying material between the AS and the RS allows the AS to apply cryptographic protection to the access token to ensure that its content cannot be modified, and if needed, that the content is confidentiality protected. </del> <ins> This framework supports a wide variety of communication security mechanisms between the ACE entities, such as client, authorization server, and resource server.  We assume that the client has been registered (also called enrolled or onboarded) to an AS using a mechanism defined outside the scope of this document.  In practice, various techniques for onboarding have been used, such as factory- based provisioning or the use of commissioning tools.  Regardless of the onboarding technique, this registration procedure implies that the client and the AS share credentials, and configuration parameters.  These credentials are used to mutually authenticate each other and to protect messages exchanged between the client and the AS. It is also assumed that the RS has been registered with the AS, potentially in a similar way as the client has been registered with the AS.  Established keying material between the AS and the RS allows the AS to apply cryptographic protection to the access token to ensure that its content cannot be modified, and if needed, that the content is confidentiality protected. </ins> The keying material necessary for establishing communication security between C and RS is dynamically established as part of the protocol

Discussion:
I have reviewed the protocol section and have made some minor edits. I believe the section is looking good. There were only two items that I believe are worthwhile to discuss: I prefer to use the term endpoint for the /token and /introspect rather than calling them resource. The term endpoint is used in the terminology section and aligns with OAuth. The client token is mentioned in this section and even after looking at the text later in the document I didn't really understood the concept.
Looks good to me. Does anyone else have a strong opinion on the use of "endpoint" vs "resource"? We might need to put a note into the text somewhere to clarify, since CoAP IMHO uses "endpoint" with a slightly different meaning.
Change:
processed immediately.  Otherwise, the stream on which the field section was received becomes blocked. <del> To bound the memory requirements of the decoder for blocked streams, encoded field section data SHOULD remain in the stream's flow control window while the stream is blocked.  A stream becomes unblocked when the Insert Count becomes greater than or equal to the Required Insert Count for all encoded field sections the decoder has started reading from the stream. </del> <ins> While blocked, encoded field section data SHOULD remain in the blocked stream's flow control window.  This data is unusable until the stream becomes unblocked, and releasing the flow control prematurely makes the decoder vulnerable to memory exhaustion attacks.  A stream becomes unblocked when the Insert Count becomes unblocked when the Insert Count becomes greater than or equal to the Required Insert Count for all encoded field sections the decoder has started reading from the stream. </ins> When processing encoded field sections, the decoder expects the Required Insert Count to equal the lowest possible value for the

Discussion:
NAME said
One could imagine an implementation using a small buffer to read the beginning of the stream. If the whole field section happens to fit into it, so be it. A MUST would probably mean that a conforming implementation had to unread the field section.
We can probably just use "can" here. From an interoperability standpoint, there is no value to recommending any particular value.
Does SHOULD -> can mean this is a design change?
Yes, so if you're advocating doing that then I'll mark this as design.
The SHOULD is there to guard against memory exhaustion attacks. Streams "parking" is a QPACK design feature. The SHOULD should stay.
The plan is to leave the SHOULD, but add more editorial text in 2.2.1 explaining why it's a good idea.
Change:
The media codecs used for ingestion in older protocols tend to be limited and not negotiated.  WebRTC includes support for negotiation of codecs, potentially alleviating transcoding on the ingest node <del> (wich can introduce delay and degrade media quality).  Server side </del> <ins> (which can introduce delay and degrade media quality).  Server side </ins> transcoding that has traditionally been done to present multiple renditions in Adaptive Bit Rate Streaming (ABR) implementations can be replaced with simulcasting and SVC codecs that are well supported

Discussion:
If you find them useful, here are some spelling fixes. The ' PATH ' spelling is confusing, I think it should be ' PATCH ' Also the draft URL points to and older draft. I have been very inspired by WHIP, thank you for giving it to the community.
Change:
the Partial IV parameter, the kid context parameter (length and value), and the kid parameter as follows: <del> The first byte of flag bits encodes the following set of flags and the length of the Partial IV parameter: </del> <ins> The first byte, called OSCORE Octet, encodes the following set of flag bits and the length of the Partial IV parameter: </ins> The three least significant bits encode the Partial IV length n.  If n = 0 then the Partial IV is not present in the

Discussion:
Solves issue (from review comments by NAME : URL) Section 4.1.3.1 - I am unclear why an OSCORE error response can be cached by an OSCORE unaware intermediate would be cached, but a success message is never going to be cached. Based on this, I don't plan to set an outer Max-Age option. In section 5.4 you have the text requestpiv: contains the value of the 'Partial IV' in the COSE object of the request (see Section 5), with one exception: in case of protection or verification of Observe cancellations, the requestpiv contains the value of the 'Partial IV' in the COSE object of the corresponding registration (see Section 4.1.3.5.1). I am unclear how/why this is different for observations. A cancelation is a message, so the IV is the request. A re-registration is a request message, any response would correspond to that request. The only interesting question has to do with updating the MID on a re-registration but not how PIVs work for this field. Section 6.1 - Is a registry needed for the leading byte of compression? Behavior if bits 0, 1, or 2 is set in the flags byte on decode? Section C - given the way that my system is implemented, it would be nice if the outputs included the first full IV to be used for both the sender and the recipient. That would allow for a test that the combination of ids and common ivs is done correctly. In my case I do not have the shared IV available for testing as I immediately or in the id.
Change:
are represented as absolute times, measured in seconds since the Unix epoch (1970-01-01T00:00:00Z).  Applications MUST define a maximum total lifetime that is acceptable for a LeafNode, and reject any <del> LeafNode where the total lifetime is longer than this duration. </del> <ins> LeafNode where the total lifetime is longer than this duration.  In order to avoid disagreements about whether a LeafNode has a valid lifetime, the clients in a group SHOULD maintain time synchronization (e.g., using the Network Time Protocol RFC5905). </ins> In the case where the leaf node was inserted into the tree via a Commit message, the "parent_hash" field contains the parent hash for

Discussion:
URL
:+1: Thank you very much for all of the explicitly worked examples. What is the reason for MUST vs RECOMMENDED difference in the two different circumstances when validating the `lifetime` field? Consider adding a platitude about communicating nodes SHOULD use some method of time synchronization... "top of these basic mechanism" -> "top of these basic mechanisms" (or maybe "top of this basic mechanism") "in an PrivateContentTBE structure" -> "in a PrivateContentTBE structure"
Change:
acceleration; PLFRAME: Physical Layer FRAME - modulated version of a BBFRAME <del> with additional information (e.g. related to synchronization); </del> <ins> with additional information (e.g., related to synchronization); </ins> QEF: Quasi-Error-Free;

Discussion:
Introduction physical-layer reliability mechanisms -- hyphenate adjectival terms style: e.g. should be in a clause separated by commas, not brackets. 500 ms one-way delivery delay (or path -- i.e. not propagation)
Intro must do the same, clarifying also it's not a standard, and give an estimation of the support it collected during discussion within the group. For instance (taken from rfc 8406): This document is the product of and represents the collaborative work and consensus of the Coding for Efficient Network Communications Research Group (NWCRG); it is not an IETF product and is not a standard. .
I think PR solves the issue.
Change:
_RFC Editor: Please fill in this value with the RFC number for this document_ and <del> 7.  References </del> <ins> 8.  References </ins> <del> 7.1.  URIs </del> <ins> 8.1.  URIs </ins> [1] https://www.iana.org/assignments/http-upgrade-tokens/

Discussion:
Add brief section describing Http2Transport's stance on the properties enumerated in the WebTransport Overview. We can move this around later as necessary, but wanted to get the text in to document which optional properties are supported and which are not.
From the : We should enumerate the position that Http2Transport takes on each of these items. Specifically: No stream independenceNo partial reliabilityYes pooling supportNo connection mobility
Change:
corresponding private key for the proof of possession. The access token is protected against modifications using a MAC or <del> a digital signature of the AS.  The choice of PoP key does not necessarily imply a specific credential type for the integrity protection of the token.  More information about PoP tokens can be found in I-D.ietf-oauth-pop-architecture. </del> <ins> a digital signature, which is added by the AS.  The choice of PoP key does not necessarily imply a specific credential type for the integrity protection of the token.  More information about PoP tokens can be found in I-D.ietf-oauth-pop-architecture. </ins> In OAuth 2.0, the client specifies the type of permissions it is seeking to obtain (via the scope parameter) in the access request. <del> In turn, the AS may use the "scope" response parameter to inform the client of the scope of the access token issued.  As the client </del> <ins> In turn, the AS may use the scope response parameter to inform the client of the scope of the access token issued.  As the client </ins> could be a constrained device as well, this memo uses CBOR encoded <del> messages defined in oauthProfile to request scopes and to be informed what scopes the access token was actually authorized for by the AS. </del> <ins> messages for CoAP, defined in oauthProfile, to request scopes and to be informed what scopes the access token was actually authorized for by the AS. </ins> The values of the scope parameter are expressed as a list of space- delimited, case-sensitive strings, with a semantic that is

Discussion:
I went through the overview section and updated the text. The text is already good and only a few minor changes had to be made. I believe we may need to determine (some time in the future) whether it is worthwhile to combine the introduction with the text in the overview section since there is some overlap.
I spotted a few sentences that were missing a word to make sense. I'll go through and try to fix this on Monday, unless someone else manages before me. Otherwise the changes look fine.
Change:
The server granted the client authorization based on an external account <del> Clients should check the "status" field of an order to determine </del> <ins> Clients SHOULD check the "status" field of an order to determine </ins> whether they need to take any action. 7.1.4.

Discussion:
EKR pointed out to me privately a couple of remaining issues after his AD review. This PR addresses those issues.
No complaints from me, looks good. Thanks NAME
Change:
The former is used to update the confirmed transcript hash and the latter to update the interim transcript hash. <ins> In this notation, "InterimTranscriptHashInput_[epoch]" and "ConfirmedTranscriptHashInput_[epoch+1]" are based on the Commit that initiated the epoch with epoch number "epoch".  (Note that the "epoch" field in this Commit will be set to "epoch - 1", since it is sent within the previous epoch.) </ins> 8.3. In addition to initializing a new epoch via KDF invocations as

Discussion:
This PR is an alternative to . This PR updates the group creation process so that epoch 0 is a "full-fledged" epoch, with an epoch secret (and all the derivatives) instead of just an init secret. One implication of that is that the interim transcript hash can now be computed in the usual way, by extending the confirmed transcript hash with a confirmation tag: This has the nice side effect of immediately mixing the epoch secret into the transcript hash, helping the group diverge (a concern NAME raised on the call today). While I was editing the group creation section, I also rationalized the requirements a bit. One reason that came up is that the group creation section currently assumes you're always starting with multiple members. So the MUST-level requirement to fetch key packages has been downgraded to a SHOULD. Finally, I updated the specification of GroupInfo to explain the fields, in particular explaining how you get the confirmation tag in epoch 0 or later epochs.
Since this PR clarifies more than and the solution is equally good, I'd suggest closing and merging this one.
Change:
The candidate details are specified in an IceCandidate field, using the same SDP syntax as the "candidate-attribute" field defined in <del> RFC5245, Section 15.1.  For example: </del> <ins> RFC5245, Section 15.1.  Note that this field does not contain an "a=" prefix, as indicated in the following example: </ins> The IceCandidate object contains a field to indicate which ICE ufrag it is associated with, as defined in RFC5245, Section 15.4.  This

Discussion:
Since it has been the cause of actual interop issues in the field, it is probably worth mentioning, in section 3.5.2.1, that the IceCandidate strings explicitly do not start with "a=".
Sure.
Change:
does not preclude endpoints from using non-imported PSKs for TLS 1.2. Indeed, this is necessary for incremental deployment. <del> 8. </del> <ins> 9. </ins> This is a WIP draft and has not yet seen significant security analysis. <del> 9. </del> <ins> 10. </ins> DISCLAIMER: This section contains a sketch of a design for protecting external PSK identities.  It is not meant to be implementable as

Discussion:
Discussed in Singapore; will merge and add security considerations motivation in a followup to .
The document says: Aside from this statement needing update in light of the changes to the binder label, the core statement here isn't expanded upon. The document needs to very clearly say that the PSK ID that is sent in the psk extension is literally the serialized content of .
Fixed in .
This seems harmless, but it is predicated on a need to separate keys that I don't understand. Is there more rationale somewhere?
Change:
A Firmware Update Architecture for Internet of Things Devices <del> draft-ietf-suit-architecture-00 </del> <ins> draft-ietf-suit-architecture-01 </ins> Abstract

Discussion:
Added David Brown as co-author Added further terms Updated text about permissions Re-wrote text about operating modes Editorial changes (including formatting) Revised section about claims Added new architecture figure Reworked security description Included device firmware update examples provided by David. Updated example flow (and included bootloader)
Change:
tcpcrypt <del> Packet Security Protocols: OpenVPN </del> 4.2. The following protocols all depend on the transport protocol to

Discussion:
Addresses
No objection, but I don't know OpenVPN.
Comment from Ekr's review of -10: Packet Security Protocols: o OpenVPN Well, sort of. OpenVPN needs TCP for its key establishment phase but not its transport phase. That doesn't seem like that interesting a point to make here, as if TCP wasn't available, it could just cut over to DTLS.
Agreed: My notes on OpenVPN say that it can run completely over UDP, in which case it provides its own reliability layer for handshake and key exchange, and no reliability for data packets. I guess that means that OpenVPN does not have any transport dependencies, so deleting it from Section 4.1 is correct and I don't see any other place in Section 4 for it. I'd say stating it can run over either TCP or UDP is enough here, so this PR is sufficient.
Change:
2. A Concise Problem Details data item is a CBOR data item with the <del> following structure: </del> <ins> following structure (rules named starting with "tag38" are defined in tag38): </ins> A number of problem detail entries, the Standard Problem Detail entries, are predefined (more predefined details can be registered,

Discussion:
Capture the discussion in the 2022-06-08 interim and .
Comment by NAME : I have a hard time motivating why this can be unadorned CBOR text string, given that these two fields are always human-readable text. Maybe we need to add a default, i.e. that when text used, that is to be interpreted as English language is used.
(w/ TF:) making "foo" a shorthand for 38(["en", "foo", false]) makes sense in the Anglo-American dominated world we live in. Details (en? en-US?) need to be discussed though.
I wouldn't go down the rabbit hole of also picking the locale. Too much stress I'm happy with the minimum required to satisfy the rule, i.e., "en".
In we decided to go with the following: use context if available fall back to english Now, similar to , should we have a (and ) keys for when the CPD is stored/forwarded and therefore the context is lost?
LGTM
Change:
In case a key is repeated or conflicted, implementations MUST give precedence to whichever value is positioned first. <del> 3.2. </del> <ins> 2.2. </ins> Since tags can include all sorts of additional information, different standards bodies/organizations need a way to identify which part

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.