jiebi/CodeConvo huggingface dataset:
Change:
The most basic form of sending on a connection involves enqueuing a single Data block as a complete Message, with default Message <del> Properties.  Message data is transferred as an array of bytes, and the resulting object contains both the byte array and the length of the array. </del> <ins> Properties. </ins> The interpretation of a Message to be sent is dependent on the implementation, and on the constraints on the Protocol Stacks implied

Discussion:
Looks fine to me. I wonder if we want to add some text and given some implementation hints. Not sure if that is needed but it could be useful...?
Looks good.
In section 7.1 of API it says: messageData := "hello".bytes() Connection.Send(messageData) For some languages that are dynamic typed (i.e. python) this limits the usability of the API as it adds an unnecessary extra step to each send. To me this seems like it should be an implementation detail and not specified in the API.
What are the options other than raw bytes?
In python you could just pass any type that gets automatically converted inside the API. For example, in our implementation you could just pass a string or integer that gets converted to bytes inside the implementation before sending. Also, if there is a TLV framer, you could just pass a [type,value] tuple without having to go through the message context.
We generally consider this a case for framers. However, I think it's reasonable to assume that any of the objects used in a TAPS implementation should provide some way for the app to get at the underlying bytes (and therefore, at least implicitly, the length). I don't read this text as prohibiting the use of some object that is able.
I agree that this is an implementation detail that's irrelevant to the abstract API. Can we close this issue?
Requiring the data be accessible as a byte array is overly restrictive. Can we just remove "Message data is transferred as an array of bytes, and the resulting object contains both the byte array and the length of the array." and the call?
Change:
make such delegations as long as they only enable the recipient of the delegation to speak for names that the CA has authorized.  For clarity, we will refer to the certificate issued by the CA as a <del> "certificate", or "deleagation certificate", and the one issued by the operator as a "delegated credential". </del> <ins> "certificate", or "delegation certificate", and the one issued by the operator as a "delegated credential". </ins> 2.

Discussion:
Based on There is currently no binding of the credential to the signature scheme used to sign the handshake. The field of the encodes the DC public key type; but there's not a one-to-one correspondence between X.509's and TLS . Hence, the TLS terminator could use a signature scheme to sign the handshake other than the scheme intended by the delegator. To prevent this, this PR adds the SignatureScheme that the TLS terminator selects in the "signature_algorithms" extension to scope of the delegation signature. In addition, it makes this and the protocol version explicit parameters of the Credential structure. This is intended to make debugging easier.
Change:
5.4. In order to maximize interoperability, DNS API clients and DNS API <del> servers MUST support the "application/dns-udpwireformat" media type. Other media types MAY be used as defined by HTTP Content Negotiation (RFC7231 Section 3.4). </del> <ins> servers MUST support the "message/dns" media type.  Other media types MAY be used as defined by HTTP Content Negotiation (RFC7231 Section 3.4). </ins> 6.

Discussion:
The media type has been the subject of some debate. The above might be the best I've seen.
Change:
the server to allow the server to decline resumption and fall back to a full handshake, if needed.  The server responds with a "pre_shared_key" extension to negotiate use of PSK key establishment <del> and can (as shown here) to negotiate use of PSK key establishment and can (as shown here) respond with a "key_share" extension to do </del> <ins> and can (as shown here) respond with a "key_share" extension to do </ins> (EC)DHE key establishment, thus providing forward secrecy. When PSKs are provisioned out of band, the PSK identity and the KDF

Discussion:
Reading through the spec again I found a few tiny things to fix. I'm suggesting to replace "Zero-RTT" with "0-RTT" in the paragraph because I found "Zero-RTT" used only in headlines, but "0-RTT" consistently in paragraphs.
NAME Please provide a PR to add yourself to acknowledgements.
Change:
is a JWS object whose JSON payload contains the certificate to be revoked: <del> The certificate to be revoked, in the Base64-encoded version of the DER format.  (Note: This field uses the same modified Base64-encoding rules used elsewhere in this document, so it is different from PEM.) </del> <ins> The certificate to be revoked, in the Base64url-encoded version of the DER format.  (Note: This field uses the same modified Base64 encoding rules used elsewhere in this document, so it is different from PEM.) </ins> Revocation requests are different from other ACME request in that they can be signed either with an account key pair or the key pair in

