jiebi/CodeConvo huggingface dataset:
Change:
This pull request tries to motivate why ~60min is about right.
section 2.2.2: doc> Since network addresses may change, a client SHOULD NOT assume that doc> extended token lengths are supported by a server later than 60 doc> minutes after receiving the most-recent response with an extended doc> token length. 60 minutes for address changes? Out of curiosity, upon what was this based? I lack a good deal of context, but this kind of feels like the kind of constant that will get baked into code and come to govern some behaviour that later might need updating.
The number indeed sounds arbitrary. We could make use of the parameter mechanics that RFC 7252 has (ACK_TIMEOUT and friends) and set the default to 1800 s.

Discussion:
are supported by the server. Since network addresses may change, a client SHOULD NOT assume that <del> extended token lengths are supported by a server later than 60 minutes after receiving the most-recent response with an extended token length. </del> <ins> extended token lengths are supported by a server for an unlimited duration.  Unless additional information is available, the client should assume that addresses (and therefore extended token lengths) are valid for a minimum of 1800s, and for a maximum of 86400s (1 day).  A client may use additional forms of input into this determination.  For instance a client may assume a server which is in the same subnet as the client has a similiar address lifetime as the client.  The client may use DHCP lease times or Router Advertisements to set the limits.  For servers which is not local, if the server was looked up using DNS, then the DNS resource record will have a Time To Live, and the extended token length should be kept for only that amount of time. </ins> If a server supports extended token lengths but receives a request with a token of a length it is unwilling or unable to handle, it MUST
Change:
… into more positive language
[[TODO]]
Not sure I follow the 5077 analogy. Do we ever plan to use stateless without some integrity protection? We might save a lot of weasel-wording by simply requiring it.

Discussion:
appropriate.  In the absence of integrity and reply protection, an on-path attacker or rogue server/intermediary could return a state (either one modified in a reply, or an unsolicited one) that could <del> alter the internal state of the client.  However, a careful analysis of any potential attacks to the security and privacy properties of the system might reveal that there are cases where such cryptographic protections do not add value in a specific case. </del> <ins> alter the internal state of the client.  It is this reason that at least the use of integrity protection on the token is always recommended. It maybe that in some very specific case, as a result of a careful and detailed analysis of any potential attacks, that there may be cases where such cryptographic protections do not add value.  The authors of this document have not found such a use case as yet. </ins> RFC3610 with a 64-bit tag is RECOMMENDED, combined with a sequence number and a replay window.  Where encryption is not needed, RFC6234,
Change:
This is some advice on how big the replay window needs to be.
doc> a 64 bit tag is recommended, combined with a sequence number and a doc> replay window. Where encryption is not needed, HMAC-SHA-256, doc> combined with a sequence number and a replay window, may be used. [[TODO]]
An absolute timestamp is probably not necessary, as the key should be newly generated on a reboot. A boot-relative timestamp may be enough. The window pretty much becomes the "patience" value -- how long does the client wait for getting its response?

Discussion:
encryption is not needed, RFC6234, combined with a sequence number and a replay window, may be used. <ins> This size of the replay window depends upon the number of outstanding requests that need to be outstanding.  This can be determined from the rate at which new ones are made, and the expected duration in which responses are expected. For instance, given a CoAP ACK_TIMEOUT of 2s, and a request rate of 10 requests/second, any request that is not answered within 2s will be considered to have failed.  Thus at most 20 request can be outstanding at a time, and any convenient replay window larger than 20 will work.  As replay windows are often implemented with a sliding window and a bit, the use of a 32-bit window would be sufficient. For use cases where requests are being relayed from another node, the request rate may be estimated by the total link capacity allocated for that kind of traffic.  An alternate view would consider how many IPv6 Neighbor Cache Entries (NCEs) the system can afford to allocate for this use. </ins> When using an encryption mode that depends on a nonce, such as AES- CCM, repeated use of the same nonce under the same key causes the cipher to fail catastrophically.
Change:
The term "function" might imply idempotence and/or freedom from side effects, depending on who you ask. RPC uses the term "procedure" in order to be more general.
NAME would you suggest s/function/procedure/g ?
Changed to "procedure"

