jiebi/CodeConvo huggingface dataset:
Change:
Coding enables E2E reliable communication over DTN with adaptive re- encoding, as proposed in THAI15.  In this case, the use-cases <del> proposed in subsec:varying would legitimate the usage of coding </del> <ins> proposed in subsec:varying would legitimize the usage of coding </ins> within the DTN stack to improve the channel utilization and the E2E transmission delay.  In this context, the use of erasure coding inside a Consultative Committee for Space Data Systems (CCSDS)

Discussion:
Just corrected legitimize.
legitimate -> legitimize. This entire section is unnecessary. With this draft on a multi-gateway satellite system and DVB, you're talking about geostationary satellites which are always visible. Little disruption. 600ms or so delay is coped with by Internet protocols (RFC829 SATNET work etc.) So, not a significant delay issue either. It's out of scope for the abstract. And geostationary satellites generally don't use CCSDS for broadband; TDRSS is so much a special case. Since we're not standards track, References aren't split informative/normative -- but given the DVB starting point, I'd expect to see more DVB-S references. EN 302 307, which details extensions of the original satellite transmission standard DVB-S (EN 300 421), etc.
We need to discuss this point. Just corrected legitimize in
Change:
2.2. <del> Both the client and the server MUST send a Capability and Settings </del> <ins> Both the client and the server MUST send a Capabilities and Settings </ins> message (CSM see csm) as its first message on the connection.  This message establishes the initial settings and capabilities for the endpoint such as maximum message size or support for block-wise

Discussion:
One more 7.01 change to 7.00. Removed redundant requirement for references to abort: MAY immediately abort the connection (see Section 4.6) . since the Abort section already has the SHOULD.
URL Signaling s/Share/Relate/ (the nodes do not "share these characteristics") Shut down s/Ordered/Orderly/ Provide diagnostic information when terminating a connection in ... 4.3. Capability and Settings Messages (CSM) Hmm, should this be "Capabilities and Settings Messages"? (Need to change throughout.) s/A/One/ s/Capability and Settings message/CSM/ s/and/. Further CSM/ s/settings/setting/ 4.3.2. Max-Message-Size Capability Option (above 1152?)
URL Appendix B. Negotiating Protocol Versions s/Capability and Settings/Capabilities and Settings Messages (CSM)/
URL Cl.4.5/4.6: The text mentions a "diagnostic payload", is some standard envisaged for this or is it implementation dependent? This is implementation dependent, although it might be helpful to adapt or reference - URL
Reviewed in more detail. There is a reference to RFC7252 in an earlier section URL
Perhaps the RFC7252 references needs to be emphasized more. Options: Blockquote related RFC7252 Section 5.5.2 in section 4.1 to call more attention to it Include an xref with each related normative statement The simplest mitigation is the xref: A Release message indicates that the sender does not want to continue maintaining the connection and opts for an orderly shutdown. The details are in the options. A diagnostic payload (see Section 5.5.2 of [RFC7252]) MAY be included.
Change:
Preference is of type Boolean, with "true" indicating that the Selection Property has been applied. <ins> Tuple: An ordered grouping of multiple value types.  In this this document, it is written as a list in brackets, e.g., "(Enumeration, Preference)" The composition of types and their order depends on the property and is fixed for the property.  The actual representation is implementation-dependent. Collection: An unordered grouping of one or more values of the same type.  The actual representation, e.g. as a set or an array, is implementation-dependent. </ins> For types Integer and Numeric, special values can be defined per property; it is up to implementations how these special values are represented (e.g., by using -1 for an otherwise non-negative value).

Discussion:
I should have said: I approve this, modulo the changes requested by NAME
Thanks for incorporating my suggested changes. I think this can be merged now.
Change:
7.7. To reduce the overhead of sending multiple small Messages on a <del> Connection, the application may want to batch several Send actions </del> <ins> Connection, the application may want to batch several Send Actions </ins> together.  This provides a hint to the system that the sending of these Messages should be coalesced when possible, and that sending any of the batched Messages may be delayed until the last Message in the batch is enqueued. <ins> The semantics for starting and ending a batch can be implementation- specific, but need to allow multiple Send Actions to be enqueued. </ins> 7.8. For application-layer protocols where the Connection initiator also

