Subject: [Netconf] comments on draft-ietf-netconf-zerotouch-07

From: Michael Richardson <[email-masked]>
Date: Sun, 03 Apr 2016 13:35:24 -0400

1) I have sent Kent and Mikhail a github pull request with editorial
   suggestions on the text against the XML.  Here is the link to the diffs,
and I also include them at the end of this email for archival purposes,
omitting whitespace changes:

   https://github.com/netconf-wg/zero-touch/pull/10

2) section 3, Information Types.
   "This document only tries to support the encodings supported by
    RESTCONF, namely XML and JSON, while leaving extensibility mechanisms
    in place to support future extensions."

mcr>  Is there a MTI? Is information going to be available in multiple
mcr>  formats? Who decides?: Or does it not matter, because the vendor
mcr>  decides?

3) where "X.509" is written, I think maybe we should be writing PKIX?

4) is there any reason why an artifact that is retrieved securely
   can not *also* be signed?

5) section 3.2:
   > The configuration can configure any aspect of the device but, in
   > order to fulfill the goal of the zero touch bootstrapping process,

Could this be recursive? i.e. the first server actually returns a new set of
"hints" and trust anchors that lets it start again? Could other goals be
defined? It seems that this requirement is pretty soft.

6) I suggest in section 4.1, Removable Storage, I suggest adding a reference
   to one of:
      https://help.ubuntu.com/community/CloudInit
      https://cloudinit.readthedocs.org/en/latest/
      https://www.digitalocean.com/community/tutorials/an-introduction-to-cloud-config-scripting

  but I don't have a reference to a protocol specification that is behind all
  of this.

7) 4.1: add reference to some embedded signature format.
   (I don't have one to add)

8) section 4.2 says: "no definition for bootstrap
   information using DNS-SD is provided by this document."

 but it seems that really it does define a way to store everything... so I'm
 confused.

9) section 4.2 should have a reference to gzip compression.
   All of section 4.2 needs an example, and some review...

10) maybe the validation of the boot image (referenced in 4.1 and 4.3) should
be a seperate section to be referenced.

11) section 4.3 repeats the part about unsigned. I removed it in the proposal.
12) is the client permitted to send "no notification", if it has nothing to
say?

13) In section 5.3:
    >Details such as the format of filesystem and
    >the naming of the files are left to the device's manufacturer to
    >define.

I think we should actually say something about the formats here: We should
say that they SHOULD be industry standard formats.

14) section 5.3 repeats security again.
    "If the redirect information contained in the DHCP option..."

    and the next point.

diff --git a/draft-ietf-netconf-zerotouch.xml b/draft-ietf-netconf-zerotouch.xml
index ad2a667..1ae8b5b 100644
--- a/draft-ietf-netconf-zerotouch.xml
+++ b/draft-ietf-netconf-zerotouch.xml
@@ -150,6 +150,9 @@
           <t>This document uses the following terms:
             <list style="hanging" hangIndent="4">

+              <t hangText="ABS:">artifact based solution.  A solution in which the artifacts
+              are signed, and may be retrieved by insecure channels.</t>
+
               <t hangText="Artifact:">The term "artifact" is used throughout to represent the
               encoded form of any of Bootstrap Information, Redirect Information,
               Owner Certificate, and Ownership Voucher.  The Bootstrap Server defined in this
@@ -212,6 +215,15 @@
               on signed data. This data is formally defined by the "ownership-voucher"
               container in the YANG module defined in <xref target="yang-module"/>.</t>

+              <t hangText="PBS:">protocol based solution.  A solution in which the artifacts
+              need not be signed, but must be retrieved by secure channels only.</t>
+
+              <t hangText="POV:">presented ownership voucher.</t>
+
+              <t hangText="POV:">Presented Owner Certificate.</t>
+
+              <t hangText="PA">presented artifact</t>
+
               <t hangText="Redirect Information:">The term "redirect information" is used herein
               to refer to bootstrapping data that redirects a device to connect to another
               Bootstrap Server.  This data is formally defined by the "redirect-information"
