jiebi/CodeConvo huggingface dataset:
Change:
ClientHellos that include this extension but do not include 0x0304 in the list of versions. <del> A server which negotiates TLS 1.3 MUST respond by sending a "supported_versions" extension containing the selected version value (0x0304).  It MUST set the ServerHello.legacy_version field to 0x0303 (TLS 1.2).  Clients MUST check for this extension prior to processing the rest of the ServerHello (although they will have to parse the ServerHello in order to read the extension).  If this extension is present, clients MUST ignore the ServerHello.legacy_version value and MUST use only the "supported_versions" extension to determine the selected version.  If the "supported_versions" extension contains a version not offered by the client, the client MUST abort the handshake with an "illegal_parameter" alert. </del> <ins> A server which negotiates a version of TLS prior to TLS 1.3 MUST set ServerHello.version and MUST NOT send the "supported_versions" extension.  A server which negotiates TLS 1.3 MUST respond by sending a "supported_versions" extension containing the selected version value (0x0304).  It MUST set the ServerHello.legacy_version field to 0x0303 (TLS 1.2).  Clients MUST check for this extension prior to processing the rest of the ServerHello (although they will have to parse the ServerHello in order to read the extension).  If this extension is present, clients MUST ignore the ServerHello.legacy_version value and MUST use only the "supported_versions" extension to determine the selected version.  If the "supported_versions" extension contains a version not offered by the client or contains a version prior to TLS 1.3, the client MUST abort the handshake with an "illegal_parameter" alert. </ins> 4.2.1.1.

Discussion:
LGTM!
This is natural, since if you negotiate prior to 1.3 you must use the ServerHello rules for the negotiated URL
Change:
requesting more than one ticket is desirable. Third, we should note that the various tickets in the client's <del> possession ultimately derive from an initial full handshake. </del> <ins> possession ultimately derive from some initial full handshake. </ins> Especially when the client was initially authenticated with a client certificate, that session may need to be refreshed from time to time. <del> Consequently, a server may periodically perform a full handshake even </del> <ins> Consequently, a server may periodically force a full handshake even </ins> when the client presents a valid ticket for a session that is too <del> old.  When that happens, it is possible that all tickets derived from the same original session are equally invalid.  A client avoids a full handshake on subsequent connections if it replaces all stored tickets with fresh values.  The number of tickets the server should vend for a full handshake may therefore need to be larger than the number for routine resumption. </del> <ins> old.  When that happens, it is possible that any other tickets derived from the same original session are equally invalid.  A client avoids a full handshake on subsequent connections if it replaces all stored tickets with fresh ones obtained from the just performed full handshake.  The number of tickets the server should vend for a full handshake may therefore need to be larger than the number for routine resumption. </ins> This document specifies a new TLS extension - "ticket_request" - that can be used by clients to express their desired number of session

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:
address, the request will only support a single IP version.  If the target is a hostname, the server is expected to perform DNS resolution to determine which route(s) to advertise to the client. <ins> The server SHOULD send a ROUTE_ADVERTISEMENT capsule that includes routes for all usable resolved addresses for the requested hostname. </ins> The variable "ipproto" contains an IP protocol number, as defined in the "Assigned Internet Protocol Numbers" IANA registry.  If

Discussion:
We should be clear that when a proxy resolves a hostname, it SHOULD give all results back as routes to the client (unless there is some policy to restrict it). Credit to NAME for proposing this
I agree
What is a client expected to do with this information? Say I ask for the proxy to connect to URL I get back a RA that includes the result of DNS lookups for URL (maybe multiple RAs that include all the answers from A/AAAA records?). Am I supposed to assume that this is the result of the DNS lookup? How do I distinguish that from other RAs that might just advertise where I might be able send packets via the tunnel? If the purpose of this is to provide name resolution, it is probably better to include an explicit signal. It's a bit of a rathole, but a new capsule type seems fairly obvious. That leads me to ask a whole bunch of questions about whether the proxy needs to supply a DNS service, ...
Nit: there is no port number. That's the status quo in this draft for hostname targets. The implicit signal here doesn't bother me, since it's unambiguous. I'm also fine with dropping support for DNS targets, although I think it might be useful in some scenarios.
Of course. I somehow got mislead by the first example: "URL{target}/{target_port}/"
Yeah, looks like that example had a copy paste error from CONNECT-UDP. I filed
The ability to specify a host to proxy to was important in our discussions for keeping parity with other proxying methods.
Indeed, that was bad copy-pasta from me, my apologies. It's been fixed in the editor's copy.
NAME thanks!
Thanks! ... wanted to raise the issue. URL". Section 4.1 says "route(s)", implying that the proxy might choose to advertise multiple routes to the target host, presumably because DNS resolution returned multiple A/AAAA records. I see the current text as an implicit "MAY return all the IP addresses", and I'm suggesting an upgrade to SHOULD.
Change:
it trusts the oblivious proxy resource to remove, such as fields that are listed in the Connection header field. <ins> The client role in this protocol acts as an HTTP client both with respect to the oblivious proxy resource and the oblivious target resource.  For the request the clients makes to the oblivious target resource, this diverges from typical HTTP assumptions about the use of a connection (see Section 3.3 of HTTP) in that the request and response are encapsulated rather than sent over a connection.  The oblivious proxy resource and the oblivious request resource also act as HTTP clients toward the oblivious request resource and oblivious target resource respectively. </ins> The oblivious proxy resource interacts with the oblivious request <del> resource by constructing a request using the same restrictions as the client request, except that the target URI is the oblivious request resource.  The content of this request is copied from the client. The oblivious proxy resource MUST NOT add information about the client to this request. </del> <ins> resource as an HTTP client by constructing a request using the same restrictions as the client request, except that the target URI is the oblivious request resource.  The content of this request is copied from the client.  The oblivious proxy resource MUST NOT add information about the client to this request. </ins> When a response is received from the oblivious request resource, the oblivious proxy resource forwards the response according to the rules

