half. The client MUST ensure that the certificate is served to TLS <del> connections specifying a Server Name Indication (SNI) value of SAN B. </del>  The response to the TLS-SNI challenge simply acknowledges that the client is ready to fulfill this challenge. Compute SAN A and SAN B in the same way as the client. Open a TLS connection to the domain name being validated on the <del> requested port, presenting SAN B in the SNI field. </del>  The server MUST request the certificate using an SNI value of SAN <del> B. </del>  <del> The server SHOULD ensure that it does not reveal SAN A in any way </del>  when making the TLS connection, such that the presentation of SAN <del> A in the returned certificate proves association with the client. </del>  Verify that the certificate contains a subjectAltName extension containing dNSName entries of SAN A and SAN B and no other

This replaces tls-sni-01 with tls-sni-02, which requires that domains being validated return a certificate which contains a hostname that is not revealed by the server in its handshake. This ensures that challenges cannot be passed by domains which auto-generate self-signed certificates in response to requests with SANs for domains not previously seen.

half. The client MUST ensure that the certificate is served to TLS  <ins> connections specifying a Server Name Indication (SNI) value of SAN A. </ins> The response to the TLS-SNI challenge simply acknowledges that the client is ready to fulfill this challenge. Compute SAN A and SAN B in the same way as the client. Open a TLS connection to the domain name being validated on the  <ins> requested port, presenting SAN A in the SNI field. </ins> The server MUST request the certificate using an SNI value of SAN  <ins> A. </ins>  <ins> The server SHOULD ensure that it does not reveal SAN B in any way </ins> when making the TLS connection, such that the presentation of SAN  <ins> 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


There are certain factors that arise in operational reality that operators of ACME-based CAs will need to keep in mind when <del> configuring their services. </del>  [[ TODO: Other operational considerations ]]

I've noticed that boulder uses DNS over TCP. I suppose this has not been an arbitrary choice, but something that would be useful to document.
As an FYI, Boulder currently uses TCP for DNS to its local authoritative resolver, but the resolver uses UDP. We tried making the resolver do upstream resolution with TCP but got a large number of failures.

There are certain factors that arise in operational reality that operators of ACME-based CAs will need to keep in mind when  <ins> configuring their services.  For example: It is advisable to perform DNS queries via TCP to mitigate DNS forgery attacks over UDP </ins> [[ TODO: Other operational considerations ]]


to sign the request.  Once created, the authorization may only be updated by that account.  Before processing the authorization further, the server SHOULD determine whether it is willing to issue certificates for the identifier.  For example, the server should check that the identifier