@@ -281,21 +293,26 @@
         <section title="Conveying Trust">
           <t>A device in its factory default state possesses a limited set of manufacturer specified
           trust anchors.  In this document, there are two types of trust anchors of interest.
-          The first type of trust anchor is used to authenticate a secure connection to, for
+          The first type of trust anchor is used to authenticate a secure (HTTPS) connection to, for
           instance, a manufacturer-hosted Internet-based bootstrap server.  The second type of trust
           anchor is used to authenticate manufacturer-signed data, such as the owner certificate
           and ownership voucher described in this document.</t>
           <t>In the first case, trust is conveyed by the device first authenticating the secure
           connection to the server and then by the device trusting that the server would only provide
-          data that its rightful owner staged for it to find.  For instance, the staged data may
-          be redirect information that includes the IP address and another trust anchor certificate
+          data that its rightful owner staged for it to find. Actual end system data may be returned,
+          or a redirection may be returned.
+          The redirection will include
+          redirect information that includes the IP address and another trust anchor certificate
           for the deployment-specific bootstrap server.  The device can then use the discovered trust
           anchor to authenticate a secure connection to the deployment-specific bootstrap server.</t>
           <t>In the second case, trust is conveyed by the device first authenticating the owner
           certificate and ownership voucher and then, using the public key in the owner certificate,
           authenticate a signed artifact, such as redirect information.  And again the device can use
           the discovered trust anchor to authenticate a secure connection to the deployment-specific
-          bootstrap server.</t>
+          bootstrap server.
+          This mechanism lets the original manufacturer redirect to a customer provided bootstrap
+          server in a secure fashion.
+          </t>
         </section>
         <section title="Ownership" anchor="ownership">
           <t>The goal of this document is to enable a device to connect with its rightful owner's NMS.
@@ -303,25 +320,31 @@
           of this document), as well as an ability to convey that information to devices (in scope).
           Matching the two ways to convey trust, this document provides both a protocol oriented
           solution as well as an artifact based solution for conveying ownership.</t>
-          <t>The protocol based solution conveys ownership by the device first authenticating a secure
+
+          <section title="Protocol Based Solution (PBS)">
+          <t>The protocol based solution (PBS) conveys ownership by the device first authenticating a secure
           connection to a bootstrap server and then trusting that the server would only provide
           data that its rightful owner staged for it to find.  In the case of a manufacturer-hosted
           bootstrap server, the manufacturer takes the onus of ensuring that only data configured by