Discussion:
6.2. <del> To modify resource state, clients usually GET a representation from the server, process it locally, and transfer the resulting state back to the server with a PUT.  Sometimes, however, the state can only be modified on the server side, for instance, because representations would be too large to transfer or part of the required information shall not be accessible to clients. In this case, resource state is modified by calling a function.  This is usually modeled with a POST request, as it leaves the behavior semantics completely to the server. </del> <ins> To modify resource state, clients usually use GET to retrieve a representation from the server, modify that locally, and transfer the resulting state back to the server with a PUT (see sec-uniform- interface).  Sometimes, however, the state can only be modified on the server side, for instance, because representations would be too large to transfer or part of the required information shall not be accessible to clients.  In this case, resource state is modified by calling a procedure (or "function").  This is usually modeled with a POST request, as this method leaves the behavior semantics completely to the server.  Procedure calls can be divided into two different classes based on how long they are expected to execute: "instantly" returning and long-running. </ins> 6.2.1. <ins> When the procedure can return within the expected response time of the system, the result can be directly returned in the response.  The result can either be actual content or just a confirmation that the call was successful.  In either case, the response does not contain a representation of the resource, but a so-called action result. Action results can still have hypermedia controls to provide the possible transitions in the application state machine. </ins> 6.2.2. <ins> When the procedure takes longer than the expected response time of the system, or even longer than the response timeout, it is a good pattern to create a new resource to track the "task" execution.  The server would respond instantly with a "Created" status (HTTP code 201 or CoAP 2.01) and indicate the location of the task resource in the corresponding header field (or CoAP option) or as a link in the action result.  The created resource can be used to monitor the progress, to potentially modify queued tasks or cancel tasks, and to eventually retrieve the result. Monitoring information would be modeled as state of the task resource, and hence be retrievable as representation.  The result - when available - can be embedded in the representation or given as link to another sub-resource.  Modifying tasks can be modeled with forms that either update sub-resources via PUT or do a partial write using PATCH or POST.  Canceling a task would be modeled with a form that uses DELETE to remove the task resource. </ins> 6.2.3. GET is cachable, good for static information such as look-up tables
Change:
I just gave this advice and it might be a good rule of thumb: Assuming human-readable representation formats (i.e., text-based not binary) and a client supporting the URI scheme used, a good rule of thumb for a good hypermedia-driven design is the following: A developer should only need an entry point URI to drive the application. All further information how to navigate through the application (links) and how to construct more complex requests (forms) are published by the server(s). There must be no need for additional, out-of-band information (e.g., API specification). For machines, a well-chosen set of information needs to be shared a priori to agree on machine-understandable semantics. (Agreeing on the exact semantics of terms for relation types and data elements will of course also help the developer.)
Yes, except that text-based doesn't mean human-readable (as exemplified by JSON -- in reality you need a formatting tool to look at any instances that aren't entirely trivial). More important is that the format is self-describing (and the tool you need to look at that not too obscure).
Yes, yes, all this is already in the assumptions to get a concise rule of thumb :) Next iteration: Assuming self-describing representation formats (i.e., human-readable with carefully chosen terms or processible by a formatting tool) and a client supporting the URI scheme used, a good rule of thumb for a good hypermedia-driven design is the following: A developer should only need an entry point URI to drive the application. All further information how to navigate through the application (links) and how to construct more complex requests (forms) are published by the server(s). There must be no need for additional, out-of-band information (e.g., API specification). For machines, a well-chosen set of information needs to be shared a priori to agree on machine-understandable semantics. (Agreeing on the exact semantics of terms for relation types and data elements will of course also help the developer.)
At least one little update :)Looks good. There's just a small problem: Nobody is doing it.

Discussion:
entry point for requesting the links hosted by servers with known or discovered addresses RFC6690. <ins> 5.4. Assuming self-describing representation formats (i.e., human-readable with carefully chosen terms or processible by a formatting tool) and a client supporting the URI scheme used, a good rule of thumb for a good hypermedia-driven design is the following: A developer should only need an entry point URI to drive the application.  All further information how to navigate through the application (links) and how to construct more complex requests (forms) are published by the server(s).  There must be no need for additional, out-of-band information (e.g., API specification). For machines, a well-chosen set of information needs to be shared a priori to agree on machine-understandable semantics.  Agreeing on the exact semantics of terms for relation types and data elements will of course also help the developer. </ins> 6. Certain kinds of design problems are often recurring in variety of
Change:
Tweak a bit the message of this: non-resource identifiers are not really part of the REST style, but a system usually needs them and the IETF has good means with URIs, which include URNs, and can be used for such non-resource identifiers (e.g., for physical asset, device, etc.).
We added the terms to the terminology, but should explain a bit more at the end of the URI sections.
Solved in

