jiebi/CodeConvo huggingface dataset:
Change:
Importance: Extra <del> This event is emitted when the single recovery loss timer is set. </del> <ins> This event is emitted when a recovery loss timer changes state.  The three main event types are: set: the timer is set with a delta timeout for when it will trigger next expired: when the timer effectively expires after the delta timeout cancelled: when a timer is cancelled (e.g., all outstanding packets are acknowledged, start idle period) Note: to indicate an active timer's timeout update, a new "set" event is used. </ins> Data:

Discussion:
Not 100% sure this is enough for all the latest draft-27(+) changes though, added a TODO in the draft for that purpose. Also added a packetnumberspace field to metrics_updated to be flexible for implementations that don't want to implement all types of events. It's not a great fit at that location, but it seemed the most synergistic without having a completely new event type. PTAL NAME
Currently, we log in . However, we can have multiple PTO's running across multiple PN spaces and there is no proper way to correlate them with a PN space in metricsupdated. This also impacts the event types. Possible resolutions: Add pnspace attribute to Split PTO count into a separate event (potentially merge with loss_timer?) TODO: reason more about how these metrics are tied to PN spaces in general (are there others than PTO that are duplicated) cc NAME
Most other metrics in the event are independent of the PN space, so that would be weird. I'd prefer to do that. Not sure if it makes sense to merge is with the loss timer events, since we also need to be able to log a reset of the PTO count to 0 (which doesn't require setting of a timer).
Change:
domain(s). DV certificate validation commonly checks claims about properties <del> related to control of a domain name - properties that can be observed by the certificate issuer in an interactive process that can be conducted purely online.  That means that under typical </del> <ins> related to control of a domain name -- properties that can be observed by the certificate issuer in an interactive process that can be conducted purely online.  That means that under typical </ins> circumstances, all steps in the request, verification, and issuance process can be represented and performed by Internet protocols with no out-of-band human intervention.

Discussion:
Thanks NAME - diff looks fine to me.Looks fine to mepurely editorial, good for me.
Change:
5. <del> This specification defines the following expressions for use in CoSWID and to provide interoperability with schemes used in SWID. Because both the "swid" and "swidpath" schemes are to be interpreted within a local, rather than a global, context, neither of these scheme are URIs as defined in RFC3986 and the swid and swidpath scheme names are not registered as permanent schemes with IANA.  That noted, swid and swidpath expressions conform to all rules for URI </del> <ins> This specification defines the following scheme names for use in CoSWID and to provide interoperability with scheme names used in SWID.  Because both the "swid" and "swidpath" scheme names are to be interpreted within a local (rather than a global) context, neither of these are technically URI scheme names as defined in RFC3986.  For this reason, the swid and swidpath scheme names are registered with IANA as provisional, rather than permanent, scheme names.  However, registering these scheme names as provisional ensures that the scheme names are reserved and that they are properly defined going forward. The swid and swidpath expressions conform to all rules for URI </ins> syntax.  All uses of these expressions encountered within a CoSWID are to be interpreted as described in this section.

Discussion:
Added back IANA registrations (as provisional) for swid and swidpath URI schemes. Slight re-wording of the intro paragraph to section 5 (discussing the schemes) to reflect this modification.
Change:
response "response", servers generate an Encapsulated Response "enc_response" as follows: <del> Export a secret "secret" from "context", using the string "response" as context.  The length of this secret is "max(Nn, Nk)", where "Nn" and "Nk" are the length of AEAD key and nonce </del> <ins> Export a secret "secret" from "context", using the string "ohttp response" as context.  The length of this secret is "max(Nn, Nk)", where "Nn" and "Nk" are the length of AEAD key and nonce </ins> associated with "context". Generate a random value of length "max(Nn, Nk)" bytes, called

Discussion:
This is a breaking change, but I think that it's worthwhile. "request" is an extraordinary generic string and the risk of it being used in another context is too high.
We can address test vectors in a followup PR.
Change:
they work with paths that select structured values. <del> To test the value of a node selected by a path, an explicit </del> <ins> To examine the value of a node selected by a path, an explicit </ins> comparison is necessary.  For example, to test whether the node selected by the path "@.foo" has the value "null", use "@.foo == null" (see null-semantics) rather than the negated existence test