-          the device's rightful owner is made available to the device.  With this approach, the
-          assignment of a device to an owner is ephemeral, with the manufacturer being able is
-          reassign the device at any time.</t>
-          <t>The artifact based solution, which is ideal for when a secure connection
-          cannot be established (e.g., loading data off a removable storage device),
-          involves the manufacturer signing an owner certificate and then later, when
-          the ownership for devices is established, the manufacturer signing a voucher
-          that assigns those devices to the owner, and then the owner using their
-          private key to sign the artifacts.  Thus, from the device's perspective,
-          it can use the presented ownership voucher to validate the presented owner
-          certificate, which it can then use to validate the signature over the
-          presented artifact.  With this approach, the assignment of a device to
-          an owner is somewhat permanent, as the ability for the manufacturer to
-          reliably distribute CRLs to revoke assignments not possible when the
-          devices do not contain a real time clock (see <xref target="sec-con"/>
+          the device's rightful owner is made available to the device.  With the PBS approach, the
+          assignment of a device to an owner is ephemeral. The manufacturer being able is
+          able to reassign the device at any time.</t>
+          </section>
+          <section title="Artifact Based Solution (ABS)">
+          <t>The artifact based solution (ABS) is ideal for when a secure connection
+          cannot be established (e.g., loading data off a removable storage device).
+          The ABS method has the manufacturer signing an owner certificate and then later, when
+          the ownership for devices is established, the manufacturer sign a voucher
+          to assign those devices to the owner.
+          The owner uses their private key to sign the artifacts.
+          Thus, from the device's perspective,
+          it can use the Presented Ownership Voucher (POV) to validate the Presented Owner
+          Certificate (POC), which it can then use to validate the signature over the
+          presented artifact (PA).  With this approach, the assignment of a device to
+          an owner is somewhat permanent; while the manufacturer could
+          attempt to revoke the signature via a Certificate Revocation List
+          (CRL), this would depend upon the device having a secure real time
+          clock (see <xref target="sec-con"/>
           for information about this).</t>
         </section>
       </section>   <!-- end guiding principles -->
@@ -345,32 +368,53 @@
           to the specified bootstrap servers, until finding one that it can bootstrap itself off of.
           Redirect information is primarily distinguished from standard HTTP redirect by its optional
           inclusion of trust anchors, in which case it may be referred to as a "secure redirect".</t>
-          <t>Redirect information may be signed or unsigned.  If the redirect information is not
-          signed, then the device MUST NOT trust any included trust anchor certificates, equivalent
-          to had they not been specified at all.</t>
+          <t>Redirect information may be signed or unsigned.
+
+          Included trust anchors MAY ONLY be trusted if the redirect is
+          signed.  Unsigned trust anchors MUST be discarded. </t>
+
           <t>When redirect information is signed, then the device MUST establish a secure
           connection to the specified bootstrap server using X.509 certificate path validation
           (<xref target="RFC6125"/>, Section 6) to the specified trust anchor, and MUST send
-          its IDevID certificate in the form of a client certificate, and MUST POST notifications
-          to the bootstrap server.  Furthermore, in this case, any data obtained from the bootstrap
-          server MAY NOT be signed, as it is already trusted by virtue of the secure connection.</t>
-          <t>When redirect information is unsigned, or doesn't specify a trust anchor certificate,
-          and the device connects to the bootstrap server by blindly accepting the bootstrap
-          server's TLS certificate, the device MUST NOT send its IDevID certificate in the form
-          of a client certificate, and MUST NOT POST notifications to the bootstrap server.
-          Furthermore, the device MUST assert that any data obtained from the bootstrap server
-          is signed, much as it would assert bootstrap information loaded from a removable
-          storage device is signed.</t>
+          its IDevID certificate in the form of a client certificate.
+          The client MUST use a POST method to send
+          notifications to the bootstrap server.
+          Furthermore, in this case, any data obtained from the bootstrap
+          server MAY be unsigned, as it is already trusted by virtue of the
+          secure connection.</t>
+
+          <t>A client MUST send it’s client certificate only in the case
+          where the redirect information is signed, and a trust anchor is
+          provided.  In all other cases, it MUST NOT send a client
+          certificate.  Sending client certificates in the insecure cases
+          permits MITM attacks.  The following cases are insecure:
+          <list style="hanging" hangIndent="4">
+
+            <t hangText="1.">When redirect information is unsigned</t>
+            <t hangText="2.">the redirect doesn't specify a trust</t>
+            <t hangText="3.">anchor certificate</t>
+            <t hangText="4.">the device connects to the bootstrap server by
+            blindly accepting the bootstrap server's TLS certificate.</t>
+          </list>
+
+          <t>
+          In all insecure cases, the device MUST assert that any data
+          obtained from the bootstrap server is signed, much as it would
+          assert bootstrap information loaded from a removable storage device
+          is signed.
+          </t>
+
+
         </section>
         <section title="Bootstrap Information" anchor="bootstrap-information">
-          <t>Bootstrap information provides all the data neccessary for the device
+          <t>Bootstrap information provides all the data necessary for the device
           to bootstrap itself, in order to be considered ready to be managed.
           This data includes criteria about the boot image the device MUST be running,
           an initial configuration the device MUST commit, and an optional script that,
           if specified, the device MUST successfully execute.  Descriptions for these
           follow:
             <list style="symbols">
-              <t>The boot image creteria is used to ensure the device is running a version
+              <t>The boot image criteria is used to ensure the device is running a version
               of software that will be able to understand the configuration and script, if
               any.  The criteria is flexible in that it allows for both an absolute
               specification of the boot image a device MUST be running, or just a list
@@ -391,10 +435,13 @@
               statement provided in the YANG module defined in <xref target="yang-module"/>.</t>
             </list>
           </t>
-          <t>Bootstrap information may be signed or unsigned.  If the device is accessing
+
+          <t>It is always permitted for bootstrap information to be signed,
+          even if it was obtained in a secure fashion. If the device is accessing
           the bootstrap server in an unsecured manner (e.g., from a removable storage device
-          or from an untrusted server), then the bootstrap information MUST be signed,
-          otherwise it MAY be signed.</t>
+          or from an untrusted server), then the bootstrap information MUST
+          be signed.</t>
+
           <t>Devices MUST process bootstrap information as is specified in <xref
           target="process-bootstrap-information"/>.</t>
           <t>The bootstrap information type is formally defined by the "bootstrap-information"
