jiebi/CodeConvo huggingface dataset:
Change:
resolver IP addresses, to be used for traditional unencrypted DNS. A solution is required that enhances the set of information delivered <del> to include details of one or more equivalent encrypted DNS resolvers, or states that there are none. </del> <ins> to include details of one or more designated encrypted DNS resolvers, or states that there are none.  Such resolvers could be on the local network, somewhere upstream, or on the public Internet. </ins> <del> 5. </del> <ins> 3.5. </ins> To support cases where the network is unable to identify an encrypted resolver, it should be possible to learn the details of one or more <del> equivalent encrypted DNS resolvers by communicating with the network- recommended unencrypted Do53 resolver.  This should involve an exchange that uses standard DNS messages that can be handled, or forwarded, by existing deployed software. </del> <ins> designated encrypted DNS resolvers by communicating with the network's designated Do53 resolver.  This should involve an exchange that uses standard DNS messages that can be handled, or forwarded, by existing deployed software. </ins> <del> It is frequently the case that Do53 resolvers announced by home networks are difficult to upgrade to support encrypted operation.  In such cases it is possible that the only option for encrypted operation is to refer to a separate globally-addressed encrypted DNS resolver. </del> <ins> Each resolver in the set may be at a different network location, which leads to several subcases for the mapping from Do53 to a particular designated resolver. 3.5.1. </ins> If the local resolver has been upgraded to support encrypted DNS, the client may not initially be aware that its local resolver supports

Discussion:
This PR simplifies further by removing any mention of properties of the encrypted resolvers, or properties of the relationship between the Do53 and the encrypted resolver. It now purely focusses on the ability of an untrusted network or resolver to designate other encrypted resolvers. This is an assertion that the encrypted resolver is safe and appropriate to use, but little else. Clients will of course make their own decisions about whether to use designated resolvers or not. Other drafts will look at trusted networks, and communicating information that can be useful to clients as part of the untrusted decision-making.
comments
comments on the draft02
It was pointed out that this should be limited to IETF-standardised encrypted DNS protocols rather than potentially including DNSCrypt and being very open-ended.
Change:
with a value of 1, even if the application does not intend to use HTTP Datagrams.  This helps to avoid "sticking out"; see security. <del> 3.1.1. </del> <ins> 2.1.1.1. </ins> [[RFC editor: please remove this section before publication.]]

Discussion:
NAME thank you for the suggestions over on URL David and I worked through your proposal from top to bottom and turned it into this PR, which accepts many suggestions but not all. Please review and let us know if you're happy with it. NAME we believe some of your comments are addressed here too (unless tracked on a separate ticket). Please take a look.
While the argument in Section 2 "requests are strictly serialised in the connection, therefore demultiplexing is not needed" is technically correct, Section 4. further restricts the use of HTTP/1.1 connections to a single stream of capsules/HTTP datagrams. I would prefer to see this restriction as an argument here.
The sentence "Additionally, this document defines the Capsule Protocol that can convey datagrams over prior versions of HTTP." seems a little misleading … During the IETF 113 discussions, I understood capsules as general mechanism reliable datagrams/wire encoding over HTTP In the draft however, Section 1 state "Additionally, this document defines the Capsule Protocol that can convey datagrams over prior versions of HTTP." contradicts this impression. Can we clarify this?
Why is the ebnf instead of ? Should this allow request/upgrade methods to append a list of additional parameters?
Yes, allows parameters but does not. We didn't see a good reason to ban future parameters
Maybe you should mention it and require intermediaries to pass and ignore them in case they don't understand them.
as per recent changes in HTTPland specs, the ABNF adds confusion. My suggestion is to remove the ABNF. That might still leave a question over the structured types, but that is answered by the Structured Field value specs and we are unlikely to need to state anything ourselves. I can take a pass at this.
LGTM, thanks!
Change:
By definition, the Attester role creates Evidence.  An Attester may consist of one or more nested or staged environments, adding complexity to the architectural structure.  The unifying component is <del> the Root of Trust and the nested, staged, or chained attestation </del> <ins> the root of trust and the nested, staged, or chained attestation </ins> Evidence produced.  The nested or chained structure includes Claims, collected by the Attester to aid in the assurance or believability of the attestation Evidence.