Discussion:
batch sending, as currently specified, means that you already have to have all messages ready in the application because you can declare a patch. That means you have to potentially "buffer" some message in the application. Wouldn't it may be better/easier to have a message property that indicates that a certain message should wait (probably up until a maximum time) for the next message and then buffer it in the transport instead?
We can just clarify the text that the batch may be an arbitrarily long-running block of code, and not require knowing up front all of the data.
Could also allow begin batch/end batch. Explain use case around optimizing send performance.
Change:
For each supported codec that is present in the offer, "a=rtpmap" and "a=fmtp" lines, as specified in RFC4566, Section 6, and RFC3264, Section 6.1.  For audio, the codecs specified in I- <del> D.ietf-rtcweb-audio, Section 3, MUST be be supported.  Note that for simplicity, the answerer MAY use different payload types for </del> <ins> D.ietf-rtcweb-audio, Section 3, MUST be supported.  Note that for simplicity, the answerer MAY use different payload types for </ins> codecs than the offerer, as it is not prohibited by Section 6.1. If "rtx" is present in the offer, for each primary codec where RTP retransmission should be used, a corresponding "a=rtpmap" line indicating "rtx" with the clock rate of the primary codec and an <del> "a=fmtp" line that references the payload type fo the primary </del> <ins> "a=fmtp" line that references the payload type of the primary </ins> codec, as specified in RFC4588, Section 8.1. For each supported FEC mechanism that is present in the offer, a

Discussion:
LGTM
LGTM with nit above
URL Justin to respond on the list and the changes to be attached to this issue.
Editorial changes: Section 3.2, Paragraph 4 Should read "only after an offer". yep Section 3.4.2, Paragraph 1 "... the number of media streams for which to gather candidates." ok, not a fan of ending a sentence with a preposition, I see. I'll go along with this one. Section 3.5, Paragraph 1 Should say, "... the media plane that is relevant." yep Section 4.1.5, Paragraph 2 and 3 Maybe I'm alone on this but I prefer the following: "Calling this API changes the local media state." The API doesn't do anything on its own, but is a mechanism for calling some action. (Same issue as above) "The candidate gathering process is indirectly controlled through this API." Will think this over. Overall, want to be consistent in how the term 'API' is used. Section 5.2.1, Paragraph 4 "into which it is being bundled." ok Section 5.2.1, Paragraph 5 Space needed after RFC reference. yep Section 5.2.1, Paragraph 7, bullet 6 "of" yep Section 5.2.1, Paragraph 7, bullet 11 "specified" yep Section 5.3.1, Paragraph 7 "URL then be generated..." yep Section 5.3.1, Paragraph 7, bullet 4 "... and there is a local MediaStreamTrack that has been associated ..." indeed, not my best work Section 5.3.1, Paragraph 7, bullet 5 "... Section 3, MUST be supported." yep Section 5.3.1, Paragraph 7, bullet 6 "... the payload type of the primary..." yep Section 5.3.1, Paragraph 7, bullet 11 "... as specified in ..." yep
Change:
If an RtpTransceiver has been stopped and is associated with an m= section, and the m= section is not being recycled as described above, an m= section MUST be generated for it with the port set to <del> zero and the "a=msid", "a=ssrc", and "a=ssrc-group" lines removed. </del> <ins> zero and the "a=msid" line removed. </ins> <del> For RtpTransceivers that are not stopped, the "a=msid", "a=ssrc", and "a=ssrc-group" lines MUST stay the same if they are present in the current description. </del> <ins> For RtpTransceivers that are not stopped, the "a=msid" line MUST stay the same if they are present in the current description. </ins> Each "m=" and c=" line MUST be filled in with the port, protocol, and address of the default candidate for the m= section, as