@@ -422,58 +469,70 @@
           <t>A device MAY attempt to acquire bootstrapping data from a directly attached
           removable storage device.  The bootstrapping data MAY be either redirect information
           or bootstrap information.</t>
-          <t>If redirect information is provided, it SHOULD be signed, as removable storage
-          devices are not trustworthy.  However, if the redirect information is not signed,
-          then the device MUST NOT trust any included trust anchor certificates,
-          which means that the device would have to establish an unsecured connection to
+
+          <t>Redirect information found in removable storage MUST be treated
+          in the same manner as redirect information retrieved from an HTTPS
+          connection: trust anchors are to be ignored if unsigned as they
+          would cause the device to establish an unsecured connection to
           the specified bootstrap servers.  See <xref target="redirect-information"/> for
           more about this case.</t>
+
           <t>If bootstrap information is provided, it MUST be signed, as removable storage
           devices are not trustworthy and there is no option to process the data in a
           degraded manner, unlike as with redirect information.</t>
+
           <t>For the case when the signed bootstrap information is provided, it is notable
           that even the raw boot image file itself can be on the removable storage device,
           by letting the URL reference a local file (e.g., file:///path/to/file), making
-          use of the removable storage device a fully self-standing bootstrapping solution.</t>
+          use of the removable storage device a fully self-standing
+          bootstrapping solution.</t>
+
           <t>However, regardless if the boot image file resides on the local storage device
           or if the device must follow the URL to download it from a remote (and unsecured)
-          server, the device MUST authenticate the validity of the boot image file, either by
-          using the MD5 and SHA fingerprints supplied by the bootstrapping information, or by
-          virtual of the boot image containing an embedded signature, if any.</t>
+          server, the device MUST authenticate the validity of the boot image
+          file, such as by using MD5,SHA, or other cryptographic fingerprints
+          supplied in the bootstrapping information.
+          Some boot image formats can contain an embedded signature [XXXREF], if any.
+          </t>
         </section>
+
         <section title="DNS Server" anchor="dns-server">
           <t>A device MAY attempt to acquire bootstrapping data from a DNS server using
           DNS-based service discovery (DNS-SD) <xref target="RFC6763"/>.  Due to DNS packet
           size limitations the bootstrapping data provided using DNS-SD can only be
-          redirect information, no support for bootstrap information using DNS-SD is
+          redirect information: no definition bootstrap information using DNS-SD is
           provided by this document.</t>
-          <t>The redirect information provided SHOULD be signed, as this document does
+          <t>The redirect information provided via DNS-SD SHOULD be signed
+          internally (not via DNSSEC), as this document does
           not define a solution to secure the DNS records using DNSSEC <xref target="RFC6698"/>.
-          However, if the redirect information is not signed, then the device MUST NOT trust
-          any included trust anchor certificates, which means that the device would have to
-          establish an unsecured connection to the specified bootstrap servers.  See
+          As before, devices MUST disregard unsigned redirect information. See
           <xref target="redirect-information"/> for more about this case.</t>
+
           <t>To use this approach, the device MAY perform DNS-SD via multicast DNS
           <xref target="RFC6762"/> searching for the service "_zerotouch._tcp.local.".
           Alternatively the device MAY perform DNS-SD via normal DNS operation, using
           the domain returned to it from the DHCP server, searching for the service
           "_zerotouch._tcp.example.com".</t>
+
           <t>The mapping of redirect information onto DNS SRV <xref target="RFC2782"/> and
-          DNS TXT <xref target="RFC1035"/> records as follows:
-           is as follows:
+          DNS TXT <xref target="RFC1035"/> records is as follows:
+
             <list style="symbols">
               <t>The bootstrap server's hostname or IP address is returned by the "Target"
               component of the DNS SRV record.</t>
               <t>The bootstrap server's port is returned by the "Port" component of the
               DNS SRV record.</t>
+
               <t>The bootstrap server's trust anchor is returned using the key "anchor" in
               the DNS TXT record with the binary value being the `gzip` compression over the
               redirect-information's "trust-anchor" value. To save additional space, it is
               RECOMMENDED that the trust anchor certificate uses an elliptical curve
-              algorithm, rather than the seemingly ubiquitous RSA algorithm.</t>
+              algorithm, rather than the larger, more common RSA algorithm.</t>
+
               <t>The signature over the preceding three values is returned using the key
               "sig" in the DNS TXT record with the binary value being the `gzip` compression
               over the redirect-information's "signature" value.</t>
+
               <t>The owner certificate is returned using the key "cert" in the DNS TXT
               record with the binary value being the `gzip` compression over the
               redirect-information's "owner-certificate/certificate" value.  There isn't
@@ -506,10 +565,9 @@
           degraded manner, unlike as with redirect information.</t>
           <t>For the case when the signed bootstrap information is provided, it is notable
           that the URL would have to point to another file server (e.g., http://, ftp://, etc.),
-          as DHCP servers do not themselves distribute files.  In this case, the device MUST
-          authenticate the validity of the boot image file, either by using the MD5 and SHA
-          fingerprints supplied by the bootstrapping information, or by virtual of the boot
-          image containing an embedded signature, if any.</t>
+          as DHCP servers do not themselves distribute files.
+          [[Reference to end of section 4.1 here]]
+          </t>
           <t>It is expected that DHCP servers will provide redirect information more often than bootstrap
           information, since redirect information is more generic, potentially applicable to a large number
           of devices, with the number limited only by the number of devices listed by the associated
@@ -526,24 +584,19 @@
           has been staged for that one device.</t>
         </section>
         <section title="Bootstrap Server" anchor="bootstrap-server">
+
           <t>A device MAY attempt to acquire bootstrapping data from a trusted Internet-based
           bootstrap server, a server implementing the RESTCONF API defined by the YANG module
           provided in <xref target="yang-module"/>.  The bootstrapping data provided by the
-          server MAY be either redirect information or bootstrap information.</t>
-          <t>Actually, a bootstrap server is not only a source for bootstrapping data, but
+          server MAY be either redirect information or bootstrap
+          information.</t>
+
+          <t>As describe in section {TBD}, a bootstrap server is not only a source for bootstrapping data, but
           it is also the consumer of notification messages from devices.  These notification
-          messages both enable visability into the bootstrapping process (e.g., reporting
+          messages both enable visibility into the bootstrapping process (e.g., reporting
           warnings and errors) and well as provide potentially useful completion status
           information (e.g., the device's SSH host-keys).</t>
-          <t>If the device is able to authenticate the bootstrap server, using X.509
-          certificate path validation (<xref target="RFC6125"/>, Section 6) to a trust
-          anchor the device was manufactured with, or it securely learned from another
-          source of bootstrapping data, then the data the device obtains from the
-          bootstrap server MAY NOT be signed.  Notably, this is the only mechanism defined
-          in this document whereby unsigned bootstrap information (not redirect information)
-          can be used.  When the device is able to authenticate the bootstrap server's
-          TLS certificate, the device MUST send its IDevID certificate in the form of
-          client-certificate and it MUST POST notifications to the bootstrap server.</t>
+
           <t>If the device is unable to authenticate the bootstrap server's TLS certificate,
           for any reason, then any data it receives from the bootstrap server MUST be
           signed in order for the device to be able to make use of it.  When the device

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Kent Watsen <[email-masked]>
Date: Thu, 7 Apr 2016 00:09:44 +0000

Hi Michael,

Thank you for your review and github pull-request!

>   https://github.com/netconf-wg/zero-touch/pull/10

I just incorporated this.  I changed a few things from your pull request, but the spirit of it mostly survived.   I did back out the new terms you proposed, as well as the associated sub-sections in the "Conveying Ownership" section, but I did so only after rewriting that section to be more precise, which is what I think you were trying to achieve as well.  Please let me know if you disagree!

>mcr>  formats? Who decides?: Or does it not matter, because the vendor

Each source of bootstrapping information has its own strategy for typing the data:

1) Removable storage: presumably the file's suffix (e.g., config.xml or config.json)
2) DNS server: data is mapped to DNS SVR and TXT records
3) DHCP server: the DHCP options defined in Section 9.1 have an "encoding" parameter
4) Bootstrap server: per RESTCONF, HTTP "Accept" and "Content-Type" headers are used

