Change:
Several comprehensibility improvements to the first three sections of the draft RFC. For clarity about the contents of this pull request, please consider using the option (git CLI) or the "rich diff" option (GitHub web interface) to evaluate it, in preference to a traditional line-based diff.
NAME - I think these changes are valuable. Thank you! I don't personally have any qualms/feedback having read through the diff but it would help get more eyes on this if you emailed the ACME mailing list with a brief mention of your PR (even though it's strictly editorial I think more folks monitor the list than the Github repo).
LGTM. Thanks NAME !

Discussion:
PKI are trusted to verify that an applicant for a certificate legitimately represents the domain name(s) in the certificate. <ins> Different types of certificates reflect different kinds of CA verification of information about the certificate subject.  "Domain Validation" (DV) certificates are by far the most common type.  For DV validation, the CA merely verifies that the requester has effective control of the web server and/or DNS server for the domain, but does not explicitly attempt to verify their real-world identity. (This is as opposed to "Organization Validation" (OV) and "Extended Validation" (EV) certificates, where the process is intended to also verify the real-world identity of the requester.) </ins> Existing Web PKI certificate authorities tend to run on a set of ad <del> hoc protocols for certificate issuance and identity verification.  A typical user experience is something like: </del> <ins> hoc protocols for certificate issuance and identity verification.  In the case of DV certificates, a typical user experience is something like: </ins> Generate a PKCS#10 RFC2986 Certificate Signing Request (CSR).

2. <del> The major guiding use case for ACME is obtaining certificates for Web sites (HTTPS RFC2818).  In that case, the server is intended to speak for one or more domains, and the process of certificate issuance is intended to verify that the server actually speaks for the domain(s). Different types of certificates reflect different kinds of CA verification of information about the certificate subject.  "Domain Validation" (DV) certificates are by far the most common type.  For DV validation, the CA merely verifies that the requester has effective control of the web server and/or DNS server for the domain, but does not explicitly attempt to verify their real-world identity. (This is as opposed to "Organization Validation" (OV) and "Extended Validation" (EV) certificates, where the process is intended to also verify the real-world identity of the requester.) </del> <ins> The guiding use case for ACME is obtaining certificates for Web sites (HTTPS RFC2818).  In this case, the user's web server is intended to speak for one or more domains, and the process of certificate issuance is intended to verify that this server actually speaks for the domain(s). </ins> DV certificate validation commonly checks claims about properties related to control of a domain name - properties that can be observed

process can be represented and performed by Internet protocols with no out-of-band human intervention. <del> 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: </del> <ins> At time of writing, when deploying an HTTPS server, an operator typically gets a prompt to generate a self-signed certificate.  If the operator were instead deploying 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.

required to keep the server functional and its credentials up-to- date. <del> The overall idea is that it's nearly as easy to deploy with a CA- issued certificate as a self-signed certificate, and that once the operator has done so, the process is self-sustaining with minimal manual intervention.  Close integration of ACME with HTTPS servers, for example, can allow the immediate and automated deployment of certificates as they are issued, optionally sparing the human administrator from additional configuration work. </del> <ins> In this way, it would be nearly as easy to deploy with a CA-issued certificate as with a self-signed certificate.  Furthermore, the maintenance of that CA-issued certificate would require minimal manual intervention.  Such close integration of ACME with HTTPS servers would allow the immediate and automated deployment of certificates as they are issued, sparing the human administrator from much of the time-consuming work described in the previous section. </ins> 3.

identifiers.  For example, all of the identifier validation challenges described in identifier-validation-challenges below address validation of domain names.  The use of ACME for other <del> protocols will require further specification, in order to describe </del> <ins> identifiers will require further specification, in order to describe </ins> how these identifiers are encoded in the protocol, and what types of validation challenges the server might require.