Discussion:
These editorial changes from PR are needed in the base.
I confess I tend to write tedious text when precision is at stake. Hopefully, the second commit avoids the tedium.
Why was this merged so quickly?!
We merged this editorial change quickly so we could rebase the other substantive PRs on it and put us in a better position to compare their pro's and con's.
Looks good now! Should merge this quickly so we can rebase the others.
Change:
Since the original HTTP CONNECT method allowed conveying the target host and port but not the scheme, proxy authority, path, nor query, <del> there exist proxy configuration interfaces that only allow the user to configure the proxy host and the proxy port.  Client implementations of this specification that are constrained by such limitations MAY attempt to access UDP proxying capabilities using the default template, which is defined as: </del> <ins> there exist clients with proxy configuration interfaces that only allow the user to configure the proxy host and the proxy port. Client implementations of this specification that are constrained by such limitations MAY attempt to access UDP proxying capabilities using the default template, which is defined as: </ins> "https://$PROXY_HOST:$PROXY_PORT/.well-known/masque/ udp/{target_host}/{target_port}/" where $PROXY_HOST and $PROXY_PORT are the configured host and port of the UDP proxy respectively.  UDP

Discussion:
Nit from the AD review. Reading this sentence, it took me a moment to figure out if we were talking about config on the client or the on the proxy.
Change:
Security (EAP-TLS) with TLS 1.3 while remaining backwards compatible with existing implementations of EAP-TLS.  TLS 1.3 provides significantly improved security, privacy, and reduced latency when <del> compared to earlier versions of TLS.  EAP-TLS with TLS 1.3 further improves security and privacy by always providing forward secrecy, never disclosing the peer identity, and by mandating use of revocation checking.  This document also provides guidance on </del> <ins> compared to earlier versions of TLS.  EAP-TLS with TLS 1.3 (EAP-TLS 1.3) further improves security and privacy by always providing forward secrecy, never disclosing the peer identity, and by mandating use of revocation checking.  This document also provides guidance on </ins> authorization and resumption for EAP-TLS in general (regardless of the underlying TLS version used).  This document updates RFC 5216.

Discussion:
I see that "EAP-TLS 1.3" is used more an more in the discussions to refer to this the combination of EAP-TLS and TLS 1.3. The term is used in the document but not in the title and abstract
Hi John, Please run this title change by the list.
Looking at this it seems that this change is simpler than I originally thought. This looks OK to merge
Change:
presentation, such as its intended proofing mechanism and key material. <del> REQUIRED.  If "true", the access token presented is active, as defined above.  If any of the criteria for an active token are not true, or if the AS is unable to make a determination (such as the token is not found), the value is set to "false" and other fields are omitted. </del> If the access token is active, additional fields from the single access token response structure defined in I-D.ietf-gnap-core- protocol are included.  In particular, these include the following: <del> REQUIRED.  The access rights associated with this access token. This MUST be in the format described in the Resource Access Rights section of I-D.ietf-gnap-core-protocol.  This array MAY be filtered or otherwise limited for consumption by the identified RS, including being an empty array. REQUIRED if the token is bound.  The key bound to the access token, to allow the RS to validate the signature of the request from the client instance.  If the access token is a bearer token, this MUST NOT be included. OPTIONAL.  The set of flags associated with the access token. </del> The response MAY include any additional fields defined in an access token response and MUST NOT include the access token "value" itself.

Discussion:
Deploy Preview for gnap-resource-servers-editors-draft ready! Explore the source changes: 94d11a4362aaea79f357583969d87ec4955655a9 Inspect the deploy log: Browse the preview:
Change:
even if it is rough, as long as that does not jeopardize the objective of obtaining a usable, stable JSON query language. <ins> The term was chosen because of the XPath inspiration and also because the outcome of a query consists of identifying nodes in the JSON argument. </ins> 1.3. The JSON value a JSONPath query is applied to is, by definition, a

