jiebi/CodeConvo huggingface dataset:
Change:
3. <del> Some captive portal network deployments may be unable to change, or unwilling to risk changing, the network infrastructure necessary to use any of the above options.  In such deployments, when clear text HTTP intercept and redirection are used, a Link relation header (RFC8288, Section 3.3) MAY be inserted to convey to a HTTP client (user agent) the associated Captive Portal API URI. HTTP user agents MUST ignore this link relation in any context other than when explicitly probing to detect the presence of a captive portal.  Failure to do so could allow an attacker to inject a Captive Portal API URI other than the correct URI for a given network or for networks where there is no captive portal present at all. 4. </del> A device may learn about Captive Portal API URIs through more than one of (or indeed all of) the above options.  It is a network configuration error if the learned URIs are not all identical.

Discussion:
At IETF 106, we discussed removing the link relation. This PR does that.
I suppose we should be reading and implementing draft-ietf-git-github-wg-configuration ... As Warren's T-shirt says: "In my defense I was left unsupervised."
100% agreed about the build output...
People who put build output in their repository deserve a special place.
Change:
This document defines a specific protocol for sending DNS RFC1035 queries and getting DNS responses over modern versions of HTTP RFC7540 using https:// (and therefore TLS RFC5246 security for <del> integrity and confidentiality). </del> <ins> integrity and confidentiality).  Each DNS query-response pair is mapped into a HTTP request-response pair. </ins> The described approach is more than a tunnel over HTTP.  It establishes default media formatting types for requests and responses

Discussion:
… issue
It is not stated crystal clear in the -01 draft if there's only one DNS packet per HTTP request or if it is allowed to send more than one. Some wordings (like ) suggest a single packet. I think it would benefit the document to be more explicit on this detail.
good point - it is meant to be one, otherwise blocking and reordering (which is resolved at the intra-request http level) would be a problem. we'll add text.
Change:
Let us consider the example of a typical service provider network (fi2), with PE and P nodes. <del> The Service Orchestration layer does not need to know about the </del> <ins> The Service orchestration layer does not need to know about the </ins> internals of the underlying network (e.g., P nodes). fi2a shows the abstract network view as seen by the Service Orchestrator.  However, this view is not enough to provide to the Service Orchestration layer

Discussion:
Check if we need to expose SAPs per servcie-type and if so, how we can easily add support for it OLD: NEW:
Change:
response. Some of response codes that are defined in RFC1035 have acquired <del> their own shorthand names.  Some common response code names that appear without reference to the numeric value are "FORMERR", "SERVFAIL", and "NXDOMAIN" (the latter of which is also referred to as "Name Error").  All of the RCODEs are listed at </del> <ins> their own shorthand names.  All of the RCODEs are listed at </ins> http://www.iana.org/assignments/dns-parameters, although that site uses mixed-case capitalization, while most documents use all-caps. <ins> Some of the names are described here, but the official list is in the IANA registry. "No error condition" (Quoted from RFC1035, Section 4.1.1.) "Format error - The name server was unable to interpret the query."  (Quoted from RFC1035, Section 4.1.1.) "Server failure - The name server was unable to process this query due to a problem with the name server."  (Quoted from RFC1035, Section 4.1.1.) "Name Error - Meaningful only for responses from an authoritative name server, this code signifies that the domain name referenced in the query does not exist."  (Quoted from RFC1035, Section 4.1.1.) "Not Implemented - The name server does not support the requested kind of query."  (Quoted from RFC1035, Section 4.1.1.) "Refused - The name server refuses to perform the specified operation for policy reasons.  For example, a name server may not wish to provide the information to the particular requester, or a name server may not wish to perform a particular operation (e.g., zone transfer) for particular data."  (Quoted from RFC1035, Section 4.1.1.) </ins> "A pseudo RCODE which indicates that the name is valid for the given class, but there are no records of the given type.  A NODATA