Discussion:
a=ssrc and a=ssrc-group.
NAME note I still assume you might receive a=ssrc because it might come from non-JSEP endpoints. LMK if you want that removed.
Change:
QUIC probing packets, which can be sent on multiple paths at once, are used to perform address validation as well as measure path <del> characteristics as input for the switching decision.  Probing packets cannot carry application data but may contain padding frames. Endpoints can use information about their receipt as input to congestion control for that path.  Applications could use information learned from probing to inform a decisions to switch paths. </del> <ins> characteristics.  Probing packets cannot carry application data but likely contain padding frames.  Endpoints can use information about their receipt as input to congestion control for that path. Applications could use information learned from probing to inform a decisions to switch paths. </ins> Only the client can actively migrate in version 1 of QUIC.  However, servers can indicate during the handshake that they prefer to

Discussion:
The text here mentioned the decision to use a new path twice. Also, probing packets almost always include padding frames now: we require that the datagram is full-sized when probing so that we can probe for MTU, and probing is almost certainly done with short header packets, where padding has to be inside the packet.
Change:
Clients MAY send this extension in ClientHello.  It contains the following structure: <del> The number of tickets desired by the client when the server chooses to negotiate a new connection. </del> <ins> The number of tickets desired by the client if the server chooses to negotiate a new connection. </ins> <del> The number of tickets desired by the client when the server is </del> <ins> The number of tickets desired by the client if the server is </ins> willing to resume using a ticket presented in this ClientHello. A client starting a new connection SHOULD set new_session_count to

Discussion:
From Ben: One nit that can be rolled in with any LC comments: in Section 3, we say "clients can send a resumption_count equal to the number of sessions they are attempting in parallel", and "connections" probably works better than "sessions" in that case.
Document: draft-ietf-tls-ticketrequests-06 Reviewer: Dale R. Worley Review Date: 2020-11-27 IETF LC End Date: 2020-12-03 IESG Telechat date: Not known Summary: This draft is ready for publication as a Standards Track RFC. Editorial comments: Use Cases Parallel HTTP connections: To minimize ticket reuse while still improving performance, it may be useful to use multiple, distinct tickets when opening parallel connections. To the naive reader, the ordering of the phrases doesn't seem to match the logical ordering of the concepts. Perhaps Parallel HTTP connections: To improve performance, a client may open parallel connections. To avoid ticket reuse, the client may use multiple, distinct tickets on each connection. Decline resumption: Clients can indicate they have no intention of resuming connections by sending a ticket request with count of zero. "have no intention" seems to me to suggest a decision that will not change. Since the future cannot be guaranteed, perhaps better wording is "do not intend to resume", suggesting a current state that might possibly change in the future. newsessioncount The number of tickets desired by the client when the server chooses to negotiate a new connection. resumptioncount The number of tickets desired by the client when the server is willing to resume using a ticket presented in this ClientHello. If I understand the processing which is suggested correctly, when the client sends a ClientHello, the server can choose to either negotiate a new connection, or (if a ticket is present in the ClientHello) the server can choose to resume the previous connection represented by the ticket. These two parameters provide the requested ticket count for the two situations. Assuming the above is correct, I would recommend changing the wording slightly, as "when" suggests a fact which is true over an extended period of time, whereas the provided counts are applicable in just this one instance: newsessioncount The number of tickets desired by the client if the server chooses to negotiate a new connection.