Discussion:
Per design team meeting today Signed-off-by: Dave Thaler
I think it should be root of trust because it is not a defined term like Attester or Verifier.
Lower case is fine, I think. Any objections?
Change:
This document specifies version 1.0 of the Messaging Layer Security (MLS) protocol.  MLS allows group messaging for a large number of <del> clients over a network with the help of a delivery service for messages, and potentially an authentication service to provide long term identity keys, in a way that is designed to prevent eavesdropping, tampering, and message forgery. </del> <ins> networked clients by providing a delivery service for messages, and potentially an authentication service, in a way that is designed to prevent eavesdropping, tampering, and message forgery. </ins> 1. End-to-end security is a requirement for instant messaging systems <del> and is commonly deployed in many such systems designed over the past few years.  In this context, what end-to-end means is that the users of the system enjoy some level of security - with the precise level depending on the system design - even when the messaging service they are using misbehaves. </del> <ins> and is commonly deployed in many such systems.  In this context, "end-to-end" captures the notion that users of the system enjoy some level of security - with the precise level depending on the system design - even when the messaging service they are using performs unsatisfactorily. </ins> Messaging Layer Security (MLS) specifies an architecture (this document) and an abstract protocol [TODO:XREF] for providing end-to-

Discussion:
A few minor edits to (hopefully) improve readability, and a few comments in square braces ([ ]).
Something looks wrong with your text editor... ;)
Arg! Will fix, sorry about this.
Change:
10.1. <del> The following entries are added to the "HTTP/2 Settings" registry </del> <ins> The following entry is added to the "HTTP/2 Settings" registry </ins> established by RFC7540: <del> The "SETTINGS_ENABLE_WEBTRANSPORT" parameter indicates that the specified HTTP/2 connection is WebTransport-capable. ENABLE_WEBTRANSPORT 0x2b603742 0 This document </del> The "SETTINGS_WEBTRANSPORT_MAX_SESSIONS" parameter indicates that the specified HTTP/2 connection is WebTransport-capable and the number of <del> concurrent sessions it is willing to receive.  The default value for the SETTINGS_MAX_WEBTRANSPORT_SESSIONS parameter is "0", meaning that the server is not willing to receive any WebTransport sessions. </del> <ins> concurrent sessions an endpoint is willing to receive.  The default value for the SETTINGS_MAX_WEBTRANSPORT_SESSIONS parameter is "0", meaning that the endpoint is not willing to receive any WebTransport sessions. </ins> WEBTRANSPORT_MAX_SESSIONS

Discussion:
Remove SETTINGSENABLEWEBTRANSPORT in favor of SETTINGSWEBTRANSPORTMAX_SESSIONS.
I can't seem to remember or work out what the purpose of SETTINGSENABLEWEBTRANSPORT is now that we have SETTINGSWEBTRANSPORTMAXSESSIONS. This leads to the following questions: If the server sends SETTINGSWEBTRANSPORTMAXSESSIONS>0 but SETTINGSENABLEWEBTRANSPORT=0, what does that mean? If the client sends SETTINGSENABLEWEBTRANSPORT=0 but sends a WebTransport request, what is the purpose of having the server fail the request?
Yeah, I thought that we would remove SETTINGSENABLEWEBTRANSPORT when the session limit was added. If nothing else, it removes those awkward interactions.
Chair: discussed in editor's meeting, sounds like we should remove SETTINGSENABLEWEBTRANSPORT. We might add another setting to be removed by the RFC editor for versioning between drafts
IIRC, we discussed at IETF 115 and only the server needed to send MAX_SESSIONS, so we kept both. Can spell that either way though.
If we're doing this for H2, should we also do it for H3, since we have SETTINGSMAXWEBTRANSPORT_SESSIONS there, too?
h3 requires SETTINGSENABLEWEBTRANSPORT because it changes the format of server-initiated bidi streams h2 has no such requirement for a setting
Change:
deployed cluster, then this cluster is considered a single client instance. <ins> In these cases, the distinct components of what is considered a GNAP client instance may use any number of different communication mechanisms between them, all of which would be considered an implementation detail of the client instances and out of scope of GNAP. </ins> For another example, an AS could likewise be built out of many constituent components in a distributed architecture.  The component that the client instance calls directly could be different from the <del> component that the the RO interacts with to drive consent, since API </del> <ins> component that the RO interacts with to drive consent, since API </ins> calls and user interaction have different security considerations in many environments.  Furthermore, the AS could need to collect identity claims about the RO from one system that deals with user attributes while generating access tokens at another system that deals with security rights.  From the perspective of GNAP, all of these are pieces of the AS and together fulfill the role of the AS as <del> defined by the protocol. </del> <ins> defined by the protocol.  These pieces may have their own internal communications mechanisms which are considered out of scope of GNAP. </ins> 1.3.