This allows clients to determine whether an authorization already exists in a way most likely to be relevant to their use cases. It also allows clients which are not in a position to obtain authorizations but which may wish to issue certificates under existing ones to test for their existence without spamming the database with unused authorizations. NAME thoughts?
NAME Have you been seeing the unused auths become a recurring problem in your client? (I have in mine, and although that's still a bug in my code, I wonder if it would be helpful to know authoritatively from the ACME server that a challenge is already under way.)
I haven't. I keep track of which hostnames have successfully completed authorizations. I'd rather not have to keep track of that, though - my client operates on the principle of keeping as little state as possible. The less state kept, the less that can be messed up, the less that can be desynced.
For example if a different client on a different machine uses the same account key, there could be a usable authorization it doesn't know about. There's an authorization enumeration endpoint specified in the directory, but I think this conditional creation covers 99% of the use cases of that endpoint.
I like the general idea of making authorization reuse more straightforward, but I'm not sure this is the best approach. For instance, the field on the registration object in theory makes this possible, though it may be onerous to fetch all of the authorizations if you only care about one. If we wanted to make that easier, we could specify a way to look up existing authorizations by name and pending / valid status. Or, another alternative: Say that in response to new-authz, the server may choose at its option to reply with 302 Found to an existing valid or pending authorization (but not an expired or invalid one). In general the server would presumably choose to do so based on how much time was left until the relevant authorization expired, because it would be annoying to redirect to an authorization that was about to expire.
I considered that initially, creating or redirecting based on the expiry. The issue I think is that the client is in the best position to know how much time it needs, or maybe you want to renew the authorization for some reason. I think there are likely to be hazards to rendering it impossible to create a new authorization for a while. Moreover it's a protocol change. I think if the client opts in to it, it's okay. The only difference is you pass "existing": "accept".

to sign the request.  Once created, the authorization may only be updated by that account. <ins> When submitting a new authorization request, the key "existing" with a string value MAY be included in the resource object.  This object is not considered part of an authorization resource but controls request processing as described below. If the authorization request specifies "existing" with a value of "accept" or "require", before proceeding, the server SHOULD determine if there are any existing authorization resources for the account and given identifier which are presently valid.  If one or more such authorizations exists, a response SHOULD returned with status code 303 (See Other) and a Location header pointing to the existing resource URL; processing of the request then stops.  If there are multiple such authorizations, the authorization with the latest expiry date SHOULD be returned.  Otherwise, if the "existing" item was "require", status code 404 (Not Found) is returned; if it was "accept" or was any other value or was absent, processing continues as follows. </ins> Before processing the authorization further, the server SHOULD determine whether it is willing to issue certificates for the identifier.  For example, the server should check that the identifier


As a domain may resolve to multiple IPv4 and IPv6 addresses, the server will connect to at least one of the hosts found in A and AAAA <del> records, at its discretion.  Because many webservers allocate a default HTTPS virtual host to a particular low-privilege tenant user in a subtle and non-intuitive manner, the challenge must be completed over HTTP, not HTTPS. </del>  The string "http-01" The key authorization for this challenge.  This value MUST match the token from the challenge and the client's account key.  On receiving a response, the server MUST verify that the key authorization in the response matches the "token" value in the challenge and the client's account key.  If they do not match, then Verify that the resulting URI is well-formed. <del> Dereference the URI using an HTTP GET request. </del>  Verify that the body of the response is well-formed key authorization.  The server SHOULD ignore whitespace characters at

This looks fine to me, and consistent with the list discussions. (I have a couple of minor issues, which I filed as .) I am merging this in preference to , which got negative feedback on the list.
The format should be specified more clearly, by reference to a couple of RFCs The "peer" provision seems kind of awkward. For server implementations where the validation is done by a separate entity than the ACME interactions (like ), this means that the challenge no longer has all the information that the validation agent needs to do the validation. I'm inclined to drop it and put the burden on the client.

As a domain may resolve to multiple IPv4 and IPv6 addresses, the server will connect to at least one of the hosts found in A and AAAA  <ins> records.  Because many webservers allocate a default HTTPS virtual host to a particular low-privilege tenant user in a subtle and non- intuitive manner, the challenge must be completed over HTTP, not HTTPS. </ins> The string "http-01" The key authorization for this challenge.  This value MUST match the token from the challenge and the client's account key. <ins> In addition, the client MAY advise the server at which IP the challenge is provisioned: An IPv4 or IPv6 address which, if given, MUST be included in the set of IP addresses to which the domain name resolves.  If given, the server will connect to that specific IP address instead of arbitrarily choosing an IP from the set of A and AAAA records to which the domain name resolves.  If the field is given but equal to ""peer"", the server MUST treat the field as if it contained the IP address from which the response was received. </ins> On receiving a response, the server MUST verify that the key authorization in the response matches the "token" value in the challenge and the client's account key.  If they do not match, then Verify that the resulting URI is well-formed.  <ins> If the client has supplied an address to use, verify that the address is included in the A or AAAA records to which the domain name resolves.  If the address is not included in the result, the validation fails. Dereference the URI using an HTTP GET request.  If an address was supplied by the client, use that address to establish the HTTP connection. </ins> Verify that the body of the response is well-formed key authorization.  The server SHOULD ignore whitespace characters at


When the server responds with an error status, it SHOULD provide additional information using problem document I-D.ietf-appsawg-http- <del> problem.  The "type" and "detail" fields MUST be populated.  To facilitate automatic response to errors, this document defines the following standard tokens for use in the "type" field (within the "urn:ietf:params:acme:error:" namespace): </del>  This list is not exhaustive.  The server MAY return errors whose "type" field is set to a URI other than those defined above.  Servers

These fields are not required by draft-ietf-appsawg-http-problem-03.

When the server responds with an error status, it SHOULD provide additional information using problem document I-D.ietf-appsawg-http-  <ins> problem.  To facilitate automatic response to errors, this document defines the following standard tokens for use in the "type" field (within the "urn:ietf:params:acme:error:" namespace): </ins> This list is not exhaustive.  The server MAY return errors whose "type" field is set to a URI other than those defined above.  Servers


ACME messaging is based on HTTPS RFC2818 and JSON RFC7159. <del> Binary fields are encoded using Base64url encoding described in </del>  RFC4648 Section 5, according to the profile specified in JSON Web Signature RFC7515 Section 2.  This encoding uses a URL safe character set.  Trailing '=' characters MUST be stripped. is a JWS object whose JSON payload contains the certificate to be revoked: <del> The certificate to be revoked, in the Base64url-encoded version of </del>  the DER format.  (Note: This field uses the same modified Base64 encoding rules used elsewhere in this document, so it is different from PEM.) parameters N and E, in order to avoid ambiguity with regard to the sign of the number.  As noted in JWA RFC7518, a JWK object MUST NOT include this zero octet.  That is, any initial zero octets MUST be <del> stripped before the values are Base64url-encoded. </del>  7.2. A random value that uniquely identifies the challenge.  This value MUST have at least 128 bits of entropy, in order to prevent an attacker from guessing it.  It MUST NOT contain any characters <del> outside the URL-safe Base64 alphabet. </del>  A client responds to this challenge by constructing a self-signed certificate which the client MUST provision at the domain name The string "proof-of-possession-01" <del> An array of certificates, in Base64url-encoded DER format, that </del>  contain acceptable public keys. In response to this challenge, the client uses the private key A random value that uniquely identifies the challenge.  This value MUST have at least 128 bits of entropy, in order to prevent an attacker from guessing it.  It MUST NOT contain any characters <del> outside the URL-safe Base64 alphabet. </del>  A client responds to this challenge by constructing a key authorization from the "token" value provided in the challenge and

The current draft stipulates Base64 encoding without padding in relation to JSON data. It is unclear whether omitting the padding characters also applies to the Base64url encoding of key authorization resources (which are not JSON objects). To avoid ambiguity with regards to the encoding of the key authorization string (with padding / without padding) either specify "Base64url Encoding" in the terminology section or change the wording of the aforementioned provision so it is clear that the RFC7515 variant applies to any Base64 encoding throughout the spec. Reference: URL
Data for the discussion: boulder uses Base64url without padding (a.k.a. ) everywhere. (The DNS challenge deployed to boulder's staging instance was buggy, has been fixed in master, and is going to be deployed to again Real Soon Now)

ACME messaging is based on HTTPS RFC2818 and JSON RFC7159.  <ins> Binary fields are encoded using base64url encoding described in </ins> RFC4648 Section 5, according to the profile specified in JSON Web Signature RFC7515 Section 2.  This encoding uses a URL safe character set.  Trailing '=' characters MUST be stripped. is a JWS object whose JSON payload contains the certificate to be revoked:  <ins> The certificate to be revoked, in the base64url-encoded version of </ins> the DER format.  (Note: This field uses the same modified Base64 encoding rules used elsewhere in this document, so it is different from PEM.) parameters N and E, in order to avoid ambiguity with regard to the sign of the number.  As noted in JWA RFC7518, a JWK object MUST NOT include this zero octet.  That is, any initial zero octets MUST be  <ins> stripped before the values are base64url-encoded. </ins> 7.2. A random value that uniquely identifies the challenge.  This value MUST have at least 128 bits of entropy, in order to prevent an attacker from guessing it.  It MUST NOT contain any characters  <ins> outside the URL-safe Base64 alphabet and MUST NOT contain any padding characters ("="). </ins> A client responds to this challenge by constructing a self-signed certificate which the client MUST provision at the domain name The string "proof-of-possession-01"  <ins> An array of certificates, in base64url-encoded DER format, that </ins> contain acceptable public keys. In response to this challenge, the client uses the private key A random value that uniquely identifies the challenge.  This value MUST have at least 128 bits of entropy, in order to prevent an attacker from guessing it.  It MUST NOT contain any characters  <ins> outside the URL-safe Base64 alphabet and MUST NOT contain any padding characters ("="). </ins> A client responds to this challenge by constructing a key authorization from the "token" value provided in the challenge and


ACME uses different URIs for different management functions.  Each function is listed in a directory along with its corresponding URI, <del> so clients only need to be configured with the directory URI. </del>  The "up" link relation is used with challenge resources to indicate the authorization resource to which a challenge belongs.  It is also

Since the rest of the spec and protocol makes extensive use of JSON, when I was reading the spec the first time, I didn't know if the link relations were supposed to be JSON link relations like HAL or LinkedData. The spec mentions "link relation" 6 times, but only one of them (the 2nd-to-last) makes explicit reference to RFC 5988 for web linking via HTTP header.

ACME uses different URIs for different management functions.  Each function is listed in a directory along with its corresponding URI,  <ins> so clients only need to be configured with the directory URI.  These URIs are connected by a few different link relations RFC5988. </ins> The "up" link relation is used with challenge resources to indicate the authorization resource to which a challenge belongs.  It is also


by replacing the old account key with the public key carried in the "jwk" header parameter of the "newKey" JWS object.  6.5. Once a client has created an account with an ACME server, it is

I'm not sure if this is the correct place for issues with the actual server, but https://acme-URL is returning me an error message of When accessed from several machines.
No, this isn't the right place. Contact LetsEncrypt directly. This is for discussing the IETF protocol.
https://ietf-wg-URL does not detail what status code should be returned. I assume it should be a 202, in line with Registration update, but it needs specifying IMO.

by replacing the old account key with the public key carried in the "jwk" header parameter of the "newKey" JWS object. <ins> If the update was successful, then the server sends a response with status code 200 (OK) and the updated registration object as its body. If the update was not successful, then the server responds with an error status code and a problem document describing the error. </ins> 6.5. Once a client has created an account with an ACME server, it is


registration, to allow a client to retrieve the "new-authorization" and "terms-of-service" URI <del> 6.4. </del>  A client may wish to change the public key that is associated with a registration, e.g., in order to mitigate the risk of key compromise. If the update was not successful, then the server responds with an error status code and a problem document describing the error. <del> 6.5. </del>  Once a client has created an account with an ACME server, it is possible that the private key for the account will be lost.  The may now use this in the same way as if he had gotten it from a new- registration transaction. <del> 6.6. </del>  The identifier authorization process establishes the authorization of an account to manage certificates for a given identifier.  This 201 (Created) response, with the authorization URI in a Location header field, and the JSON authorization object in the body. <del> The client needs to respond with information to complete the challenges.  To do this, the client updates the authorization object received from the server by filling in any required information in the elements of the "challenges" dictionary.  (This is also the stage where the client should perform any actions required by the challenge.) </del>  The client sends these updates back to the server in the form of a JSON object with the response fields required by the challenge type, the validation is still in progress, the server MUST return a 202 (Accepted) response with a Retry-After header field. <del> 6.7. </del>  The holder of an authorized key pair for an identifier may use ACME to request that a certificate be issued for that identifier.  The the certificate URI does not yield one, then the client may initiate a new-certificate transaction to request one. <del> 6.8. </del>  To request that a certificate be revoked, the client sends a POST request to the ACME server's revoke-cert URI.  The body of the POST

Adds a little more granularity to section headings.
It should be possible for a client to delete his account / registration, and to renounce authorization for a domain. The right way to do this is probably to define a "delete" object that can be POSTed to the reg/account URI, rather than having a separate endpoint (as for certificate revocation).

registration, to allow a client to retrieve the "new-authorization" and "terms-of-service" URI  <ins> 6.3.1. </ins> A client may wish to change the public key that is associated with a registration, e.g., in order to mitigate the risk of key compromise. If the update was not successful, then the server responds with an error status code and a problem document describing the error.  <ins> 6.3.2. </ins> Once a client has created an account with an ACME server, it is possible that the private key for the account will be lost.  The may now use this in the same way as if he had gotten it from a new- registration transaction.  <ins> 6.3.3. If a client no longer wishes to have an account key registered with the server, it may request that the server delete its account by sending a POST request to the account URI containing the "delete" field. delete (required, boolean): The boolean value "true". The request object MUST contain the "resource" field as required above(with the value "reg").  It MUST NOT contain any fields besides "resource" and "delete". Note that although this object is very simple, the risk of replay or fraudulent generation via signing oracles is mitigated by the need for an anti-replay token in the protected header of the JWS. On receiving a POST to an account URI containing a "delete" field, the server MUST verify that no other fields were sent in the object (other than "resource"), and it MUST verify that the value of the "delete" field is "true" (as a boolean, not a string).  If either of these checks fails, then the server MUST reject the request with status code 400 (Bad Request). If the server accepts the deletion request, then it MUST delete the account and all related objects and send a response with a 200 (OK) status code and an empty body.  The server SHOULD delete any authorization objects related to the deleted account, since they can no longer be used.  The server SHOULD NOT delete certificate objects related to the account, since certificates issued under the account continue to be valid until they expire or are revoked. 6.4. </ins> The identifier authorization process establishes the authorization of an account to manage certificates for a given identifier.  This 201 (Created) response, with the authorization URI in a Location header field, and the JSON authorization object in the body.  <ins> 6.4.1. To prove control of the identifer and receive authorization, the client needs to respond with information to complete the challenges. To do this, the client updates the authorization object received from the server by filling in any required information in the elements of the "challenges" dictionary.  (This is also the stage where the client should perform any actions required by the challenge.) </ins> The client sends these updates back to the server in the form of a JSON object with the response fields required by the challenge type, the validation is still in progress, the server MUST return a 202 (Accepted) response with a Retry-After header field.  <ins> 6.4.2. If a client wishes to relinquish its authorization to issue certificates for an identifier, then it may request that the server delete the authorization.  The client makes this request by sending a POST request to the authorization URI containing a payload in the same format as in deleting-an-account.  The only difference is that the value of the "resource" field is "authz". The server MUST perform the same validity checks as in deleting-an- account and reject the request if they fail.  If the server deletes the account then it MUST send a response with a 200 (OK) status code and an empty body. 6.5. </ins> The holder of an authorized key pair for an identifier may use ACME to request that a certificate be issued for that identifier.  The the certificate URI does not yield one, then the client may initiate a new-certificate transaction to request one.  <ins> 6.6. </ins> To request that a certificate be revoked, the client sends a POST request to the ACME server's revoke-cert URI.  The body of the POST


The above process to locate the serial-number MUST be performed by the pledge when filling out the voucher-request.  Signed voucher- <del> requests are always passed up to the MASA, and the connection between the serial-number in the voucher-request and the serial number in the IDevID certificate. </del>  As explained in RequestVoucherFromMASA the Registrar MUST extract the <del> serial-number again itself from the pledge's TLS certificate.  It may </del>  consult the serial-number in the pledge-request if there are any possible confusion about the source of the serial-number (hwSerialNum vs serialNumber). registrar's proximity. The "prior-signed-voucher-request" leaf is used in registrar voucher- <del> requests.  If present, it is the encoded (signed form) of the pledge voucher-request.  This provides a method for the registrar to forward the pledge's signed request to the MASA.  This completes transmission of the signed "proximity-registrar-cert" leaf. </del>  Unless otherwise signaled (outside the voucher-request artifact), the signing structure is as defined for vouchers, see RFC8366. The following example illustrates a registrar voucher-request. The 'prior-signed-voucher-request' leaf is populated with the pledge's voucher-request (such as the prior example).  The <del> pledge's voucher-request, if a signed artifact with a CMS format signature is a binary object.  In the JSON encoding used here it must be base64 encoded.  The nonce, created-on and assertion is carried forward.  The serial-number is extracted from the pledge's Client Certificate from the TLS connection.  See </del>  RequestVoucherFromMASA. The following example illustrates a registrar voucher-request. that it will not be able to reach the MASA during deployment.  See RequestVoucherFromMASA. <del> The following example illustrates a registrar voucher-request. The 'prior-signed-voucher-request' leaf is not populated with the pledge voucher-request because the pledge did not sign its own request.  This form might be used when more constrained pledges are being deployed.  The nonce is populated from the pledge's request.  See RequestVoucherFromMASA. </del> 3.4. Following is a YANG RFC7950 module formally extending the RFC8366 This is done with an HTTPS POST using the operation path value of "/.well-known/est/requestvoucher". <del> The pledge voucher-request Content-Types are: </del>  The request is a "YANG-defined JSON document that has been signed using a CMS structure" as described in voucher-request using the request.  The pledge SHOULD sign the request using the IDevIDextension credential. <del> The request is the "YANG-defined JSON document" as described in voucher-request with the exception that it is not within a CMS structure.  It is protected only by the TLS client authentication. This reduces the cryptographic requirements on the pledge. For simplicity the term 'voucher-request' is used to refer to any of these media types.  Registrar impementations SHOULD anticipate future media types but of course will simply fail the request if those types are not yet known. </del>  The pledge SHOULD include an RFC7231 section 5.3.2 "Accept" header indicating the acceptable media type for the voucher response.  The request-examples Example 1. The registrar validates the client identity as described in EST <del> RFC7030 section 3.3.2.  If the request is signed the registrar confirms that the associated 'proximity-registrar-cert' is correct. </del>  5.3. The idevid-issuer value from the pledge certificate is included to ensure a statistically unique identity. <del> If a signed pledge voucher-request was received then it SHOULD be included in the registrar voucher-request.  (NOTE: what is included is the complete pledge voucher-request, inclusive of the 'assertion', 'proximity-registrar-cert', etc wrapped by the pledge's original signature).  If a signed voucher-request was not recieved from the pledge then this leaf is omitted from the registrar voucher request. </del>  A nonceless registrar voucher-request MAY be submitted to the MASA. Doing so allows the registrar to request a voucher when the pledge is

This should be a complete set of diffs for removing unsigned pledge voucher-requests from the text.
For issue
The text "This artifact may be optionally signed" is buried in the yang module (ietf-voucher-URL) and needs to be removed.
When a pledge decides to use an unsigned voucher request, the Registrar will place it into prior-signed-voucher request on the BRSKI-MASA arc. It will be JSON embedded in. When a pledge decides to use a signed voucher request, the Registrar will place the base64 encode of the pledge_request in as a string. The MASA can tell the difference between the two because the signed thing (whether CBOR, COSE, CMS signed CBOR, or CMS signed JSON) will always be base64 encoded. We need to explain this somewhere.
section 5.5 indicates that: prior-signed-voucher-request: If a signed pledge voucher-request was received then it SHOULD be included in the registrar voucher- request. (NOTE: what is included is the complete pledge voucher- request, inclusive of the 'assertion', 'proximity-registrar-cert', etc wrapped by the pledge's original signature). If a signed voucher-request was not recieved from the pledge then this leaf is omitted from the registrar voucher request. This indicates that the MASA never needs to "tell the difference" only the registrar. (The pledge to registrar signaling is via request media type as detailed in s5.2). I did notice this when reading: s3.3. these references to voucher in the leaf description should be to voucher request? "If it is necessary to change a voucher, or re-sign and forward a voucher that was previously provided along a protocol path, then the previously signed voucher SHOULD be included in this field." etc. subsequent paragraphs.
URL tries to fix the lack of specification for unsigned voucher requests.
Max to produce a draft branch that removes unsigned voucher request so we can examine the ramifications of this.
v20 of BRSKI removed unsigned voucher requests. What were the reasons for removing? I don't see a mention of this in the anima WG email. If removed as a final decision, then this issue can be closed also.
Hi, yes, we could close this now. I did post several times to the list in Feb and March, and it was raised during the WG meeting itself, asking for feedback.
Ok, I now see the email list discussion also in December 2018 and based on this the unsigned voucher was removed.

The above process to locate the serial-number MUST be performed by the pledge when filling out the voucher-request.  Signed voucher-  <ins> requests are always passed up to the MASA. </ins> As explained in RequestVoucherFromMASA the Registrar MUST extract the  <ins> serial-number again itself from the pledge's TLS certificate.  It can </ins> consult the serial-number in the pledge-request if there are any possible confusion about the source of the serial-number (hwSerialNum vs serialNumber). registrar's proximity. The "prior-signed-voucher-request" leaf is used in registrar voucher-  <ins> requests.  If present, it is the signed pledge voucher-request.  This provides a method for the registrar to forward the pledge's signed request to the MASA.  This completes transmission of the signed "proximity-registrar-cert" leaf. </ins> Unless otherwise signaled (outside the voucher-request artifact), the signing structure is as defined for vouchers, see RFC8366. The following example illustrates a registrar voucher-request. The 'prior-signed-voucher-request' leaf is populated with the pledge's voucher-request (such as the prior example).  The  <ins> pledge's voucher-request is a binary object.  In the JSON encoding used here it must be base64 encoded.  The nonce, created-on and assertion is carried forward.  The serial-number is extracted from the pledge's Client Certificate from the TLS connection.  See </ins> RequestVoucherFromMASA. The following example illustrates a registrar voucher-request. that it will not be able to reach the MASA during deployment.  See RequestVoucherFromMASA.  3.4. Following is a YANG RFC7950 module formally extending the RFC8366 This is done with an HTTPS POST using the operation path value of "/.well-known/est/requestvoucher".  <ins> The pledge voucher-request Content-Type is: </ins> The request is a "YANG-defined JSON document that has been signed using a CMS structure" as described in voucher-request using the request.  The pledge SHOULD sign the request using the IDevIDextension credential.  <ins> Registrar impementations SHOULD anticipate future media types but of course will simply fail the request if those types are not yet known. </ins> The pledge SHOULD include an RFC7231 section 5.3.2 "Accept" header indicating the acceptable media type for the voucher response.  The request-examples Example 1. The registrar validates the client identity as described in EST  <ins> RFC7030 section 3.3.2.  The registrar confirms that the 'proximity' assertion and associated 'proximity-registrar-cert' are correct. </ins> 5.3. The idevid-issuer value from the pledge certificate is included to ensure a statistically unique identity.  <ins> The signed pledge voucher-request SHOULD be included in the registrar voucher-request.  (NOTE: what is included is the complete pledge voucher-request, inclusive of the 'assertion', 'proximity-registrar-cert', etc wrapped by the pledge's original signature).  If a signed voucher-request was not recieved from the pledge then this leaf is omitted from the registrar voucher request. </ins> A nonceless registrar voucher-request MAY be submitted to the MASA. Doing so allows the registrar to request a voucher when the pledge is


Registrar. This is done with an HTTPS POST using the operation path value of <del> "/requestvoucher". </del>  The request media types are: requirement that holds for any REST interface). This is done with an HTTP POST using the operation path value of <del> "/requestvoucher". </del>  The request media type is: in the log. This is done with an HTTP GET using the operation path value of <del> "/requestauditlog". </del>  The Registrar MUST HTTP POSTs the same Registrar voucher-request as it did when requesting a Voucher.  It is posted to the request with the original, and by now already validated, Registrar voucher-request so as to avoid an extra crypto validation.  The request media type is: The request is a "YANG-defined JSON document that has been signed

Proposes 201/Location: operation optional for /requestauditlog end-point.
Think we should discuss.

Registrar. This is done with an HTTPS POST using the operation path value of  <ins> "/.well-known/est/requestvoucher". </ins> The request media types are: requirement that holds for any REST interface). This is done with an HTTP POST using the operation path value of  <ins> "/.well-known/est/requestvoucher". </ins> The request media type is: in the log. This is done with an HTTP GET using the operation path value of  <ins> "/.well-known/est/requestauditlog". </ins> The Registrar MUST HTTP POSTs the same Registrar voucher-request as it did when requesting a Voucher.  It is posted to the request with the original, and by now already validated, Registrar voucher-request so as to avoid an extra crypto validation. <ins> Rather than returning the audit log as a response to the POST (with a return code 200), the MASA MAY instead return a 201 ("Created") RESTful response (RFC7231 section 7.1) containing a URL to the prepared (and easily cachable) audit response. MASA servers that return URLs SHOULD take care to make the returned URL unguessable.  URLs containing a database number such as https://example.com/auditlog/1234 or the EUI of the device such https://example.com/auditlog/10-00-00-11-22-33, would be easily enumerable by an attacker.  It is recommended put to put some meaningless randomly generated slug that indexes a database instead. A MASA that returns a code 200 MAY also include a Location: header for future reference by the Registrar. </ins> The request media type is: The request is a "YANG-defined JSON document that has been signed


The primary method of Registrar "authentication" by the MASA is detailed in RequestVoucherFromMASA.  As detailed in securityconsiderations the MASA might find it necessary to request <del> additional Registrar authentication.  Registrars MUST be prepared to support TLS client certificate authentication and HTTP Basic or Digest authentication as described in RFC7030 for EST clients. </del>  Implementors are advised that contacting the MASA is to establish a secured REST connection with a web service and that there are a number of authentication models being explored within the industry. administrative notifications or logs in the advent of unexpected HTTP 401 (Unauthorized) responses from the MASA.  5.4. When a Registrar receives a Pledge voucher-request it in turn submits

Adds text to include SNI in BRSKI-MASA handshake.
I like the first diff (expanding the client authentication discussion into a paragraph). I don't see the need for RFC6066 SNI reference. But since it is a "SHOULD" don't have a technical complaint.

The primary method of Registrar "authentication" by the MASA is detailed in RequestVoucherFromMASA.  As detailed in securityconsiderations the MASA might find it necessary to request  <ins> additional Registrar authentication. The Registrar is the client in the BRSKI-MASA connection.  When operating as such, the Registrars MUST be prepared to support TLS client certificate authentication.  The registrar should also be configurable to support HTTP Basic or Digest authentication as described in RFC7030 for EST clients: provision of such credentials of outside the scope of this document and would be part of a supply- chain integration process. </ins> Implementors are advised that contacting the MASA is to establish a secured REST connection with a web service and that there are a number of authentication models being explored within the industry. administrative notifications or logs in the advent of unexpected HTTP 401 (Unauthorized) responses from the MASA. <ins> In order to support multi-tenant MASA implementations the Registrar SHOULD include the RFC6066 Server Name Indicator. </ins> 5.4. When a Registrar receives a Pledge voucher-request it in turn submits


6.  This section map the requirements to support proof of possession and proof of identity to selected existing enrollment protocols.  Note that that the work in the ACE WG described in I-D.selander-ace-coap- underlying TLS using OSCORE resulting in an authenticated self- contained object. <del> 6.1. </del>  When using EST RFC7030, the following constraints should be considered: [RFC Editor: please delete] /* TBD: clarification of retry for fullcmc is necessary as not specified in the context of EST */ <del> 6.2. </del>  Instead of using CMP RFC4210, this specification refers to the lightweight CMP profile I-D.ietf-lamps-lightweight-cmp-profile, as it as specified in section 5.2.4 of I-D.ietf-lamps-lightweight-cmp- profile with delayed enrollment. <del> 7. </del>  This document requires the following IANA actions: included for the defined namespaces in addressing and discovery_eo . */ <del> 8. </del>  The credential used by the registrar-agent to sign the data for the pledge in case of the pledge-initiator-mode should not contain technician operating the device, to avoid revealing this information to the MASA. <del> 9. </del>  <del> 9.1. </del>  Exhaustion attack on pledge based on DoS attack (connection establishment, etc.) <del> 9.2. </del>  Registrar-agent that uses acquired voucher and enrollment response for domain 1 in domain 2: can be detected in Voucher Request IDevID.  Alternatively, the LDevID may be acquired by a service technician after authentication against the issuing CA. <del> 10. </del>  We would like to thank the various reviewers for their input, in particular Brian E.  Carpenter, Michael Richardson, Giorgio

Do we augment 8995? Do we augment 8366? Do we need to do both? What does it mean to augment something that augments something?
Hi, I'm working on that pull request right now. . I don't know how to manage YANG stuff in a bare MT / XML Makefile. We extend 8995 for the voucher-request. There are some practical YANG practices that I'm missing.
I enhanced the voucher-request with two additional leafs for the agent-sign-cert and the agent-provided-proximity-certificate.
YANG module for the extension of the voucher request will be put into the next update of the draft. The will need more investigation by the YANG doctor.
I guess this is fine as far as it goes, but I will admit to being nervous about augmenting a voucher-request (because it in itself is a voucher), but beyond that we also have to add a new assertion enumeration.

6. <ins> The following modules extends the RFC8995 Voucher Request to include a signed artifact from the registrar agent. 7. </ins> This section map the requirements to support proof of possession and proof of identity to selected existing enrollment protocols.  Note that that the work in the ACE WG described in I-D.selander-ace-coap- underlying TLS using OSCORE resulting in an authenticated self- contained object.  <ins> 7.1. </ins> When using EST RFC7030, the following constraints should be considered: [RFC Editor: please delete] /* TBD: clarification of retry for fullcmc is necessary as not specified in the context of EST */  <ins> 7.2. </ins> Instead of using CMP RFC4210, this specification refers to the lightweight CMP profile I-D.ietf-lamps-lightweight-cmp-profile, as it as specified in section 5.2.4 of I-D.ietf-lamps-lightweight-cmp- profile with delayed enrollment.  <ins> 8. </ins> This document requires the following IANA actions: included for the defined namespaces in addressing and discovery_eo . */  <ins> 9. </ins> The credential used by the registrar-agent to sign the data for the pledge in case of the pledge-initiator-mode should not contain technician operating the device, to avoid revealing this information to the MASA.  <ins> 10. </ins>  <ins> 10.1. </ins> Exhaustion attack on pledge based on DoS attack (connection establishment, etc.)  <ins> 10.2. </ins> Registrar-agent that uses acquired voucher and enrollment response for domain 1 in domain 2: can be detected in Voucher Request IDevID.  Alternatively, the LDevID may be acquired by a service technician after authentication against the issuing CA.  <ins> 11. </ins> We would like to thank the various reviewers for their input, in particular Brian E.  Carpenter, Michael Richardson, Giorgio


The following list provides an abstract description of the flow depicted in enrollfigure. <del> CA Certs Request: The pledge optionally requests the latest </del>  relevant CA certificates.  This ensures that the pledge has the complete set of current CA certificates beyond the pinned-domain- cert (which is contained in the voucher and may be just the domain registrar certificate). <del> CA Certs Response: It MUST contain the current root CA </del>  certificate, which typically is the LDevID trust anchor, and any additional certificates that the pledge may need to validate certificates. <del> Attribute Request: Typically, the automated bootstrapping occurs without local administrative configuration of the pledge. </del>  Nevertheless, there are cases in which the pledge may also include additional attributes specific to the target domain into the certification request.  To get these attributes in advance, the attribute request can be used. <del> Attribute Response: It MUST contain the attributes to be included in the subsequent certification request. </del>  <del> Certificate Request: This certification request MUST contain the authenticated self-contained object ensuring both proof-of- </del>  possession of the corresponding private key and proof-of-identity of the requester. <del> Certificate Response: The certification response message MUST </del>  contain on success the requested certificate and MAY include further information, like certificates of intermediate CAs. <del> Certificate Confirm: An optional confirmation sent after the </del>  requested certificate has been received and validated.  It contains a positive or negative confirmation by the pledge whether the certificate was successfully enrolled and fits its needs. <del> PKI/Registrar Confirm: An acknowledgment by the PKI or registrar that MUST be sent on reception of the Cert Confirm. </del>  The generic messages described above may be implemented using various enrollment protocols supporting authenticated self-contained objects,

This is mostly typos and rewording, plus converting some diagrams so that aasvg can do a better job.
Thank you for improvements. I will merge them now and then place some fixups.

The following list provides an abstract description of the flow depicted in enrollfigure.  <ins> CA Certs Request [1]: The pledge optionally requests the latest </ins> relevant CA certificates.  This ensures that the pledge has the complete set of current CA certificates beyond the pinned-domain- cert (which is contained in the voucher and may be just the domain registrar certificate).  <ins> CA Certs Response [2]: It MUST contain the current root CA </ins> certificate, which typically is the LDevID trust anchor, and any additional certificates that the pledge may need to validate certificates.  <ins> Attribute Request [3]: Typically, the automated bootstrapping occurs without local administrative configuration of the pledge. </ins> Nevertheless, there are cases in which the pledge may also include additional attributes specific to the target domain into the certification request.  To get these attributes in advance, the attribute request can be used.  <ins> Attribute Response [4]: It MUST contain the attributes to be included in the subsequent certification request. </ins>  <ins> Certificate Request [5]: This certification request MUST contain the authenticated self-contained object ensuring both proof-of- </ins> possession of the corresponding private key and proof-of-identity of the requester.  <ins> Certificate Response [6]: The certification response message MUST </ins> contain on success the requested certificate and MAY include further information, like certificates of intermediate CAs.  <ins> Certificate Confirm [7]: An optional confirmation sent after the </ins> requested certificate has been received and validated.  It contains a positive or negative confirmation by the pledge whether the certificate was successfully enrolled and fits its needs.  <ins> PKI/Registrar Confirm [8]: An acknowledgment by the PKI or registrar that MUST be sent on reception of the Cert Confirm. </ins> The generic messages described above may be implemented using various enrollment protocols supporting authenticated self-contained objects,


excluding the ASN.1 encoding of "OCTET STRING" of the LDevID(RegAgt) certificate. <del> The body of the agent-signed-data contains an "ietf-voucher-request- prm:agent-signed-data" element (defined in voucher-request-prm-yang): </del>  created-on: MUST contain the creation date and time in yang:date- and-time format. data (as defined in asd) and provided as trigger parameter. The enhancements of the YANG module for the ietf-voucher-request with <del> these new leaves are defined in voucher-request-prm-yang. </del>  The PVR is signed using the pledge's IDevID credential contained as x5c parameter of the JOSE header. prior-signed-voucher-request: PVR as in The RVR MUST be enhanced with the following parameter, when the <del> assertion "agent-proximity" is requested, as defined in voucher- request-prm-yang: </del>  agent-sign-cert: LDevID(RegAgt) certificate or the LDevID(RegAgt) certificate including certificate chain.  In the context of this 7.1. <del> The following enhancement extends the voucher-request as defined in RFC8995 to include additional fields necessary for handling bootstrapping in the pledge-responder-mode. 7.1.1. The following tree diagram is mostly a duplicate of the contents of RFC8995, with the addition of the fields agent-signed-data, registrar-proximity-certificate, and agent-signing certificate.  The tree diagram is described in RFC8340.  Each node in the diagram is fully described by the YANG module in Section voucher-request-prm- yang-module. 7.1.2. The following YANG module extends the RFC8995 Voucher Request to include a signed artifact from the registrar-agent (agent-signed- data) as well as the registrar-proximity-certificate and the agent- signing certificate. </del>  Examples for the PVR are provided in exchanges_uc2_2. 10.5. <del> The enhanced voucher-request described in section voucher-request- prm-yang is bases on RFC8995, but uses a different encoding based on I-D.ietf-anima-jws-voucher.  Therefore similar considerations as described in RFC8995 section 11.7 (Security Considerations) apply. The YANG module specified in this document defines the schema for data that is subsequently encapsulated by a JOSE signed-data Content- type as described in I-D.ietf-anima-jws-voucher.  As such, all of the YANG-modeled data is protected against modification.  The use of YANG to define data structures via the "yang-data" statement, is relatively new and distinct from the traditional use of YANG to define an API accessed by network management protocols such as NETCONF RFC6241 and RESTCONF RFC8040.  For this reason these </del>  guidelines do not follow the template described by RFC8407 section 3.7 (Security Considerations Section).

move YANG to RFC8366bis
Some corrections are necessary regarding the referenced fields defined. BRSKI-PRM specifies the agent-provided-registrar-certificate in contrast to the registar-proximity-certificate. Will be addressed in the next commit.

excluding the ASN.1 encoding of "OCTET STRING" of the LDevID(RegAgt) certificate.  <ins> The body of the agent-signed-data contains an "ietf-voucher- request:agent-signed-data" element (defined in RFC8366bis): </ins> created-on: MUST contain the creation date and time in yang:date- and-time format. data (as defined in asd) and provided as trigger parameter. The enhancements of the YANG module for the ietf-voucher-request with  <ins> these new leaves are defined in RFC8366bis. </ins> The PVR is signed using the pledge's IDevID credential contained as x5c parameter of the JOSE header. prior-signed-voucher-request: PVR as in The RVR MUST be enhanced with the following parameter, when the  <ins> assertion "agent-proximity" is requested, as defined in RFC8366bis: </ins> agent-sign-cert: LDevID(RegAgt) certificate or the LDevID(RegAgt) certificate including certificate chain.  In the context of this 7.1.  <ins> RFC8366bis extends the voucher-request as defined in RFC8995 to include additional fields necessary for handling bootstrapping in the pledge-responder-mode.  They are: agent-signed-data, registrar- proximity-certificate, and agent-signing certificate. </ins> Examples for the PVR are provided in exchanges_uc2_2. 10.5.  <ins> The enhanced voucher-request described in RFC8366bis is based on RFC8995, but uses a different encoding based on I-D.ietf-anima-jws- voucher.  The security considerations as described in RFC8995 section 11.7 (Security Considerations) apply. The YANG module specified in RFC8366bis defines the schema for data that is subsequently encapsulated by a JOSE signed-data Content-type as described in I-D.ietf-anima-jws-voucher.  As such, all of the YANG-modeled data is protected against modification. The use of YANG to define data structures via the RFC8971 "structure" statement, is relatively new and distinct from the traditional use of YANG to define an API accessed by network management protocols such as NETCONF RFC6241 and RESTCONF RFC8040.  For this reason these </ins> guidelines do not follow the template described by RFC8407 section 3.7 (Security Considerations Section).


transferred to a backend that offers a higher level of operational security.  4. Based on the intended target environment described in sup-env and the

I think this is the text we discussed, and can do so again tomorrow.
I accepted the proposal and changed the heading from Applicability to Limitations. As Michael wrote, the statements were rather directed towards examples, in which the approach does not work. I also deleted the last sentence, referring to BRSKI as this may not be an option for the pledge as server. I made two corrections: pledge-agent to registrar-agent. I can't recall if we are including the - or not. [stf] always with ”-“ In general, when I read about applicability, I'd rather that it had more positive hint. I.e. "use this when X,Y,Z is true", while this text tells me to not use it when not-Q. [stf] yes, changed to limitations. CAs may also demand higher security in the registration procedures. Especially the CA/Browser forum currently increases the security requirements in the certificate issuance procedures for publicly trusted certificates. There may be the situation in which the target domain does not offer enough security to operate a RA/CA and therefore this service is transferred to a backend that offers a higher level of operational security. +## Applicability +The mechanisms in this draft presume the availability of the pledge to +communicate with the pledge agent. This may not be possible in Suggested change CAs may also demand higher security in the registration procedures. Especially the CA/Browser forum currently increases the security requirements in the certificate issuance procedures for publicly trusted certificates. There may be the situation in which the target domain does not offer enough security to operate a RA/CA and therefore this service is transferred to a backend that offers a higher level of operational security. +## Applicability +The mechanisms in this draft presume the availability of the pledge to +communicate with the pledge agent. This may not be possible in +constrained environments where, in particular, power must be +conserved. In these situations, it is anticipated that the +transceiver will be powered down most of the time. This presents a +rendezvous problem: the pledge is unavailable for certain periods of +time, and the pledge agent is similarly presumed to be unavailable for Suggested change
See PR for text.
Was included as limitation section. General boundary conditions may also be discussed in architecture documents. Eliot already contacted Brendan Moran to include specifics into Draft
I made two corrections: pledge-agent to registrar-agent. I can't recall if we are including the - or not. In general, when I read about applicability, I'd rather that it had more positive hint. I.e. "use this when X,Y,Z is true", while this text tells me to not use it when not-Q. Proposal to delete the last sentence. As BRSKI-PRM addresses the case in which the pledge is not the initiator, it would be contrary to use it as fallback here. A solution in this case may be that the pledge provides a (physically or other) wakeup function.

transferred to a backend that offers a higher level of operational security. <ins> 3.3. The mechanisms in this draft presume the availability of the pledge to communicate with the registrar-agent. This may not be possible in constrained environments where, in particular, power must be conserved.  In these situations, it is anticipated that the transceiver will be powered down most of the time.  This presents a rendezvous problem: the pledge is unavailable for certain periods of time, and the registrar-agent is similarly presumed to be unavailable for certain periods of time.  In this case, it is recommended that pledges initiate communications directly to the registrar as originally specified in RFC8995. </ins> 4. Based on the intended target environment described in sup-env and the


The most simple example of this process might involve identifying the single IP address to which the implementation wishes to connect, <del> using the system's current default interface or path, and starting a TCP handshake to establish a stream to the specified IP address. However, each step may also differ depending on the requirements of the connection: if the endpoint is defined as a hostname and port, then there may be multiple resolved addresses that are available; there may also be multiple interfaces or paths available, other than the default system interface; and some protocols may not need any transport handshake to be considered "established" (such as UDP), while other connections may utilize layered protocol handshakes, such as TLS over TCP. </del>  Whenever an implementation has multiple options for connection establishment, it can view the set of all individual connection document. Each leaf node of the tree represents a single, coherent connection <del> attempt, with an endpoint, a path, and a set of protocols that can directly negotiate and send data on the network.  Each node in the tree that is not a leaf represents a connection attempt that is either underspecified, or else includes multiple distinct options. </del>  For example, when connecting on an IP network, a connection attempt to a hostname and port is underspecified, because the connection attempt requires a resolved IP address as its Remote Endpoint.  In hostname is a parent node, with child nodes for each IP address. Similarly, an implementation that is allowed to connect using multiple interfaces will have a parent node of the tree for the <del> decision between the paths, with a branch for each interface. </del>  The example aggregate connection attempt above can be drawn as a tree by grouping the addresses resolved on the same interface into child node will be uniquely identified by concatenating its integer to it's parents identifier with a dot in between, such as "1.1" and "1.2".  Each node will be summarized by a tuple of three elements: <del> endpoint, path, and protocol.  The above example can now be written more succinctly as: </del>  When an implementation views this aggregate set of connection attempts as a single connection establishment, it only will use one If a connection originally targets a single endpoint, there may be multiple endpoints of different types that can be derived from the <del> original.  The connection library creates an ordered list of the derived endpoints according to application preference, system policy and expected performance. </del>  DNS hostname-to-address resolution is the most common method of endpoint derivation.  When trying to connect to a hostname endpoint 4.1.1.2. <del> If a client has multiple network interfaces available to it, e.g., a mobile client with both Wi-Fi and Cellular connectivity, it can attempt a connection over any of the interfaces.  This represents a branch point in the connection establishment.  Similar to a derived endpoint, the interfaces should be ranked based on preference, system policy, and performance.  Attempts should be started on one interface, and then on other interfaces successively after delays based on expected round-trip-time or other available metrics. </del>  This same approach applies to any situation in which the client is <del> aware of multiple links or views of the network.  Multiple Paths, each with a coherent set of addresses, routes, DNS server, and more, may share a single interface.  A path may also represent a virtual interface service such as a Virtual Private Network (VPN). </del>  The list of available paths should be constrained by any requirements <del> or prohibitions the application sets, as well as system policy. </del>  4.1.1.3.

After reading , I reviewed the latest text. I'm unsure I want to make changes to Arch/API: I see path as "network path", that is the set of hops through which the packet is forwarded (the local interface being the first local hop, and PvD information/PMTU/etc relating to something non-local). This changes the examples using interface to align with this.
Impl draft, section 4.1.2: "Each node will be summarized by a tuple of three elements: Endpoint, Path, and Protocol. The above example can now be written more succinctly as: 1 [URL, Any, TCP] 1.1 [URL, Wi-Fi, TCP] 1.1.1 [192.0.2.1:80, Wi-Fi, TCP] 1.2 [URL, LTE, TCP] 1.2.1 [192.0.2.1:80, LTE, TCP] 1.2.2 [2001:DB8::1.80, LTE, TCP]" looking at the example I would not call this "Endpoint, Path, and Protocol" but "Remote Endpoint, Local Endpoint or interface, and Protocol". Not sure we have defined the term Path well but I would consider a path to consists of both the local and remote endpoint plus optionally maybe even some more information about the path characteristics that might be known for this endpoint pair.
Yeah, it is "remote endpoint", "interface/local endpoint", and "protocol".
note that the wording needs to be fix at least in a few more places, so whoever puts the PR in should probably reach for the word path and ensure it's used correctly...
especially 4.1.3.2. (Alternate Paths) wouldn't fit that well anymore and would probably need some rewriting...

The most simple example of this process might involve identifying the single IP address to which the implementation wishes to connect,  <ins> using the system's current default path (i.e., using the default interface), and starting a TCP handshake to establish a stream to the specified IP address.  However, each step may also differ depending on the requirements of the connection: if the endpoint is defined as a hostname and port, then there may be multiple resolved addresses that are available; there may also be multiple paths available, (in this case using an interface other than the default system interface); and some protocols may not need any transport handshake to be considered "established" (such as UDP), while other connections may utilize layered protocol handshakes, such as TLS over TCP. </ins> Whenever an implementation has multiple options for connection establishment, it can view the set of all individual connection document. Each leaf node of the tree represents a single, coherent connection  <ins> attempt, with an endpoint, a network path, and a set of protocols that can directly negotiate and send data on the network.  Each node in the tree that is not a leaf represents a connection attempt that is either underspecified, or else includes multiple distinct options. </ins> For example, when connecting on an IP network, a connection attempt to a hostname and port is underspecified, because the connection attempt requires a resolved IP address as its Remote Endpoint.  In hostname is a parent node, with child nodes for each IP address. Similarly, an implementation that is allowed to connect using multiple interfaces will have a parent node of the tree for the  <ins> decision between the network paths, with a branch for each interface. </ins> The example aggregate connection attempt above can be drawn as a tree by grouping the addresses resolved on the same interface into child node will be uniquely identified by concatenating its integer to it's parents identifier with a dot in between, such as "1.1" and "1.2".  Each node will be summarized by a tuple of three elements:  <ins> endpoint, path (labeled here by interface), and protocol.  The above example can now be written more succinctly as: </ins> When an implementation views this aggregate set of connection attempts as a single connection establishment, it only will use one If a connection originally targets a single endpoint, there may be multiple endpoints of different types that can be derived from the  <ins> original.  This creates an ordered list of the derived endpoints according to application preference, system policy and expected performance. </ins> DNS hostname-to-address resolution is the most common method of endpoint derivation.  When trying to connect to a hostname endpoint 4.1.1.2.  <ins> If a client has multiple network paths available to it, e.g., a mobile client with intefaces for both Wi-Fi and Cellular connectivity, it can attempt a connection over any of the paths. This represents a branch point in the connection establishment. Similar to a derived endpoint, the paths should be ranked based on preference, system policy, and performance.  Attempts should be started on one path (e.g., a specific interface), and then successively on other paths (or interfaces) after delays based on expected path round-trip-time or other available metrics. </ins> This same approach applies to any situation in which the client is  <ins> aware of multiple links or views of the network.  A single interface may be shared by multiple network paths, each with a coherent set of addresses, routes, DNS server, and more.  A path may also represent a virtual interface service such as a Virtual Private Network (VPN). </ins> The list of available paths should be constrained by any requirements  <ins> the application sets, as well as by the system policy. </ins> 4.1.1.3.


Once a Preconnection has been used to create an outbound Connection or a Listener, the implementation should ensure that the copy of the <del> properties held by the Connection or Listener is not affected when the application makes changes to a Preconnection object.  This may involve the implementation performing a deep-copy, copying the object with all the objects that it references. </del>  Once the Connection is established, Transport Services implementation maps actions and events to the details of the chosen Protocol Stack.

Preconnections are mutable, until they are not. The second paragraph of section 2 states "bundles of properties an application can both read and write", which seems to conflict with this. Para should lead with the fact of mutable mutability over the preconnection lifecycle, not "is mutable".
The Connection/Listener makes a deep copy that is now immutable, but the original object is still mutable.

Once a Preconnection has been used to create an outbound Connection or a Listener, the implementation should ensure that the copy of the  <ins> properties held by the Connection or Listener cannot be mutated by the application making changes to the original Preconnection object. This may involve the implementation performing a deep-copy, copying the object with all the objects that it references. </ins> Once the Connection is established, Transport Services implementation maps actions and events to the details of the chosen Protocol Stack.


hostnames.  Each of these hostnames might resolve to one or more addresses, which would create multiple layers of branching.  4.1.1.2. If a client has multiple network paths available to it, e.g., a

In the impl draft, I'm supposed to build a tree based on, in order (1) "path": AFAICT this means "interface". The -api draft provides in interface preference framework in 4.2.11. (BTW if it really means interface maybe we should say 'interface'). (2) Protocol: almost all of 4.2 in -api explains how to express this. (with an assist in -impl 4.1.3 explaining how to handle PREFER vs. AVOID) (3) "derived endpoint" I gather this is basically multiple addresses coming back from remote endpoint resolution. But where is the construct in -api that allows applications to express a preference here?
I'm not sure we want to add anything to the API here. There are existing preferences that can bias towards IPv6, such as preferring or requiring . I think we can just detail that in the implementation draft.
Thanks, LGTM!

hostnames.  Each of these hostnames might resolve to one or more addresses, which would create multiple layers of branching. <ins> Applications can influence which derived endpoints are allowed and preferred via Selection Properties set on the Preconnection.  For example, setting a preference for "useTemporaryLocalAddress" would prefer the use of IPv6 over IPv4, and requiring "useTemporaryLocalAddress" would eliminate IPv4 options, since IPv4 does not support temporary addresses. </ins> 4.1.1.2. If a client has multiple network paths available to it, e.g., a


Properties can be added to a MessageContext object only before the context is used for sending.  Once a MessageContext has been used with a Send call, further modifications to the MessageContext object <del> do not have any effect on this Send call. </del>  The Message Properties could be inconsistent with the properties of the Protocol Stacks underlying the Connection on which a given allow out-of-order delivery for certain messages, e.g., by multiplexing independent messages onto different streams.  9.1.3.4. safelyReplayable may disable retransmissions or other reliability mechanisms for this particular Message, but such disabling is not guaranteed.  9.1.3.8. msgCapacityProfile This enumerated property specifies the application's preferred tradeoffs for sending this Message; it is a per-Message override of <del> the Capacity Profile connection property (see prop-cap-profile). </del>  9.1.3.9.

of the API Draft states: At this point, the reader gains the impression that is created independently of any Connection/Selection Properties. However, goes on to state: This raises numerous questions: Does this mean that Selection Properties have to be "in scope" whenever a object is created? (i.e., shouldn't take the current Selection Properties as an argument?) How does, a Selection Property of, e.g., even meaningfully map to a Boolean? (i.e., why is the Property Type a Boolean instead of a Preference?) (Note that the property from raises similar questions)
That's a great catch, thanks! I agree that it should be possible to create a messageContext independent of Connection/Selection properties. A static default may be bad: one may e.g. always have msgOrdered=true, not care about it, and never be able to benefit from a Connection that can do msgOrdered=false. So, instead, I'm tempted to suggest that the default will be assigned (unless the value has been specifically assigned with "add" as in your example above) based on Connection/Selection properties upon use - during the Send call. But this also easily gets bad: it would be an easy mistake to miss this in a TAPS Transport System implementation, and ... if I want to read the value of this parameter of the messageContext, what do I get? Maybe we could define a new special value: "to be updated upon use" ? Tricky. Ideas, anyone?
In my implementation, I've tentatively changed the Type to the enum Type This has a number of advantages: The default value of , which the spec defines as "no preference" unambiguously stands for "simply inherit this Property from the connection properties when sending this message" and are equivalent to the semantics from the spec The possible values of and are essentially equivalent to and , but are understood to not generate errors, even if the underlying connection has no support for the desired Property Note that this setup alone does not allow the Object to "query" a default value for this Property from other contexts. It is not quite clear to me why this would ever be needed in practice.
Interesting! I don't think we should spec it using the Preference type though (seems like a bit of a hack: a "Preference" isn't what this is, and the re-interpretation of Avoid and Prefer isn't too nice either... but that's ok for an implementation!). We could have the type definition as follows: Type: Boolean or (this is similar in style to the type definitions in e.g. 8.1.4, 8.1.8, 8.1.9) Default: ... and we could explain that here means to inherit the value from the connection properties when sending this message. As for querying a default value, I agree that this isn't something one would need in practice but I wanted to be consistent here (everything can be queried as far as I understand) - anyway, querying without changing anything should yield the value , so that's ok, then. If folks agree with this, I can make a PR.
I guess making this inheritance mechanism more obvious could really help here. But using "ignore" for "inherit" or "default" is a bad choice, though. When designing this, we rather thought the message context to be something like a dictionary, where we put all "changes" we want to apply to the message, but making it somewhat of a strongly typed object may require constructing it from the connection in order to derive the defaults.
Agreed with NAME We should make the inheritance of properties from connection-wide preferences onto messages more clear.
Suggestion: In 9.1.3, explain that if you don't set a specific property on a message, the connection/selections properties apply based on what the connection has, and the ones that don't inherit from a connection just use their default.
[Note to self] ... and additionally put specific text about this in the description of the properties where the default is described as "inheriting" from the Connection.

Properties can be added to a MessageContext object only before the context is used for sending.  Once a MessageContext has been used with a Send call, further modifications to the MessageContext object  <ins> do not have any effect on this Send call.  Message Properties that are not added to a MessageContext object before using the context for sending will either take a specific default value or be configured based on Selection or Connection Properties of the Connection that is associated with the Send call.  This initialization behavior is defined per Message Property below. </ins> The Message Properties could be inconsistent with the properties of the Protocol Stacks underlying the Connection on which a given allow out-of-order delivery for certain messages, e.g., by multiplexing independent messages onto different streams. <ins> If it is not configured by the application before sending, this property's default value will be based on the Selection Property "preserveOrder" of the Connection associated with the Send Action. </ins> 9.1.3.4. safelyReplayable may disable retransmissions or other reliability mechanisms for this particular Message, but such disabling is not guaranteed. <ins> If it is not configured by the application before sending, this property's default value will be based on the Selection Property "reliability" of the Connection associated with the Send Action. </ins> 9.1.3.8. msgCapacityProfile This enumerated property specifies the application's preferred tradeoffs for sending this Message; it is a per-Message override of  <ins> the Capacity Profile connection property (see prop-cap-profile).  If it is not configured by the application before sending, this property's default value will be based on the Connection Property "connCapacityProfile" of the Connection associated with the Send Action. </ins> 9.1.3.9.


during connection establishment include: Trust verification callback: Invoked when a Remote Endpoint's <del> trust must be validated before the handshake protocol can continue. </del>  Identity challenge callback: Invoked when a private key operation is required, e.g., when local authentication is requested by a

2 from this . Is s6.3.2 supposed to be about certificate path validation? It might be worth explicit saying that and providing a reference to RFC 5280? Note that I do not have a proposed solution (yet).
Yes, we should reference RFC 5280 here. Reviewer: Sean Turner Review result: Has Issues This is an early sector review. Based on the ARTART early reviews of this I-D and the -arch I-D, there is no doubt going to need to be another review after the authors get done restructuring both I-Ds. BTW: Theresa thank you for the heads up about that restructuring. It forced me to read the -arch and -impl I-Ds, but that probably helped me not make silly requests of the authors/WG. tl;dr: I picked "has issues" knowing there is a rewrite on the way and I would like to reserve final judgement until then. I apologize upfront because I am going to ramble a bit before I get to the specifics: The taps I-Ds are about “a protocol-independent Transport Services Application Programming Interface (API).” I took a pretty liberal approach when reviewing this I-D from a security perspective because these I-Ds are somewhat different than the “normal” protocol I-Ds. As noted in the -arch I-D: these I-Ds do not specify “specific protocols or algorithms” … gasp. But, that’s probably okay in this context. I wondered what you would say about an API: Apps need to use the API properly! check: see -arch I-D Implementation/Library needs to be from trust source! check: see -interface I-D - Apps need to use the right keys at the right time! check: see -arch I-D - Avoid fallback/downgrade to insecure protocols! check: see -arch I-D and -impl I-D - Deal with 0-RTT! check: see -impl I-D - Address privacy aspects! check: see -interface I-D I mean maybe you could add something about: randomness for keys - but that better already be in the security protocol specifications so I do not think it is absolutely needed here. following good programming techniques - but I am not sure where you would point nor whether it really makes sense to do so. I think I found what I was looking for is somewhere in the stack of I-Ds. Am I worried somebody can implement this wrong. Sure. But, not any more than I would be for any other protocol. Now on to the specifics: NOTE: I tried not repeat anything from the ARTART review. 0) s6: maybe this wording would be better? For these two sentences are you trying to say that MUST else if? OLD: At least one Local Endpoint MUST be specified if the Preconnection is used to Listen() for incoming Connections, but the list of Local Endpoints MAY be empty if the Preconnection is used to Initiate() connections. NEW: At least one Remote Endpoint MUST be specified if the Preconnection is used to Initiate() Connections, but the list of Remote Endpoints MAY be empty if the Preconnection is used to Listen() for incoming Connections 1) s6.3.1 I know this is an example, but can we replace: SecurityParameters.Set(supported-group, "secp256k1") with SecurityParameters.Set(supported-group, "secp256r1") r1 the current MTI for TLS. k1 is for bitcoin :) Or, is this where I get a bitcoin because I caught the shiny object? :) 2) s6.3.2: Is this like checking the certificate status? 3) s8.1.1- I read this definition a bunch. Are there two special values? The Type line says “Full Coverage” is special, but then the description says “0” is special too. Maybe look at s91.3.6 for inspiration? 4) s8.1.2: Any reason it’s not called connPriority? Seems arbitrary to drop the end of the word when connTimeout is even longer. 5) s8.1.2-should “Type” line also include (non-negative) like s8.1.1 and s9.1.3.2 do? 6) s8.1.3/.4: The Numeric values specifies seconds, minutes, hours, or millennia? 7) s8.1.6: don’t you need to specify the Type? I guess Enumeration is what you’re after? 8) s8.1.11.2/.3/.4: Are these sizes in bytes too like 8.1.11.1? 9) s8.2.1: RFC 5482 allows granularity of minutes or seconds don’t you need to say which it is here? 10) s8.2.2: Is there some reason it’s not called tcp.userTimeoutEnabled? 11) s8.2.3: Is there some reason it’s not called tcp.userTimeoutChangable? 12) s9.1.3.2: Why 100? 13) s9.1.3.2: Why shorten to msrPrio when msgOrdered is almost as long and safelyReplayable is longer? 14) A.1: Could the caution about freeing memory be generalized? 15) What follows are the I-D nits references to check. Some of these might be on purpose: == Outdated reference: A later version (-11) exists of draft-ietf-taps-arch-10 ** Obsolete normative reference: RFC 4941 (Obsoleted by RFC 8981) == Outdated reference: A later version (-06) exists of draft-ietf-httpbis-priority-03 == Outdated reference: A later version (-10) exists of draft-ietf-taps-impl-09 -- Obsolete informational reference (is this intentional?): RFC 5245 (Obsoleted by RFC 8445, RFC 8839) -- Obsolete informational reference (is this intentional?): RFC 5766 (Obsoleted by RFC 8656)

