jiebi/CodeConvo huggingface dataset:
Change:
Message Properties can be set and queried using the Message Context: To get or set Message Properties, the optional scope parameter is <del> left empty, for framing meta-data, the framer is passed. </del> <ins> left empty.  To get or set meta-data for a Framer, the application has to pass a reference to this Framer as the scope parameter. </ins> For MessageContexts returned by send events (see send-events) and receive events (see receive-events), the application can query

Discussion:
Tentatively answering my own questions in : Removed the messageContext here because the RendezvousError does not necessarily relate to a specific sent Message. If it does, the "reason" parameter can point to that message and/or a messageContext. The beginning of Section 7 actually already said that this IS the messageContext. I removed the word "implementation-specific" because to me this word made it sound like this reference can't be the messageContext. Split into two sentences and changed the second sentence to active voice. Also, I slightly reworded the beginning of Section 7, which is now a bit clearer in my opinion.
When reading the current API draft, I found three minor issues related to Message Contexts. The RendezvousError (Section 6.3) includes a messageContext (which is even required), but neither the InitiateError nor the ListenError include one. Why? Should this messageContext at least be optional?In Section 7.3, it says "The Sent Event contains an implementation-specific reference to the Message to which it applies." - Is this in addition to the messageContext? If yes, why do we need both?In Section 9, it says "To get or set Message Properties, the optional scope parameter is left empty, for framing meta-data, the framer is passed." - I think this sentence is a bit hard to parse and it wasn't immediately obvious to me what kind of framing meta-data this refers to. Perhaps this refers to Section 10.2, so I think it's worth adding a reference to that section here. Also, I suggest turning this into two sentences, with the sentence on framing meta-data specifying that this is per-Message metadata to be used by the framer.
Thanks a lot for doing this! It clears things up nicely, I think.
Change:
volume of activity to follow.  Participants who wish to limit this time commitment might follow GitHub activity selectively, either by following only specific issues or by occasionally reviewing the state <del> of the document.  Chairs are reminded that assessing consensus based on GitHub content alone cannot be assumed to reach all interested participants. </del> <ins> of the document.  Other participants might not use GitHub at all. Chairs are reminded that assessing consensus based on GitHub content alone cannot be assumed to reach all interested participants. Chairs MUST consider input from all discussion venues when assessing consensus including GitHub, mailing lists, and in-person meetings. Each venue has different selection biases that might need to be considered. </ins> A Working Group chair MUST consult the Working Group mailing list for any issue that is potentially contentious.  Relying on input provided through GitHub alone might result in gaining input from a narrower set of participants.  This includes important milestones like Working Group Last-Call, where review from the widest possible audience <del> ensures a higher quality document.  Managing input from multiple sources in assessing consensus is similar to what is needed when balancing mailing list discussion versus in-person meeting discussion. </del> <ins> ensures a higher quality document. </ins> <del> It is expected that technical decisions will be made based on discussion and interaction on GitHub.  This is especially the case during early stages of development of a document.  Any decisions are ultimately confirmed through review, and ultimately, through Working Group Last Call (see Section 7.4 of RFC2418). </del> <ins> If permitted, GitHub will be used for technical discussion and decisions, especially during early stages of development of a document.  Any decisions are ultimately confirmed through review, and ultimately, through Working Group Last Call (see Section 7.4 of RFC2418). </ins> The use of issues and labels has proven to be effective in managing contentious issues.  Explicitly labeling closed issues to explicitly

Discussion:
This has two commits: Unpack "session" a little more to make it clear that this isn't just IETF meetings. Explain that participation on GitHub isn't the only possible input, and the effect that this has on assessing WG consensus.
Change:
closing the connection by sending a "close_notify" is more appropriate.  This alert MUST be followed by a "close_notify". This alert generally has AlertLevel=warning.  Receiving <del> implementations should continue to read data from the peer until a </del> <ins> implementations SHOULD continue to read data from the peer until a </ins> "close_notify" is received, though they MAY log or otherwise record them.