Discussion:
All of the Base64 strings are actually Base64 URL encoded In the Java support for big ints the top byte is set to 0 to eliminate issues with signs. The thumbprint used here does not support that. It would be useful to mention that in the spec. I think it would help if there was an appendix with a complete example from key to key authorization to help clarify the points above.
Right, point 3 is pretty unclear and requires searching with your favorite search engine.
Change:
4.1. <ins> The WebTransport framework OVERVIEW defines a set of optional transport properties that clients can use to determine the presence of features which might allow additional optimizations beyond the common set of properties available via all WebTransport protocols. </ins> Because WebTransport over TCP-based HTTP semantics relies on the underlying protocols to provide in order and reliable delivery, there are some notable differences from the way in which QUIC handles <del> application data. Endpoints MUST send stream data in order.  As there is no ordering mechanism available for the receiver to reassemble incoming data, receivers assume that all data arriving in capsules is contiguous and in order. DATAGRAM capsules are delivered to the remote WebTransport endpoint reliably, however this does not require that the receiving implementation deliver that data to the application in a reliable manner. </del> <ins> application data.  For example, endpoints send stream data in order. As there is no ordering mechanism available for the receiver to reassemble incoming data, receivers assume that all data arriving in capsules is contiguous and in order. Below are details about support in WebTransport over HTTP/2 for the properties defined by the WebTransport framework. WebTransport over HTTP/2 does not support stream independence, as HTTP/2 inherently has head-of-line blocking. WebTransport over HTTP/2 does not support partial reliability, as HTTP/2 retransmits any lost data.  This means that any datagrams sent via WebTransport over HTTP/2 will be retransmitted regardless of the preference of the application.  The receiver is permitted to drop them, however, if it is unable to buffer them. WebTransport over HTTP/2 supports pooling, as multiple transports using WebTransport over HTTP/2 may share the same underlying HTTP/2 connection and therefore share a congestion controller and other transport context.  Note that WebTransport streams over HTTP/2 are contained within a single HTTP/2 stream and do not compete with other pooled WebTransport sessions for per-stream resources. WebTransport over HTTP/2 does not support connection mobility, unless an underlying transport protocol that supports multipath or migration, such as MPTCP MPTCP, is used underneath HTTP/2 and TLS. Without such support, WebTransport over HTTP/2 connections cannot survive network transitions. </ins> 4.2.

Discussion:
Moved the later section up, fixed up some sections, and consolidated some of the text.
When I did , I hadn't read Section 8. My suggestion is that this be merged into the material from the (current) Sections 4 and 5. Also, this is the first use of Http2Transport. I think that we should remove that. It's a fine class name for a C++ implementation, but we don't use it elsewhere.
Just to make sure I understand, the idea is for this "what properties do we provide and how do they satisfy the WT requirements" part to be up front with 4/5? Seems good to me. Yeah, that's mostly leftover from previous versions where we had a more defined name. Can clean up and not lose anything of value, I think.
Change:
for the entity acting as EAP peer and TLS client.  The term EAP-TLS server is used for the entity acting as EAP server and TLS server. <ins> Readers are expected to be familiar with the terms and concepts used in EAP-TLS RFC5216 and TLS RFC8446.  The term EAP-TLS peer is used for the entity acting as EAP peer and TLS client.  The term EAP-TLS server is used for the entity acting as EAP server and TLS server. </ins> 2. 2.1.

