Original text:
Abstract <del> This document specifies the behavior of a BRSKI Cloud Registrar, and how a pledge can interact with a BRSKI Cloud Registrar when bootstrapping. RFCED REMOVE: It is being actively worked on at https://github.com/ anima-wg/brski-cloud </del>  1. Both mechanisms are described in detail later in this document. <del> 2.1. OEM - Equipment manufacturer.  Operate the MASA. Network operator.  Operate the Owner Registrar.  Often operated by end owner (company), or by outsourced IT entity. </del>  <del> Network integrator.  They operate a Cloud Registrar. 2.2. </del>  The assumption is that the pledge already has network connectivity prior to connecting to the cloud registrar.  The pledge must have an between the pledge and the cloud registar are all out of scope of this document. <del> 2.3. </del>  BRSKI section 5.9.2 specifies that the pledge MUST send an EST RFC7030 CSR Attributes request to the registrar.  The registrar MAY The pledge SHOULD restart the process using a new voucher request using the location provided in the HTTP redirect.  Note if the pledge is able to validate the new server using a trust anchor found in its <del> Implicit Trust Anchor database, then it MAY accept another 307 redirect.  The pledge MUST never visit a location that it has already been to.  If that happens then the pledge MUST fail the onboarding attempt and go back to the beginning, which includes listening to other sources of onboarding information as specified in BRSKI section 4.1 and 5.0. </del>  The pledge SHOULD establish a provisional TLS connection with specified local domain registrar.  The pledge SHOULD NOT use its

Reviewer comments:
I find this section too telegraphic. Needs a bit more grammar...
Maybe we just delete this section completely NAME ?
I think we should eliminate the heading, but expand the content to better match the diagram.
I'm not convinced. In the rest of the doc, we never mention OEM or Network integrator. And Network operator is only mentioned again in secetion "Issues with Security of HTTP Redirect" I lean to delete completely, unless you have some explicit ideas and concepts you need to get across. FIne if you do - maybe include that in your abstract rewrite PR?
This is a bit short. I think it should provide a little context for a casual reader (what is BRSKI, what is a pledge, what is a registrar).
No, this is a runon sentence. It is worth. Let me work on something for Friday.

Revised text:
Abstract  <ins> Bootstrapping Remote Secure Key Infrastructures defines how to onboard a device securely into an operator maintained infrastructure. It assumes that there is local network infrastructure for the device to discover and to help the device.  This document extends the new device behaviour so that if no local infrastructure is available, such as in a home or remote office, that the device can use a well defined "call-home" mechanism to find the operator maintained infrastructure. To this, this document defines how to contact a well-known cloud registrar, and two ways in which the new device may be redirected towards the operator maintained infrastructure. </ins> 1. Both mechanisms are described in detail later in this document.  <ins> As depicted in architecture-figure, there are a number of parties involve in the process.  The Manufacturer, or Original Equipment Maker (OEM) builds the device, but also is expected to run the MASA, or arrange for it to exist. The network operator or enterprise is the intended owner of the new device: the pledge.  This could be the enterprise itself, or in many cases there is some outsourced IT department that might be involved. They operator the Registrar or EST Server.  They may operate the CA, or they may contract those services from another entity. Unlike in RFC8995 there is a potential additional party involved, the network integrator, who may operate the Cloud Registrar.  This is typically a value added reseller who works with the OEM to ship products with the right configuration to the owner.  For example, SIP telephones or other conferencing systems may be installed by this VAR, often shipped directly from a warehouse to the customer's remote office location.  The network integrator and manufacturer are aware of which devices have been shipped to the integrator through sales channel integrations, and so the manufacturer's Cloud Registrar is able to redirect the pledge through a chain of Cloud Registrars, as explained in redirect-response. </ins>  <ins> 2.1. </ins> The assumption is that the pledge already has network connectivity prior to connecting to the cloud registrar.  The pledge must have an between the pledge and the cloud registar are all out of scope of this document.  <ins> 2.2. </ins> BRSKI section 5.9.2 specifies that the pledge MUST send an EST RFC7030 CSR Attributes request to the registrar.  The registrar MAY The pledge SHOULD restart the process using a new voucher request using the location provided in the HTTP redirect.  Note if the pledge is able to validate the new server using a trust anchor found in its  <ins> Implicit Trust Anchor database, then it MAY accept additional 307 redirects.redirect.  The pledge MUST never visit a location that it has already been to.  If that happens then the pledge MUST fail the onboarding attempt and go back to the beginning, which includes listening to other sources of onboarding information as specified in BRSKI section 4.1 and 5.0. </ins> The pledge SHOULD establish a provisional TLS connection with specified local domain registrar.  The pledge SHOULD NOT use its