Discussion:
Change "should" -> "SHOULD" around user_canceled Replicate the 8773 language to another place where external PSKs is discussed. Remove an OPEN ISSUE marker
Change:
information about the source physical interface (e.g.  a tunnel). The API Server faces a similar problem, implying that it should co- <del> exist with the Enforcement Device, or that the enforcement device </del> <ins> exist with the Enforcement Device, or that the Enforcement Device </ins> should extend requests to it with the identifying information. 3.4.2.

Discussion:
We were using "Captive Portal Enforcement", "Captive Portal Enforcement Device" and "Enforcement Device", with varying capitilisation, inconsistently throughout the document. Address that by defining the component as "Captive Portal Enforcement Device", and using that term in section headings, and "Enforcement Device" everywhere else. Fixes issue
Looks good to me
Used in different ways: Captive Portal Enforcement, enforcement device, etc.
I think keeping it shorter is likely better. ? Caps to make it clear it's a first class component in the architecture?
Change:
encryption is not needed, RFC6234, combined with a sequence number and a replay window, may be used. <ins> This size of the replay window depends upon the number of outstanding requests that need to be outstanding.  This can be determined from the rate at which new ones are made, and the expected duration in which responses are expected. For instance, given a CoAP ACK_TIMEOUT of 2s, and a request rate of 10 requests/second, any request that is not answered within 2s will be considered to have failed.  Thus at most 20 request can be outstanding at a time, and any convenient replay window larger than 20 will work.  As replay windows are often implemented with a sliding window and a bit, the use of a 32-bit window would be sufficient. For use cases where requests are being relayed from another node, the request rate may be estimated by the total link capacity allocated for that kind of traffic.  An alternate view would consider how many IPv6 Neighbor Cache Entries (NCEs) the system can afford to allocate for this use. </ins> When using an encryption mode that depends on a nonce, such as AES- CCM, repeated use of the same nonce under the same key causes the cipher to fail catastrophically.

Discussion:
This is some advice on how big the replay window needs to be.
doc> a 64 bit tag is recommended, combined with a sequence number and a doc> replay window. Where encryption is not needed, HMAC-SHA-256, doc> combined with a sequence number and a replay window, may be used. [[TODO]]
An absolute timestamp is probably not necessary, as the key should be newly generated on a reboot. A boot-relative timestamp may be enough. The window pretty much becomes the "patience" value -- how long does the client wait for getting its response?
Change:
The receives this request and removes the HPKE protection to obtain an HTTP request. <del> The makes an HTTP request that includes the target URI, method, fields, and content of the request it acquires. The answers this HTTP request with an HTTP response. </del> <ins> The then handles the HTTP request.  This typically involves making an HTTP request using the content of the . Once the has an HTTP response for this request, the following steps occur to return this response to the client: </ins> The encapsulates the HTTP response following the process in response and sends this in response to the request from the .

Discussion:
This change tries to emphasize that OHTTP is a protocol between client, relay, and gateway, and that the target is sort of ancillary to the whole thing. It further clarifies that the relay should not act as an open proxy when it's operated by an entity that is separate from the target server.
This works for me. We can merge this and then I want to take another pass at the other PR.Thanks NAME -- couple nits, otherwise lgtm.LGTM
Change:
client's appearance in the group, signed by that client: The "public_key" field conains an HPKE public key whose private key <del> is held only by the member occupying this leaf.  The "credential" contains authentication information for this member, as described in credentials. </del> <ins> is held only by the member occupying this leaf (or in the case of a LeafNode in a KeyPackage object, the issuer of the KeyPackage).  The "credential" contains authentication information for this member, as described in credentials. </ins> The "capabilities" field indicates what protocol versions, ciphersuites, protocol extensions, and non-default proposal types are

Discussion:
This PR picks up changes from clarifying and cleaning up a few issues around LeafNode.
A big improvement in readability and correctness.
Change:
Section 22.1.1 of QUIC-TRANSPORT. The initial allocations in these registries created in this document <del> are all assigned permanent status and list as contact both the IESG (iesg@ietf.org) and the HTTP working group (ietf-http-wg@w3.org). </del> <ins> are all assigned permanent status and list as contact both the IETF and the HTTP working group (ietf-http-wg@w3.org). </ins> 11.2.1.

