Draft: anima-brski-cloud

Commentary: I find this section too telegraphic . Needs a bit more grammar ... 
 Maybe we just delete this section completely ? 
 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 .
This document specifies the behavior of a BRSKI Cloud Registrar, and
how a pledge can interact with a BRSKI Cloud Registrar when
bootstrapping.
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.
OEM - Equipment manufacturer.  Operate the MASA.
Network operator.  Operate the Owner Registrar.  Often operated by
end owner (company), or by outsourced IT entity.
Network integrator.  They operate a Cloud Registrar.
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.
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
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.