Discussion:
PR changed the spec to use "path" only for paths, and "query" for queries. The term "JSONPath" is then left in need of some motivation. This is provided in the History section so as not to interfere with the normative text.
... fine ...
Change:
Compute SAN A and SAN B in the same way as the client. <del> Open a TLS connection to TCP port 443 the domain name being validated on the requested port, presenting SAN A in the SNI field.  In the ClientHello initiating the TLS handshake, the server MUST include a server_name extension (i.e., SNI) containing SAN A.  The server SHOULD ensure that it does not reveal SAN B in any way when making the TLS connection, such that the presentation of SAN B in the returned certificate proves association with the client. </del> <ins> Open a TLS connection to the domain name being validated, presenting SAN A in the SNI field.  This connection MUST be sent to TCP port 443 on the server.  In the ClientHello initiating the TLS handshake, the server MUST include a server_name extension (i.e., SNI) containing SAN A.  The server SHOULD ensure that it does not reveal SAN B in any way when making the TLS connection, such that the presentation of SAN B in the returned certificate proves association with the client. </ins> Verify that the certificate contains a subjectAltName extension containing dNSName entries of SAN A and SAN B and no other

Discussion:
Pull request was recently merged to clarify that HTTP and TLS challenge requests must use port 80 and 443 respectively. The "TLS with Server Name Indication (TLS SNI)" section was updated to read: This is a typo ("port 443 the domain name") and also still includes the phrase "on the requested port", which is no longer true. This PR updates the SNI challenge description to fix the typo and to explicitly say that the server MUST use port 443 in the same style/manner as the HTTP edit from .
Thanks for fixing my lame typos
Change:
in RFC5245, Section 15.5, and the set of specified options is stored. <ins> Any "a=candidate" attributes MUST be parsed as specified in RFC5245, Section 15.1, and their values stored. Any "a=remote-candidates" attributes MUST be parsed as specified in RFC5245, Section 15.2, but their values are ignored. If present, a single "a=end-of-candidates" attribute MUST be parsed as specified in I-D.ietf-ice-trickle, Section 8.2, and its presence or absence flagged and stored. </ins> Any "a=fingerprint" lines are parsed as specified in RFC4572, Section 5, and the set of fingerprint and algorithm values is stored.

Discussion:
Rewrite intro to be clearer Move table to appendix Fix some parsing instructions that were in the wrong place
LGTM (other than the little bad xml issue)
Change:
2. <del> Clients SHOULD NOT include MD5 and SHA-1 in the signature_algorithms </del> <ins> Clients MUST NOT include MD5 and SHA-1 in the signature_algorithms </ins> extension.  If a client does not send a signature_algorithms extension, then the server MUST abort the handshake and send a handshake_failure alert, except when digital signatures are not used

Discussion:
As per discussion on mailing list.
NAME can you please float this change on the mailing list?
Change:
2.1. <del> The SNI was defined to facilitate management of servers, though the developers of middleboxes soon found out that they could take advantage of the information.  Many examples of such usage are reviewed in RFC8404.  They include: </del> <ins> The SNI was defined to facilitate management of servers, but the developers of middleboxes found out that they could take advantage of the information.  Many examples of such usage are reviewed in RFC8404.  They include: </ins> The SNI is probably also included in the general collection of <del> metadata by pervasive surveillance actors. </del> <ins> metadata by pervasive surveillance actors, for example to identify services used by surveillance targets. </ins> 2.2.