resumptioncount The number of tickets desired by the client if the server chooses to resume (using the ticket presented in this ClientHello). (Change "the" to "a" in the last sentence if the ClientHello can present more than one ticket among which the server can choose.)
Change:
provide similar forward-secrecy properties to using ephemeral Diffie- Hellman (DHE) key exchange mechanisms.  For longer-lived access tokens, DHE cipher suites should be used, i.e., cipher suites of the <del> form TLS_DHE_PSK_*. </del> <ins> form TLS_DHE_PSK_* or TLS_ECDHE_PSK_*. </ins> Constrained devices that use DTLS RFC6347 are inherently vulnerable to Denial of Service (DoS) attacks as the handshake protocol requires

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:
continue to be supported. If User Equipment supports the Captive Portal API, it MUST validate <del> the API server's TLS certificate (see RFC2818).  An Enforcement Device SHOULD allow access to any services that User Equipment could need to contact to perform certificate validation, such as OCSP responders, CRLs, and NTP servers; see Section 4.1 of I-D.ietf- capport-api for more information.  If certificate validation fails, User Equipment MUST NOT proceed with any of the behavior described above. </del> <ins> the API server's TLS certificate (see RFC2818) according to the procedures in RFC6125.  The API server's URI is obtained via a network provisioning protocol, which will typically provide a hostname to be used in TLS server certificate validation, against a DNS-ID in the server certificate.  If the API server is identified by IP address, the iPAddress subjectAltName is used to validate the server certificate.  An Enforcement Device SHOULD allow access to any services that User Equipment could need to contact to perform certificate validation, such as OCSP responders, CRLs, and NTP servers; see Section 4.1 of I-D.ietf-capport-api for more information.  If certificate validation fails, User Equipment MUST NOT proceed with any of the behavior described above. </ins> 2.2.

Discussion:
A reviewer requested that we provide more detail on how the user equipment should so certificate validation. This does so.
Do this. Figure out the proper 'name type'.
Ben suggests Let's use this, and attribute it to him in the acknowledgements.
Change:
in the existing registry for ExtensionType (defined in I-D.ietf-tls- tls13), with "TLS 1.3" column values being set to "CH", and "Recommended" column being set to "Yes". <ins> 8.2. IANA is requested to create an entry in the DNS Underscore Global Scoped Entry Registry (defined in I-D.ietf-dnsop-attrleaf) with the "RR Type" column value being set to "TXT", the "_NODE NAME" column value being set to "_esni", and the "Reference" column value being set to this document. </ins>

Discussion:
URL is in wglc and seems likely to become a standards track doc. It establishes a registry for undesrscore scoped names it means a blocking reference to ATTRLEAF, but that doesn't seem like a problem time wise
Change:
following structure: The number of tickets desired by the client when the server <del> chooses to negotiate a fresh session (full handshake), thereby implicitly invalidating all other tickets sharing the same initial session as the presented ticket.  This is also the ticket count requested when the client presented no initial ticket making a full handshake unavoidable. </del> <ins> chooses to negotiate a fresh session (full handshake).  This is also the ticket count requested when the client presented no initial ticket making a full handshake unavoidable. </ins> The number of tickets desired by the client when the server is <del> willing to resume the associated session. </del> <ins> willing to resume using the presented ticket. </ins> Clients can use the above structure to indicate the number of tickets they would prefer to receive when sessions are resumed or new

Discussion:
This improves both happy eyeballs and ticket reuse.
I am significantly skeptical re complexity. The server looks at one counter when resuming and the other when doing a full handshake. Where's the complexity? I am sorry to say that to me personally, the complexity objection sounds rather like reluctance to reconsider the design than a response on the merit.
I still don't think that the additional count is warranted. The rationale here is reasonable, and does provide a degree of justification for the change, but I would prefer not to take on the additional complexity.Thanks for making the updatesThanks for putting this down in writing! I think a separate counter is fine given the rationale, but I disagree with all text on re-use. I think that should happen elsewhere. So, requesting changes for now, though if the WG decides to address ticket re-use here then we will revisit!
Change:
1.1. We use the same definition of server and client that is used in <del> draft-davidson-pp-protocol and draft-davidson-pp-architecture. </del> <ins> draft-ietf-privacypass-protocol and draft-ietf-privacypass- architecture. </ins> We assume that all protocol messages are encoded into raw byte format before being sent.  We use the TLS presentation language RFC8446 to

