Subject: [Anima] Technical comments on draft-ietf-anima-autonomic-control-plane-12 (part 2)

From: William Atwood <[email-masked]>
Date: Thu, 2 Nov 2017 23:00:40 -0400

Subject to correction of the points below, and some non-technical 
suggestions sent to the document authors, I believe that this document 
is ready to publish.

   Bill

Technical issues

1) Somewhere, the document needs to have a definitive reference to the 
definition of a VRF.  If no such reference exists, then a definition of 
Virtual Referencing and Forwarding must be given inside this document. 
This could be included in the explanation of VRF in Section 2, or 
inserted at an appropriate place in the subsequent text.

2) The ACP is defined in various ways in the ANIMA documents.  I don't 
like any of the ones that I have seen in published documents; I find the 
one in Section 3.1 of draft-ietf-anima-reference-model-05 to be 
particularly opaque.  It is very important that all definitions of the 
ACP (in the reference model, in the ACP document, etc.) say the same 
thing.  The one that I like best was suggested by Brian Carpenter in a 
discussion with me and some others:

   "The ACP is the secure transport substrate that is *used by* the ANI 
for its interactions with other *autonomic* nodes and services."

I hope that a good definition can be agreed to by all document writers; 
the important thing is that we not be seen as saying different things in 
different documents.

3) Section 6, para 2, line 3.  "following ACP specific information field 
in its domain certificate" -> "ACP specific information in the xxx field 
of its domain certificate, as specified in Section 6.1.1,"  (The word 
"following" refers to something that is 5 paragraphs away, and so is 
ambiguous.  It is important to be specific here.  Note: I cannot tell 
from the text what field of the domain certificate must contain this 
information, so I have written "xxx".  Please make the appropriate 
substitution.)

4) In Section 6.8.2, para 6, line 3.  "equally built"  (What does 
"equally" mean here?  I cannot puzzle out what is intended.)

5) In Section 6.10.1, bullet 4, this bullet appears to be talking about 
three types of addresses, "ULA", "ULA-Random", and "assigned ULA", when 
in fact there are only two.  I suggest the following text for the first 
sentence:
     "Use-ULA: For loopback interfaces of ACP nodes, we use
      Unique Local Addresses (ULA), specifically ULA-Random, as
      specified in [RFC4193]."

6) In Section 6.10.3 and Section 6.10.3.1, the phrases "zone", "Zone 
ID", "zone-ID", and "Zone-ID" are used interchangeably.  This is 
ambiguous.  Since almost all of the discussion is about the "Zone-ID" 
field, the two sections should be reviewed carefully, with the goal of 
using a single phrase throughout these two sections.  If "zone", Zone 
ID, "zone-ID", or "Zone-ID" is used elsewhere in the document, it should 
be examined.  When discussing the concept of a zone, "zone" should be 
used; when discussing the Zone-ID field, "Zone-ID" should be used.

-- 
Dr. J.W. Atwood, Eng.             tel:   +1 (514) 848-2424 x3046
Distinguished Professor Emeritus  fax:   +1 (514) 848-2830
Department of Computer Science
    and Software Engineering
Concordia University EV 3.185     email:[email-masked]
1455 de Maisonneuve Blvd. West    http://users.encs.concordia.ca/~bill
Montreal, Quebec Canada H3G 1M8

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 3 Nov 2017 16:57:44 +1300

On 03/11/2017 16:00, William Atwood wrote:
...
> used; when discussing the Zone-ID field, "Zone-ID" should be used.

This is particularly important since "zone" and "zone index" and
"zone_id" are used in a completely different sense in RFC 4007 and
other RFCs that depend on RFC 4007. In fact, it might be worth
a note that this is different from that.

I commented elsewhere that the ACP adjacency table needs to include
the interface index for link-local addresses**, and that is in fact
exactly what RFC 4007 calls the "zone index". So unless we make
this excessively clear, we can be certain that some readers will
get the two things mixed up.

** How you determine the interface index is o/s dependent, so
it's important to put this in the adjacency table, for maximum
portability of code.

   Brian