Discussion:
It would be wrong to use "user agent" as this could be used for an HTTP request made by any client toward any server (using the HTTP definitions).
Why don't use "Oblivious Client" and the "OC" acronym, like OAuth does with "Authorization Server"? This would preserve the natural "client" meaning, and could make the document more readable. The same acronym trick could ease readability wrt "Oblivious Request Resource" and "Oblivious Target Resource"...
I know that people like acronyms, but it doesn't really solve this problem. The oblivious HTTP client really is an HTTP client in the sense that HTTP knows; calling it anything else would be more confusing, I think. As it seems like this is a case where more words would help. I've added more words.
Since there are so many occurrencies of I think that's ok :) Probably in the Introduction, "client" means "HTTP client", but anyway the difference is clear to me now :D
since there are various layers, the term "client" can be applicable to both the oblivious proxy/request resource. Maybe the term User agent can be appropriate when we refer to the originating client?
Hi Roberto, Does URL clarify things? I think that "client" still makes a lot of sense here, but you are right that this is not an HTTP client in the strictest sense. (Although, now that I write this, it really is, it's just that this uses something other than a connection as a medium from getting a request to the server...)
LGTM
Change:
1.1. <ins> The Transport Services architecture is based on the survey of Services Provided by IETF Transport Protocols and Congestion Control Mechanisms RFC8095, and the distilled minimal set of the features offered by transport protocols I-D.ietf-taps-minset.  These documents identified common features and patterns across all transport protocols developed thus far in the IETF. Since transport security is an increasingly relevant aspect of using transport protocols on the Internet, this architecture also considers the impact of transport security protocols on the feature-set exposed by transport services I-D.ietf-taps-transport-security. One of the key insights to come from identifying the minimal set of features provided by transport protocols I-D.ietf-taps-minset was that features either require application interaction and guidance (referred to as Functional or Optimizing Features), or else can be handled automatically by a system implementing Transport Services (referred to as Automatable Features).  Among the Functional and Optimizing Features, some were common across all or nearly all transport protocols, while others could be seen as features that, if specified, would only be useful with a subset of protocols, but would not harm the functionality of other protocols.  For example, some protocols can deliver messages faster for applications that do not require messages to arrive in the order in which they were sent. However, this functionality needs to be explicitly allowed by the application, since reordering messages would be undesirable in many cases. 1.2. This document describes the Transport Services architecture in three sections: model describes how the API model of Transport Services differs from traditional socket-based APIs.  Specifically, it offers asynchronous event-driven interaction, the use of messages for data transfer, and the ability to easily adopt different transport protocols. design explains the design principles that guide the Transport Services API.  These principles are intended to make sure that transport protocols can continue to be enhanced and evolve without requiring too many changes by application developers. concepts presents the Transport Services architecture diagram and defines the concepts that are used by both the API and implementation documents.  The Preconnection allows applications to configure connection properties, and the Connection represents an object that can be used to send and receive Messages. 1.3. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. 2. </ins> The traditional model of using sockets for networking can be represented as follows:

Discussion:
Based on discussion with NAME rearrange things to put a proper document overview in the intro, and split out the API Model discussion into its own section outside of the introduction.
LGTM (modulo one nit)Thank you NAME to do this - really improves the structure.
Change:
there is none. The MUD file permits access to a particular Internet service, but <del> the name of that service resolved to something that was not permitted. </del> <ins> the name of that service has not been resolved (or name resolution failed). </ins> The administrator overrode the recommendations in the MUD file.

Discussion:
I added a container to report ACL violation dropped packets. I am not sure how the l3l4info is going to be used. The YANG model was fixed (I think some parens missing). Please check and let me know you agree with these changes. Thanks, Ranga
Change:
challenges.  An entity that can provision false DNS records for a domain can attack the DNS challenge directly, and can provision false A/AAAA records to direct the ACME server to send its TLS SNI or HTTP <del> validation query to a server of the attacker's choosing.  There are a few different mitigations that ACME servers can apply: </del> <ins> validation query to a remote server of the attacker's choosing. There are a few different mitigations that ACME servers can apply: </ins> Always querying the DNS using a DNSSEC-validating resolver (enhancing security for zones that are DNSSEC-enabled)

Discussion:
As pointed out by NAME on the ACME mailing list there are a few places where there was some potential ambiguity about what "server" meant. This PR is the result of a once-through pass looking for places where we could be more specific when saying "server". In most cases the default definition of "server" from the Terminology section applied and no change was made. I attempted to clarify any usage of "server" that wasn't qualified sufficiently to differentiate from the ACME server.
Change:
2. Informally, a group is a set of users who possibly use multiple <del> endpoint devices to interact with the Messaging Service (MS).  A group may be as small as two members (the simple case of person to person messaging) or as large as thousands. </del> <ins> endpoint devices to interact with the Service Provider (SP).  A group may be as small as two members (the simple case of person to person messaging) or as large as thousands. </ins> In order to communicate securely, users initially interact with services at their disposal to establish the necessary values and credentials required for encryption and authentication. <del> The Messaging Service (MS) presents two abstract services that allow </del> <ins> The Service Provider presents two abstract services that allow </ins> clients to prepare for sending and receiving messages securely: An Authentication Service (AS) which is responsible for

Discussion:
This PR addresses URL
Thanks!
In the context of this document, the meaning of the term Messaging Service (MS) seems a little unclear to me. The document states that the protocol is intended to be embedded in a concrete protocol such as XMPP. However, is a MS meant to be a messaging service such as SMS or MMS? Or a service on the application layer, such as FB or WhatsApp? Essentially who provides / controls the AS and DS? I would be grateful for some clarification on this. Thanks.
It is meant to mean application layer, would changing that to "service provider" work better for you?
Thank you. I do think that the term service provider is less ambiguous.
Ack, will fix soon.
I can make a PR, if you want?
Sure, please go for it.
Fixed by
Change:
the CertificateRequest message in the main handshake, though they MAY send it in post-handshake authentication (see post-handshake- authentication) provided that the client has sent the <del> "post_handshake_auth" extension (see post_handshake_auth).  Servers which are authenticating with an external PSK MUST NOT send the </del> <ins> "post_handshake_auth" extension (see post_handshake_auth).  In the absence of some other specification to the contrary, servers which are authenticating with an external PSK MUST NOT send the </ins> CertificateRequest message either in the main handshake or request <del> post-handshake authentication.  Future specifications MAY provide an extension to permit this. </del> <ins> post-handshake authentication.  RFC8773 provides an extension to permit this, but has not received the level of analysis as this specification. </ins> 4.4.

Discussion:
Change "should" -> "SHOULD" around user_canceled Replicate the 8773 language to another place where external PSKs is discussed. Remove an OPEN ISSUE marker
Change:
"alg" (Algorithm) <del> "jwk" (JSON Web Key, only for requests to new-account and revoke-cert resources) </del> <ins> "jwk" (JSON Web Key, for all requests not signed using an existing account, e.g. newAccount) </ins> <del> "kid" (Key ID, for all other requests) </del> <ins> "kid" (Key ID, for all requests signed using an existing account) </ins> "nonce" (defined in replay-protection below)

Discussion:
The example was misleading in case a certificate is revoked by signing the revocation request with the certificate's private key. I assume "jwk" should be the public key from the certificate in this case and not the account key; see URL
Merging because it looks like the issue raised by NAME has been addressed.
Change:
for the initiator and responder roles, broken down per protocol phase. <del> 7. </del> <ins> 7.2. </ins> Note: This algorithm also takes the off-path scenario into account.

Discussion:
Section 4 should only provide a description of the RRC messages (chal/resp & delete) and say a few words about extensibility of the feature. I think the discussion around interplay between RRC and CID should go in a separate (sub)section.
Change:
CoAP nodes should listen to; CoAP needs the Link-Local and Site-Local scopes only. <ins> [ The RFC editor is asked to replace MCD1 and MCD2 with the assigned addresses throughout the document. ] </ins> 10. Two examples are presented: a Lighting Installation example in lt-ex

Discussion:
Request a dedicated IPv4 address (rather than sharing with All CoAP nodes) Fix erroneous examples Editorial changes Add figure numbers to examples Update RD parameters table to reflect changes of earlier versions in the text Typos and minor wording
Where IANA has not yet allocated a value, we cannot say "has allocated a value". Yes, it is a bit tedious to change this once the allocation has been done, but IANA has to be able to derive from the text what it needs to do. Also, I don't understand the "equal to" language in section mc-registration; do you mean ", the same as"?
Changing this as of finishing up the pending comments. Ad "equal to", my understanding is that we don't actually register a new address but just ask people to use "All CoAP nodes" for the same purpose (given the tighter address space). Is that the agreed-upon intention? If so: Does this warrant IANA action (by adding another name alias to the same address), or won't we just say where we use it that there ain't no IPv4 multicast address for that, and All CoAP nodes are used instead?
I cannot recall a recent discussion on this, but this is indeed one possible interpretation of the not so clear language. I don’t think the registry uses aliases. So there would be no IANA action. There should be no text in mc-registration (since this is for IANA), but there should be text in 4.3 URI Discovery saying that. Alternatively, we could simply go for another IPv4 address. The registry doesn’t seem to explode (there is just one entry after RFC 7252). But let’s find the WG discussion first. Grüße, Carsten
anchors are /sensors/temp but targets are /temp
some examples have figure numbers, some don't
Figure 6 has a spurious anchor (and figure 7 right below is not labeled as a figure)
The -12 draft suggests as a heuristic to ask at . There is a multicast address for All CoAP Nodes, I suggest we use that (would be ).
Indeed, that is an obvious change to be made. We also could think of registering a multicast address for "all CoRE resource directories", if that turns out to be useful.

agree fully with Carsten chrysn schreef op 2017-11-04 13:07:
I like the "All CoRE RDs" address. It's trivial for IPv6, but the v4 addresses are more scarce. Can we register one of both, or would the v4 behavior just be "All CoAP nodes" again?
Let's stick to all CoRE RDs address; specify a new address for v6, and equate all CoRE RD address equal to all CoAP nodes.
Inserted text for "all RD" MC address registry, called MCD1 for the moment
the equation would have turned out a bit complicated in the iana considerations (either it'd have spread the text around or we'd be aliasing multicast addresses), going with a dedicated address. See URL and today's CoRE chat logs.
Change:
RTCP feedback.  If AVPF is provided, or an "a=rtcp-fb" attribute is present, assume AVPF timing, i.e., a default value of "trr- int=0".  Otherwise, assume that AVPF is being used in an AVP <del> compatible mode and use AVP timing, i.e., "trr-int=4". </del> <ins> compatible mode and use a value of "trr-int=4000". </ins> For data m= sections, JSEP endpoints MUST support receiving the <del> "UDP/ DTLS/SCTP", "TCP/DTLS/SCTP", or "DTLS/SCTP" (for backwards </del> <ins> "UDP/DTLS/SCTP", "TCP/DTLS/SCTP", or "DTLS/SCTP" (for backwards </ins> compatibility) profiles. Note that re-offers by JSEP endpoints MUST use the correct profile

Discussion:
Adding link to
Originally raised by Magnus: Otherwise, assume that AVPF is being used in an AVP compatible mode and use AVP timing, i.e., "trr-int=4". I find this sentence confusing. I think this should be clarified to say: Otherwise, assume that AVPF is being used in an AVP compatible mode, i.e. use AVPF timing configured with a "trr-int=4". Section 5.1.3: Spurious space in: For data m= sections, JSEP endpoints MUST support receiving the "UDP/ DTLS/SCTP", "TCP/DTLS/SCTP", or "DTLS/SCTP" (for backwards compatibility) profiles.
NAME PR wanted.
NAME the text here was trying to indicate that "AVP timing" was a minimum interval of 4 seconds. With the proposed change, the paragraph becomes confusing, as both parts reference "AVPF timing". What do you suggest we do?
ping NAME
NAME the text you quote appears to be correct. The important aspect is that AVPF becomes compatible with AVP if one uses trr-int=4.0. Where if AVPF (SAVPF) is offered one should use either the default trr-int=0, or negotiate another value. I assume what you find confusing is this part "assume that AVPF is being used in an AVP compatible mode". A possible change could be to change that third sentence to read: "If AVP is offered, then use AVPF in an AVP compatible mode, i.e. set trr-int=4000 (4 s). Does this solve the issue?
I think slight change here would address Justin's comment