Discussion:
adds a paragraph to the introduction adds specific examples under roles
Deploy preview for gnap-core-protocol-editors-draft ready! Built with commit aa65f1110cdcc11a60ca4d2d284e78f7909d0817 https://deploy-preview-254--gnap-core-protocol-editors-URL
Change:
the query domain name.  That is, if a client queries example.com, the ESNI TXT Resource Record might be: <del> Servers MUST ensure that, if multiple A, AAAA or ALTSVC I-D.schwartz- httpbis-dns-alt-svc records are returned for a domain with ESNI support, all the servers pointed to by those records are able to handle the keys returned as part of a ESNI TXT record for that domain. </del> <ins> Servers MUST ensure that, if multiple A or AAAA records are returned for a domain with ESNI support, all the servers pointed to by those records are able to handle the keys returned as part of a ESNI TXT record for that domain. </ins> Alt-Svc records may be used to inform the client of the plaintext (fronting) SNI.  If present, clients SHOULD use its value in the SNI

Discussion:
Also see URL
LGTM -- thanks!
I suggest dropping the references to Ben's individual alt-svc in DNS draft.. it hasn't been adopted and its future is murky. actual alt-svc (the non dns kind) actually requires the use of the plaintext SNI. As those are both cachable and connections to new IP addresses (less linkable) you could consider updating it with mike bishop's URL (also an individual draft atm)
NAME also suggested that the reference might not be needed in URL so I made to actually remove it.
Change:
further processing for this m= section can be skipped. Provided that is not the case, each m= section in the answer should <del> then be generated as specified in RFC3264, Section 6.1.  Because use of DTLS is mandatory, the <proto> field MUST be set to "UDP/TLS/RTP/ SAVPF".  If the offer supports BUNDLE, all m= sections to be BUNDLEd must use the same ICE credentials and candidates; all m= sections not being BUNDLEd must use unique ICE credentials and candidates.  Each m= section MUST include the following: </del> <ins> then be generated as specified in RFC3264, Section 6.1.  For the m= line itself, the following rules must be followed: The port value would normally be set to the port of the default ICE candidate for this m= section, but given that no candidates have yet been gathered, the "dummy" port value of 9 (Discard) MUST be used, as indicated in I-D.ietf-mmusic-trickle-ice, Section 5.1. Because use of DTLS is mandatory, the <proto> field MUST be set to "UDP/TLS/RTP/SAVPF". The m= line MUST be followed immediately by a "c=" line, as specified in RFC4566, Section 5.7.  Again, as no candidates have yet been gathered, the "c=" line must contain the "dummy" value "IN IP6 ::", as defined in I-D.ietf-mmusic-trickle-ice, Section 5.1. If the offer supports BUNDLE, all m= sections to be BUNDLEd must use the same ICE credentials and candidates; all m= sections not being BUNDLEd must use unique ICE credentials and candidates.  Each m= section MUST include the following: </ins> 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