Discussion:
I have added your text (approximately) and merged the pull request.
During the discussion that led to RFC 7719, there was a request to split out error names in their own terms to make them easier to find in the document. Now with the index in place, this seems like a good idea.
Oooh, yes, I think that this would be great. [Sorry for the non-substantive / bikeshed comment]
Entered in the doc as URL
I think this is ok, but I'd like a tiny edit before the list starts: "The names as of this writing are described below, but the official list is in the IANA registry." Or something like this. I just don't want to suggest we're arguing with the authoritative registry.
Change:
In order to accept early data, the server MUST have accepted a PSK cipher suite and selected the first key offered in the client's "pre_shared_key" extension.  In addition, it MUST verify that the <del> following values are consistent with those negotiated in the connection during which the ticket was established. </del> <ins> following values are consistent with those associated with the selected PSK: </ins> <del> The TLS version number and cipher suite. </del> <ins> The TLS version number </ins> <del> The selected ALPN RFC7301 protocol, if any. </del> <ins> The selected cipher suite The selected ALPN RFC7301 protocol, if any The selected SNI (Section 3 of RFC6066) value, if any These requirements are a superset of those needed to perform a 1-RTT handshake using the PSK in question.  For externally established PSKs, the associated values are those provisioned along with the key. For PSKs established via a NewSessionTicket message, the associated values are those negotiated in the connection during which the ticket was established. </ins> Future extensions MUST define their interaction with 0-RTT.

Discussion:
Both for 0-RTT and 1-RTT. Give NST- and externally-provisioned PSKs more uniform treatment.
NAME ping? It would be good to get some resolution in this space, as it's somewhat relevant to URL
I guess we could perhaps recommend that external PSKs not be provisioned with a SNI value, since the PSK value itself ought to serve as enough of a lookup key for what the intended communication semantics are.
NAME is there a path forward for this (e.g., does it need to go to the list)?
NAME I think this is generally good except for the SNI stuff which conflicts with PR , which we also need to resolve one way or another. What say we land this without those pieces and then when we we will know what to do
SGTM. Do you need me to adjust the patch?
Nah, I'll do it.
These actually just seem to make the SNI requirements clearer but no sharper, so merging.
The Early Data Indication section contains this sentence: The parameters for the 0-RTT data (symmetric cipher suite, ALPN protocol, etc.) are the same as those which were negotiated in the connection which established the PSK. This implies to me that you can only do 0-RTT where the PSK was established via an earlier connection. In external PSK this is not the case. I don't think this interpretation was the intention.
This is stale text from before we allowed 0-RTT with external PSK, IIRC.
Zero-RTT Data says: But 4.6.1. New Session Ticket Message says: For consistency, I would like to have the latter in Section 2.2 with the same style. Moreover, I would like to know where this differences of requirements come from.
I think 4.2.10 may be more appropriate than 2.2, as it is closer to where the server is doing the relevant processing.
Now 4.2.10 has clear requirements. So, why don't we remove the same requirement from 2.3? additional information MUST be provisioned to both parties:
Change:
For each offered "m=" section, if any of the following conditions are true, the corresponding "m=" section in the answer MUST be marked as <del> rejected by setting the port in the "m=" line to zero, as indicated </del> <ins> rejected by setting the <port> in the "m=" line to zero, as indicated </ins> in RFC3264, and further processing for this "m=" section can be skipped:

Discussion:
The following changes have been made: changed to "set to zero" from "set to 0", removed comment. formatted media-field subfields consistently, removed comment.