Discussion:
While reading draft-ietf-emu-eap-tls13-15 I noticed that section now uses which is the named used in but not in RFC 8446 itself. I first thought this was a typo, before a further look showed that this change was mentioned in IETF 110 . Suggestion: make clear which parts need to be looked up from RFC 8446bis. In addition to exporter terminology, the meeting slides above also discuss about usercancelled behavior on slide 10. For clarity, any updates from RFC 8446bis should be marked clearly.
It would be best not to have normative references that block on RFC 8446bis. Perhaps we can just reference that it is renamed from "exportermastersecret"
Sounds good. That should make clear where it comes from and that there's no need to file errata about unknown term and/or RFC 8446bis dependency. Taking another look at my comment about usercancelled behavior on slide 10; to clarify what I was meaning: The slides hint that clarifications in 8446bis are needed by EAP-TLS too. If so, this looks like a reference to RFC 8446bis too. Finally, one nit: the alert name in RFC 8446 is "usercanceled", not "user_cancelled" as in draft -15.
I made a PR with explaining that the document use the terminology from RFC8446bis. URL Do we need to say anything about usercancelled? RFC8446bis might do several clarifications and corrections. I think we should only mention things that are directly relevant for EAP-TLS 1.3 URL Current plan for RFC8446bis seems to be to ignore closenotify and I assume require close_notify after. This does not seem directly relevant for EAP-TLS 1.3. Or?
close issue?
Yes, please close this. I think it's now clear where exportersecret comes from. Also, thanks for the pointer to TLSv1.3 discussion. I agree usercanceled followed by close_notify discussion is not relevant for EAP-TLS 1.3. It's seems to be TLSv1.3 specification and implementation level detail as opposed to something that EAP-TLS 1.3 needs to directly react on.
Change:
7.5.9. <del> singularTransmission </del> <ins> noFragmentation </ins> Boolean false This property specifies that a message should be sent and received as <del> a single packet without transport-layer segmentation or network-layer fragmentation, if possible.  Attempts to send a message with this property set with a size greater to the transport's current estimate of its maximum transmission segment size will result in a "SendError".  When used with transports supporting this functionality and running over IP version 4, the Don't Fragment bit will be set. </del> <ins> a single packet network-layer fragmentation, if possible.  Attempts to send a message with this property set with a size greater to the transport's current estimate of its maximum transmission segment size will result in a "SendError".  When used with transports supporting this functionality and running over IP version 4, the Don't Fragment bit will be set. </ins> 7.6.