Discussion:
Initial work for fixing .
NAME
As discussed during IETF 110, the architecture document should provide guidance on how redemption contexts can be used and how they impact privacy. This is a bit of the calculus we don't yet have. cc NAME NAME
Yeah, this likely needs to be embedded both into the Architecture draft for the generic concept of a context, and then an actual instantiation of redemption contexts in the HTTP API doc.
Yep should we split out the HTTP work into a separate issue?
Thanks NAME This looks good, I have mostly just a few nits to resolve.
Change:
2.2.2. <del> I-D.ietf-intarea-provisioning-domains proposes a mechanism for User Equipment to be provided with PvD Bootstrap Information containing the URI for a JSON file containing key-value pairs to be downloaded over HTTPS.  This JSON file would fill the role of the Captive Portal API described in section_api. </del> <ins> Although still a work in progress, I-D.pfister-capport-pvd proposes a mechanism for User Equipment to be provided with PvD Bootstrap Information containing the URI for the JSON-based API described in section_api. </ins> The PvD security model provides secure binding between the information provided by the trusted Router Advertisement and the HTTPS server. <del> One key-value pair can be used to indicate the network has restricted access, requiring captive portal navigation by a user.  E.g., key="captivePortal" and value=<URI of portal>.  The key-value pair should provide a different result when access is not restricted. E.g., key="captivePortal" and value="". This JSON file is extensible, allowing new key-value pairs to indicate such things as network access expiry time, URI for API access by IOT devices, etc. The PvD server MUST support multiple (repeated) queries from each User Equipment, always returning the current captive portal information.  The User Equipment is expected to make this query upon receiving (and validating) a Captive Portal Signal (see section_signal). </del> 2.3. The purpose of a Captive Portal API is to permit a query of Captive

Discussion:
We were incorrectly describing the behaviour of the capport PvD option. Update the text to better reflect how it will work, and reference the new draft describing that behaviour. This removes most of the section describing the behaviour, since it's now in the new draft. Fixes Issue .
Let's talk about adoption of the capport-pvd draft before we make this sort of change.
NAME , was the capport-pvd draft discussed during IETF 104? I don't see anything in the minutes.
NAME we did not specifically discuss the capport-pvd draft. I think that doesn't need to be in this first core flight of docs. Note we'll be discussing the core PvD doc more in intarea and hopefully will get that out to last call.
NAME Alright. The existing content is still wrong, though. So, to fix this, perhaps we should just remove the references to PvDs in general?
This text incorrectly describes the PvD JSON as the API JSON. This is incorrect. We should also refer to the CAPPORT PvD proposal document which explains this.
anything left for this please?
NAME
Seems fine to me to close
Does PvD mechanism deliver the capport state, or a pointer to the capport API, from which capport state is retrieved?
In IETF101 capport meeting, I think I heard that PvD is not designed for conveying per-UE state. Hence, PvD may provide a URI to the capport API, but not convey the state itself.
NAME is this addressed in in the sense that the referenced doc covers it?
Yes. I think it is.
Change:
provide segmentation of messages larger than the maximum size permitted by the network layer, and also to avoid network-layer source fragmentation of messages.  When running over IPv4, setting <del> this property to true can result in a sending endpount setting the </del> <ins> this property to true will result in a sending endpount setting the </ins> Don't Fragment bit in the IPv4 header of packets generated by the <del> transport layer.  An attempt to send a message that results in a size greater than the transport's current estimate of its maximum packet size (singularTransmissionMsgMaxLen) will result in a SendError. This only takes effect when the transport and network layer support this functionality. </del> <ins> transport layer. An attempt to send a message that results in a size greater than the transport's current estimate of its maximum packet size ("singularTransmissionMsgMaxLen") will result in a "SendError".  This only takes effect when the transport and network layer support this functionality. </ins> 9.2.

Discussion:
This seems otherwise inconsistent: for the noFragmentation property, we say that, in case of IPv4, setting this will result in setting the "Don't Fragment" bit. the noSegmentation property is described as avoiding fragmentation AND avoiding segmentation. So logically, this should also result in setting the "Don't Fragment" bit in case of IPv4. Generally, I'm not sure how an implementer should interpret the "can" here, in contrast with the "will" in the "Don't Fragment" case above... the textual difference seems to hint that this could be implemented differently, but then, how?