jiebi/TextFlow huggingface dataset:
Original text:
anchors.  Clients can fetch these alternates and use their own heuristics to decide which is optimal. <del> An ACME client MAY attempt to fetch the certificate with a GET request.  If the server does not allow GET requests for certificate resources, then it will return an error as described in post-as-get. On receiving such an error, the client SHOULD fall back to a POST-as- GET request. </del> A certificate resource represents a single, immutable certificate. If the client wishes to obtain a renewed certificate, the client initiates a new order process to request one.

Reviewer comments:
Thanks to Felipe Gasper for .
Merging despite spurious CI failure, since it seems pretty clear that the CI failure is spurious. Hi all, Draft 16 has this: An ACME client MAY attempt to fetch the certificate with a GET request. If the server does not allow GET requests for certificate resources, then it will return an error as described in Section 6.3 . On receiving such an error, the client SHOULD fall back to a POST-as- GET request. From what I can discern from this list’s most recent posts on the topic, I’m under the impression that plain GET for certificates is not to be part of the principal ACME spec; should the above, then, be removed? -FG

Revised text:
anchors.  Clients can fetch these alternates and use their own heuristics to decide which is optimal.  A certificate resource represents a single, immutable certificate. If the client wishes to obtain a renewed certificate, the client initiates a new order process to request one.
Original text:
with an array of supported "alg" values.  See errors for more details on the structure of error responses.  Because client requests in ACME carry JWS objects in the Flattened JSON Serialization, they must have the Content-Type header field set to "application/jose+json".  If a request does not meet this

Reviewer comments:
NAME Sure. I've just posted this: URL
LGTMThe bullet points improve readability quite a bit, thanks NAME !also not purely editorial, but okay. I realize it's very late for making non-editorial changes to draft-ietf-acme-acme, but I'd like to propose adding a new badPublicKey error. This error would be returned by the server whenever it does not support, or wishes to reject, a "jwk" public key supplied in a client's request. Proposed text: URL The 'array of supported "alg" values' in a badSignatureAlgorithm response is useful, but ISTM that it doesn't provide detailed enough information to assist a client in generating a suitable public key. (If the consensus is that it's too late to add a new error type, then my alternative proposal will be to use "malformed" instead of adding "badPublicKey", but keep the rest of PR 478 as is; I think it's a good idea to call out the need for a server to sanity check each client-supplied public key). Rob Stradling Senior Research & Development Scientist Sectigo Limited

Revised text:
with an array of supported "alg" values.  See errors for more details on the structure of error responses. <ins> If the server supports the signature algorithm "alg" but either does not support or chooses to reject the public key "jwk", then the server MUST return an error with status code 400 (Bad Request) and type "urn:ietf:params:acme:error:badPublicKey".  The problem document detail SHOULD describe the reason for rejecting the public key; some example reasons are: "alg" is "RS256" but the modulus "n" is too small (e.g., 512-bit) "alg" is "ES256" but "jwk" does not contain a valid P-256 public key "alg" is "EdDSA" and "crv" is "Ed448", but the server only supports "EdDSA" with "Ed25519" the corresponding private key is known to have been compromised </ins> Because client requests in ACME carry JWS objects in the Flattened JSON Serialization, they must have the Content-Type header field set to "application/jose+json".  If a request does not meet this
Original text:
process can be represented and performed by Internet protocols with no out-of-band human intervention. <del> When an operator deploys a current HTTPS server, it generally prompts him to generate a self-signed certificate.  When an operator deploys an ACME-compatible web server, the experience would be something like this: </del>  The ACME client prompts the operator for the intended domain name(s) that the web server is to stand for.

Reviewer comments:
Avoid changing the "him" in the MitM paragraph, because of the inherent notion of a Man in the Middle, which is a larger discussion.
LGTM. Thanks for the elegant fix.

Revised text:
process can be represented and performed by Internet protocols with no out-of-band human intervention.  <ins> When deploying a current HTTPS server, an operator generally gets a prompt to generate a self-signed certificate.  When an operator deploys an ACME-compatible web server, the experience would be something like this: </ins> The ACME client prompts the operator for the intended domain name(s) that the web server is to stand for.
Original text:
certificate was issued, and one with relation "author" to indicate the registration under which this certificate was issued. <del> The server MAY include an Expires header as a hint to the client about when to renew the certificate.  (Of course, the real expiration of the certificate is controlled by the notAfter time in the certificate itself.) </del> If the CA participates in Certificate Transparency (CT) RFC6962, then they may want to provide the client with a Signed Certificate Timestamp (SCT) that can be used to prove that a certificate was

