jiebi/CodeConvo huggingface dataset:
Change:
Path Properties of the path(s) in use, once the Connection has been established.  These properties can be derived from the local <del> provisioning domain, measurements by the Protocol Stack, or other sources.  They can only be queried. </del> <ins> provisioning domain RFC7556, measurements by the Protocol Stack, or other sources.  They can only be queried. </ins> 9.1.

Discussion:
Implements
tagging discuss since NAME and I, at least, apparently have a fairly fundamental disagreement on flexibility versus classification of layers 2.
NAME - I don't think I'll fight for this one, but to begin with, tell me: what do you think is wrong about my view?
Thanks for the hearty discussion! On this point, I do agree with NAME that we're not going to achieve full portability across systems for interfaces and PvDs, and it likely doesn't need to be a goal. If I'm writing an implementation in ten years for some new system that only uses Wi-Fi and [INSERT FANCY NEW RADIO TYPE HERE], why would I need to add support for this wired ethernet thing that I don't have any devices for? Since moving between different implementations isn't likely going to be 100% portable anyhow due to language differences and symbol differences, applications will need to change. However, a specific implementation that is portable (like NEAT, or like Apple's if we make it cross-platform) should endeavor to offer the same types across systems.
Fine by me, go ahead
NAME NAME please take a look at the update! NAME I assume based on your last comment that you're okay with the change going in now?
Yes, I agree with it!
let's land this one then...
Works for me now. Sorry for the delay!in my opinion, almost there… only minor comments to address left
Change:
JSEP applications typically inform the JSEP implementation to begin ICE gathering via the information supplied to setLocalDescription, as <del> this is where the app specifies the number of media streams, and thereby ICE components, for which to gather candidates.  However, to accelerate cases where the application knows the number of ICE </del> <ins> the local description indicates the number of ICE components which will be needed and for which candidates must be gathered.  However, to accelerate cases where the application knows the number of ICE </ins> components to use ahead of time, it may ask the implementation to gather a pool of potential ICE candidates to help ensure rapid media setup.

Discussion:
I tried to clarify bundle-only while Iw as in here.
BLOCKER: The final paragraph in section 3.5.1 says that candidates are only gathered for m= sections referenced in BUNDLE tags. Section 3.5.4 talks about gathering more candidates than that under certain circumstances. Please make these consistent with each other.
Agree this needs to be rewritten; with BUNDLE, # of media streams is not the number of ICE components.
Change:
difference is that TCP does not provide stream multiplexing and therefore stream multiplexing would need to be implemented in the application layer if needed.  Further, TCP implementations and <del> network paths often do not support the Fast Open option, which is analogous to 0-RTT session resumption.  Note that there is some evidence of middleboxes blocking SYN data even if TFO was successfully negotiated (see PaaschNanog).  And even if Fast Open successfully operates end-to-end, it is limited to a single packet of payload, unlike QUIC 0-RTT. </del> <ins> network paths often do not support the Fast Open option RFC7413, which enables sending of payload data together with the first control packet of a new connection as also provided by 0-RTT session resumption in QUIC.  Note that there is some evidence of middleboxes blocking SYN data even if TFO was successfully negotiated (see PaaschNanog).  And even if Fast Open successfully operates end-to- end, it is limited to a single packet of TLS handshake and application data, unlike QUIC 0-RTT. </ins> Moreover, while encryption (in this case TLS) is inseparably integrated with QUIC, TLS negotiation over TCP can be blocked.  If

Discussion:
I don't think this sentence was accurate. TFO isn't analogous to 0-RTT session resumption, but it's needed to achieve the same application effect.
maybe analogous wasn't the right term but I'm also not sure about the word "true" here...
NAME "true" meaning "actual", i.e. you can resume a session without a round trip. We could specify that further but it probably has to be more wordy.
Change:
signatures for certificates that contain the keyEncipherment KeyUsage (RFC5280 section 4.2.1.3) In order to prevent this type of cross- protocol attack, we define a new DelegationUsage extension to X.509 <del> which permits use of delegated credentials.  Clients MUST NOT accept </del> <ins> that permits use of delegated credentials.  Clients MUST NOT accept </ins> delegated credentials associated with certificates without this extension.