>3) where "X.509" is written, I think maybe we should be writing PKIX?

Can you call out exactly where you think this should be done?

>   can not *also* be signed?

It can.  For instance, Section 4.4 says:

  If the device is able to trust the bootstrap server, by verifying its
  TLS server certificate using a preconfigured or learned trust anchor,
  then the data the device obtains from the bootstrap server MAY be
  unsigned.

It's a bit unfair for me to reference that particular text, since it's new based on the update from your pull request, but I'm sure the document says the same thing in other places as well.  Let's just say that it is definitely the intent to allow that possibility.

>   > order to fulfill the goal of the zero touch bootstrapping process,
>

The solution does allow for recursive redirections, but I think your question regards what the configuration the device downloads from the bootstrap server.  As currently defined, this draft does not define a YANG module providing a configuration data-model that could be used to configure the bootstrapping data.  Do you think it should?

Regarding other goals, as the quoted text above says, the configuration downloaded from the bootstrap server can be anything.  So, for instance, the configuration could additionally configure MPLS or IPSEC if desired.  Is this what you meant?

>  but I don't have a reference to a protocol specification that is behind all

I see the similarity, but I don't see why there might be a desired to add a reference to cloud-init.  What are you thinking here?

>   (I don't have one to add)

Right, I saw that in your pull request.  I decided to instead to delete all the text regarding the possibility of the boot-image.  

I also realized that this text was not unique to removable storage, and so instead moved it to Section 6.6 (Processing Bootstrap Information).

> but it seems that really it does define a way to store everything... so I'm

Right, the DNS-SD solution only supports redirect information (not bootstrap information).  This is because DNS records are too small to support something as large as an initial configuration, which could be megabytes in size.

>   All of section 4.2 needs an example, and some review...

I added a ref to RFC 1951.

>be a seperate section to be referenced.

Yes, I moved it to Section 6.6 (see comment above).  I don't see it in Section 4.3 though...

>11) section 4.3 repeats the part about unsigned. I removed it in the proposal.