Reviewer comments:
For discussion.
See also: URL
I proposed on the mailing list to remove implicit renewal some time ago, and it received some support. Creating this issue to track it. All discussion should be done on the mailing list.

Revised text:
certificate was issued, and one with relation "author" to indicate the registration under which this certificate was issued.  If the CA participates in Certificate Transparency (CT) RFC6962, then they may want to provide the client with a Signed Certificate Timestamp (SCT) that can be used to prove that a certificate was
Original text:
for a certificate using a Link relation header field with relation "ct-sct". <del> A certificate resource always represents the most recent certificate issued for the name/key binding expressed in the CSR.  If the CA allows a certificate to be renewed, then it publishes renewed versions of the certificate through the same certificate URI. Clients retrieve renewed versions of the certificate using a GET query to the certificate URI, which the server should then return in a 200 (OK) response.  The server SHOULD provide a stable URI for each specific certificate in the Content-Location header field, as shown above.  Requests to stable certificate URIs MUST always result in the same certificate. To avoid unnecessary renewals, the CA may choose not to issue a renewed certificate until it receives such a request (if it even allows renewal at all).  In such cases, if the CA requires some time to generate the new certificate, the CA MUST return a 202 (Accepted) response, with a Retry-After header field that indicates when the new certificate will be available.  The CA MAY include the current (non- renewed) certificate as the body of the response. Likewise, in order to prevent unnecessary renewal due to queries by parties other than the account key holder, certificate URIs should be structured as capability URLs W3C.WD-capability-urls-20140218. From the client's perspective, there is no difference between a certificate URI that allows renewal and one that does not.  If the client wishes to obtain a renewed certificate, and a GET request to the certificate URI does not yield one, then the client may initiate a new-certificate transaction to request one. </del>  6.6.

Reviewer comments:
For discussion.
See also: URL
I proposed on the mailing list to remove implicit renewal some time ago, and it received some support. Creating this issue to track it. All discussion should be done on the mailing list.

Revised text:
for a certificate using a Link relation header field with relation "ct-sct".  <ins> A certificate resource represents a single, immutable certificate. If the client wishes to obtain a renewed certificate, the client initiates a new-certificate transaction to request one. Because certificate resources are immutable once issuance is complete, the server MAY enable the caching of the resource by adding Expires and Cache-Control headers specifying a point in time in the distant future.  These headers have no relation to the certificate's period of validity. </ins> 6.6.
Original text:
In addition, the client MAY advise the server at which IP the challenge is provisioned: <del> 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. </del>  On receiving a response, the server MUST verify that the key authorization in the response matches the "token" value in the

Reviewer comments:
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.

Revised text:
In addition, the client MAY advise the server at which IP the challenge is provisioned:  <ins> An IPv4 or IPv6 address which, in dotted decimal form or RFC4291 form, respectively.  If given, this address MUST be included in the set of IP addresses to which the domain name resolves.  If given, the server SHOULD 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. </ins> On receiving a response, the server MUST verify that the key authorization in the response matches the "token" value in the
Original text:
IANA is requested to register the following Service Names:  8. 8.1.