Discussion:
This suggests some minor changes to the draft, the goal being to clarify the text without changing any semantics. Most are minor, but one of the commits changes the way the client verification procedure is presented.
thanks a lot for the fixes, I like all of these changes
Change:
character and leading spaces on wrapped lines are not part of the value. <ins> Terminology specific to GNAP is defined in the terminology section of the core specification I-D.ietf-gnap-core-protocol, and provides definitions for the protocol roles: Authorization Server (AS), Client, Resource Server (RS), Resource Owner (RO), End-user; as well as the protocol elements: Attribute, Access Token, Grant, Privilege, Protected Resource, Right, Subject, Subject Information.  The same definitions are used in this document. </ins> 2. When the AS issues an access token for use at an RS, the RS needs to

Discussion:
closing
:heavycheckmark: Deploy Preview for gnap-resource-servers-editors-draft ready! Built :hammer: Explore the source changes: 35665c3208b87850c24d51a1083919c030a1978d :mag: Inspect the deploy log: :sunglasses: Browse the preview:
Added the list of terms
Include a reference to the Terminology section of the Core doc.
I think we should list out the terminology in question here as well as the general reference.
Change:
description describing the error and what types of contact URL the server considers acceptable. <del> The server creates an account and populates the account object with the "key" field containing the JWK public key used to verify the JWS. The server returns this account object in a response with a 201 (Created) status code, with the account URI in a Location header field. </del> <ins> The server creates an account and stores the public key used to verify the JWS (i.e., the "jwk" element of the JWS header) to authenticate future requests from the account.  The server returns this account object in a 201 (Created) response, with the account URI in a Location header field. </ins> If the server already has an account registered with the provided account key, then it MUST return a response with a 200 (OK) status

Discussion:
The client knows what its public key is, because it has to have access to the private key in order to sign new-account requests or updates to the account resource. So this field serves no purpose.
Has this been discussed on list? I'm concerned that we're removing information that could be valuable for debugging client issues. There's no harm in keeping this; the server has to store this information anyway.
Yep, this was discussed on-list. I can say that as a client developer, I've never found this field useful. Clients need to be able to successfully serialize a jwk in order to speak the protocol. Also, I have no objection to servers including this as an extra field, but it seems wrong to normatively require it when it serves no purpose.
For the record where it was available for discussion. For me, the observation that you need the private key to get an account object is dispositive. There's not even debugging utility here. So I'm OK to merge. Right now, account objects echo back the public key associated with the account, in the "key" field. However, this is redundant since the only request types that can return an account object are signed by the corresponding private key, so the client necessarily knows what its public key is. Removing this simplifies the spec somewhat. URL Thoughts?
Change:
HTTP/3 endpoints contain a QPACK encoder and decoder.  Each endpoint MUST initiate at most one encoder stream and at most one decoder stream.  Receipt of a second instance of either stream type MUST be <del> treated as a connection error of type HTTP_WRONG_STREAM_COUNT.  These streams MUST NOT be closed.  Closure of either unidirectional stream type MUST be treated as a connection error of type </del> <ins> treated as a connection error of type HTTP_STREAM_CREATION_ERROR. These streams MUST NOT be closed.  Closure of either unidirectional stream type MUST be treated as a connection error of type </ins> HTTP_CLOSED_CRITICAL_STREAM. An endpoint MAY avoid creating its own encoder stream if it's not