ACK.

>12) is the client permitted to send "no notification", if it has nothing to

First, please note that when a device connects to an untrusted bootstrap server, it MUST NOT send any notification.

That said, Section 4.4 (Bootstrap Server), and similar text in Section 6.3 (Processing a Source of Bootstrapping Data), says:

  When the device is able to trust the
  bootstrap server, it MUST send its IDevID certificate in the form of
  a client certificate, and MUST send notifications to the bootstrap
  server, using the "notification" action defined in Section 7.4.

But it doesn't say which, if any, of the "notification-type" enums defined in Section 7.4. (YANG Module) are to be sent.  Presumably a device would minimally send the "bootstrap-initiated" and "bootstrap-complete" notifications, but this isn't currently stated.

What is your opinion on this?

>    >the naming of the files are left to the device's manufacturer to
>    >define.
>

I can go either way, does anyone else have an option?

Regardless, I moved this sentence to Section 4.1 (Removable Storage).

>    "If the redirect information contained in the DHCP option..."

Replaced with "Details regarding how to process bootstrapping data received from a DHCP server are discussed in <xref target="dhcp-server"/>."

Thanks again,
Kent

---

From: Michael Richardson <[email-masked]>
Date: Thu, 07 Apr 2016 13:35:11 -0400

> I just incorporated this.  I changed a few things from your pull
    > request, but the spirit of it mostly survived.   I did back out the new
    > terms you proposed, as well as the associated sub-sections in the
    > "Conveying Ownership" section, but I did so only after rewriting that
    > section to be more precise, which is what I think you were trying to
    > achieve as well.  Please let me know if you disagree!