Reviewer comments:
(n.b., i was not able to "make" and test the change, due to external pyang dependencies of some form.

Revised text:
IANA is requested to register the following Service Names: <ins> 7.5. The IANA is requested to list the name "masa" in the MUD extensions registry defined in I-D.ietf-opsawg-mud.  Its use is documented in mud-extension. </ins> 8. 8.1.
Original text:
"Connection Priority" on one Connection does not change it on the other Connections in the same Connection Group.  Message Properties set on a Connection also apply only to that Connection.

Reviewer comments:
Does this make sense outside of a protocol-specific context? I am aware that this is a different can of worms adding protocol specific parameters to clone, but this looks like a strange concept to add an Integer here that may have different side effects in QUIC and SCTP…
That's a very good question. This feature request came up in the QuIC mapping part of the discussion in Vienna, see: URL Not sure what to do: keep it as it is, remove it, or add the protocol: assign: "if protocol = x, then stream ID = y" read: "stream ID is y, and your protocol is x" I have to say, I don't like this particular way, as it would complicate matters quite a bit. But how else to do it?
All of the multistreaming protocols we know about have an integer stream identifier. I suppose a future protocol could use some sort of binary blob for identifying streams (which are... pedantically... representable as arbitrary-length integers)
Interim discussion: let's make Clone() and Initiate() take a group of protocol-specific parameters (optionally) which allow protocols like QUIC and SCTP to extend this.
I just made a very minimalist update, where "protocolSpecificProperties" is only a parameter of Clone(). Why not list it as readable properties, and why not as a parameter of Initiate, as we discussed? What's the point of saying "there can be protocol-specific properties which are currently not defined, and they can be readable"? This is for a future spec to say, when it proposes a new transport property. Regarding Initiate(), I think this should in fact not be a parameter to the Initiate Action itself, but a transport property to be supplied when creating a Preconnection. Again, this made me find that I would only write something like "There can also be transport properties that are not yet defined", which doesn't seem to be useful text. In conclusion, I found that only the Clone() Action needs this as a new parameter. Everything else is for future mapping documents. Thoughts?
Many thanks! I incorporated your suggestion, and made a tiny edit to it (behaviour => behavior, underlaying => underlying, and "stream or connection" instead of "stream/connection").
... combined with "if the transport is mux'ing, else ..."
Thanks – I guess we have a fairly good solution.

Revised text:
"Connection Priority" on one Connection does not change it on the other Connections in the same Connection Group. <ins> The optional "connectionProperties" parameter allows passing Transport Properties that control the behavior of the underlying stream or connection to be created, e.g., protocol-specific properties to request specific stream IDs for SCTP or QUIC. </ins> Message Properties set on a Connection also apply only to that Connection.
Original text:
Data Unit: Datagram The Transport Services API mappings for UDP-Lite are identical to <del> UDP.  Properties that require checksum coverage are not supported by UDP-Lite, such as "msgChecksumLen", "fullChecksumSend", "recvChecksumLen", and "fullChecksumRecv". </del>  10.5.

Reviewer comments:
Initially I thought the description for UDP-Lite was incomplete, but mapping back to the details of the API draft I realized it was incorrect. UDP-Lite supports the msgChecksumLen and recvChecksumLen properties. The API for theses primitives is a bit messy. As specified I think it means the following: UDP can use them to set full coverage or no checksum using the special value of 0. UDP-Lite can use them to set full coverage or a partial coverage. Setting the checksum to only cover the header, although supported by UDP-Lite, will not be possible as 0 is a special value. The special value of 0 can not be used by UDP-Lite, but I left this detail out of the pull request as I thought it got very detailed. It can be added if you think it is needed.

Revised text:
Data Unit: Datagram The Transport Services API mappings for UDP-Lite are identical to  <ins> UDP.  In addition, UDP-Lite supports the "msgChecksumLen" and "recvChecksumLen" Properties that allow an application to specify the minimum number of bytes in a message that need to be covered by a checksum. </ins> 10.5.
Original text:
of efficiency.  This is not a strict requirement.  The default is to not have this option. <del> Notification of special errors (excessive retransmissions, ICMP error message arrival): This boolean property specifies whether an application considers it useful to be informed in case sent data was retransmitted more often than a certain threshold, or when an ICMP error message arrives.  This property applies to Connections and Connection Groups.  This is not a strict requirement.  The default is to have this option. </del>  Control checksum coverage on sending or receiving: This boolean property specifies whether the application considers it useful to

Reviewer comments:
What makes these errors "special"? It seems a strange term to use, and the meaning is unclear.
I didn't write this, but I think it was an effort to lump together, from minset, two quite different types of errors: 1) notification of excessive retransmissions; 2) notification of icmp error message arrival. Any suggestions for a common term?
If it's just those two types of errors, we can probably just list them...
URL is what I did in minset :)
so the suggestion is to split these out into two protocol selection properties?
yes, I think so
all right then, see
lgtm

Revised text:
of efficiency.  This is not a strict requirement.  The default is to not have this option.  <ins> Notification of excessive retransmissions: This boolean property specifies whether an application considers it useful to be informed in case sent data was retransmitted more often than a certain threshold.  This property applies to Connections and Connection Groups.  This is not a strict requirement.  The default is to have this option. Notification of ICMP error message arrival: This boolean property specifies whether an application considers it useful to be informed when an ICMP error message arrives.  This property applies to Connections and Connection Groups.  This is not a strict requirement.  The default is to have this option. </ins> Control checksum coverage on sending or receiving: This boolean property specifies whether the application considers it useful to
Original text:
Boolean <del> If true, it specifies that a Message should be delivered to the other side after the previous Message which was passed to the same Connection via the Send Action.  If false, the Message may be delivered out of order.  This property is used for protocols that support preservation of data ordering, see prop-ordering, but allow out-of-order delivery for certain messages. </del>  7.3.4.