Discussion:
NAME see .
Section 11.2: URL "The initial allocations in these registries created in this document are all assigned permanent status and list as contact both the IESG (EMAIL) and the HTTP working group (EMAIL)." From my perspective it is better to have IETF as change controller. In practice that would mean that any chartered WG to work on this registry would by completing the IETF process be allowed to introduce changes to the registry. Having HTTP Working Group as contact is fine. So I would propose to change this to: "The initial allocations in these registries created in this document are all assigned permanent status and list as change controller the IETF and the HTTP working group (EMAIL) as contact."
Change:
by sending the client an empty "signature_algorithms" extension. The "extension_data" field of this extension in a ClientHello <del> contains a "supported_signature_algorithms" value: </del> <ins> contains a SignatureSchemeList value: </ins> %%% Signature Algorithm Extension

Discussion:
Criteria for one member structure / non structure is as follows: Non structure: basic type -- not messages nor extensions One member structure: others such as messages or extensions
LGTM
Change:
5.6.1. <del> SWID or CoSWID by the referenced tag's tag-id.  This URI needs to be resolved in the context of the endpoint by software that can lookup other SWID or CoSWID tags.  For example, "swid:2df9de35-0aff- 4a86-ace6-f7dddd1ade4c" references the tag with the tag-id value "2df9de35-0aff-4a86-ace6-f7dddd1ade4c". </del> There is a need for a scheme name that can be used in URIs that point to a specific SWID/CoSWID tag by that tag's tag-id, such as the use of the link entry as described in section model-link) of this

Discussion:
Fixed typo identified by Alex Nelson. Also removed some extra working text that was accidentally left in an IANA section. This PR will be kept open until the WGLC concludes.
Change:
The creator of an MLS group creates the group's first epoch unilaterally, with no protocol interactions.  Thereafter, the members of the group advance their shared cryptographic state from one epoch <del> to another by exchanging MLS messages: </del> <ins> to another by exchanging MLS messages. </ins> A _KeyPackage_ object describes a client's capabilities and provides keys that can be used to add the client to a group.

Discussion:
This removes the following graf: The DS and AS may also apply additional policies to MLS operations to obtain additional security properties. For example, MLS enables any participant to add or remove members of a group; a DS could enforce a policy that only certain members are allowed to perform these operations. MLS authenticates all members of a group; a DS could help ensure that only clients with certain types of credential are admitted. MLS provides no inherent protection against denial of service; A DS could also enforce rate limits in order to mitigate these risks. My sense is this belongs in Security Considerations, not here.
This looks good to me. Please do move the removed paragraph to the security considerations, either here or in .
Change:
5.1.2. When using simulcast, the same input image will produce N different <del> encoded frames (one per simulcat layer) which would be processed inpependently by the frame encryptor and assigned an unique counter </del> <ins> encoded frames (one per simulcast layer) which would be processed independently by the frame encryptor and assigned an unique counter </ins> for each. 5.1.3.

Discussion:
Rewrite the Key management section Add MLS subsection Update the SFrame format Fixed typos
Change:
9.2. In addition to the SenML Fragment Identifiers described above, with <del> the XML SenML formats also the syntax defined in XPointerFramework can be used, as recommended by RFC7303. </del> <ins> the XML and EXI SenML formats also the syntax defined in XPointerFramework can be used.  (This is required by RFC7303 for media types using the "+xml" structured syntax suffix.  SenML allows this for the EXI formats as well for consistency.) Note that fragment identifiers are available to the client side only; they are not provided in transfer protocols such as CoAP or HTTP. Thus, they cannot be used by the server in deciding which media type to send.  Where a server has multiple representations available for a resource identified by a URI, it might send a JSON or CBOR representation when the client was directed to use an XML/EXI fragment identifier with this.  Clients can prevent running into this problem by explicitly requesting an XML or EXI media type (e.g., using the CoAP Accept option) when XML/EXI-only fragment identifier syntax is in use in the URI. </ins> 10.

