jiebi/CodeConvo huggingface dataset:
Code change:
In Section 7.4.1 "Pre-Authorization" the spec says: If a CA wishes to allow pre-authorization within ACME, it can offer a "new authorization" resource in its directory by adding the field "newAuthz" with a URL for the new authorization resource. That text indicates that the CA may wish to not support pre-authorization in which case the "newAuthz" resource will not be present in the directory. One example of an ACME CA choosing to not support pre-authorization is Let's Encrypt. This commit clarifies the "newAuthz" field of the directory is optional in Section 7.1.1 "Directory" where a developer is likely to look to understand which resources must be supported/present in the directory and which are optional ("meta", "newAuthz"). If the server doesn't support pre-authorization it MUST omit the "newAuthz" field.

Related discussion:
text: a host which only functions as an ACME server could place the directory under the path "/". <ins> If the ACME server does not implement pre-authorization (Section 7.4.1) it MUST omit the "newAuthz" field of the directory. </ins> The object MAY additionally contain a field "meta".  If present, it MUST be a JSON object; each field in the object is an item of metadata relating to the service provided by the ACME server.
Code change:
In addition to adding the error, as proposed in , this PR fixes some issues discussed in the F2F meeting, namely moving ACME URNs under the IETF parameters space, and having errors be a sub-namespace of an overall ACME namespace.

Related discussion:
text: 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 <del> "urn:acme:" namespace): </del> <ins> "urn:ietf:params:acme:error:" namespace): This list is not exhaustive.  The server MAY return errors whose "type" field is set to a URI other than those defined above.  Servers MUST NOT use the ACME URN namespace for errors other than the standard types.  Clients SHOULD display the "detail" field of such errors. </ins> Authorization and challenge objects can also contain error information to indicate why the server was unable to validate
Code change:
URL
Thanks NAME On Sat, Sep 15, 2018 at 08:51:55PM -0500, Benjamin Kaduk wrote: My apologies if I missed it when it went by, but did we ever hear more about this requirement from the proponents of externalAccountBinding? Thanks, Benjamin

Related discussion:
text: The inner JWS MUST have the same "url" header parameter as the outer JWS. <del> The inner JWS MAY omit the "nonce" header parameter.  The server MUST ignore any value provided for the "nonce" header parameter. </del> <ins> The inner JWS MUST omit the "nonce" header parameter. </ins> This transaction has signatures from both the old and new keys so that the server can verify that the holders of the two keys both
Code change:
Some grammar fixes POST-as-GETs should be indicated as having a signature in flow Specify that the JWS profile we define in Section 6.2 is for ACME request bodies, to distinuish it from the profile used for External Account Binding. They have incompatible requirements: MUST NOT use MAC vs MUST use MAC. Clarify that Replay-Nonce is an HTTP header field since it's defined near JWS header parameters. Don't include "wildcard": false in examples. Section 7.1.4 requires that it MUST be absent when false. There was lingering language in the Section 7.5.1 about "updating" an authorization body in response to fields in a challenge POST. Since the challenge POST is now described explicitly as "an empty JSON body", this language didn't make sense. Fixed.
Per offline review, I added back in a sentence that contained a MUST:

Related discussion:
text: Cut and paste the CSR into a CA's web page. <del> Prove ownership of the domain by one of the following methods: </del> <ins> Prove ownership of the domain(s) in the CSR by one of the following methods: </ins> Put a CA-provided challenge at a specific place on the web server.
Code change:
Some grammar fixes POST-as-GETs should be indicated as having a signature in flow Specify that the JWS profile we define in Section 6.2 is for ACME request bodies, to distinuish it from the profile used for External Account Binding. They have incompatible requirements: MUST NOT use MAC vs MUST use MAC. Clarify that Replay-Nonce is an HTTP header field since it's defined near JWS header parameters. Don't include "wildcard": false in examples. Section 7.1.4 requires that it MUST be absent when false. There was lingering language in the Section 7.5.1 about "updating" an authorization body in response to fields in a challenge POST. Since the challenge POST is now described explicitly as "an empty JSON body", this language didn't make sense. Fixed.
Per offline review, I added back in a sentence that contained a MUST:

Related discussion:
text: The CA verifies that the client controls the requested domain name(s) by having the ACME client perform some action(s) that can only be done with control of the domain name(s).  For example, the <del> CA might require a client requesting example.com to provision DNS record under example.com or an HTTP resource under </del> <ins> CA might require a client requesting example.com to provision a DNS record under example.com or an HTTP resource under </ins> http://example.com. Once the CA is satisfied, it issues the certificate and the ACME
Code change:
Some grammar fixes POST-as-GETs should be indicated as having a signature in flow Specify that the JWS profile we define in Section 6.2 is for ACME request bodies, to distinuish it from the profile used for External Account Binding. They have incompatible requirements: MUST NOT use MAC vs MUST use MAC. Clarify that Replay-Nonce is an HTTP header field since it's defined near JWS header parameters. Don't include "wildcard": false in examples. Section 7.1.4 requires that it MUST be absent when false. There was lingering language in the Section 7.5.1 about "updating" an authorization body in response to fields in a challenge POST. Since the challenge POST is now described explicitly as "an empty JSON body", this language didn't make sense. Fixed.
Per offline review, I added back in a sentence that contained a MUST:

Related discussion:
text: MUST verify the JWS before processing the request.  Encapsulating request bodies in JWS provides authentication of requests. <del> JWS objects sent in ACME requests MUST meet the following additional criteria: </del> <ins> A JWS object sent as the body of an ACME request MUST meet the following additional criteria: </ins> The JWS MUST be in the Flattened JSON Serialization
Code change:
Some grammar fixes POST-as-GETs should be indicated as having a signature in flow Specify that the JWS profile we define in Section 6.2 is for ACME request bodies, to distinuish it from the profile used for External Account Binding. They have incompatible requirements: MUST NOT use MAC vs MUST use MAC. Clarify that Replay-Nonce is an HTTP header field since it's defined near JWS header parameters. Don't include "wildcard": false in examples. Section 7.1.4 requires that it MUST be absent when false. There was lingering language in the Section 7.5.1 about "updating" an authorization body in response to fields in a challenge POST. Since the challenge POST is now described explicitly as "an empty JSON body", this language didn't make sense. Fixed.
Per offline review, I added back in a sentence that contained a MUST:

Related discussion:
text: 6.5.1. <del> The Replay-Nonce header field includes a server-generated value that the server can use to detect unauthorized replay in future client requests.  The server MUST generate the value provided in Replay- Nonce in such a way that they are unique to each message, with high probability, and unpredictable to anyone besides the server.  For instance, it is acceptable to generate Replay-Nonces randomly. </del> <ins> The Replay-Nonce HTTP header field includes a server-generated value that the server can use to detect unauthorized replay in future client requests.  The server MUST generate the values provided in Replay-Nonce header fields in such a way that they are unique to each message, with high probability, and unpredictable to anyone besides the server.  For instance, it is acceptable to generate Replay-Nonces randomly. </ins> <del> The value of the Replay-Nonce field MUST be an octet string encoded according to the base64url encoding described in Section 2 of </del> <ins> The value of the Replay-Nonce header field MUST be an octet string encoded according to the base64url encoding described in Section 2 of </ins> RFC7515.  Clients MUST ignore invalid Replay-Nonce values.  The ABNF RFC5234 for the Replay-Nonce header field follows:
Code change:
Some grammar fixes POST-as-GETs should be indicated as having a signature in flow Specify that the JWS profile we define in Section 6.2 is for ACME request bodies, to distinuish it from the profile used for External Account Binding. They have incompatible requirements: MUST NOT use MAC vs MUST use MAC. Clarify that Replay-Nonce is an HTTP header field since it's defined near JWS header parameters. Don't include "wildcard": false in examples. Section 7.1.4 requires that it MUST be absent when false. There was lingering language in the Section 7.5.1 about "updating" an authorization body in response to fields in a challenge POST. Since the challenge POST is now described explicitly as "an empty JSON body", this language didn't make sense. Fixed.
Per offline review, I added back in a sentence that contained a MUST:

Related discussion:
text: signed with the requested new account key.  This "inner" JWS becomes the payload for the "outer" JWS that is the body of the ACME request. <del> The outer JWS MUST meet the normal requirements for an ACME JWS (see request-authentication).  The inner JWS MUST meet the normal requirements, with the following differences: </del> <ins> The outer JWS MUST meet the normal requirements for an ACME JWS request body (see request-authentication).  The inner JWS MUST meet the normal requirements, with the following differences: </ins> The inner JWS MUST have a "jwk" header parameter, containing the public key of the new key pair.
Code change:
Some grammar fixes POST-as-GETs should be indicated as having a signature in flow Specify that the JWS profile we define in Section 6.2 is for ACME request bodies, to distinuish it from the profile used for External Account Binding. They have incompatible requirements: MUST NOT use MAC vs MUST use MAC. Clarify that Replay-Nonce is an HTTP header field since it's defined near JWS header parameters. Don't include "wildcard": false in examples. Section 7.1.4 requires that it MUST be absent when false. There was lingering language in the Section 7.5.1 about "updating" an authorization body in response to fields in a challenge POST. Since the challenge POST is now described explicitly as "an empty JSON body", this language didn't make sense. Fixed.
Per offline review, I added back in a sentence that contained a MUST:

Related discussion:
text: old key.  The "outer" JWS represents the current account holder's assent to this request. <del> On receiving keyChange request, the server MUST perform the following steps in addition to the typical JWS validation: </del> <ins> On receiving a keyChange request, the server MUST perform the following steps in addition to the typical JWS validation: </ins> Validate the POST request belongs to a currently active account, as described in message-transport.
Code change:
Some grammar fixes POST-as-GETs should be indicated as having a signature in flow Specify that the JWS profile we define in Section 6.2 is for ACME request bodies, to distinuish it from the profile used for External Account Binding. They have incompatible requirements: MUST NOT use MAC vs MUST use MAC. Clarify that Replay-Nonce is an HTTP header field since it's defined near JWS header parameters. Don't include "wildcard": false in examples. Section 7.1.4 requires that it MUST be absent when false. There was lingering language in the Section 7.5.1 about "updating" an authorization body in response to fields in a challenge POST. Since the challenge POST is now described explicitly as "an empty JSON body", this language didn't make sense. Fixed.
Per offline review, I added back in a sentence that contained a MUST:

Related discussion:
text: That the client controls the identifier in question. <del> This process may be repeated to associate multiple identifiers to a key pair (e.g., to request certificates with multiple identifiers) or to associate multiple accounts with an identifier (e.g., to allow </del> <ins> This process may be repeated to associate multiple identifiers with an account (e.g., to request certificates with multiple identifiers) or to associate multiple accounts with an identifier (e.g., to allow </ins> multiple entities to manage certificates). Authorization resources are created by the server in response to <del> certificate orders or authorization requests submitted by an account key holder; their URLs are provided to the client in the responses to </del> <ins> newOrder or newAuthorization requests submitted by an account key holder; their URLs are provided to the client in the responses to </ins> these requests.  The authorization object is implicitly tied to the account key used to sign the request. <del> When a client receives an order from the server in reply to a new order request, it downloads the authorization resources by sending </del> <ins> When a client receives an order from the server in reply to a newOrder request, it downloads the authorization resources by sending </ins> POST-as-GET requests to the indicated URLs.  If the client initiates authorization using a request to the newAuthz resource, it will have already received the pending authorization object in the response to
Code change:
Some grammar fixes POST-as-GETs should be indicated as having a signature in flow Specify that the JWS profile we define in Section 6.2 is for ACME request bodies, to distinuish it from the profile used for External Account Binding. They have incompatible requirements: MUST NOT use MAC vs MUST use MAC. Clarify that Replay-Nonce is an HTTP header field since it's defined near JWS header parameters. Don't include "wildcard": false in examples. Section 7.1.4 requires that it MUST be absent when false. There was lingering language in the Section 7.5.1 about "updating" an authorization body in response to fields in a challenge POST. Since the challenge POST is now described explicitly as "an empty JSON body", this language didn't make sense. Fixed.
Per offline review, I added back in a sentence that contained a MUST:

Related discussion:
text: representation of the challenge with the response object provided by the client.  The server MUST ignore any fields in the response object that are not specified as response fields for this type of challenge. <del> The server provides a 200 (OK) response with the updated challenge object as its body. </del> <ins> Note that the challenges in this document do not define any response fields, but future specifications might define them.  The server provides a 200 (OK) response with the updated challenge object as its body. </ins> If the client's response is invalid for any reason or does not provide the server with appropriate information to validate the
Code change:
Included in the text. Maybe will include further text for
In 5.5.1: This kind of suggests that an Agent may also not know the serial number. But in creating the agent-signed-data, this number is required later on. Could we clarify perhaps the Agent MUST know the serial-number; e.g. in one of these ways: configured (as in quoted text above) discovered (in "standard" way using mDNS / DNS-SD first part of service instance name) discovered (in vendor-specific way e.g. RF beacons) other (in vendor-specific way, e.g. scan QR code of packaging) - maybe that's the same as category 1 from the Agent point of view.
Additional Note: figure 4 doesn't show the part where the Agent discovers the serial number of the Pledge. This was adding to the confusion. Maybe figure 4 can stay as is; this is just to clarify that at the start of Fig 4 the Agent MUST know the serial-number. So some small link is missing to get the complete picture.
I reopened as the initial point if the registrar-agent MUST know the serial number is not solved by the QR code reference. As the registrar-agent needs to know, which pledges he is bootstrapping, he needs the list of serial numbers in advance to be able to construct the agent signed data. Text proposed will be included into the pre-conditions described in section 5.5.1, In addition, the registrar-agent MUST know the product-serial-number(s) of the pledge(s) to be bootstrapped. The registrar-agent MAY be provided with the product-serial-number in different ways: configured, e.g., as a list of pledges to be bootstrapped via QR code scanning discovered by using standard approaches like mDNS as described in 5.4.2. discovered by using a vendor specific approach, e.g., RF beacons
Ok

Related discussion:
text: This is necessary to allow the discovery of pledges by the registrar- agent using mDNS.  The list may be provided by administrative means or the registrar agent may get the information via an interaction <del> with the pledge, like scanning of product-serial-number information using a QR code or similar. </del> <ins> with the pledge.  For instance, RFC9238 describes scanning of a QR code, the product-serial-number would be initialized from the 12N B005 Product Serial Number. </ins> According to RFC8995 section 5.3, the domain registrar performs the pledge authorization for bootstrapping within his domain based on the
Code change:
It seems blindingly obvious to me that an implementation would need to take care of this... and this note of caution seems quite appropriate (if unnecessary... but surely it doesn't hurt).
Dynamic framer add and passthrough (last two paragraphs of section 6.1) assume synchronous operation; what happens to bytes in the send/receive buffers when the framer stack changes? There either needs to be an explicit mutex here (allowing the framer/implementation to lock the buffers at the exact point the framer change happens, not allowing any bytes to be processed while the dynamic framer decision is made), or some way to annotate in a buffer the replay point after which a dynamic reframing is necessary. Are we going to leave this up to implementors to figure out, or should we point out that here be dragons?
We should clarify that these operations within the data path of the stack should be synchronized.

Related discussion:
text: the main Connection implementation that delivers events to the custom framer implementation whenever data is ready to be parsed or framed. <ins> The Transport Services implementation needs to ensure that all of the events and actions taken on a Message Framer are synchronized to ensure consistent behavior.  For example, some of the actions defined below (such as PrependFramer and StartPassthrough) modify how data flows in a protocol stack, and require synchronization with sending and parsing data in the Message Framer. </ins> When a Connection establishment attempt begins, an event can be delivered to notify the framer implementation that a new Connection is being created.  Similarly, a stop event can be delivered when a
Code change:
SORRY I made a PR on your PR, when I meant to leave a review comment, see 1024. .... Silly to make a PR on a PR - I added a review comment instead...
In section 4.1.4 in the impl draft, we have: "The order of operations for branching, where lower numbers are acted upon first, should be: Alternate Paths Protocol Options Derived Endpoints" However, I would say there is not really a strict ordering required. The text actually indicates that selection of the protocol is rather independent while there is usually a dependency between the interface and derived endpoint. I think this is related to my other issue about the use of the term path, because a path consists of both the local and remote endpoint and therefore there is of course a dependency. So in summary I'm not sure how useful I find this whole section as currently written...
We should conclude if anything more is needed here besides cleaning up the terminology, where Alternate Paths is not a good term - see .
Any implementation should have a consistent order of operations. This is a recommended example. Reference the arch text that says it needs to work the same way each time.
Reference ICE/HE

Related discussion:
text: 4.1.2. <del> Branch types must occur in a specific order relative to one another to avoid creating leaf nodes with invalid or incompatible settings. In the example above, it would be invalid to branch for derived endpoints (the DNS results for www.example.com) before branching between interface paths, since there are situations when the results will be different across networks due to private names or different supported IP versions.  Implementations must be careful to branch in an order that results in usable leaf nodes whenever there are multiple branch types that could be used from a single node. The order of operations for branching should be: Alternate Paths </del> <ins> Branch types ought to occur in a specific order relative to one another to avoid creating leaf nodes with invalid or incompatible settings.  In the example above, it would be invalid to branch for derived endpoints (the DNS results for www.example.com) before branching between interface paths, since there are situations when the results will be different across networks due to private names or different supported IP versions.  Implementations need to be careful to branch in a consistent order that results in usable leaf nodes whenever there are multiple branch types that could be used from a single node. This document recommends the following order of operations for branching: Network Paths </ins> Protocol Options
Code change:
Appendix B.1 lists two properties as "under discussion": Bounds on Send or Receive Rate: (PR 1036 fixes the name): this is no longer under discussion, these properties exist. Cost Preferences: this is no longer under discussion, I suppose?? We don't have this in the interface draft. So I have the impression that this should no longer be an appendix, the text on Cost Preferences should be removed, and the text on Bounds on Send and Receive Rate should be moved elsewhere, and not be mentioned as "under discussion".
LGMT

Related discussion:
text: highest available capacity, based on the observed maximum throughput. <ins> As another example, branch sorting can also be influenced by bounds on the Send or Receive rate (Selection Properties "minSendRate" / "minRecvRate" / "maxSendRate" / "maxRecvRate"): if the application indicates a bound on the expected Send or Receive bitrate, an implementation may prefer a path that can likely provide the desired bandwidth, based on cached maximum throughput, see performance- caches.  The application may know the Send or Receive Bitrate from metadata in adaptive HTTP streaming, such as MPEG-DASH. </ins> Implementations process the Properties (Section 6.2 of I-D.ietf-taps- interface) in the following order: Prohibit, Require, Prefer, Avoid. If Selection Properties contain any prohibited properties, the