Re: [Anima] [Gen-art] dealing with many the secdir and genart comments [on draft-ietf-anima-bootstrapping-keyinfra]

[Michael Richardson <[e-mail]>]

Brian E Carpenter <[e-mail]> wrote:
    >> The authors seriously believe that this will result in an attempt to
    >> boil the ocean.  Yes, BRSKI is exciting for many and opens many doors,
    >> but in the context of the *ANIMA* Charter, we strongly think that this
    >> document should leave the oceans alone, and deal only with the ANIMA
    >> ACP usage.

    > Yes, violent agreement. From all the interest outside ANIMA, the basic
    > idea of BRSKI is a big hit and will be re-used in other contexts. I
    > think a strong statement about the specific scope of *this* document
    > belongs in the Abstract and Introduction, with a comment that variant
    > usages of BRSKI in other scenarios will be documented separately.

Brian, these are my proposed changes to the abstract, intro,
and adding a section on ACP Applicability.  I think that there is probably
more to say there.

This has become issue #116.

diff --git a/dtbootstrap-anima-keyinfra.xml b/dtbootstrap-anima-keyinfra.xml
index 78ce2a3..e705904 100644
--- a/dtbootstrap-anima-keyinfra.xml
+++ b/dtbootstrap-anima-keyinfra.xml
@@ -82,19 +82,21 @@
 
     <abstract>
       <t>
-        This document specifies automated bootstrapping of a remote secure
-        key infrastructure (BRSKI) using manufacturer installed X.509 certificate, in
-        combination with a manufacturer's authorizing service, both online and offline.
+        This document specifies automated bootstrapping of an Autonomic
+        Control Plane.  To do this a remote secure
+        key infrastructure (BRSKI) is created using manufacturer installed
+        X.509 certificate, in combination with a manufacturer's authorizing
+        service, both online and offline. 
         Bootstrapping a new device can occur using a routable address and a
         cloud service, or using only link-local connectivity, or on
         limited/disconnected networks. Support for lower security models,
         including devices with minimal identity, is described for legacy reasons
 
@@ -103,7 +105,22 @@
       <t>
         BRSKI provides a solution for secure zero-touch (automated) bootstrap of
         virgin (untouched) devices that are called pledges in this
-        document. These pledges need to discover (or be discovered by) an
+        document.
+      </t>
+      
+      <t>
+        This document primarily provides for the needs of
+        the ISP and Enterprise focused ANIMA 
+        <xref target="I-D.ietf-anima-autonomic-control-plane">Autonomic 
+        Control Plane (ACP)</xref>.  Other users of the BRSKI protocol
+        will need to provide separate applicability statements that
+        include privacy and security considerations appropriate to that
+        deployment.  Section <xref target="acpapplicability" /> explains the details
+        applicability for this the ACP usage.
+      </t>
+      
+      <t>
+        This document describes how pledges discover (or be discovered by) an
         element of the network domain to which the pledge belongs to perform
         the bootstrap.  This element (device) is called the
         registrar.  Before any other operation, pledge and registrar need to

@@ -2755,6 +2772,64 @@ Reference: [This document]
 	  </t>
 	</section>
     </section>
+    <section anchor="acpapplicability" title="Applicability to the Autonomic
+                                              Control Plane">
+      <t>
+        This document provides a solution to the requirements for secure
+        bootstrap set out in <xref target="RFC8368">Using an Autonomic Control Plane for
+        Stable Connectivity of Network Operations, Administration, and
+        Maintenance </xref>, 
+        <xref target="I-D.ietf-anima-reference-model" >A Reference Model for
+        Autonomic Networking</xref> and specifically the 
+        <xref target="I-D.ietf-anima-autonomic-control-plane">An Autonomic
+        Control Plane (ACP)</xref>, section 3.2 (Secure Bootstrap), and
+        section 6.1 (ACP Domain, Certificate and Network).
+      </t>
+      <t>
+        The protocol described in this document has appeal in a number of
+        other non-ANIMA use cases.  Such uses of the protocol will be
+        deploying into other environments with different tradeoffs of
+        privacy, security, reliability and autonomy from manufacturers.
+        As such those use cases will need to provide their own applicability
+        statements, and will need to address unique privacy and security
+        considerations for the environments in which they are used.
+      </t>
+      <t>
+        The autonomic control plane that this document provides bootstrap
+        for is typically a medium to large Internet Service Provider
+        organization, or an equivalent Enterprise that has signficant layer-3
+        router connectivity.  (A network consistenting of primarily layer-2
+        is not excluded, but the adjacencies that the ACP will create and
+        maintain will not reflect the topology until all devices participate
+        in the ACP).
+      </t>
+      <t>
+        As specified in the ANIMA charter, this work "..focuses on
+        professionally-managed networks."  Such a network has an operator
+        and can do things like like install, configure and operate the
+        Registrar function.  The operator makes purchasing decisions
+        and is aware of what manufacturers it expects to see on it's
+        network.
+      </t>
+      <t>
+        Such an operator also is capable of performing the traditional
+        (craft serial-console) based bootstrap of devices. The zero-touch
+        mechanism presented in this and the ACP document represents a
+        signficiant efficiency: in particular it reduces the need to
+        put senior experts on airplanes to configure devices in person.
+        There is a recognition as the technology evolves that not every
+        situation may work out, and occasionally a human still still have to
+        visit.
+      </t>
+      <t>
+        The BRSKI protocol is going into environments where there have
+        already been quite a number of vendor proprietary management
+        systems.  Those are not expected to go away quickly, but rather to
+        leverage the secure credentials that are provisioned by BRSKI.  The
+        connectivity requirements of said management systems are provided
+        by the ACP.
+      </t>
+    </section>
     <section anchor="privacyconsiderations" title="Privacy Considerations">
       <section title="MASA audit log">
       <t>
@@ -3292,6 +3367,7 @@ Reference: [This document]
 
       <?rfc include="reference.I-D.ietf-anima-autonomic-control-plane" ?>
       <?rfc include="reference.RFC.8366" ?>
+      <?rfc include="reference.RFC.8368" ?>
       <?rfc include="reference.I-D.ietf-anima-grasp" ?>
 
       <reference anchor="IDevID"

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