Discussion:
EXI is XML so for consistency we should allow anything that is allowed for (character) XML for EXI as well. Make Klaus' point about content negotiation possibly leading to a format where xpointer does not apply and add the Accept workaround.
LGTM
Change:
and no trailing newline character. The party then hashes this string with the appropriate algorithm <del> based on the "hash_method" parameter under the "finish" key.  If the "hash_method" value is not present in the client instance's request, the algorithm defaults to "sha3". [[ See issue #56 [11] ]] </del> <ins> based on the "hash_method" parameter under the "finish" key.  The resulting byte array from the hash function is then encoded using URL-Safe Base64 with no padding RFC4648.  The resulting string is the hash value. </ins> <del> 4.2.3.1. </del> <ins> The "hash_method" value MUST be one of the hash name strings defined in the IANA Named Information Hash Algorithm Registry [11]. </ins> <del> The "sha3" hash method consists of hashing the input string with the 512-bit SHA3 algorithm.  The byte array is then encoded using URL Safe Base64 with no padding RFC4648.  The resulting string is the hash value. </del> <ins> If the "hash_method" value is not present in the client instance's request, the algorithm defaults to "sha3-512". </ins> <del> 4.2.3.2. </del> <ins> For example, the "sha3-512" hash method consists of hashing the input string with the 512-bit SHA3 algorithm.  The byte array is then encoded using URL-Safe Base64 with no padding RFC4648.  The resulting string is the hash value. </ins> <del> The "sha2" hash method consists of hashing the input string with the 512-bit SHA2 algorithm.  The byte array is then encoded using URL Safe Base64 with no padding RFC4648.  The resulting string is the </del> <ins> The "sha2-512" hash method consists of hashing the input string with the 512-bit SHA2 algorithm.  The byte array is then encoded using URL-Safe Base64 with no padding RFC4648.  The resulting string is the </ins> hash value. 5.

Discussion:
To edit notification comments on pull requests, go to your ._
Receive a Callback After Interaction: Editor's note: This should be expandable via a registry of cryptographic options, and it would be good if we didn't define our own identifiers here. Calculating the interaction hash: Editor's note: These hash algorithms should be pluggable, and ideally we shouldn't redefine yet another crypto registry for this purpose, but I'm not convinced an appropriate one already exists. Furthermore, we should be following best practices here whether it's a plain hash, a keyed MAC, an HMAC, or some other form of cryptographic function. I'm not sure what the defaults and options ought to be, but SHA512 and SHA3 were picked based on what was available to early developers.
This is probably the right registry to reference: URL
Please add a changelog, but this looks good to me!
Change:
When a DNS client is configured with an Unencrypted DNS Resolver IP address, it SHOULD query the resolver for SVCB records for the name <del> "resolver.arpa" before making other queries.  Specifically, the client issues a query for "_dns.resolver.arpa" with the SVCB resource record type (64) I-D.ietf-dnsop-svcb-https. </del> <ins> "resolver.arpa" before making other queries, in order to use Encrypted DNS for all other queries, if possible.  Specifically, the client issues a query for "_dns.resolver.arpa." with the SVCB resource record type (64) I-D.ietf-dnsop-svcb-https. </ins> Because this query is for an SUDN, which no entity can claim ownership over, the ServiceMode SVCB response MUST NOT use the "."

Discussion:
NAME please check!
I think there are way too many bald SHOULDs in this document. Since SHOULD presents an implementer with a choice, it's usually a good idea to describe that choice rather than presenting something that looks like "you really should do this, but it's probably fine if you don't" and moves on. To wit: An example of one that could use improvement is the first one in Section 4, as I've no idea why you would not always do what it says. An example of one that does provide such guidance is the second one in Section 4, where I understand the consequences of not doing what it says.
LGTM!
Change:
have been added to improve readability but are not valid in SDP. More examples of SDP for WebRTC call flows, including examples with <del> IPv6 addresses, can be found in I-D.nandakumar-rtcweb-sdp. </del> <ins> IPv6 addresses, can be found in I-D.ietf-rtcweb-sdp. </ins> 7.1.

