Re: [Anima] ACP document --- 07 to 08 changes

[Michael Richardson <[e-mail]>]

All of my minor edits and a few smallish friendly amendments are at:
    https://github.com/anima-wg/autonomic-control-plane/pull/3


Michael Richardson <[e-mail]> wrote:
    > I'm reading the -07 version of ACP (because it's been open in a tab

Now to the changes in -08:

    AN "Autonomic Network".  A network according to
         [I-D.ietf-anima-reference-model].  Its main components are Intent,
         Autonomic Functions and ANI.

So, I had an initial problem with this, that it referes to something we have
no idea about, "Intent". Then I wondered if this was well defined in the
reference, and I find that actually the reference model has no terminology
section.... maybe one could consider the entire document a terminology
section.  But, it seems strange to be definining this way in *this* document.
I think that it should end at the first period.  If the second sentence is
needed, it should go into the reference.

On this topic (which is not "ACP document"), I'm concerned about the amount
of (*) text in the reference model document!

    AN Domain Name  A string name (typically in a format of a DNS domain
              name) identifying an Autonomic Network.  It is stored in the
              ACP information field of an ANI devices LDevID.

re (typically..) either it's an FQDN (with all the QNAME restrictions and a
reference), or it's just a string.  Let's decide one way or the other, rather
than "typically".

I think that there are a number of other terms which should not be introduced
definitatively in this document....

5.  Inside the ACP VRF, each node sets up a virtual (loopback)
    interface with its ULA IPv6 address.

I think we should say that it's a /128.

section 6.1.2 says "Maintenance" but, it's about AN_join_registrar.

I don't think that the AN_join_registrar definition belongs in this document.
I agree that some minor bit of text should exist, but I don't think this
belongs here.  This belongs in BRSKI.
Perhaps it got clipped out in editing, but that's a bug.


section 6.6:
        If our devices certificate indicates a CDP or OCSP then the peers
        certificate must be valid occrding to those (eg: OCSP check across
        the ACP or not listed in the CRL).
        {see git for a grammar fix to above}

Somewhere, I think that we should be saying that Certificate
Distribution Points (CDPs) or OCSP servers (whichever is used) SHOULD be
available via the connections inside the ACP.    BUT, as those things are
usually referenced with names there are some MIF-like isues that I think the
ACP document should address:
1) DNS.
2) address preferences.
(Homenet's naming architecture is dealing with the same questions, but I
think the answers may be different)

6.8.1.  GRASP as a core service of the ACP

I think that this section is really important.
Too important to belong buried in a document about to build secure tunnels
for IP traffic.   At the least, this belongs prominently in the reference
model document.  At the largest, it needs a new document with a title like:
    "The ACP profile of GRASP as a core service"

along with 6.8.2.

re 6.10.2:
   -> 8+40+2 = 50 bits.
   so why in 6.10.3 says, "51 bits" for subscheme.

I don't find the rational for the V bit very convincing. I don't think you
need any real justification for it.

6.10.4.  ACP V8 Addressing Sub-Scheme
     The sub-scheme defined here is defined by the Type value 1 (one) in
     the base scheme.

I think you mean, "Type value 01 (one)", since there are two type bits.
I find the use of 1 confusing, given that we also have the Z bit.
You've made me happy with the address definition.

I sent some text via pull request to clarify some of the no-artifact choice
in RPL.  most of the rest of the text looks great to me...
(I just learnt that "artefact" was british spelling for artifact.. I guess we
just need to pick one or the other.)

I'll have to ask Pascal why he suggested:
      Trickle: Not used.

7.1 --- a pretty important section.
One consideration that might be worth doing in a future document is
registering a TLV for LLDP (CDP) that could carry GRASP M_FLOOD ACP
messages. That would please switch fabric vendors because then making the
topologies follow physical would be very easy. LLDP does not get forwarded.

I wonder who knows the right IEEE incantations to do this.

section 10.1: it seems like it's all been said already.
section 10.2 ---> move to an appendix.
section 10.3 ---> appendix or cut.
I see that it all *WAS* in an appendix. I don't know why you moved it.




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