Discussion:
On receiving duplicate QPACK streams, the error should be HTTPSTREAMCREATION_ERROR which matches with control stream duplicates.
Technically should have a corresponding issue, but yes. Nice spot!
Change:
Indicates support of the corresponding named curve.  Note that some curves are also recommended in ANSI X9.62 X962 and FIPS 186-4 <del> DSS.  Others are recommended in I-D.irtf-cfrg-curves.  Values 0xFE00 through 0xFEFF are reserved for private use. </del> <ins> DSS.  Others are recommended in RFC7748.  Values 0xFE00 through 0xFEFF are reserved for private use. </ins> Indicates support of the corresponding finite field group, defined

Discussion:
(Let me know if you think this is sufficiently non-trivial that it deserves a mailing list posting. It is a wire format change, but I think a fairly boring one.) Only the outer length prefix is necessary, not the inner one. Named groups can just as easily take a byte string with known length rather than need to parse fields out. This is consistent with the definition of DigitallySigned.signature; the signature is an opaque field which is passed as a byte string into the corresponding signature algorithm. The definition of rsapsssha256 does not define an inner u16 length prefix. It simply takes the opaque byte string and passes it into the rsapsssha256 function. (In fact, this change means KeyShareEntry and DigitallySigned structures exactly parallel.) This also fixes some references to non-existent structures like ECPoint and dh_Yc. (Those seem to be remnants of TLS 1.2.)
Change:
If a data channel m= section has been offered, a m= section MUST also be generated for data.  The <media> field MUST be set to <del> "application" and the <proto> and "fmt" fields MUST be set to exactly match the fields in the offer.  Note that if media m= sections are bundled into a data m= section, then certain TRANSPORT and IDENTICAL attributes may appear in the data m= section even if they would otherwise only be appropriate for a media m= section (e.g., "a=rtcp- mux"). </del> <ins> "application" and the <proto> and <fmt> fields MUST be set to exactly match the fields in the offer. </ins> Within the data m= section, an "a=mid" line MUST be generated and included as described above, along with an "a=sctp-port" line

Discussion:
NAME PTAL at this. I realized the answer section also needed to be updated to match the new offer text, so I made some changes there which involved a bit of massaging of the text added in .
LGTM
Change:
with possible stateful treatment of requests are sufficiently large that the cost of deploying this protocol can be justified.  Oblivious HTTP is simpler and less costly than more robust systems, like Prio <del> (PRIO) or Tor (Dingledine2004), which can provide stronger guarantees at higher operational costs. </del> <ins> (PRIO) or Tor (DMS2004), which can provide stronger guarantees at higher operational costs. </ins> Oblivious HTTP is more costly than a direct connection to a server. Some costs, like those involved with connection setup, can be

Discussion:
Dingledine2004 -> DMS2004 ODoH -> ODOH-PETS
Comment by NAME ODOH and ODoH seems very similar and likely to cause confusion. Rename one?
thanks
Comment by NAME Using "[Dingledine2004]" as description identifier for TOR is a bit weird :P
This is entirely appropriate given the nature of the reference. This is a reference to a paper, not a specification for Tor, so using "[TOR]" could be misleading. It's possible that we could cite a specification, but it's really hard to pin that down properly. URL seems right, but it doesn't bear a date and appears to be a rendering from URL which is in turn just a snapshot (currently URL). Aside from referential stability, the specification is less of a useful reference as it says less about what Tor is and gets buried in detail. I'm inclined to leave as-is, or switch to "[DMS2004]" to reference all author's names.
ok
Change:
1.5.4. In this example flow, the AS policy allows the client instance to <del> make a call on its own behalf, without the need for a RO to be </del> <ins> make a call on its own behalf, without the need for an RO to be </ins> involved at runtime to approve the decision.  Since there is no explicit RO, the client instance does not interact with an RO. The client instance request.  The client instance does not send <del> any interactions modes to the server. </del> <ins> any interaction modes to the server. </ins> The AS determines that the request is been authorized, the AS grants access to the information in the form of response-token to