Discussion:
I don't know why build of ghpages is failing travis. It works for me on my machine so going to ignore this for a bit.
Here is the diff of the change.
BLOCKER: The nits tool reports (and a cursory hand check supports this) that six of the references are unused, and RFC4572 has been (recently) obsoleted. The remaining references are largely out of date by many versions, which I believe the current tools will automatically handle if version numbers are simply pulled out of the source. Finally, a large number of the referenced working group documents still use the individual name (e.g., draft-nandakumar-rtcweb-sdp instead of draft-ietf-rtcweb-sdp).
Need to verify section numbers when these refs change, but otherwise seems fine.
LGTMLG, assuming this generates the equivalent text.
Change:
the Connection's transport properties.  The SendError contains a reference to the Message to which it applies. <del> 8.2.4. </del> <ins> 8.2.3. </ins> It is not always possible for an application to send all data associated with a Message in a single Send Action.  The Message data

Discussion:
says: But it appears the Connection object is still required to call Send, so what value does this provide? I.e., how are you supposed to use replyMessageContext from the example?
I agree - it seems to me now that this really adds no value. What am I missing? I'm assigning NAME because he was among the first to propose this... maybe he can explain
Ping :)
Interim: We will remove all "reply/replies" from the API doc.
Change:
6. <del> Security considerations for DetNet are described in detail in I- D.ietf-detnet-security.  General security considerations are described in RFC8655.  This section considers exclusively security considerations which are specific to the DetNet MPLS data plane. </del> <ins> General security considerations are described in RFC8655. Additionally, security considerations and a threat analysis are described in I-D.ietf-detnet-security.  This section considers exclusively security considerations which are specific to the DetNet MPLS data plane. </ins> Security aspects which are unique to DetNet are those whose aim is to provide the specific quality of service aspects of DetNet, which are

Discussion:
Fixing the comments received during the IESG review.
MPLS document
MPLS: All 01-27 changes updated
Done
Change:
the packet is sufficiently large to initiate a new connection for any version supported by the server, it SHOULD send a Version Negotiation packet as described in send-vn.  Servers MAY rate control these <del> packets to avoid storms of Version Negotiation packets. </del> <ins> packets to avoid storms of Version Negotiation packets.  Otherwise, servers MUST drop packets that specify unsupported versions. </ins> The first packet for an unsupported version can use different semantics and encodings for any version-specific field.  In

Discussion:
Qualifies a MUST with an 'otherwise', since otherwise it would appear to directly contradict previous normative text.
Change:
3.4. Registration Base URIs can contain link-local IP addresses.  To be <del> usable across hosts, those can not be serialized to contain zone </del> <ins> usable across hosts, those cannot be serialized to contain zone </ins> identifiers (see RFC6874 Section 1). Link-local addresses can only be used on a single link (therefore RD <del> servers can not announce them when queried on a different link), and </del> <ins> servers cannot announce them when queried on a different link), and </ins> lookup clients using them need to keep track of which interface they got them from.

Discussion:
Will merge before the interim to have a discussion on the big stuff with the small stuff out of the way.
Change:
discard any additional tickets.  Servers SHOULD additionally place a limit on the number of tickets they are willing to send, to save resources.  Therefore, the number of NewSessionTicket messages sent <del> will be the minimum of the server's self-imposed limit and </del> <ins> will typically be the minimum of the server's self-imposed limit and </ins> TicketRequestContents.count. Servers that support ticket requests MUST NOT echo "ticket_request"

Discussion:
I don't think any of this paragraph should have 2119 language in it. But, even overlooking that minor disagreement, it's important to avoid unintentional requirements. I think my edit guides well-meaning implementors, while making no guarantees.
This editorial change is fine by me.