Original text:
BRSKI defines how a pledge MAY contact a well-known URI of a cloud registrar if a local domain registrar cannot be discovered. <del> Additionally, certain pledge types may never attempt to discover a local domain registrar and may automatically bootstrap against a </del>  cloud registrar. The details of the URI are manufacturer specific, with BRSKI giving 3.1.2. The pledge MUST use an Implicit Trust Anchor database (see EST <del> 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. </del>  The pledge MUST NOT establish a provisional TLS connection (see BRSKI section 5.1) with the cloud registrar. 3.2. <del> The cloud registrar must determine pledge ownership.  Once ownership is determined, or if no owner can be determined, then the registrar may: </del>  return a suitable 4xx or 5xx error response to the pledge if the <del> registrar is unwilling or unable to handle the voucher request </del>  redirect the pledge to an owner register via 307 response code 3.2.2. Once the cloud registrar has determined pledge ownership, the cloud <del> registrar may redirect the pledge to the owner registrar in order to </del>  complete bootstrap.  Ownership registration will require the owner to register their local domain.  The mechanism by which pledge owners register their domain with the cloud registrar is out-of-scope of The cloud registrar returned a 307 response to the voucher request. <del> The pledge should restart the process using a new voucher request </del>  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 another 307 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 </del>  Implicit Trust Anchor database for validating the local domain <del> registrar identity.  The pledge should send a voucher request message </del>  via the local domain registrar.  When the pledge downloads a voucher, it can validate the TLS connection to the local domain registrar and continue with enrollment and bootstrap as per standard BRSKI 3.3.2. The cloud registrar returned a voucher to the pledge.  The pledge <del> should perform voucher verification as per standard BRSKI operation. The pledge should verify the voucher signature using the manufacturer-installed trust anchor(s), should verify the serial number in teh voucher, and must verify any nonce information in the </del>  voucher. <del> The pledge should extract the "est-domain" field from the voucher, and should continue with EST enrollment as per standard BRSKI </del>  operation. 4.

Reviewer comments:
The two occurences of lower-case "may" might be clearer as "might". "The Pledge can be done with" ???? "may" or "MAY"? There are a few occurences of "should" and "must" in these sections, and I wondered about "SHOULD" and "MUST".

Revised text:
BRSKI defines how a pledge MAY contact a well-known URI of a cloud registrar if a local domain registrar cannot be discovered.  <ins> Additionally, certain pledge types might never attempt to discover a local domain registrar and might automatically bootstrap against a </ins> cloud registrar. The details of the URI are manufacturer specific, with BRSKI giving 3.1.2. The pledge MUST use an Implicit Trust Anchor database (see EST  <ins> RFC7030) to authenticate the cloud registrar service.  In order to make use of a Cloud Registrar, the Pledge MUST be manufactured with pre-loaded trust-anchors that are used to validate the TLS connection.  The TLS connection can be validated 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. 3.2.  <ins> The cloud registrar must determine pledge ownership.  if the registrar is unwilling or unable to handle the voucher request, for example it is unable to determine ownership, then the cloud registrar MUST return a suitable 4xx or 5xx error response to the pledge. If the cloud registrar successfully determines ownership, then the registrar MUST take one of the following actions: </ins> return a suitable 4xx or 5xx error response to the pledge if the  <ins> registrar is unwilling or unable to handle the voucher request for any reason </ins> redirect the pledge to an owner register via 307 response code 3.2.2. Once the cloud registrar has determined pledge ownership, the cloud  <ins> registrar MAY redirect the pledge to the owner registrar in order to </ins> complete bootstrap.  Ownership registration will require the owner to register their local domain.  The mechanism by which pledge owners register their domain with the cloud registrar is out-of-scope of The cloud registrar returned a 307 response to the voucher request.  <ins> The pledge SHOULD restart the process using a new voucher request </ins> 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 another 307 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 </ins> Implicit Trust Anchor database for validating the local domain  <ins> registrar identity.  The pledge SHOULD send a voucher request message </ins> via the local domain registrar.  When the pledge downloads a voucher, it can validate the TLS connection to the local domain registrar and continue with enrollment and bootstrap as per standard BRSKI 3.3.2. The cloud registrar returned a voucher to the pledge.  The pledge  <ins> SHOULD perform voucher verification as per standard BRSKI operation. The pledge SHOULD verify the voucher signature using the manufacturer-installed trust anchor(s), SHOULD verify the serial number in the voucher, and SHOULD verify any nonce information in the </ins> voucher.  <ins> The pledge SHOULD extract the "est-domain" field from the voucher, and SHOULD continue with EST enrollment as per standard BRSKI </ins> operation. 4.