during connection establishment include: Trust verification callback: Invoked when a Remote Endpoint's  <ins> trust must be verified before the handshake protocol can continue. For example, the application could verify an X.509 certificate as described in RFC5280. </ins> Identity challenge callback: Invoked when a private key operation is required, e.g., when local authentication is requested by a


should be immediately closed by sending a RST to the peer (ABORT.TCP).  10.2. Connectedness: Connected Calling "Abort" on a UDP Connection (ABORT.UDP(-Lite)) is identical to calling "Close". <del> 10.4. </del>  Connectedness: Connectionless Coverage on Sending", "Required Minimum Corruption Protection Coverage for Receiving", and "Full Checksum Coverage on Receiving". <del> 10.5. </del>  Connectedness: Connectionless Calling "Abort" on a UDP Multicast Receive Connection (ABORT.UDP(- Lite)) is identical to calling "Close". <del> 10.6. </del>  Connectedness: Connected same SCTP assocation, and shutdown proceeds as described under "Close".  11. RFC-EDITOR: Please remove this section before publication.

So, for a multiplexing protocol (SCTP, QUIC), CloseGroup and AbortGroup has a specific meaning to treat the group vs a single connection/stream. For TCP/UDP I wrote it to be a no-op, but I can say that it affects any other connections that were cloned out? But I wonder if that might be a little weird too.
I think we need the system to treat it that way for consistency. Clearly, for a mux'ing protocol this is the obvious choice - but the application is not aware of the protocol below... so if it creates a group of TCP connections, with or without congestion control coupling, it will expect: that changing a connection property on one of the connections will affect the others (so that also must be implemented - because it WILL happen with a mux'ing protocol), that closing the group will close them all. Imagine an application getting QUIC once, and not getting it another time... surely we need a consistent behavior towards the app for both of these cases?
NAME sounds good, please check the updated text (or suggest text if you have further ideas!)
This is probably fine as is, but I suggested alternative phrasing which might be even more clear.Great, thanks!!LGTM with the updates, thanks!

