Draft: draft-ietf-anima-autonomic-control-plane

Commentary: I discovered that the .xml file had -13 in it , which made me think that I was editing a not - most - recent version . So I removed all the bad .xml files around . The point of using  is that there is history in .xml , and if you want a record of where things are , then make branches or tags . And there is n't a - file . I grabbed - from the DT and put it place , and deleted the others . I edited the ACP rfc822name definitions , moving the routing - subdomain out of the middle , since it 's actually not relevant to an implementor . Also fixed the description , because it 's something that the ACP simply uses ONCE ( at configuration time ) to generate the 48 - bit ULA . It ca n't generate it each time , because it has to keep track of which ACP spaces are in use , etc . I changed text around Vlong to name the first bit of the Node - Number as the " F " , for format , so that the description is more understandable .
When Alice and Bob successfully establish the GRASP/TSL session, they
will negotiate the channel mechanism to use using objectives such as
performance and perceived quality of the security.  After agreeing on
a channel mechanism, Alice and Bob start the selected Channel
protocol.  Once the secure channel protocol is successfully running,
the GRASP/TLS connection can be kept alive or timed out as long as
the selected channel protocol has a secure association between Alice
and Bob.  When it terminates, it needs to be re-negotiated via GRASP/
TLS.
Negotiation of a channel type may require IANA assignments of code
points.
TLS is subject to reset attacks, which IKEv2 is not.  Normally,
ACP connections (as specified in this document) will be over link-
local addresses so the attack surface for this one issue in TCP
should be reduced (note that this may not be true when ACP is
tunneled as described in conf-tunnel.
GRASP packets received inside a TLS connection established for
GRASP/TLS ACP negotiation are assigned to a separate GRASP domain
unique to that TLS connection.
An ACP domain is the set of all ACP nodes using certificates from the
same CA using the same domain field.  GRASP inside the ACP is run
across all transitively connected ACP nodes in a domain.
The rsub element in the domain information field primarily allows to
use addresses from different ULA prefixes.  One use case is to create
multiple networks that initially may be separated, but where it
should be possible to connect them without further extensions to ACP
when necessary.
Another use case for routing subdomains is as the starting point for
structuring routing inside an ACP.  For example, different routing
subdomains could run different routing protocols or different
instances of RPL and auto-aggregation / distribution of routes could
be done across inter routing subdomain ACP channels based on
negotiation (e.g.: via GRASP).  This is subject for further work.
RPL scales very well.  It is not necessary to use multiple routing
subdomains to scale ACP domains in a way it would be possible if
other routing protocols where used.  They exist only as options for
the above mentioned reasons.
If different ACP domains are to be created that should not allow to
connect to each other by default, these ACP domains simply need to
have different domain elements in the domain information field.
These domain elements can be arbitrary, including subdomains of one
another: Domains "example.com" and "research.example.com" are
separate domains if both are domain elements in the domain
information element of certificates.
It is not necessary to have a separate CA for different ACP domains:
an operator can use a single CA to sign certificates for multiple ACP
domains that are not allowed to connect to each other because the
checks for ACP adjacencies includes comparison of the domain part.
If multiple independent networks choose the same domain name but had
their own CA, these would not form a single ACP domain because of CA
mismatch.  Therefore there is no problem in choosing domain names
that are potentially also used by others.  Nevertheless it is highly
recommended to use domain names that one can have high probability to
be unique.  It is recommended to use domain names that start with a
DNS domain names owned by the assigning organization and unique
within it.  For example "acp.example.com" if you own "example.com".
Future extensions, primarily through intent can create more flexible
options how to build ACP domains.
Intent could modify the ACP connection check to permit connections
between different domains.
If different domains use the same CA one would change the ACP setup
to permit for the ACP to be established between the two ACP nodes,
but no routing nor ACP GRASP to be built across this adjacency.  The
main difference over routing subdomains is to not permit for the ACP
GRASP instance to be built across the adjacency.  Instead, one would
only build a point to point GRASP instance between those peers to
negotiate what type of exchanges are desired across that connection.
This would include routing negotiation, how much GRASP information to
transit and what data-plane forwarding should be done.  This approach
could also allow for Intent to only be injected into the network from
one side and propagate via this GRASP connection.
If different domains have different CAs, they should start to trust
each other by intent injected into both domains that would add the
other domains CA as a trust point during the ACP connection setup -
and then following up with the previous point of inter-domain
connections across domains with the same CA (e.g.: GRASP
negotiation).
The ACP specifies the use of ULA and deriving its prefix from the
domain name so that no address allocation is required to deploy the
ACP.  The ACP will equally work not using ULA but any other /50 IPv6
prefix.  This prefix could simply be a configuration of the
registrars when using BRSKI to enroll the domain certificates -
instead of the registrar deriving the /50 ULA prefix from the AN
domain name.
Some solutions may already have an auto-addressing scheme, for
example derived from existing unique device identifiers (e.g.: MAC
addresses).  In those cases it may not be desirable to assign
addresses to devices via the ACP address information field in the way
described in this document.  The certificate may simply serve to
identify the ACP domain, and the address field could be empty/unused.
The only fix required in the remaining way the ACP operate is to
define another element in the domain certificate for the two peers to
decide who is Alice and who is Bob during secure channel building.
Note though that future work may leverage the acp address to
authenticate "ownership" of the address by the device.  If the
address used by a device is derived from some pre-existing permanent
local ID (such as MAC address), then it would be useful to store that
address in the certificate using the format of the access address
information field or in a similar way.
The ACP is defined as a separate VRF because it intends to support
well managed networks with a wide variety of configurations.
Therefore, reliable, configuration-indestructible connectivity cannot
be achieved from the data-plane itself.  In solutions where all
transit connectivity impacting functions are fully automated
(including security), indestructible and resilient, it would be
possible to eliminate the need for the ACP to be a separate VRF.
Consider the most simple example system in which there is no separate
data-plane, but the ACP is the data-plane.  Add BRSKI, and it becomes
a fully autonomic network - except that it does not support automatic
addressing for user equipment.  This gap can then be closed for
example by adding a solution derived from I-D.ietf-anima-prefix-
management.
The routing protocol chosen by the ACP design (RPL) does explicitly
not optimize for shortest paths and fastest convergence.  Variations
of the ACP may want to use a different routing protocol.
Variations such as what routing protocol to use, or whether to
instantiate an ACP in a VRF or (as suggested above) as the actual
data-plane, can be automatically chosen in implementations built to
support multiple options by deriving them from future parameters in
the certificate.  Parameters in certificates should be limited to
those that would not need to be changed more often than certificates
would need to be updated anyhow; Or by ensuring that these parameters
can be provisioned before the variation of an ACP is activated in a
node.  Using BRSKI, this could be done for example as additional
follow-up signaling directly after the certificate enrolment, still
leveraging the BRSKI TLS connection and therefore not introducing any
additional connectivity requirements.
Last but not least, secure channel protocols including their
encapsulation are easily added to ACP solutions.  Secure channels may
even be replaced by simple neighbor authentication to create
simplified ACP variations for environments where no real security is
required but just protection against non-malicious misconfiguration.
Or for environments where all traffic is known or forced to be end-
to-end protected and other means for infrastructure protection are
used.  Any future network OAM should always use end-to-end security
anyhow and can leverage the domain certificates and is therefore not
dependent on security to be provided for by ACP secure channels.
An ACP is self-protecting and there is no need to apply configuration
to make it secure.  Its security therefore does not depend on
configuration.
An ACP is self-protecting and there is no need to apply configuration
to make it secure.  Its security therefore does not depend on
configuration.  See self-protecting for details of how the ACP
protects itself against attacks from the outside and to a more
limited degree from the inside as well.
IPv6 addresses used by nodes in the ACP are covered as part of the
nodes domain certificate as described in domcert-acpinfo.  This
allows even verification of ownership of a peers IPv6 address when
using a connection authenticated with the domain certificate.
IPv6 addresses used by nodes in the ACP are covered as part of the
node's domain certificate as described in domcert-acpinfo.  This
allows even verification of ownership of a peers IPv6 address when
using a connection authenticated with the domain certificate.
The ACP is designed to minimize attacks from the outside by
minimizing its dependency against any non-ACP operations on a node.
The only dependency in the specification in this document is the need
to share link-local addresses for the ACP secure channel
encapsulation with the data-plane.  See general_addressing.
In combination with BRSKI, ACP enables a resilient, fully zero-touch
network solution for short-lived certificates that can be renewed or
re-enrolled even after unintentional expiry (e.g.: because of
interrupted connectivity).  See bootstrap.
The ACP is designed to minimize attacks from the outside by
minimizing its dependency against any non-ACP (Data-Plane)
operations/configuration on a node.  See also general_addressing.
In combination with BRSKI, ACP enables a resilient, fully zero-touch
network solution for short-lived certificates that can be renewed or
re-enrolled even after unintentional expiry (e.g., because of
interrupted connectivity).  See bootstrap.
The IANA is requested to create an ACP Parameter Registry with
currently one registry table - the "ACP Address Type" table.
Changed focus: more focus on autonomic functions, not only virtual
out of band.  This goes a bit throughout the document, starting
with a changed abstract and intro.
Changed focus: more focus on autonomic functions, not only virtual
out-of-band.  This goes a bit throughout the document, starting
with a changed abstract and intro.
scheme: changed from MD5 for calculating the first 40 bits to
SHA256; reason is MD5 should not be used any more.
scheme: changed from MD5 for calculating the first 40-bits to
SHA256; reason is MD5 should not be used any more.
Fixed up text for ACP/GRE encap.  Removed text claiming its
incompatible with non-GRE IPsec and detailled it.
Fixed up text for ACP/GRE encap.  Removed text claiming its
incompatible with non-GRE IPsec and detailed it.
Enhanced text for ACP across tunnels to decribe two options: one
across configured tunnels (GRE, IPinIP etc) a more efficient one via
directed DULL.
Moved decription of BRSKI to appendex to emphasize that BRSKI is not
a (normative) dependency of GRASP, enhanced text to indicate other
options how Domain Certificates can be provisioned.
Enhanced text for ACP across tunnels to describe two options: one
across configured tunnels (GRE, IPinIP etc) a more efficient one via
directed DULL.
Moved decription of BRSKI to appendix to emphasize that BRSKI is not
a (normative) dependency of GRASP, enhanced text to indicate other
options how Domain Certificates can be provisioned.
Enhanced "self-protection" properties section: protect legacy
management protocols.  Security in ACP is for protection from outside
and those legacy protocols.  Otherwise need end-to-end encryption
also inside ACP, e.g.: with domain certificate.
Enhanced "self-protection" properties section: protect legacy
management protocols.  Security in ACP is for protection from outside
and those legacy protocols.  Otherwise need end-to-end encryption
also inside ACP, e.g., with domain certificate.
Added reference to RFC4191 and explained how it should be used on ACP
edge routers to allow autoconfiguration of routing by NMS hosts.
This came after review of stable connectivity draft where ACP connect
is being referred to.
Added reference to RFC4191 and explained how it should be used on ACP
edge routers to allow auto configuration of routing by NMS hosts.
This came after review of stable connectivity draft where ACP connect
is being referred to.
Added new ACP "Manual" addressing sub-scheme with /64 subnets for
use with ACP connect interfaces.  Being covered by the ACP ULA
prefix, these subnets do not require additional routing entries
for NMS hosts.  They also are fully 64-bit IID length compliant
and therefore not subject to 4191bis considerations.  And they
avoid that operators manually assign prefixes from the ACP ULA
prefixes that might later be assigned autonomiously.
ACP connect auto-configuration: Defined that ACP edge devices, NMS
hosts should use RFC4191 to automatically learn ACP prefixes.
This is especially necessary when the ACP uses multiple ULA
prefixes (via e.g.: the rsub domain certificate option), or if ACP
connect subinterfaces use manually configured prefixes NOT covered
by the ACP ULA prefixes.
Added a separate subsection to talk about "software" instead of
"NMS hosts" connecting to the ACP via the "ACP connect" method.
The reason is to point out that the "ACP connect" method is not
only a workaround (for NMS hosts), but an actual desirable long
term architectural component to modularily build software (e.g.:
ASA or OAM for VNF) into ACP devices.
Added new ACP "Manual" addressing sub-scheme with /64 subnets for
use with ACP connect interfaces.  Being covered by the ACP ULA
prefix, these subnets do not require additional routing entries
for NMS hosts.  They also are fully 64-bit IID length compliant
and therefore not subject to 4191bis considerations.  And they
avoid that operators manually assign prefixes from the ACP ULA
prefixes that might later be assigned autonomically.
ACP connect auto-configuration: Defined that ACP edge devices, NMS
hosts should use RFC4191 to automatically learn ACP prefixes.
This is especially necessary when the ACP uses multiple ULA
prefixes (via e.g., the rsub domain certificate option), or if ACP
connect sub-interfaces use manually configured prefixes NOT
covered by the ACP ULA prefixes.
Added a separate subsection to talk about "software" instead of
"NMS hosts" connecting to the ACP via the "ACP connect" method.
The reason is to point out that the "ACP connect" method is not
only a workaround (for NMS hosts), but an actual desirable long
term architectural component to modularly build software (e.g.,
ASA or OAM for VNF) into ACP devices.
Made this ACP document be an update to RFC4291 and RFC4193.  At the
core, some of the ACP addressing sub-schemes do effectively not use
64-bit IIDs as required by RFC4191 and debated in rfc4191bis.  During
6man in prague, it was suggested that all documents that do not do
this should be classified as such updates.  Add a rather long section
that summarizes the relevant parts of ACP addressing and usage and.
Aka: This section is meant to be the primary review section for
readers interested in these changes (e.g.: 6man WG.).
Made this ACP document be an update to RFC4291 and RFC4193.  At the
core, some of the ACP addressing sub-schemes do effectively not use
64-bit IIDs as required by RFC4191 and debated in rfc4191bis.  During
6man in Prague, it was suggested that all documents that do not do
this should be classified as such updates.  Add a rather long section
that summarizes the relevant parts of ACP addressing and usage and.
Aka: This section is meant to be the primary review section for
readers interested in these changes (e.g., 6man WG.).
and multipoint).  Did seek for pre-existing RFCs that explain how to
built a multi-access interface on top of a full mesh of p2p
connections (6man WG, anima WG mailing lists), but could not find any
prior work that had a succinct explanation.  So wrote up an
explanation here.  Added hopefully all necessary and sufficient
details how to map ACP unicast packets to ACP secure channel, how to
deal with ND packet details.  Added verbage for ACP not to assign the
virtual interface link-local address from the underlying interface.
Addd note that GRAP link-local messages are treated specially but
logically the same.  Added paragraph about NBMA interfaces.
and multipoint).  Did seek for pre-existing RFCs that explain how to
build a multi-access interface on top of a full mesh of p2p
connections (6man WG, anima WG mailing lists), but could not find any
prior work that had a succinct explanation.  So wrote up an
explanation here.  Added hopefully all necessary and sufficient
details how to map ACP unicast packets to ACP secure channel, how to
deal with ND packet details.  Added verbiage for ACP not to assign
the virtual interface link-local address from the underlying
interface.  Added note that GRAP link-local messages are treated
specially but logically the same.  Added paragraph about NBMA
interfaces.
GRASP unicsast connections across ACP is double encryption (plus
underlying ACP secure channel), but highly necessary to avoid very
simple man-in-the-middle attacks by compromised ACP members on-path.
Ultimately, this is done to ensure that any apps using GRASP can get
full end-to-end secrecy for information sent across GRASP.  But for
publically known ASA services, even this will not provide 100%
security (this is discussed).  Also why double encryption is the
better/easier solution than trying to optimize this.
GRASP unicast connections across ACP is double encryption (plus
underlying ACP secure channel), but highly necessary to avoid very
simple man-in-the-middle attacks by compromised ACP members on-path.
Ultimately, this is done to ensure that any apps using GRASP can get
full end-to-end secrecy for information sent across GRASP.  But for
publically known ASA services, even this will not provide 100%
security (this is discussed).  Also why double encryption is the
better/easier solution than trying to optimize this.
attaacks (not an issue for ACP).
attacks (not an issue for ACP).
specified what needs to be done (e.g.: in 2 switches doing ACP per L2
port).
specified what needs to be done (e.g., in 2 switches doing ACP per L2
port).
Same text as -10 Unfortunately when uploading -10 .xml/.txt to
datatracker, a wrong version of .txt got uploaded, only the .xml was
correct.  This impacts the -10 html version on datatra cker and the
PDF versions as well.  Because rfcdiff also compares the .txt
version, this -11 version was crea ted so that one can compare
changes from -09 and changes to the next version (-12).
Same text as -10 Unfortunately when uploading -10 .xml/.txt to
datatracker, a wrong version of .txt got uploaded, only the .xml was
correct.  This impacts the -10 html version on datatracker and the
PDF versions as well.  Because rfcdiff also compares the .txt
version, this -11 version was created so that one can compare changes
from -09 and changes to the next version (-12).
Removed the claim that the document is updating RFC4291,RFC4193 and
the section detailling it.  Done on suggestion of Michael Richardson
- just try to describe use of addressing in a way that would not
suggest a need claim update to architecture.
Removed the claim that the document is updating RFC4291,RFC4193 and
the section detailing it.  Done on suggestion of Michael Richardson -
just try to describe use of addressing in a way that would not
suggest a need claim update to architecture.
Replaced term "autonomic FOOBAR" with "acp FOOBAR" as whereever
appropriate: "autonomic" would imply that the node would need to
support more than the ACP, but that is not correct in most of the
cases.  Wanted to make sure that implementers know they only need
to support/implement ACP - unless stated otherwise.  Includes
"AN->ACP node", "AN->ACP adjacency table" and so on.
Replaced term "autonomic FOOBAR" with "acp FOOBAR" as wherever
appropriate: "autonomic" would imply that the node would need to
support more than the ACP, but that is not correct in most of the
cases.  Wanted to make sure that implementers know they only need
to support/implement ACP - unless stated otherwise.  Includes
"AN->ACP node", "AN->ACP adjacency table" and so on.
Important to discuss this for security reasons (e.g.: why to never
never auto-enable ANI on brownfield devices), for implementers and to
answer ongoing questions during WG meetings about how to deal with
shutdown interface.
Important to discuss this for security reasons (e.g., why to never
auto-enable ANI on brownfield devices), for implementers and to
answer ongoing questions during WG meetings about how to deal with
shutdown interface.
various: Autonomous -> autonomic(ally) in all remaining occurances.
various: Autonomous -> autonomic(ally) in all remaining occurrences.
6.10.5 Fixed length of Node-Numbers in ACP Vlong Addressing Sub-
Scheme.
Disclaimer: All new text introduced by this revision provides only
additional explanations/ details based on received reviews and
analysis by the authors.  No changes to behavior already specified in
prior revisions.
Unclear how much ACP depends on BRSKI.  ACP document was referring
unqualified to registrars and Registrar-ID in the addressing
section without explaining what a registrar is, leading to the
assumption it must be a BRSKI Registrar.
Unclear how the ACP addresses in ACP domain certificates are
assigned because the BRSKI document does not defines this, but
refers to this ACP document.
Wrt. 1: ACP does NOT depend on BRSKI registrars, instead ANY
appropriate automated or manual mechanism can be used to enroll ACP
nodes with ACP domain certificates.  This revision calls defines such
mechanisms the "ACP registrar" and defines requirements.  this is
non-normative, because it does not define specific mechanisms that
need to be support.  In ANI devices, ACP Registrars are BRSKI
Registrars.  In non-ANI ACP networks, the registrar may simply be a
person using CLI/web-interfaces to provision domain certificates and
set the ACP address correctly in the ACP domain certificate.
Wrt. 2.: The BRSKI document does rightfully not define how the ACP
address assignment and creation of the ACP domain information field
has to work because this is independent of BRSKI and needs to follow
the same rules whatever protocol/mechanisms are used to implement an
ACP Registrar.  Another set of protocols that could be used instead
of BRSKI is Netconf/Netconf-Call-Home, but such an alternative ACP
Registrar solution would need to be specified in its own document.
Additional text/sections had to be added to detail important
conditions so that automatic certificate maintenance for ACP nodes
(with BRSKI or other mechanisms) can be done in a way that as good as
possible maintains ACP address information of ACP nodes across the
nodes lifetime because that ACP address is intended as an identifier
of the ACP node.
6.1.3.5/6.1.3.6 (normative): re-enrollment of ACP nodes after
certificate expiry/failure in a way that allows to maintain as
much as possible ACP address information.
6.10.7 (normative): defines "ACP Registrar" including requirements
and how it can perform ACP address assignment.
10.3 (informative): details / examples about registrars to help
implementers and operators understand easier how they operate, and
provide suggestion of models that a likely very useful (sub-CA
and/or centralized policy management).
10.4 (informative): Explains the need for the multiple address
sub-spaces defined in response to discuss with Joel.
Updated references (RFC8366, RFC8368).
Introduced sub-section headings for 6.1.3 (certificate maintenance)
because section became too long with newly added sub-sections.  Also
some small text fixups/remove of duplicate text.
4. added explanation for ACP4 (finally).
6.1.1 Simplified text in bullet list explaining rfc822 encoding.
6.1.3 refined second paragraph defining remembering of previous EST
server and explaining how to do this with BRSKI.
9.1 Added paragraph outlining the benefit of the sub-CA Registrar
option for supporting partitioned networks.
6.1.1: added note about "+ +" format in address field when acp-
address and rsub are empty.
6.5.10 - clarified text about V bit in Vlong addressing scheme.
6.10.3/6.10.4 - moved the Z bit field up front (directly after base
scheme) and indicated more explicitly Z is part of selecting of the
sub-addressing scheme.
Refined text about reaching CRL Distribution Point, explain why
address as indicator to use ACP.
Note from Brian Carpenter: RFC Editor note for section reference into
GRASP.
Various Nits/typos.
TBD: Punted wish for mentioning RFC reference titles to RFC editor
for now.
1.  Added section 1.1 - applicability, discussing protocol choices
re. applicability to constrained devices (or not).  Added notion of
TCP/TLS via CoAP/DTLS to section 10.4 in support of this.
2.  Added in-band / out-of-band into terminology.
5.  Referenced section 8.2 for remote ACP channel configuration.
6.7.x Clarified conditional nature of MUST for the profile details of
IPsec parameters (aka: only 6.7.3 defines actual MUST for nodes,
prior notions only define the requirements for IPsec profiles IF
IPsec is supported.
6.8.1 Moved discussion about IP multicast, IGP, RPL for GRASP into a
new subsection in the informative part (section 10) to tighten up
text in normative part.
6.10.1 added another reference to stable-connectivity for interop
with IPv4 management.
6.10.1 removed mentioning of ULA-Random, term was used in email
discus of ULA with L=1, but term actually not defined in rfc4193, so
mentioning it is just confusing/redundant.  Also added note about the
random hash being defined in this document, not using SHA1 from
rfc4193.
6.11.1.1 added suggested text about mechanisms to further reduce
opportunities for loop during reconvergence (active signaling options
from RFC6550).
6.11.1.3 made mode 2 MUST and mode 2 MAY (RPL MOP - mode of
operations).  Removes ambiguity.
6.12.5 Added recommendation for RFC4429 (optimistic DAD).
1. swapped order of "purposes" for ACP to match order in section 3.
1.  Added notion about manageability of ACP gong beyond RFC7575
(before discussion of stable connectivity).
2.  Changed definition of Intent to be same as reference model
(policy language instead of API).
6.1.1 changed BNF specification so that a local-part without acp-
address (for future extensions) would not be rfcSELF.+rsub but
simpler rfcSELF+rsub.  Added explanation why rsub is in local-part.
Tried to eliminate unnecessary references to VRF to minimize
assumption how system is designed.
6.1.3 Explained how to make CDP reachable via ACP.
6.7.2 Made it clearer that constrained devices MUST support DTLS if
they cannot support IPsec.
6.8.2.1 clarified first paragraph (TCP retransmissions lightweight).
6.11.1 fixed up RPL profile text - to remove "VRF".  Text was also
buggy. mentioned control plane, but it's a forwarding/silicon issue
to have these header.
6.12.5 Clarified how link-local ACP channel address can be derived,
and how not.
8.2.1 Fixed up text to distinguish between configuration and model
describing parameters of the configuration (spec only provides
parameter model).
Only reshuffling and formatting changes, but wanted to allow
reviewers later to easily compare -13 with -14, and these changes in
-15 mess that up too much.
increased TOC depth to 4.
Separated and reordered section 10 into an operational and a
background and futures section.  The background and futures could
also become appendices if the layout of appendices in RFC format
wasn't so horrible that you really only want to avoid using them (all
the way after a lot of text like references that stop most readers
from proceeding any further).
Tightened requirements for ACP related GRASP objective timers.
Better text to introduce/explains baseline and constrained ACP
profiles.
IANA guideline: MUST only accept extensible last allocation for
address sub-scheme.
Moved section 11 into appendix.
Removed "global routing table", replaced with "Data-Plane routing
(and forwarding) tables.
added text to indicate how routing protocols do like to have data-
plane dependencies.
Changed power consumption section re. admin-down state.  Power needed
to bring up such interfaces make t inappropriate to probe.  Need to
think more about best suggests -> beyond scope.
Replaced "console" with out-of-band... (console/management ethernet).
Fixed up domain information field ABNF to eliminate confusion that
rsub is not an FQDN but only a prefix to routing-subdomain.
Corrected certcheck to separate out cert verification into lifetime
validity and proof of ownership of private key.
Fixed pagination for "ACP as security and transport substrate for
GRASP" picture.
NOC nodes have ACP domain cert without acp-address field.  Are ACP
domain members, but cannot build ACP secure channels (just end-to-end
or nay other authentications.
ACP nodes may have other methods to assign ACP address than getting
it through the cert.  This is indicated through new value 0 for acp-
address in certificate.
Accordingly modified texts in ABNF/explanation and Cert-Check
section.
Eliminated perception that "rsub" (routing subdomain) is only
beneficial with future work.  Example in A.7.
Added RFC-editor note re formatting of references to terms defined in
terminology section.
Using now correct RFC 8174 boilerplate.
Clarified semantic and use of manual ACP sub-scheme.  Not used in
certificates, only assigned via traditional methods.  Use for ACP-
connect subnets or the like.
Corrected text about Data-Plane dependencies of ACP.  Appropriate
implementations can be fully data-plane independent (without more
spec work) if not sharing link-local address with Data-Plane. 6.12.2
text updated to discuss those (MAC address), A.10.2 discusses options
that would require new standards work.
Moved all text about Intent into A.8 to clearly mark it as futures.
Changed suggestion of future insecure ACP option to future "end-to-
end-security-only" option.
Various textual fixes.
Some fixes also mentioned by Alissa.
Added reference for OT.
Fixed notion that secure channel is not only a security association.
Added picture requested by Pascal Thubert about Dual-NOC (A.10.4).
Moved RFC-editor request for better first RFC reference closer to the
top of the document.
Fixed typo /126 -> 127 for prefix length with zone address scheme.
most issues fixed through other review in -16.  Added reference to
self-protection section 9.2 into security considerations section.
Too many word/grammar mistakes in -17.