Discussion:
identical, these are two different resources, in two distinct namespaces. <ins> Some schemes are for URIs with main purpose as identifiers and hence are not dereferencable, e.g., the "urn" scheme can be used to construct unique names in registered namespaces.  In particular the "urn:dev" I-D.ietf-core-dev-urn details multiple ways for generating and representing endpoint identifiers of IoT devices. </ins> The query parameters can be used to parametrize the resource.  For example, a GET request may use query parameters to request the server to send only certain kind data of the resource (i.e., filtering the
Change:
Removed "path is hierarchical query not" comment. Added note about query component order being unspecified.
This addresses issue
URL
Fixed in PR Hi, In reading draft-keranen-t2trg-rest-iot-01 I note the following: It is my understanding that this statement is subject to debate. Certainly some RESTful APIs assign hierarchical semantics to the path. For example, /foo may refer to a "collection-style" resource and /foo/bar may refer to a resource within that collection. However, is this a necessary requirement? From my perspective, this could potentially limit extensibility as future revisions of a RESTful API may, for instance, wish to insert a resource "between" /foo and /foo/bar. If the resources themselves are truly self-describing, containing links to "subordinate" resources, then the path portion of the URI can become an opaque identifier and backward compatibility in this hypothetical RESTful API could be maintained. Likewise, I have seen RESTful APIs where the order of the elements in the query portion of the URI matters (particularly if a given element occurs multiple times). I would suggest staying silent on the semantics of these parts of the URI or noting that they MAY be hierarchical / non-hierarchical. Thanks, Robby

Discussion:
address, potentially followed by a transport layer port number, are usually used in the authority component for the "http" and "coap" schemes.  The path and query contain data to identify a resource <del> within the scope of the URI's scheme and naming authority.  The path is hierarchical; the query is non-hierarchical.  The fragment allows to refer to some portion of the resource, such as a section in an HTML document. </del> <ins> within the scope of the URI's scheme and naming authority.  The fragment allows to refer to some portion of the resource, such as a section in an HTML document. </ins> For RESTful IoT applications, typical schemes include "https", "coaps", "http", and "coap".  These refer to HTTP and CoAP, with and

example, a GET request may use query parameters to request the server to send only certain kind data of the resource (i.e., filtering the response).  Query parameters in PUT and POST requests do not have <del> such established semantics and are not commonly used. </del> <ins> such established semantics and are not commonly used.  Whether the order of the query parameters matters in URIs is unspecified and they can be re-ordered e.g., by proxies.  Therefore applications should not rely on their order; see Section 3.3 of RFC6943 for more details. </ins> 3.5.

5. The authors would like to thank Mert Ocak, Heidi-Maria Back, Tero <del> Kauppinen, and Michael Koster for the reviews and feedback. </del> <ins> Kauppinen, Michael Koster, Robby Simpson, Ravi Subramaniam, and Dave Thaler for the reviews and feedback. </ins>
Change:
Relaying feedback received: We currently require EMS+TLS 1.2 or TLS 1.3+ in order for the Exported Authenticator API to be validly used. However, the definition of the APIs don't explicitly call out a failure path. We should probably address this. Simplest option would be to add a sentence to the description of each API that it fails if those conditions aren't met.

Discussion:
provide application programming interfaces by which clients and servers may request and verify exported authenticator messages. <ins> Notwithstanding the success cases described below, all APIs MUST fail if: the connection uses a TLS version of 1.1 or earlier, or the connection is TLS 1.2 and the extended master secret RFC7627 was not used </ins> Given an established connection, the application SHOULD be able to call the following APIs:
Change:
Make it possible to choose a non-empty certificaterequestcontext when there is no authenticator request. This change introduces the flexibility needed to achieve compound authentication between certificates using a technique called CRC Smuggling, described by Jonathan Hoyland.

Discussion:
The certificate message contains an opaque string called certificate_request_context, which is extracted from the authenticator request if present.  If no authenticator request is <del> provided, it is zero-length. </del> <ins> provided, the certificate_request_context can be chosen arbitrarily. </ins> The certificates chosen in the Certificate message MUST conform to the requirements of a Certificate message in the negotiated version

a signer (either the private key associated with the certificate, or interface to perform private key operation) for each chain <del> an optional authenticator request </del> <ins> an optional authenticator request or certificate_request_context (from 0 to 255 bytes) </ins> It returns the exported authenticator as a sequence of octets.  It is RECOMMENDED that the logic for selecting the certificates and
Change:
It's also the only use of 2119 language in this section, which is otherwise nicely informative.

Discussion:
an optional authenticator request or certificate_request_context (from 0 to 255 bytes) <del> It returns the exported authenticator as a sequence of octets.  It is RECOMMENDED that the logic for selecting the certificates and extensions to include in the exporter is implemented in the TLS library.  Implementing this in the TLS library lets the implementer take advantage of existing extension and certificate selection logic. </del> <ins> It returns the exported authenticator as a sequence of octets. Ideally, the logic for selecting the certificates and extensions to include in the exporter is implemented in the TLS library. Implementing this in the TLS library lets the implementer take advantage of existing extension and certificate selection logic. </ins> It is also possible to implement this API outside of the TLS library using TLS exporters.  This may be preferable in cases where the
Change:
In Section 4, clients are required to have an authenticator request before generating and sending an authenticator. Later, in Section 4.2, the draft states that clients may get authenticator information from a SH or EncryptedExtensions in the event that no authenticator request is present. This seems to contradict the requirement in Section 4.

Discussion:
An authenticator message can be constructed by either the client or the server given an established TLS connection, a certificate, and a <del> corresponding private key.  For clients, an authenticator request is required; for servers an authenticator request is optional.  The authenticator uses the message structures from Section 4.4 of TLS13, but different parameters.  These messages do not include the TLS record layer and are therefore not encrypted with a handshake key. </del> <ins> corresponding private key.  Clients MUST NOT send an authenticator without a preceding authenticator request; for servers an authenticator request is optional. The authenticator uses the message structures from Section 4.4 of TLS13, but different parameters.  These messages do not include the TLS record layer and are therefore not encrypted with a handshake key. </ins> 4.1.

If an authenticator request is present, the extensions used to guide the construction of these messages are taken from the authenticator request.  If there is no authenticator request, the extensions are <del> chosen from the TLS handshake.  That is, the extensions received in a ClientHello (for servers), ServerHello (for clients in TLS 1.2), or EncryptedExtensions (for clients in TLS 1.3). </del> <ins> chosen from the TLS handshake.  Only servers can provide an authenticator without a corresponding request.  In such cases, ClientHello extensions are used to determine permissible extensions in the Certificate message. </ins> 4.2.1.
Change:
the newline was being introduced by trailing whitespace at the end of line 136.
In the , there's a newline between two sentences that apparently can't decide whether they want to be in separate paragraphs or not.

Discussion:
the server given an established TLS connection, a certificate, and a corresponding private key.  Clients MUST NOT send an authenticator without a preceding authenticator request; for servers an <del> authenticator request is optional. The authenticator uses the message structures from Section 4.4 of TLS13, but different parameters.  These messages do not include the TLS record layer and are therefore not encrypted with a handshake key. </del> <ins> authenticator request is optional.  The authenticator uses the message structures from Section 4.4 of TLS13, but different parameters.  These messages do not include the TLS record layer and are therefore not encrypted with a handshake key. </ins> 4.1.
Change:
NAME The crc can be derived in two places: the authenticator request and the unsolicited authenticator. I want to make sure the requirement is clear in both places.
Issue raised by Jonathan Hoyland at IETF 102
So you just wanted to repeat the requirement? Because that first bit already said no repeats.

Discussion:
An opaque string which identifies the certificate request and which will be echoed in the authenticator message.  A <del> certificate_request_context value MUST NOT be repeated for multiple authenticator requests generated by the same party within the scope of a connection (thus preventing replay of authenticators).  The certificate_request_context SHOULD be chosen to be unpredictable to the peer (e.g., by randomly generating it) in order to prevent an attacker who has temporary access to the peer's private key from pre-computing valid authenticators.  This value is unrelated to the certificate_request_context used in post-handshake authentication and collisions do not need to be avoided. </del> <ins> certificate_request_context value MUST be unique for each authenticator request within the scope of a connection (preventing replay and context confusion).  The certificate_request_context SHOULD be chosen to be unpredictable to the peer (e.g., by randomly generating it) in order to prevent an attacker who has temporary access to the peer's private key from pre-computing valid authenticators.  This value is unrelated to the certificate_request_context used in post-handshake authentication and collisions do not need to be avoided. </ins> The extensions that are allowed in this structure include the extensions defined for CertificateRequest messages defined in

If an authenticator request is present, the extensions used to guide the construction of these messages are taken from the authenticator <del> request.  If there is no authenticator request, the extensions are chosen from the TLS handshake.  Only servers can provide an authenticator without a corresponding request.  In such cases, ClientHello extensions are used to determine permissible extensions in the Certificate message. </del> <ins> request.  If the certificate_request_context from the authenticator request has already been used in the connection, then no authenticator should be constructed.  If there is no authenticator request, the extensions are chosen from the TLS handshake.  Only servers can provide an authenticator without a corresponding request. In such cases, ClientHello extensions are used to determine permissible extensions in the Certificate message. </ins> 4.2.1.

The certificate message contains an opaque string called certificate_request_context, which is extracted from the authenticator request if present.  If no authenticator request is <del> provided, the certificate_request_context can be chosen arbitrarily. </del> <ins> provided, the certificate_request_context can be chosen arbitrarily but MUST be unique within the scope of the connection and be unpredictable to the peer. </ins> The certificates chosen in the Certificate message MUST conform to the requirements of a Certificate message in the negotiated version