should be immediately closed by sending a RST to the peer (ABORT.TCP). <ins> Calling "CloseGroup" on a TCP Connection (CLOSE.TCP) is identical to calling "Close" on this Connection and on all Connections in the same ConnectionGroup. Calling "AbortGroup" on a TCP Connection (ABORT.TCP) is identical to calling "Abort" on this Connection and on all Connections in the same ConnectionGroup. </ins> 10.2. Connectedness: Connected Calling "Abort" on a UDP Connection (ABORT.UDP(-Lite)) is identical to calling "Close".  <ins> Calling "CloseGroup" on a UDP Connection (ABORT.UDP(-Lite)) is identical to calling "Close" on this Connection and on all Connections in the same ConnectionGroup. Calling "AbortGroup" on a UDP Connection (ABORT.UDP(-Lite)) is identical to calling "Close" on this Connection and on all Connections in the same ConnectionGroup.  ## UDP-Lite </ins> Connectedness: Connectionless Coverage on Sending", "Required Minimum Corruption Protection Coverage for Receiving", and "Full Checksum Coverage on Receiving".  <ins> 10.4. </ins> Connectedness: Connectionless Calling "Abort" on a UDP Multicast Receive Connection (ABORT.UDP(- Lite)) is identical to calling "Close".  <ins> Calling "CloseGroup" on a UDP Multicast Receive Connection (ABORT.UDP(-Lite)) is identical to calling "Close" on this Connection and on all Connections in the same ConnectionGroup. Calling "AbortGroup" on a UDP Multicast Receive Connection (ABORT.UDP(-Lite)) is identical to calling "Close" on this Connection and on all Connections in the same ConnectionGroup. 10.5. </ins> Connectedness: Connected same SCTP assocation, and shutdown proceeds as described under "Close". <ins> CloseGroup: Calling "CloseGroup" calls CLOSE.SCTP, closing all Connections in the SCTP association. AbortGroup: Calling "AbortGroup" calls ABORT.SCTP, immediately closing all Connections in the SCTP association. </ins> 11. RFC-EDITOR: Please remove this section before publication.


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>  We also make use of the following basic types: an asynchronous interface using the Socket API generally uses a try- and-fail model.  If the application wants to read, but data has not yet been received from the peer, the call to read will fail.  The <del> application then waits and can try again later.  In contrast to the Socket API, all interaction using the Transport Services API is expected to be asynchronous and use an event-driven model (see events).  For example, an application first issues a call to receive new data from the connection.  When delivered data becomes available, this data is delivered to the application using asynchronous events that contain the data.  Error handling is also asynchronous; a failure to send data results in an asynchronous error event. </del>  This API also delivers events regarding the lifetime of a connection and changes in the available network links, which were not previously

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