Discussion:
Update of ekr's PR . Details: Initial offers/answers have no candidates Add canTrickle property Add text regarding a=end-of-candidates Clarify dummy/null address/port stuff
lgtm
NAME can you review this before Friday?
I'll try and carefully read this tomorrow morning but I'm running out of time for today. It looked good on my quick skim of it but I want to read it carefully but don't expect to have issues with it.
On this morning's Editor's Call we discussed the topic of what trickle indicators should appear in the SDP. The trickle draft prescribes two indicators: a=ice-options:trickle a=end-of-candidates However, as agreed at the interim, JSEP agents always do trickle and just expose a canTrickle property. Accordingly, the conclusion was to interpret a=ice-options:trickle as "I can do trickle" (this is consistent with half-trickle) and thus JSEP agents always send it, even if canTrickle=false. So, we should insert a=end-of-candidates when gathering is done to mean "I am done trickling". This means that JSEP agents will generate a=ice-options:trickle in response even to offers which do not contain it. However, offerers should already ignore that. As before, it's up to the app to wait for all the candidates before sending the offer if canTrickle=false
Agreed
Sounds good!
Fixed by
Change:
old key.  The "outer" JWS represents the current account holder's assent to this request. <del> On receiving key-change request, the server MUST perform the following steps in addition to the typical JWS validation: </del> <ins> On receiving keyChange request, the server MUST perform the following steps in addition to the typical JWS validation: </ins> Validate the POST request belongs to a currently active account, as described in message-transport.

Discussion:
This PR is collecting changes to make sure we address during the editing window. Editorial clarifications only, please.
Both and are also TODO's for AUTH48.
Section 7.4 says: It should say , not . NAME Would you mind fixing this typo in this PR?
NAME Turns out the RFC editor caught that one (see ), so I don't have to fix it here :)
LGTM
Change:
are running on the same device. To avoid this issue, browsers SHOULD NOT register mDNS names for <del> WebRTC applications running in a third-party browser execution context (i.e., a context that has a different origin than the top- level execution context), or a private browser execution context. </del> <ins> WebRTC applications running in a third-party browsing context (i.e., a context that has a different origin than the top-level browsing context), or a private browsing context. </ins> 4.

Discussion:
PR of
Anyone else want to take a look?
(browser) execution context -> browsing context
It was suggested to replace the name by "browsing context " in the PR of the security consideration. Execution or browser execution context is consistently used in the new commits, and I will create a PR for this if we decide to change the name.
Change:
exporters SHOULD provide a context in all exporter computations, though the value could be empty. <ins> Requirements for the format of exporter labels are defined in section 4 of RFC5705. </ins> 8. 8.1.

Discussion:
Add reference to label format in 5705. address issue
refer the reader to exporter requirements in RFC 5705 "Requirements for the format of Exporter labels are defined in section 4 of RFC5705." Creating pull request.
NAME should we expect a PR?
This appears to be done.
yes I submitted PR which has been merged already.
Change:
that out of order packets can be processed as well as packets sent during the time keys are changing. <del> 2.3. </del> <ins> When receiving a new EKTKey, implementations need to use the ekt_ttl to create a time after which this key cannot be used and they also need to create a counter that keeps track of how many times the keys has been used to encrypt data to ensure it does not exceed the T value for that cipher.  If either of theses limits are exceeded, the key can no longer be used for encryption.  At this point implementation need to either use the call signaling to renegotiation a new session or need to terminate the existing session.  Terminating the session is a reasonable implementation choice because theses limits should not be exceeded except under an attack or error condition. 2.4. </ins> EKT uses an authenticated cipher to encrypt and authenticate the EKTPlaintext.  This specification defines the interface to the

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:
handshake will fail.  It will also fail unless the "web_accepted_origins" is present. <del> QuicTransport uses a QUIC transport parameter to provide the user agent with an origin whitelist.  The origin is not sent explicitly, as TLS ClientHello messages are sent in cleartext; instead, the server provides the user agent with a whitelist of origins that are allowed to connect to it. </del> <ins> QuicTransport uses a unidirectional QUIC stream to provide the server with the origin of the client. </ins> In order to avoid the use of QuicTransport, the user agents MUST NOT allow the clients to distinguish different connection errors before