Discussion:
Comments and discussion are found in issue . The proposed changes are minimal.
Once this is processed one way or another, I would like to publish a revised draft.
Thanks for clearly writing down attacks and requirements in this document. One small technical comment on this sentence: Sec 2.3: "Per-stream QoS can be provided by a combination of packet marking and end-to-end agreements." If this sentence is meant to mean use of DSCP, I don't think this is true, as DSCP is usually not available end-to-end but most often gets changed or bleached somewhere on the path. And two editorial comments: Sec 2.1: "The SNI was defined to facilitate management of servers, though the developers of middleboxes soon found out that they could take advantage of the information." "soon found out" does sound a bit story-telling like to me. I recommend a more objective phrasing like: "The SNI was defined to facilitate management of servers, though other usages by middleboxes also take advantage of the information." or something similar... Also sec 2.1: "The SNI is probably also included in the general collection of metadata by pervasive surveillance actors." This sentence is phrased a bit speculatively and at the same kind seems inherently true as a "pervasive surveillance actor" usually just collect all available data/traffic... I guess the more interesting question would be if and how this information is used. Anyway I recommend some rephrasing like: "The SNI could also be utilised by the general collection of metadata by pervasive surveillance actors."
Hi Christian, Please see below. From my point of view „some time after“ wouldn’t make it much better because I think the important part of the information of this sentence is that middleboxes use that information (for good or bad) and not who had the idea when. But again just a comment... Yes, removing end-to-end does help but it also sounds a bit as if that is a solution ready to use which I don’t think is the case. Maybe also say “could” instead “can” (to propose another minimal change)? Mirja >
Addressed in PR
Change:
An equipment owned and managed by the SP that can support multiple services (e.g., VPNs) for different customers.  A PE is directly <del> connected to one or more CEs via attachment circuits.  A PE is usually located at an SP point of presence (PoP). </del> <ins> connected to one or more CEs via attachment circuits. </ins> <del> Describes a service's end point characteristics and its reference </del> <ins> Describes a service's endpoint characteristics and its reference </ins> to a Termination Point (TP) of the PE; used as service access point for service.

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:
in the encoding.  For uses where extensions need to be preserved in EXI, the non-strict schema mode of EXI MAY be used. <del> The EXI header option MUST be included.  An EXI schemaID options MUST be set to the value of "a" indicating the scheme provided in this specification.  Future revisions to the schema can change this schemaID to allow for backwards compatibility.  When the data will be transported over CoAP or HTTP, an EXI Cookie SHOULD NOT be used as it simply makes things larger and is redundant to information provided in the Content-Type header. </del> <ins> The EXI header MUST include an "EXI Options", as defined in W3C.REC- exi-20140211, with an schemaId set to the value of "a" indicating the schema provided in this specification.  Future revisions to the schema can change the value of the schemaId to allow for backwards compatibility.  When the data will be transported over CoAP or HTTP, an EXI Cookie SHOULD NOT be used as it simply makes things larger and is redundant to information provided in the Content-Type header. </ins> The following is the XSD Schema to be used for strict schema guided EXI processing.  It is generated from the RelaxNG.

Discussion:
Make sure the way we use schemaID match how it is defined in EXI. ( See email from Christian G - Oct 10, 2016 )
Change:
Each header block is prefixed with two integers.  The Required Insert Count is encoded as an integer with an 8-bit prefix after the encoding described in ric).  The Base is encoded as sign-and-modulus <del> integer, using a single sign bit and a value with a 7-bit prefix (see base). </del> <ins> integer, using a single sign bit ('S') and a value with a 7-bit prefix (see base). </ins> These two values are followed by representations for compressed headers.

Discussion:
Renamed S bit for static vs dynamic table to T bit (for Table) Replaced backticks with single quotes around individual bits (previously, about half used single, half used double) Added explicit references to bit letter indicators where they were missing (e.g., for 'H') Fixed broken reference to "blocked-decoding" section
As for 'B' vs , transport doc just uses (B). Maybe we should follow suit, bui I can do in a separate pass.
Change:
If |port| does not equal the request's destination TCP port, include a Uri-Port Option and let that option's value be |port|. <del> 6.6. </del> <ins> 6.7. </ins> The steps are the same as specified in Section 6.5 of RFC7252 with the following changes:

