[Anima-bootstrap] IoT and scope of bootstrap

[Michael Richardson <[e-mail]>]

I wrote some text this morning to clarify how IoT is included/excluded.
see: https://github.com/ietf-roll/anima-bootstrap/commits/master
(maybe would have been cleaner had I made it a pull request).

I also added a note about ACE, which I'll put in another email.


+      <section title="Scope of solution">
+        <t>
+          Questions have been posed as to whether this solution is suitable
+          in general for Internet of Things (IoT) networks.  In general the
+          answer is no, but the terminology of <xref target="RFC7228" /> is
+          best used to describe the boundaries.
+        </t>
+        <t>
+          The entire solution described in this document is aimed in general
+          at non-constrained (i.e. class 2+) devices  operating on a
+          non-Challenged network.
+          The entire solution described here is not intended to be useable
as-is
+          by constrained devices operating on challenged networks (such as
+          802.15.4 LLNs).
+        </t>
+        <t>
+          In many target applications, the systems
+          involved are large router platforms with multi-gigabit
+          inter-connections, mounted in controlled access data centers.  But
+          this solution is not exclusive to the large, it is intended to
+          scale to thousands of devices located in hostile environments,
such
+          as ISP provided CPE devices which are drop-shipped to the end
user.
+          The situation where an order is fulfilled from distributed
+          warehouse from a common stock and shipped directly to the target
+          location at the request of the domain owner is explicitely
+          supported.  That stock ("SKU") could be provided to a number of
+          potential domain owners, and the eventual domain owner will not
+          know a-priori which device will go to which location.
+        </t>
+        <t>
+          Specifically, there are protocol aspects described here which
might
+          result in congestion collapse or energy-exhaustion of intermediate
+          battery powered routers in an LLN.  Those types of networks SHOULD
+          NOT use this solution.
+        </t>
+        <t>
+          The imprint protocol described here could, however, be used by
+          non-energy constrained devices joining a non-constrained network
+          (for instance, smart light bulbs are usually mains powered, and
+          speak 802.11).  It could also be used by non-constrained devices
+          across a non-energy constrained, but challenged network (such as
+          802.15.4).
+        </t>
+        <t>
+          Some aspects are in scope for constrained devices on challenged
+          networks: the certificate contents, and the process by which the
+          four questions above are resolved is in scope.  It is simply the
+          actual on-the-wire imprint protocol which is likely inappropriate.
+        </t>
+      </section>



--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-