they are equivalent to Actions on a per-application global context. Events are sent to the application or application-supplied code (e.g.  <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: an asynchronous interface using the Socket API generally uses a try- and-fail model.  If the application wants to read, but data has not yet been received from the peer, the call to read will fail.  The  <ins> application then waits and can try again later. In contrast to the Socket API, all interaction using the Transport Services API is expected to be asynchronous.  The API is defined around an event-driven model (see events) in order to model this asynchronous interaction, though other forms of asynchronous communication may be available to applications depending on the platform implementing the interface. For example, an application first issues a call to receive new data from the connection.  When delivered data becomes available, this data is delivered to the application using asynchronous events that contain the data.  Error handling is also asynchronous; a failure to send data results in an asynchronous error event. </ins> This API also delivers events regarding the lifetime of a connection and changes in the available network links, which were not previously


the ability to associate deadlines with messages, for applications that care about timing; <del> the ability control reliability, which messages to retransmit when there is packet loss, and how best to make use of the data that arrived; </del>  the ability to automatically assign messages and connections to underlying transport connections to utilize multi-streaming and and System-implementation concepts, which are intended to be <del> internally used by aTransport Services implementation. </del>  The following diagram summarizes the top-level concepts in the architecture and how they relate to one another.

This pull requests fixes two minor typos in draft-ietf-taps-URL that I noticed during detailed reading of the draft.

the ability to associate deadlines with messages, for applications that care about timing;  <ins> the ability to control reliability, which messages to retransmit when there is packet loss, and how best to make use of the data that arrived; </ins> the ability to automatically assign messages and connections to underlying transport connections to utilize multi-streaming and and System-implementation concepts, which are intended to be  <ins> internally used by a Transport Services implementation. </ins> The following diagram summarizes the top-level concepts in the architecture and how they relate to one another.


endpoint, path (labeled here by interface), and protocol.  The above example can now be written more succinctly as: <del> When an implementation views this aggregate set of connection attempts as a single connection establishment, it only will use one of the leaf nodes to transfer data.  Thus, when a single leaf node becomes ready to use, then the entire connection attempt is ready to use by the application.  Another way to represent this is that every leaf node updates the state of its parent node when it becomes ready, until the trunk node of the tree is ready, which then notifies the application that the connection as a whole is ready to use. </del>  A connection establishment tree may be degenerate, and only have a single leaf node, such as a connection attempt to an IP address over

Raising this issue as part of my review of the the Implementation Draft. Quoting from Section 4.1 "Structuring Candidates as a Tree" ~ Feedback: While it is understood that "connection attempt" is here used to refer to a given node in the tree, rather than the actual (stateful) process of attempting to connect to the given endpoint (using the given parameters), it does not make for easy reading. Similarly, it is possible to grasp how an "aggregate set" can be "viewed" as "a single connection establishment", but the language could be clearer here as well. Couldn't an "attempt" that has succeeded and is "ready to use" be referred to differently? Couldn't "candidate" or "option" be substituted for "attempt" to improve readability? Proposal:
Seems quite close to me
Yes, I like this proposed text.

endpoint, path (labeled here by interface), and protocol.  The above example can now be written more succinctly as:  <ins> When an implementation is asked to establish a single connection, only one of the leaf nodes in the candidate set is needed to transfer data.  Thus, once a single leaf node becomes ready to use, then the connection establishment tree is considered ready.  One way to implement this is by having every leaf node update the state of its parent node when it becomes ready, until the trunk node of the tree is ready, which then notifies the application that the connection as a whole is ready to use. </ins> A connection establishment tree may be degenerate, and only have a single leaf node, such as a connection attempt to an IP address over


consider such a Protocol Stack to be established as soon as the Transport Services system has selected a path on which to send data. <del> However, if a peer is not reachable over the network using the connectionless protocol, or data cannot be exchanged for any other reason, the application may want to attempt using another candidate Protocol Stack.  The implementation should maintain the list of other candidate Protocol Stacks that were eligible to use. </del>  4.7. Message Framers are functions that define simple transformations between application Message data and raw transport protocol data.  A <del> Framer can encapsulate or encode outbound Messages, and decapsulate or decode inbound data into Messages. </del>  While many protocols can be represented as Message Framers, for the purposes of the Transport Services API, these are ways for

That change would have helped me understand what framers can do. It seems a bit out of sync with " A Framer can encapsulate or encode outbound Messages, and decapsulate or decode inbound data into Messages." which sounds like it'd preclude operations like processing received data (or whole messages) into connection object state without emitting a message again -- maybe that sentence could be extended along with it (if even just to include "for example" or "or modify the connection object").
NAME we've added some clarifying text in the message framer definition
Impl draft Section 4.5: Handling racing with "unconnected" protocols "In the case that the application signals that the initial Protocol Stack is failing for some reason and that another option should be attempted, the Connection can be updated to point to the next candidate Protocol Stack. This can be viewed as an application-driven form of Protocol Stack racing." How does the application indicate that? I don't think this is covered by the API draft? Also I would recommend to move this section as a subsection within 4.5. (Completing Establishment) or at least switch the order with the previous section (Establishing multiplexed connections) to get a better reading flow.
This may affect the API draft so we should conclude if the API draft needs to be updated. We do have the functionality in NEAT for racing with unconnected protocols so i think the text is based on that.
Change this to text about how a framer can be used to drive racing over UDP. We shouldn't have a special API for marking the current connection failed.
Action is to propose initial text and follow up at next interim.

consider such a Protocol Stack to be established as soon as the Transport Services system has selected a path on which to send data.  <ins> However, this can cause a problem if a specific peer is not reachable over the network using the connectionless protocol, or data cannot be exchanged with the peer for any other reason.  To mitigate this, an application can use a Message Framer message-framers on top of a connectionless protocol to only mark a specific connection attempt as ready when some data has been received, or after some application- level handshake has been performed. </ins> 4.7. Message Framers are functions that define simple transformations between application Message data and raw transport protocol data.  A  <ins> Framer can encapsulate or encode outbound Messages, decapsulate or decode inbound data into Messages, and implement parts of protocols that do not directly map to application Messages (such as protocol handshakes or preludes before Message exchange). </ins> While many protocols can be represented as Message Framers, for the purposes of the Transport Services API, these are ways for


convenience functions to simplify use of Selection Properties: see preference-conv for examples.  In addition, implementations MAY provide a mechanism to create TransportProperties objects that are <del> preconfigured for common use cases as outlined in property-profiles. </del>  Transport Properties for an established connection can be queried via the Connection object, as outlined in introspection. Local Endpoint sends a keep-alive packet to the Remote Endpoint. Adjusting this Property will only take effect when the underlying stack supports sending keep-alive packets.  Guidance on setting this <del> value for datagram transports is provided in RFC8085.  A value </del>  greater than the connection timeout (conn-timeout) or the enumerated value "Disabled" will disable the sending of keep-alive packets. characteristics and habits of the user of an application. Of course any communication over a network reveals usage <del> characteristics, as all packets, as well as their timing and size, are part of the network-visible wire image RFC8546.  However, the selection of a protocol and its configuration also impacts which </del>  information is visible, potentially in clear text, and which other entities can access it.  In most cases, information provided for protocol and path selection should not directly translate to

The guidance applies to any connectionless transport.
"Connection establishment is only a local operation for a Datagram transport (e.g., UDP(-Lite))": I think the criterion is not Datagram transports but "transports without a handshake" or "connectionless protocols" as it is used later in the document.
I wrote, and I suggest we use "connectionless protocols" explicitly mentioning examples of UDP and UDP-Lite when used as a transport without a handshake.
To whoever plans to address this: I checked occurrences of the word "datagram" in the architecture and API drafts, and I found (only) one sentence that needs fixing on similar grounds, I think, in the API draft: in Section 8.1.4 "Timeout for keep alive packets". Surely the guidance regarding this matter in the UDP usage RFC is related to the fact that UDP(-Lite) is connectionless, not that it's datagram based.
Starting to fix this.
LGTM

convenience functions to simplify use of Selection Properties: see preference-conv for examples.  In addition, implementations MAY provide a mechanism to create TransportProperties objects that are  <ins> preconfigured for common use cases, as outlined in property-profiles. </ins> Transport Properties for an established connection can be queried via the Connection object, as outlined in introspection. Local Endpoint sends a keep-alive packet to the Remote Endpoint. Adjusting this Property will only take effect when the underlying stack supports sending keep-alive packets.  Guidance on setting this  <ins> value for connection-less transports is provided in RFC8085.  A value </ins> greater than the connection timeout (conn-timeout) or the enumerated value "Disabled" will disable the sending of keep-alive packets. characteristics and habits of the user of an application. Of course any communication over a network reveals usage  <ins> characteristics, because all packets, as well as their timing and size, are part of the network-visible wire image RFC8546.  However, the selection of a protocol and its configuration also impacts which </ins> information is visible, potentially in clear text, and which other entities can access it.  In most cases, information provided for protocol and path selection should not directly translate to