Discussion:
fixed some typos fixed a broken reference HTTP -> HTTP to keep it consistent not sure if it is actually supposed to be "Key-Bound Token Access Tokens"
Deploy Preview for gnap-core-protocol-editors-draft ready! Built Explore the source changes: 5faf7b6b37c82891ee35bd06e0a71419b2fbeddc Inspect the deploy log: Browse the preview:
Change:
7. A SenML Pack or Stream can also be represented in XML format as <del> defined in this section.  The following example shows an XML example for the same sensor measurement as in co-ex. </del> <ins> defined in this section. Only the UTF-8 form of XML is allowed.  Characters in the String Value are encoded using the escape sequences defined in RFC7159. Octets in the Data Value are base64 encoded with URL safe alphabet as defined in Section 5 of RFC4648. The following example shows an XML example for the same sensor measurement as in co-ex. </ins> The SenML Stream is represented as a sensml tag that contains a series of senml tags for each SenML Record.  The SenML Fields are

Discussion:
I think that the current SenML draft is missing a note on JSON/CBOR differences in Data Value: While it is explicitly stated that vd is a base64 string in JSON and a binary-value in CBOR, the supposedly exhaustive list of differences in 6. fails to mention that no base64 encoding is done in CBOR. Suggested addition: o For Data Values, no base64url-encoding is done, as the data can be directly expressed as binary-value. Furthermore, I suggest that "Characters in the Data Value are base64 encoded" be expressed as "Bytes [...]" or "Octets are encoded [...]", to make the distinction to the character-based strings and binary data clearer. (The only context in which I'd name bytes of binary data "Character" are when speaking of a "char" in C). Best regards Christian
Indeed, characters should be called characters, and bytes should be called bytes. (In C, bytes are represented as uint8_t :-). s/can be/are/ (they are!)
Have a read of the PR I put in for this. I think it resolves the issue
Looks good to me (with the one typo fix)
typo fix
Change:
4.1. <del> A (re-)starting device may want to find one or more RDs for discovery purposes.  Dependent on the operational conditions, one or more of the techniques below apply. </del> <ins> A (re-)starting device may want to find one or more RDs before it can discover their URIs.  Dependent on the operational conditions, one or more of the techniques below apply. </ins> The device may be pre-configured to exercise specific mechanisms for finding the RD:

Discussion:
See-Also: URL Thank you -- I found this document to be a very friendly read. The Terminology section in particular was one of the best in recent memory. Comments: 1: "These CTs arethought to act on behalf of endpoints too constrained, or generally unable, to present that information themselves. " This reads very oddly - "thought to act on" sounds like we've seen some of these in the wild, and only have a vague idea about how they work. Does "These CTs act on behalf of endpoints too constrained, or generally unable, to present that information themselves. " work? 2: "From the system design point of view, the ambition is to design horizontal solutions that  can enable utilization of machines in different applications depending on their current availability and capabilities as well as application requirements, thus avoiding silo like solutions" - this is very buzzwordy, and I have no idea what it is actually trying to say... 3: "  A (re-)starting device may want to find one or more RDs for discovery purposes." Either I don't understand what this sentence is  trying to say, or "for discovery purposes" should be dropped....  4: "As some of the RD addresses obtained by the methods listed here are just (more or less educated) guesses, endpoints MUST make use of any error messages to very strictly rate-limit requests to candidate IP addresses that don't work out. " What happens if device A discovers RD X, and device B discovers RD Y? Surely there has to be some sort of deterministic method so that one doesn't end up in a "split brain" type outcome? Nits: 1: " The input to an RD is composed of links and the output is composed of links constructed from the information stored in the RD." While  true, this sentence doesn't actually communicate anything useful to the reader -- I'd suggest removing it from the Abstract (note that this is just a nit). 2: "The RD is primarily a tool to make discovery operations more efficient than querying /.well-known/core on all connected devices, or across boundaries that would be limiting those operations." s/would be limiting those/that would limit those/
Change:
UTF-8 RFC3629" (see RFC7049 section 2.1).  Thus both SWID and CoSWID use UTF-8 for the encoding of characters in text strings. <del> To ensure that UTF-8 character strings are able to be encodes/decoded </del> <ins> To ensure that UTF-8 character strings are able to be encoded/decoded </ins> and exchanged interoperably, text strings in CoSWID MUST be encoded consistent with the Net-Unicode definition defined in RFC5198.

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:
padded and AEAD-encrypted using cipher suite "suite" and with the key generated as described below. <ins> For servers (in EncryptedExtensions), this extension contains the following structure: The contents of PaddedServerNameList.nonce.  (See client- behavior.) </ins> 5.1. In order to send an encrypted SNI, the client MUST first select one

Discussion:
This is a proposal to address the misrouting and key share replacement attacks identified by Ekr, Karthik, and Benjamin. Please help me improve it!
Some minor nits.
Change:
6.2. <ins> QUIC servers might have QUIC running on multiple processes listening on the same address, and have a need to demultiplex between them.  In principle, this demultiplexer is a Layer 4 load balancer, and the guidance in lb-chains applies.  However, in many deployments the demultiplexer lacks the capability to perform decryption operations. There are some other techniques that might work, depending on the capabilities of the server architecture. Some bytes of the server ID are reserved to encode the process ID. The demultiplexer might operate based on the 4-tuple or other legacy indicator, but the receiving server process extracts the server ID, and if it does not match the one for that process, the process could "toss" the packet to the correct destination process. Each process could register the connection IDs it generates with the demultiplexer, which routes those connection IDs accordingly. Some bytes of the server ID are reserved to encode the process ID. The load balancer writes the decrypted connection ID into the packet.  The demultiplexer reads the process ID from the relevant bytes and routes it accordingly.  The receiving server process immediately re-encrypts the connection ID in deliver the packet to the correct connection and successfully authenticate the packet. While this requires coordination between load balancer and server, this document does not standardize the technique because it is unsafe to use unless the path between load balancer and server is fully secure.  An observer at that point can determine the server mapping via the IP address of the destination server, but the process ID provides additional linkability information. 6.3. </ins> Some deployments may transparently move a connection from one server to another.  The means of transferring connection state between servers is out of scope of this document.

Discussion:
Many server architectures have multiple processes. There are many ways to properly route packets between them, but many have severely limited capabilities. Add some non-normative text about options here: run QUIC-LB at the demultiplexer, packet toss, register connection IDs at the demultiplexer, or rewrite the CID with the decrypted one at the LB (which has security limitations)
Change:
Section 6.2, with a "send" simulcast stream description that lists each desired encoding, and no "recv" simulcast stream description. The m= section will also include an "a=rid" attribute for each <del> encoding, as specfied in I-D.ietf-mmusic-rid, Section 4; the use of </del> <ins> encoding, as specified in I-D.ietf-mmusic-rid, Section 4; the use of </ins> RID identifiers allows the individual encodings to be disambiguated even though they are all part of the same m= section.

Discussion:
NAME I fixed this.
Section 5.2.1 CreateOffer "given that no candidates have yet been gathered" - when people remember the pre-gathered candidate pool, this can be confusing. Suggest adding a note at the top of this section saying that CreateOffer doesn't cause candidate gathering and does not take candidates from the pre-gathered pool, and thus, no candidates are available at the initial call to CreateOffer. All subsequent references to "no candidates have yet been gathered" in this section should be replaced with "no candidates are available". This also affects section 5.3.1 CreateAnswer.
lgtm
Change:
This section defines the terms used for the systems that act as DNS clients, DNS servers, or both. <del> For teminology specific to the public DNS root server system, see </del> <ins> For terminology specific to the public DNS root server system, see </ins> RSSAC026.  That document defines terms such as "root server", "root server operator", and terms that are specific to the way that the root zone of the public DNS is served.

Discussion:
…st label', and remove dbound. Fix affiliation. I suggest these before publication. This addresses issue 18.
Yep, these all seem great.