fmt value / "fmt" value Justin: Would we also do media, port, and proto? This one needs more discusison.
RFC 4566 (SDP) was inconsistent in the formatting of fmt (, "fmt"), proto ("proto", ), and port (port, ). For the most part, media was just formatted media. RFC 8866 (SDP), which obsoletes RFC 4566, consistently formats these "m=" line subfields as , , , and . This document uses the following formats: fmt (3 instances) vs (2 instances) proto (7 instances) vs (5 instances) port (31) vs (0 instances) -- most are not referring specifically to the subfield, though I suggest using angle brackets (but not formatting -- I was just working around GitHub's markdown with that) for these terms when discussing "m=" line subfields.
SGTM, let's align with 8866 usage when an instance of these words refers specifically to a m= line subfield.
set to zero / set to 0 >(May we use the latter, because of '"dummy" port value of 9' in Sections 5.2.1 and 5.3.1?) Justin: What's the IETF style guide say on this sort of thing? 'zero' looks more natural to me, and matches RFC 3264's usage of 'zero'.
From our style guide: "In general text, we follow the CMOS guidance that numbers under 10 are written out and those above are represented using digits. However, if a value is followed by a unit of measure (e.g., 8 bytes, 3 octets), it should be in digit form regardless of value." There is one instance of "set to 0" in this document vs four instances of "set to zero". I can change that one instance to match the other four.
LGTM
Change:
"oid_filters" (Section 4.2.5. of TLS13) extensions are used to guide certificate selection. <del> Only the X509 certificate type defined in TLS13 is supported. </del> <ins> Only the X.509 certificate type defined in TLS13 is supported. </ins> Alternative certificate formats such as RFC7250 Raw Public Keys are not supported in this version of the specification and their use in this context has not yet been analysed.

Discussion:
got merged while I was reviewing it, so here's my feedback as a follow-up PR. I initially though line 244 needed a comma, but usage through the rest of the document suggests that supporting certificates are a property of one type of identity instead of something that could come along with a generic identity, so I dropped that one.
Thanks, Mike.
Change:
attempt from a client. (see RFC7507) This alert is always fatal. <del> This alert was used in previous versions of TLS.  TLS 1.3 does not include renegotiation and TLS 1.3 implementations MUST NOT send this alert when in TLS 1.3 mode.  This alert is always fatal. </del> Sent by endpoints that receive a hello message not containing an extension that is mandatory to send for the offered TLS version. This message is always fatal.  [[TODO: IANA Considerations.]]

Discussion:
Note: unRESERVEDing SHA-1 and DSA is intentional. The point is that that things which are RESERVED are totally forbidden. Because you can offer SHA-1, we need the code point. If we decide to make DSA MUSTNOT, then I'll mark it reserved and update the text.
On Saturday, October 03, 2015 04:42:44 pm ekr wrote: Agreed. Using the "RESERVED" notation before was a bit iffy and with this new refactoring it has to be changed now. Just need to make sure it's mentioned explicitly that it's restricted.
Change:
a Commit message, who apply it to keep their local views of the tree in sync with the sender's.  More specifically, when a member commits a change to the tree (e.g., to add or remove a member), it transmits <del> an UpdatePath message containing a set of public and encrypted private values for intermediate nodes in the direct path of a leaf. The other members of the group use these values to update their view of the tree, aligning their copy of the tree to the sender's. </del> <ins> an UpdatePath containing a set of public keys and encrypted path secrets for intermediate nodes in the direct path of its leaf.  The other members of the group use these values to update their view of the tree, aligning their copy of the tree to the sender's. </ins> <del> To transmit this update, the sender broadcasts to the group the following information for each node in the direct path of the leaf, including the root: </del> <ins> An UpdatePath contains the following information for each node in the direct path of the sender's leaf, including the root: </ins> The public key for the node

Discussion:
202105 Interim: To be reviewed by editors.
Ready to merge modulo one nit.
Change:
It returns an authenticator request, which is a sequence of octets that includes a CertificateRequest message. <del> 5.2. </del> <ins> 6.2. </ins> The "get context" API takes as input:

Discussion:
URL you don't want to provide one. TLS allows Certificate to be empty, with a missing CertificateVerify and Finished as normal. That would be a nice change. Alternatively, we could insist on the using application managing this, but it seems like an authenticated refusal is nice.
Resolved in PR
Change:
4.5. In order to be usable for 0-RTT, TLS MUST provide a NewSessionTicket <del> message that contains the "max_early_data" extension with the value 0xffffffff; the amount of data which the client can send in 0-RTT is controlled by the "initial_max_data" transport parameter supplied by the server.  A client MUST treat receipt of a NewSessionTicket that contains a "max_early_data" extension with any other value as a connection error of type PROTOCOL_VIOLATION. </del> <ins> message that contains the "early_data" extension with a max_early_data_size of 0xffffffff; the amount of data which the client can send in 0-RTT is controlled by the "initial_max_data" transport parameter supplied by the server.  A client MUST treat receipt of a NewSessionTicket that contains an "early_data" extension with any other value as a connection error of type PROTOCOL_VIOLATION. </ins> Early data within the TLS connection MUST NOT be used.  As it is for other TLS application data, a server MUST treat receiving early data

Discussion:
What exists is "earlydata" extension and its "maxearlydatasize" field.
Change:
A type is a set of instances.  A type is a subtype of another type if its set of instances (possibly after coercion) is a subset of the set <del> of instances of the other type. </del> <ins> of instances of the other type.  The subtype relationship is transitive: for any A, B, and C if B is a subtype of A and C is a subtype of B, then C is a subtype of A. </ins> tbl-types defines the available types in terms of abstract instances, where "n" denotes a node, "v" denotes a value, and "nl" denotes a <del> non-empty nodelist.  The table also lists the subtypes of each type. </del> <ins> non-empty nodelist.  The table also lists the (immediate) subtypes of each type. </ins> Notes:

Discussion:
Fixes URL
is a subtype by coercion of , but Table 13 does not include this subtype relationship.
Not sure I like the concept of "subtype by coercion". One can be used in place of the other as it can be coerced, but that is not usually what we'd call a subtype.
That's a different point really. Table 13 already includes at least one subtype by coercion, so this issue adds another subtype by coercion.
NAME How would you like to proceed with "subtype by coercion"? If we want to explore alternatives, I think it deserves a separate, non-editorial issue.
From the spec, just below : I disagree with the idea that coercion implies subtypes. If I have integer and floating point numeric types, I can cast from one to the other, but that doesn't mean that either is a subtype of the other. C# provides "implicit" casts where the compiler can infer a type cast from context. For example, I think this is closer to what we're dealing with here. We're looking at compatibility and conversion between types, not polymorphism (as "subtype" implies).
If I'm reading the right, it looks like the term is being used to mean different things depending on which column it's in. In column 1 ("Type") or column 3 ("Subtypes"), it's referring to the type system we're creating. In column 2 ("Abstract Instances"), it's referring to the underlying JSON(ish) value kind, i.e. , , , etc, plus . I think having the same word to define these things can be confusing for the reader, and maybe we need something else in one of these places to indicate the distinction. We've already done this for the type to distinguish it from the value.
I'm not sure there is a really good alternative. We could use for abstract instances, but in the rest of the spec, "value" implies a JSON value, so this doesn't seem quite right.
If "value" implies a JSON value (corresponding to the middle column), then we should change the others (the type name). It really is confusing.
In the interim, we decided to append the type names with "Type". I will create a PR for this.
I'm going to wait for to complete before going forward with this as they change the same chunk of text.
Thanks.

That's why I am trying to tidy up and get it merged ASAP.
(Modulo the coercion entry on OptionalValue, as discussed.)
Change:
even if the Advertisement of Alternative Addresses property (see altaddr below) is set to false. <del> Enumeration values other than "Disabled" are interpreted as a preference for choosing protocols that can make use of multiple paths.  The "Disabled" value implies a requirement not to use multiple paths in parallel but does not prevent choosing a protocol that is capable of using multiple paths, e.g., it does not prevent choosing TCP, but prevents sending the "MP_CAPABLE" option in the TCP handshake. </del> <ins> Note that Multipath Transport has no corresponding Selection Property of type Preference.  Enumeration values other than "Disabled" are interpreted as a preference for choosing protocols that can make use of multiple paths.  The "Disabled" value implies a requirement not to use multiple paths in parallel but does not prevent choosing a protocol that is capable of using multiple paths, e.g., it does not prevent choosing TCP, but prevents sending the "MP_CAPABLE" option in the TCP handshake. </ins> 4.2.15.

Discussion:
I know we have discussed Multipath Transport many times, but when reading is seems strange when you get to Multipath Transport and here there is no option to "Require" this property, only to "Prefer" it. We should at least say why. It is perhaps intuitive that you do not need to distinguish between Avoid and Prohibit, but not why Require would not be useful.
Add a sentence after this to explain why "require" wouldn't make sense:
This reflects what we agreed on, during the last interim.
Change:
The Deprecation HTTP Header Field <del> draft-ietf-httpapi-deprecation-header-02 </del> <ins> draft-ietf-httpapi-deprecation-header-latest </ins> Abstract

Discussion:
This repo wasn't set up with the automated tooling; this PR corrects that, and fixes up a few other small things.
it seems like there's some problem with this update, NAME URL
Fixed.
Change:
in the corresponding media section in the offer, this indicates a negotiation problem and MUST result in an error. <del> If the media section has RTCP mux enabled, discard any RTCP component, and begin or continue muxing RTCP over the RTP component, as specified in RFC5761, Section 5.1.3.  Otherwise, prepare to transmit RTCP over the RTCP component; if no RTCP component exists, because RTCP mux was previously enabled, this MUST result in an error. </del> <ins> If the media section has RTCP mux enabled, discard the RTCP ICE component, if one exists, and begin or continue muxing RTCP over the RTP ICE component, as specified in RFC5761, Section 5.1.3.  Otherwise, prepare to transmit RTCP over the RTCP ICE component; if no RTCP ICE component exists, because RTCP mux was previously enabled, this MUST result in an error. </ins> If the media section has reduced-size RTCP enabled, configure the RTCP transmission for this media section to use reduced-

Discussion:
Originally raised by Magnus If the media section has RTCP mux enabled, discard any RTCP component, and begin or continue muxing RTCP over the RTP component, as specified in [RFC5761], Section 5.1.3. Otherwise, prepare to transmit RTCP over the RTCP component; if no RTCP component exists, because RTCP mux was previously enabled, this MUST result in an error. I think this should say "any RTCP ICE component"..
agreed
I have a related question: Should ICEbis describe the procedures for discarding an ICE media stream or component (as needed for BUNDLE and RTCP mux negotiation)? Or is it obvious enough already what this implies?
This LGTM but see comment
Change:
multipath <del> This property specifies whether an application considers it useful to transfer data across multiple paths between the same end hosts. Generally, in most cases, this will improve performance (e.g., achieve greater throughput).  One possible side-effect is increased jitter, which may be problematic for delay-sensitive applications. The recommended default is to Ignore this option. </del> <ins> Enumeration This property specifies whether an application wants to take advantage of transferring data across multiple paths between the same end hosts.  Using multiple paths allows connections to migrate between interfaces as availability and performance properties change. Possible values are: The connection will not attempt using multiple paths once established The connection should attempt to migrate between different paths upon interface availability changes The connection should attempt to use multiple paths in response to loss or delay upon individual paths The connection should attempt to use multiple paths in parallel in order to maximize bandwidth The default is Disabled.  The other enumeration values are all interpreted as preferences. </ins> 5.2.14.

Discussion:
Complete
Thanks Tommy! I think this looks good The meaning of Interactive is a bit fuzzy, but not sure if we can solve that.
Change:
If the controlled agent receives a Binding request with the USE- CANDIDATE attribute set, and if the ICE agent accepts the request, <del> the agent constructs a candidate pair whose local candidate is equal to the transport address on which the request was received, and whose remote candidate is equal to the source transport address of the request that was received.  This candidate pair is assigned an arbitrary priority, and placed into the valid list of the associated check list.  The agent sets the nominated flag for that pair to true. </del> <ins> the agent constructs a candidate pair whose local candidate has the transport address on which the request was received, and whose remote candidate is equal to the source transport address of the request that was received.  This candidate pair is assigned an arbitrary priority, and placed into the valid list of the associated check list.  The agent sets the nominated flag for that pair to true. </ins> Once the nominated flag is set for a component of a data stream, it concludes the ICE processing for that component.  See sec-conclude.

Discussion:
Fix spelling: Replace “fulfil” with “fulfill” Fix grammar: “agent sets the state…is set to Completed“ with “agent sets the state…to Completed” Make consistent with recent changes: Replace “candidate is equal to the transport address” with “candidate has the transport address” Replace “multimedia session” with “data session” Replace “media data stream” with “RTP/RTCP data stream” or just “data stream” Replace “media data” with “data”