Reviewer comments:
I didn't like something about reliability (let's not throw an error when we can't be UNreliable, only when we can't be reliable). I updated the text on ordering a bit, to say that the Property is ignored for the first Message on a Connection, and rephrased it slightly to talk about the receiver-side transport system and the receiving application - before, the text might have talked about a sender-side behavior. I added a TODO DISCUSS comment about per-message Niceness.
Fine with me, maybe fix minor knitThanks, all good now I think.

Revised text:
Boolean  <ins> If true, it specifies that the receiver-side transport protocol stack only deliver the Message to the receiving application after the previous ordered Message which was passed to the same Connection via the Send Action, when such a Message exists.  If false, the Message may be delivered to the receiving application out of order.  This property is used for protocols that support preservation of data ordering, see prop-ordering, but allow out-of-order delivery for certain messages. </ins> 7.3.4.
Original text:
This property specifies that a message should be sent in such a way that the transport protocol ensures all data is received on the other side without corruption.  Changing the 'Reliable Data Transfer' <del> property on Messages is only possible if the transport protocol supports partial reliability (see prop-partially-reliable). Therefore, for protocols that always transfer data reliably, this property is always true and for protocols that always transfer data unreliably, this property is always false.  Changing it may generate an error. </del>  7.3.8.

Reviewer comments:
I didn't like something about reliability (let's not throw an error when we can't be UNreliable, only when we can't be reliable). I updated the text on ordering a bit, to say that the Property is ignored for the first Message on a Connection, and rephrased it slightly to talk about the receiver-side transport system and the receiving application - before, the text might have talked about a sender-side behavior. I added a TODO DISCUSS comment about per-message Niceness.
Fine with me, maybe fix minor knitThanks, all good now I think.

Revised text:
This property specifies that a message should be sent in such a way that the transport protocol ensures all data is received on the other side without corruption.  Changing the 'Reliable Data Transfer'  <ins> property on Messages is only possible if the Connection supports reliability.  When this is not the case, changing it will generate an error. </ins> 7.3.8.
Original text:
Preconnection, Connection (read only) <del> This property specifies whether the application wishes to use a </del>  transport protocol that ensures that all data is received on the other side without corruption.  This also entails being notified when a Connection is closed or aborted.  The default is to enable Reliable

Reviewer comments:
I didn't like something about reliability (let's not throw an error when we can't be UNreliable, only when we can't be reliable). I updated the text on ordering a bit, to say that the Property is ignored for the first Message on a Connection, and rephrased it slightly to talk about the receiver-side transport system and the receiving application - before, the text might have talked about a sender-side behavior. I added a TODO DISCUSS comment about per-message Niceness.
Fine with me, maybe fix minor knitThanks, all good now I think.

Revised text:
Preconnection, Connection (read only)  <ins> This property specifies whether the application needs to use a </ins> transport protocol that ensures that all data is received on the other side without corruption.  This also entails being notified when a Connection is closed or aborted.  The default is to enable Reliable
Original text:
12.3.22.  Integer Message Property - see msg-niceness. Note that this property is not a per-message override of the connection Niceness - see conn-niceness.  Both Niceness properties <del> may interact, but can be used indepentendly and be realized by </del>  different mechanisms. 12.3.23.

Reviewer comments:
I didn't like something about reliability (let's not throw an error when we can't be UNreliable, only when we can't be reliable). I updated the text on ordering a bit, to say that the Property is ignored for the first Message on a Connection, and rephrased it slightly to talk about the receiver-side transport system and the receiving application - before, the text might have talked about a sender-side behavior. I added a TODO DISCUSS comment about per-message Niceness.
Fine with me, maybe fix minor knitThanks, all good now I think.

Revised text:
12.3.22. <ins> [TODO: Discuss: should we remove this?  Whether we need this or the other depends on how we want to implement multi-streaming.  We don't need both, so we should make a decision.] </ins> Integer Message Property - see msg-niceness. Note that this property is not a per-message override of the connection Niceness - see conn-niceness.  Both Niceness properties  <ins> may interact, but can be used independently and be realized by </ins> different mechanisms. 12.3.23.
Original text:
as an asynchronous interface, they generally use 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 application <del> then waits for a notification to indicate when it can try again. </del>  All interaction with a Transport Services system is expected to be asynchronous, and use an event-driven model unlike sockets events.

Reviewer comments:
I guess here is not nessecarily a notification required in sychronuous communication
Merged in master to avoid conflict, and tweaked working to remove "some times", which felt a bit too colloquial in tone.

Revised text:
as an asynchronous interface, they generally use 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 application  <ins> then waits and can try again later. </ins> All interaction with a Transport Services system is expected to be asynchronous, and use an event-driven model unlike sockets events.