Discussion:
RFC 7252 section 5.10.1 says: The default value of the Uri-Host Option is the IP literal representing the destination IP address of the request message. Likewise, the default value of the Uri-Port Option is the destination UDP port. The default values for the Uri-Host and Uri-Port Options are sufficient for requests to most servers. Explicit Uri-Host and Uri-Port Options are typically used when an endpoint hosts multiple virtual servers. Do we expect this default value to be applicable (and/or useful) for all the cases we are looking at? Maybe keeping Default-Uri-Host is not such a bad idea after all, or maybe we should clarify that this means for, say, a WebSocket server.
We should simply document appropriate defaults for TLS and WebSockets. There is already text for WS:
Regarding this scenario in RFC7252: Explicit Uri-Host and Uri-Port Options are typically used when an endpoint hosts multiple virtual servers. This is no longer relevant in CoAP over reliable transports. As Klaus noted in the earlier TRAC issue: In CoAP over WebSockets, the virtual server is specified during the WebSocket handshake in the Host header field. The Uri-Host Option is therefore not needed. A client wishing to talk to multiple virtual servers running on the same IP address has to open one WebSocket connection to each virtual server. (Please correct me if I'm wrong.) In CoAP over TLS we have the SNI extension, so I would expect that CoAP over TLS behaves like CoAP over WebSockets: no Uri-Host Option in requests, one connection to each virtual server. For the TLS+SNI case, the default value of the URI-Host is the underlying destination address that's shared across the virtual servers. Further note that the Hostname passed in the TLS SNI extension is not an "IP literal": URL - Literal IPv4 and IPv6 addresses are not permitted in "HostName". would still require our draft to support the URI-Host Option for this case: At the moment, this issue does not appear actionable.
Change:
a local description.  If an error is returned, the session MUST be restored to the state it was in before performing these steps. <del> Next, m= sections are processed.  For each m= section, the following </del> <ins> First, m= sections are processed.  For each m= section, the following </ins> steps MUST be performed; if any parameters are out of bounds, or cannot be applied, processing MUST stop and an error MUST be returned.

Discussion:
The second paragraph of 6.8 starts "Next, ". I think it should start "First, ".
I agree with this.
Change:
they are equivalent to Actions on a per-application global context. Events are sent to the application or application-supplied code (e.g. <del> framers, see framing) for processing; the details of event processing are platform- and implementation-specific. </del> <ins> framers, see framing) for processing; the details of event interfaces are platform- and implementation-specific, and may be implemented using other forms of asynchronous processing, as idiomatic for the implementing platform. </ins> We also make use of the following basic types:

Discussion:
in architecture.
Per slide 14 in Thorben Krüger's presentation at IETF 113: URL, clarify that the API is defined in terms of events to be general, not because you have to implement an event system if you're going to implement TAPS.
LGTM
Change:
original_connection_id transport parameter if it sent a Retry packet. <del> The idle timeout is a value in seconds that is encoded as an </del> <ins> The idle timeout is a value in milliseconds that is encoded as an </ins> integer, see (idle-timeout).  If this parameter is absent or zero then the idle timeout is disabled.

Discussion:
This is fine, but I think that we want chairs to call it.
This falls under the new process, so it's upto the chairs.
Based on the discussion in I think this has rough consensus. Tagging as such and reassigning.
Slow down, we're not in the new process yet. And, in either case, consensus needs to be determined on-list, not in issues.
Currently, the t is in units of seconds. This seems to be too restrictive and not very future proof. Additionally, from an API perspective, most other timers are settable on the millisecond scale, so it creates a kind of ugly discrepancy between all the different timers settable by the app if just one of them has units of seconds. I propose we change the units from seconds to milliseconds. The change both for implementations and spec should be minimal, and it makes things (timers) a little more consistent.
This seems sensible to me both for consistency and I can imagine cases when one would want to specify a fraction(ie: 1/2 of a second).
Agreed. A second is an eternity for a intra-datacenter connection for example. For future proofing all time units should be at least msec IMO.
Don't we want to specify a minimum value now?
No, I don't think so. Even before, if you had a greater than 1 sec RTT (somehow...) if you set an idle timeout of 1 second it would cause you problems. I think bottom line you be smart about your idle timeout values. If you set too small a value you can unnecessarily kill your own connection.
As NAME says, actual idle timeout depends on RTT, and that’s what we have adopted in .
This SGTM.
I support this
I think this has rough consensus. Tagging as such and reassigning.
LG, but I don't know what process this falls under. I'll let NAME and NAME decide.