Discussion:
When I initial read the heading I thought this is again about reliability. May we can call this single-segment or something...?
Well it's a term - I don't like it much. Single segment doesn't mean it's all in one IP packet (it means it's all in one transport segment). We could just say sending as a single IP packet.
Interim: proposing to rename to something more simple like Don't Fragment? We don't have a good name.
Don't Fragment seems good too me - and tidy this sentence: OLD: /Attempts to send a message with this property set with a size greater to the transport's current estimate of its maximum transmission segment size will result in a "SendError"./ NEW: /Setting this property causes a "SendError" when an attempt is made to send a message with a size greater than the transport's current estimate of the maximum packet size./
Change:
order. The elements of the "authorizations" array are immutable once set. <del> If any change is made to the array after the object is created, the client MUST consider the order invalid. </del> <ins> The server MUST NOT change the contents of the "authorizations" array after it is created.  If a client observes a change in the contents of the "authorizations" array, then it SHOULD consider the order invalid. </ins> The "authorizations" array in the challenge SHOULD reflect all authorizations that the CA takes into account in deciding to issue,

Discussion:
Implements from the mailing list. On Tue, Nov 29, 2016 at 04:32:33PM -0500, Richard Barnes wrote: than server implementations. With the current language, the client must check that authorizations have not changed. The language for the server should be MUST NOT change the elements of the "authorizations" array once set.'', unambiguously putting the responsibility where it squarely belongs - with the server. The spec could further elaborate that clientsSHOULD consider the application invalid'' if a change is detected. I see no reason why clients should be burdened (by way of ``MUST'') with detecting a condition that will not arise with compliant servers, and is unlikely to cause practical issues if it does occur after a certificate has been issued. Thanks, Fraser
Change:
Information containing the URI for the JSON-based API described in section_api. <del> The PvD security model provides secure binding between the information provided by the trusted Router Advertisement and the HTTPS server. </del> 2.3. The purpose of a Captive Portal API is to permit a query of Captive

Discussion:
This removes some text around discovering URLs with 7710[bis] and PvD. That extra context can be handled by those documents. This builds on .
Looks good
Lgtm
LGTM
Change:
A Packet Reorder Function (PROF) re-orders packets within a DetNet flow that are received out of order.  This function may be <del> implemented at an edge node or end system. </del> <ins> implemented at an edge or relay node. </ins> A control word used for sequencing and identifying duplicate packets at the DetNet service layer.

Discussion:
Also pick up simplified makefile from ip draft
EMAIL NAME NAME can you take a look...
I got one specific comment on reordering and relay functions... comment embedded.
Change:
on a fairly regular cycle to reduce the harmfulness of a server key compromise. <ins> With an active user-base, a week gives a fairly large window for clients to participate in the Privacy Pass protocol and thus enjoy the anonymity guarantees of being part of a larger group.  The low ceiling of 12 weeks prevents a key compromise from being too destructive.  If a server realizes that a key compromise has occurred then the server should sample a new key, and upload the public key to the key registry; invoking any revocation procedures that may apply for the old key. </ins> 7.2. Similarly to the server rotation dynamic that is raised above, if

Discussion:
cc NAME NAME
Yeah, I agree. Something to bring up for discussion.
LGTM, 1 week might still be too small of a window for actively malicious servers, but I think that ties in to the open issue regarding malicious servers rather than the generic key rotation considerations.
Change:
3. <ins> 3.1. This document clarifies that when a name server generates a referral response, it MUST either include all in-domain glue records in the additional section, or MUST set TC=1. 3.2. This document clarifies that when a name server generates a referral response, it SHOULD include available sibling glue records in the additional section.  If sibling glue records do not fit in the response, the name server is NOT REQUIRED to set TC=1. 3.3. Promoted glue is a special case of sibling glue and should be treated as such. 3.4. [this doesn't really account for SHOULD on sibling glue...] </ins> Replace "Copy the NS RRs for the subzone into the authority section of the

Discussion:
work in progress. please do not merge without review & discussion.
Should we use the naming for Glue from 8499?
"Sibling domain glue" "in-domain glue" and maybe we should define "orphan glue/promoted glue". while we have 8499bis open?
IMO 8499 doesn't have glue definitions that are useful for this draft, so yeah, maybe they should be added to 8499.
Change:
identity collision occurs, the application's external PSK usage will typically take precedence over the internal session resumption path. <ins> Since resumption PSK identities are assigned by the TLS stack implementation, it is RECOMMENDED that these identifiers be assigned in a manner that lets resumption PSKs be distinguished from external PSKs to avoid concerns with collisions altogether. </ins> 7. PSK privacy properties are orthogonal to security properties

Discussion:
cc NAME
Looks good to me.
So the draft talks about collisions between PSK identities, with some assumptions baked in: external and resumption PSK identities are trivial to keep distinct (it takes a single bit), but the draft assumes that this step is not taken it might be necessary to generate PSK identities without any sort of centralized coordination, which means that you might need to worry about collisions, but that's another unstated assumption That first one is pretty poor.
It seems to me that we need to warn implementers about the situation if external and resumption PSKs are not kept distinct. We could include advice to keep them separate.
I suggest the addition of a paragraph at the end of the Section on "PSK Identity Collisions". Since resumption PSK identity is assigned by the TLS stack implementation, it is RECOMMENDED that these identifiers be assigned in a manner that lets resumption PSKs be distinguished from external PSKs to avoid concerns with collisions altogether.
Change:
Code: The Captive-Portal DHCPv4 Option (TBD) (one octet) <del> Len: The length, in octets of the URI. </del> <ins> Len: The length (one octet), in octets of the URI. </ins> URI: The URI for the captive portal API endpoint to which the user should connect (encoded following the rules in RFC3986). <ins> See RFC2132, Section 2 for more on the format of IPv4 DHCP options. </ins> Note that the URI parameter is not null terminated. 2.2.

Discussion:
Additionally: Update DHCPv6 reference from RFC 3315 to RFC 8415. Include reference to DHCPv6 option format text. Include reference to DHCPv4 option format text in RFC 2132. The DHCPv4 and v6 diagrams are not harmonized in this change. Each option format has sever documents using the style currently depicted. Issue:
""" — Sections 2.1 and 2.2 — Why aren’t the diagrams for the two in the same format? And neither explicitly says what the length of the “len” field is. In the v4 version, one has to guess that it’s the same size as the “code” field, 1 byte. In the v6 version, one can look at the diagram. I suggest making the diagrams the same format (calibrated with bit/byte markings) and explicitly specifying in the text the size of the “len” field. """ I rather suspect this goes back to whichever source documents from which the option format text was copied. Nevertheless, harmonizing them seems reasonable.
Additionally: we should restate the 255 byte limit from DHCPv4 in each option's description.
Change:
limiting its validity.  An attacker who compromises the private key of a delegated credential can act as a man in the middle until the delegate credential expires, however they cannot create new delegated <del> credentials.  Thus delegated credentials should not be used to send a delegation to an untrusted party, but is meant to be used between </del> <ins> credentials.  Thus, delegated credentials should not be used to send a delegation to an untrusted party, but is meant to be used between </ins> parties that have some trust relationship with each other.  The secrecy of the delegated private key is thus important and several <del> access control mechanisms SHOULD be used to protect it such as file system controls, physical security or hardware security modules. </del> <ins> access control mechanisms SHOULD be used to protect it, including file system controls, physical security, or hardware security modules. </ins> 5.2.

Discussion:
No substantive changes, just grammatical nits and suggestions for clarifying the exposition. In the "Client Behavior" section (Section 3.1), I added a sentence explaining how to check the time-to-live to the first of the DC-validation steps. This might be helpful, as folks have been confused in the past about how to determine if a DC has expired.
LGTM
Change:
From the returned base parameter value, the luminary learns the multicast address of the multicast group. <del> Alternatively, the CT can communicate the multicast address directly to the luminaries by using the "coap-group" resource specified in RFC7390. Dependent on the situation, only the address, "a", or the name, "n", is specified in the coap-group resource. </del> The presence sensor can learn the presence of groups that support resources with rt=tag:example.com,2020:light in its own sector by sending the same request, as used by the luminary.  The presence

Discussion:
This is a series of commits removing cruft in the examples as discussed in URL Diverging from the discussion outcome, more than a single line was kept of 10.2, as the historical note left in , by analogy, means that we should mention that application's choice of a fixed path as well. Some commits may be added still as I'm going through the list.
I'm merging this in to ensure it interacts well with the example updates (where the resource types were replaced with actual example values); any follow-ups will go to a separate PR.
Change:
setLocalDescription will succeed when it attempts to acquire those resources. <del> Calling this method may do things such as generate new ICE </del> <ins> Calling this method may do things such as generating new ICE </ins> credentials, but does not result in candidate gathering, or cause <del> media to start or stop flowing. </del> <ins> media to start or stop flowing.  Specifically, the offer is not applied, and does not become the pending local description, until setLocalDescription is called. </ins> 4.1.7.

Discussion:
NAME has given his thumbs up as well.
Originally raised by Christer Section 3.2 says: "To support this, the JSEP media layer can provide an offer via the createOffer() method whenever the Javascript application needs one for the signaling. The answerer can send back zero or more provisional answers, and finally end the offer-answer exchange by sending a final answer. The state machine for this is as follows:" 1) I would like to explicitly note that the generated offer is not applied (and any previously applied offer is not removed) until setLocalDescription() is called.
OK. In this case, we should note this for the provisional answers as well.
I thought about this for a while and came to the conclusion that this is the wrong place for such text; spelling everything out makes the overall message less clear. If we need to be super-prescriptive about the fact that the offer does not take effect until after setLD is called, we should state this in the createOffer/Answer sections (4.1.5/4.1.6), not here. NAME PTAL.
Will update document according to my last comment.
See PR
PR looks ok.