Original text:
Domain.  There may not be a Local Domain Registrar in all deployment scenarios.  1.2. Two high level use cases are documented here.  There are more details provided in sections redirect2Registrar and voucher2EST.  While both use cases aid with incremental deployment of BRSKI infrastructure, for many smaller sites (such as teleworkers) no further <del> infrastructure are expected. </del>  The pledge is not expected to know which of these two situations it is in.  The pledge determines this based upon signals that it to make the determination based upon the identity presented by the pledge. <del> While a Cloud Registrar will typically handle all the devices of a particular product line from a particular manufacturer there are no restrictions on how the Cloud Registrar is horizontally (many sites) or vertically (more equipment at one site) scaled.  It is also entirely possible that all devices sold by through a particular VAR might be preloaded with a configuration that changes the Cloud Registrar URL to point to a VAR.  Such an effort would require unboxing each device in a controlled environment, but the </del>  provisioning could occur using a regular BRSKI or SZTP RFC8572 process. have an owner registrar deployed.  The cloud registrar issues a voucher, and the pledge completes trust bootstrap using the cloud registrar.  The voucher issued by the cloud includes domain <del> information for the owner's EST service the pledge should use for certificate enrollment. </del>  In one use case, an organization has an EST service deployed, but does not have yet a BRSKI capable Registrar service deployed.  The pledge is deployed in the organization's domain, but does not <del> discover a local domain, or owner, registrar.  The pledge uses the cloud registrar to bootstrap, and the cloud registrar provides a voucher that includes instructions on finding the organization's EST service. </del>  2. 3.1.2. <del> The pledge MUST use an Implicit Trust Anchor database (see EST) to authenticate the cloud registrar service.  The Pledge can be done with pre-loaded trust-anchors that are used to validate the TLS connection.  This can be using a public Web PKI trust anchors using RFC6125 DNS-ID mechanisms, a pinned certification authority, or even a pinned raw public key.  This is a local implementation decision. </del>  The pledge MUST NOT establish a provisional TLS connection (see BRSKI section 5.1) with the cloud registrar. It may be the case that one or more 307-Redirects have taken the Pledge from the built-in Cloud Registrar to one operated by a VAR. <del> When the Pledge is directed to the Owner's EST Registrar, the Pledge validates the TLS connection with this server using the "pinned- domain-cert" attribute in the voucher.  There is no provisional TLS connection, and therefore there are no risks associated with being behind a captive portal. </del> 

Reviewer comments:
[EST] and [RFC7030] are duplicates.
s/are/is/ That sentence is really hard to decode. Please rewrite using more words! Please define VAR. Please define EST. Hard to parse. Maybe you mean "does not discover a local domain registrar or an owner registrar"?

Revised text:
Domain.  There may not be a Local Domain Registrar in all deployment scenarios. <ins> EST: Enrollment over Secure Transport VAR: Value Added Reseller </ins> 1.2. Two high level use cases are documented here.  There are more details provided in sections redirect2Registrar and voucher2EST.  While both use cases aid with incremental deployment of BRSKI infrastructure, for many smaller sites (such as teleworkers) no further  <ins> infrastructure is expected. </ins> The pledge is not expected to know which of these two situations it is in.  The pledge determines this based upon signals that it to make the determination based upon the identity presented by the pledge.  <ins> A Cloud Registrar will typically handle all the devices of a particular product line from a particular manufacturer.  This document places no restrictions on how many different deployments or owner sites the Cloud Registrar can handle, or how many devices per site that the Cloud Registrar can handle.  It is also entirely possible that all devices sold by through a particular Value Added Reseller (VAR) might be preloaded with a configuration that changes the Cloud Registrar URL to point to a VAR.  Such an effort would require unboxing each device in a controlled environment, but the </ins> provisioning could occur using a regular BRSKI or SZTP RFC8572 process. have an owner registrar deployed.  The cloud registrar issues a voucher, and the pledge completes trust bootstrap using the cloud registrar.  The voucher issued by the cloud includes domain  <ins> information for the owner's Enrollment over Secure Transport (EST) RFC7030 service the pledge should use for certificate enrollment. </ins> In one use case, an organization has an EST service deployed, but does not have yet a BRSKI capable Registrar service deployed.  The pledge is deployed in the organization's domain, but does not  <ins> discover a local domain registrar or owner registrar.  The pledge uses the cloud registrar to bootstrap, and the cloud registrar provides a voucher that includes instructions on finding the organization's EST service. </ins> 2. 3.1.2.  <ins> The pledge MUST use an Implicit Trust Anchor database (see EST RFC7030) to authenticate the cloud registrar service.  The Pledge can be done with pre-loaded trust-anchors that are used to validate the TLS connection.  This can be using a public Web PKI trust anchors using RFC6125 DNS-ID mechanisms, a pinned certification authority, or even a pinned raw public key.  This is a local implementation decision. </ins> The pledge MUST NOT establish a provisional TLS connection (see BRSKI section 5.1) with the cloud registrar. It may be the case that one or more 307-Redirects have taken the Pledge from the built-in Cloud Registrar to one operated by a VAR.  <ins> When the Pledge is directed to the Owner's EST RFC7030 Registrar, the Pledge validates the TLS connection with this server using the "pinned-domain-cert" attribute in the voucher.  There is no provisional TLS connection, and therefore there are no risks associated with being behind a captive portal. </ins>