okay, I will re-read, but not this week.

    > 4) Bootstrap server: per RESTCONF, HTTP "Accept" and "Content-Type" headers are used

yes, that explains the types, but doesn't explain which types must be
supported in order to get interoperability.   It would be fine if there was
an applicability statement that said, "VoIP Phones will use format X and Y"
or "Home NAS boxes will use format Y and Z"

    > Can you call out exactly where you think this should be done?

I think anyplace. X509 is an ITU specification which was too broad for anyone
to use, and so the IETF PKIX WG created a profile of it.

    > It can.  For instance, Section 4.4 says:

Then I think that you can simplify your text a lot by never stating that it
can not be signed.  Instead, the question isn't if it is signed, but rather
if the signature can be trusted.

    > The solution does allow for recursive redirections, but I think your
    > question regards what the configuration the device downloads from the
    > bootstrap server.  As currently defined, this draft does not define a
    > YANG module providing a configuration data-model that could be used to
    > configure the bootstrapping data.  Do you think it should?

Perhaps not this document, but I think that such a document should exist.

    > Regarding other goals, as the quoted text above says, the configuration
    > downloaded from the bootstrap server can be anything.  So, for
    > instance, the configuration could additionally configure MPLS or IPSEC
    > if desired.  Is this what you meant?

no.

    > I see the similarity, but I don't see why there might be a desired to
    > add a reference to cloud-init.  What are you thinking here?

cloud-init, and friends are an example of an unsigned artifact which a
"device" find on removable storage when it boots.
   also: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/user-data.html

    > Right, I saw that in your pull request.  I decided to instead to delete
    > all the text regarding the possibility of the boot-image.

    > I also realized that this text was not unique to removable storage, and
    > so instead moved it to Section 6.6 (Processing Bootstrap Information).

okay.
I'm sure that there must be some specifications out there that we could point
at.  My goal here is really to be inclusive of those communities.

    > First, please note that when a device connects to an untrusted
    > bootstrap server, it MUST NOT send any notification.

Yes, I get that. It got said multiple times.

    > That said, Section 4.4 (Bootstrap Server), and similar text in Section
    > 6.3 (Processing a Source of Bootstrapping Data), says:

    > But it doesn't say which, if any, of the "notification-type" enums
    > defined in Section 7.4. (YANG Module) are to be sent.  Presumably a
    > device would minimally send the "bootstrap-initiated" and
    > "bootstrap-complete" notifications, but this isn't currently stated.

Okay, so it would be good to point to at least section 7.4 there then.

    > What is your opinion on this?

It's good to know what to expect, so that the registrar/bootserver can build
a sensible statement machine.

    > I can go either way, does anyone else have an option?

I don't know if there is an IPR-free description of VFAT, but that's what I
had in mind.