Discussion:
What is the uri-scheme used in an origin? ( It may be discussed as a separate issue.
Well, the origin sent here is the origin of the webpage that created QuicTransport; so, for instance, if connects using QuicTransport to , the origin send would be . I don't think a QuicTransport connection can be an origin by itself. We are currently considering giving it its own URL scheme, but a URL can only act as an origin if a user can to it, or if the URL has storage attached to it (which QuicTransport doesn't, since it doesn't support HTTP cookies).
I misunderstood the URI schema as that of QuicTransport itself Your kind explanation made me understand. thanks
Change:
does not duplicate the sequence number of any other record received during the lifetime of the session.  This check SHOULD happen after deprotecting the packet; otherwise the packet discard might itself <del> serve as a timing channel for the sequence number. </del> <ins> serve as a timing channel for the record number.  Note that decompressing the records number is still a potential timing channel for the record number, though a less powerful one than whether it was deprotected. </ins> Duplicates are rejected through the use of a sliding receive window. (How the window is implemented is a local matter, but the following

Discussion:
NAME NAME
Well, clients can recover by tearing down the connection and starting over.
Sure, sure. I think this was in the context of a "single" connection. Perhaps it's not that important to clarify?
I'll add text.
I think the only comment that's left to be addressed is this: Perhaps what's missing is precisely that clarifying statement. Namely, that clients which find themselves in such a situation cannot recover.
Change:
any re-coding.  This allows the resource server to retrieve the shared secret directly from the "cnf" claim of the access token. <ins> DTLS 1.3 does not use the ClientKeyExchange message; for DTLS 1.3, the access token is placed in the "identity" field of a "PskIdentity" within the "PreSharedKeyExtension" of the "ClientHello". </ins> If a resource server receives a ClientKeyExchange message that contains a "psk_identity" with a length greater than zero, it MUST parse the contents of the "psk_identity" field as CBOR data structure

Discussion:
It is perhaps a stretch to call the description of using a for DLTS 1.3 as "editorial", but it really is the analogous way to do it, so this seems like just some additional exposition and not new content. I think that it will be okay to just include this in the XML file provided to the RFC Editor when they ask for one after approval.
Change:
D.ietf-cose-rfc8152bis-struct. An example of a countersignature on a signature can be found in <del> Appendix_B_1_3.  An example of a countersignature in an encryption object can be found in Appendix_B_3_3. </del> <ins> Appendix_A_1_1.  An example of a countersignature in an encryption object can be found in Appendix_A_2_1. </ins> It should be noted that only a signature algorithm with appendix (see I-D.ietf-cose-rfc8152bis-struct) can be used for countersignatures.

Discussion:
Remove the sections from the Examples Applenix that were blank, clean up the Security Considerations, and narrow the table in the IANA considerations.
Looks good to me! Thanks! Let us know if you want us to merge it or you plan to do that yourself.
Change:
Captive Portal API URI to the User Equipment when it connects to the network, and later if the URI changes.  The provisioning service could also be the same service which is responsible for provisioning <del> the User Equipment for access to the Captive Network (e.g., by </del> <ins> the User Equipment for access to the Captive Portal (e.g., by </ins> providing it with an IP address).  This section discusses two mechanisms which may be used to provide the Captive Portal API URI to the User Equipment.

Discussion:
A reviewer pointed out that Captive Portal and Captive Network were used interchangeably in the document. While we used Captive Network more frequently, Captive Portal aligns more closely with familiar use of the term. Further, other documents such as the API draft refer to the system as a whole as a Captive Portal, which makes this change more aligned with them.
Tirupachur Comerica, Subash writes: I think that this is clear: one is a network and the other a server. Review to see if the right choice is used throughout. URL point out that we assume a degree of mutual control over both.