Subject: Re: [Anima] Reference draft, version 5

From: "Michael H. Behringer" <[email-masked]>
Date: Wed, 11 Oct 2017 15:47:10 +0200

Just incorporated the comments from Artur into the draft (on github for now), FYI:

On 26/07/17 19:55, Artur Hecker wrote:
> Dear community, dear Authors,
>
>
> I reread the draft-ietf-anima-reference-model-04. I hope it's not arriving at an inappropriate moment, but please find some notes and remarks below:
>
>
> 1. Page 6: s/potentiall/potential

Fixed.

>
> 2. Page 8: Section 4. The text mentions "must implement" and "other" functions, but fails to correctly guide the reader as to the MUST or not MUST of the functions in the following subsections. It is partly not even clear from the semantics of the subsections.
>
> Suggestion: clearly group MUST, SHOULD and MAY IMPLEMENT functions in the subsections.
>

In re-reading this section, and considering it's an informational document,
I agree this is misleading. For a while I was playing around with various
"must" and "should" ideas, but abandoned this idea.

The draft is too generic to even start to indicate what is "must" or "should".
So I now completely removed the "musts" etc in the intro of this section.
With that change, I think it reads correctly for an informational document.

It's finally up to the other drafts (ACP, BRSKI, etc) to specify what is MUST
and SHOULD.

> 3. Page 12: Information Distribution - consider rewriting parts of this section entirely. Several problems:
>
> a) Remove repetitive text in the beginning:
> "Certain forms of information, such as Intent, must be distributed across an autonomic domain. The distribution of information is also a function of the Autonomic Control Plane.  One form of such information is Intent."
>
> Suggestion: Either remove the first inclusion, or the entire last sentence. I would rewrite these three, see next point:
>
> b) There seems to be a problem with the statement above, as the "must" is somehow misleading in a potentially normative text. What is meant here is that some information requires dissemination, while other might not require that.
>
> Suggestion - please REWRITE e.g. as follows:
> "Certain forms of information require per its nature distribution across a (part of) autonomic domain. Such information distribution is a function of the Autonomic Control Plane. As an example, Intents require distribution across the whole autonomic domain as per definitions from RFC7575."

Agree with a) and b) and have changed the text accordingly.

> c) Later, the text in this section somehow confuses the high level requirements (=information distribution) with a specific implementation, notably flooding. Note that there is a subtle difference between the requirement to reach all recipients (indeed, the current text seems to equal flooding to that) and flooding, which technically usually means "unconstrained broadcast". [E.g. Wikipedia: "Flooding is a simple computer network routing algorithm in which every incoming packet is sent through every outgoing link except the one it arrived on"]. This will lead to explosive message number growth, as the ACP uses routing - which does not guarantee a tree structure - while the scale of an autonomic domain is, by definitions of RFC7575, only constrained by the Intent as such ("the autonomic domain is the set of nodes, to which the intent needs to be sent"). At the same time, there are better known algorithms for routing, which achieve "distribution to all recipients" without "sending on al
>   l links except the one it arrived on" (e.g. structured broadcast, etc).
>
> Suggestion: stay at the requirements level in the Reference text, which this draft represents. In other words, remove suggestions of implementations, or reword if the requirement to reach all nodes is meant.

Disagree in some points with this one. There are different ways of flooding,
and we're not suggesting an implementation here. I think that the phrasing
with "should" is weak enough not to confuse, and I think we *do* want to make
the point that this should be very simple.
BTW, flooding is entirely independent of the routing protocol in our case.
Please re-read. If you really have a problem, shout again! :-)

> 4. Page 17, Section 6.3.3.  The Information Distribution ASA (*).
> While the text above (on page 12: Information Distribution) says that Information Distribution is function of ACP, somehow there is a distinct section in this draft, talking about an Information Distribution ASA, which is NOT ACP ASA, and which is not obligatory.
>
> How to read this correctly?

Hmmm...
Information distribution is implemented as an ASA. That is really the main
point of section 6.3.3.
I think the confusion is in the term "is a function of the ACP".
I'll replace that with "runs inside the ACP".
ASAs typically run on the ACP. See also figure 2.

There was a view in the WG that Intent may not be required on all nodes in a
domain. For example, you may have simple sensors at the edge which join the
ACP but don't act on Intent.

Does that make it clearer? Re-Reading 6.3.3, I think it is actually correct as
written... (the change was in the previous section).
  
>
> 5. Page 17, Section 7.1: "How an AN Network Is Managed"
> a) Please consider changing the title. AN is "autonomic network" network network :-)

I agree that the heading raises eyebrows, this is why the very first
sentence explains this seeming contradiction: We're talking about partially
autonomic networks, which the WG feels will be the common implementation for
a long while.

What about: "Managing a (partially) Autonomic Network" as a title? I'll use this
one for now.

> b) The first paragraph says that the co-existence is twofold. However, I can think of at least one other way: the ACP could be used as a transport channel for "traditional" management. E.g. ACP could be used to transport NETCONF messages, instead of SSH or BEEP in NETCONF. Not clear, what twofold means here (just an example, limitation, strong statement, etc).

Yes, misleading. Re-worked that paragraph, and added your example. Please re-read.

>
> 6. Page 18, Section 7.2: "Intent"
> Please reread and correct this phrase: "It is expected Intent definitions from autonomic function(s) and even from traditional network management elements". (missing verb)

Removed that sentence.

> Later in the text, the section references I-D.liu-anima-grasp-distribution, which is odd, given that the actual Information Distribution section (see above) does not. Yet, information distribution in I-D.liu-anima-grasp-distribution is not limited to intents.

Added reference in the above section. Information distribution *includes* Intent,
but there is other information. I think we've been consistent on this point.

> 7. Page 19, Section 7.5: "Control loops"
> The section talks about an "Autonomic System". Unless I am mistaken, an autonomic system is not defined (e.g. in RFC7575). This is a minor issue, as we all can imagine what a "system" is.

Changed to "autonomic network".

> 8. Page 20, Section 7.6: "APIs"
> There is a strong "MUST" requirement in this section (express and preserve semantics across different domains), which is not as clear as a MUST should be. First, it's not clear what "express and preserve semantics" means (semantics of what? Of objects? Of object methods? Of the results delivered by object methods? Of all of them?). Second, the "domain" is not defined: is an autonomic domain meant? Note that this notion is dynamic, as per intent scope, so probably not a very good reference. Third, the requirement is not corroborated clearly. Instead, an example is given, which we might discuss in its relevance to the ANIMA WG and work scope. Is ANIMA implementing software contracts? Is it a MUST requirement? Probably not. Note that web-based systems today have no such formal specifications, as mentioned in this section. Example: invariants; these are nice to have, but hard to determine for any complex piece of software (like a web service, etc).

I think what was meant was "APIs must be able to express and preserve
the semantics of data models."

Will change accordingly for now. Who was the author of this section? John? Please
re-view and comment. We clearly want to avoid doing the precise specs here, and we
should focus on the AN specific points only.

> 9. Page 20, Section 7.7: "Data Model"
> Question: why do we need this section? This looks like some text book. Do we have a specification of data model in ANIMA? Information model? Anything like that? If not, I guess this can be shortened, as it is "for reference" only. (What is MRACL? Used without explanation in text).

This section was provided by John and I leave him to comment here. I think the
main point was to explain the need for a data and information model.

> 10. Page 22, Section 8.1:
> s/mechanisms exists/mechanisms exist.

fixed.

> 11.  Page 23, Section 9: "Security Considerations"
> Please rephrase "run inside the encrypted ACP". I hope that it's not simply "encrypted" but actually features the full range of cryptographic data protection methods.
>
> Rationale: I would argue that integrity is more important than confidentiality in the ANIMA scope. As encryption alone does not provide any protection against modification, and since hopefully the used mechanisms (see Section 9.2) go beyond encryption, I would recommend to use a more correct wording, something like "protected" or "cryptographically protected ACP".
>
> Generally, the section does not sufficiently presents the threat of message modification and replay, including the discovery messages. Also, authentication is not sufficiently covered, even though a reference to I-D.ietf-anima-bootstrapping-keyinfra is made. Not sure it's the best approach, as bootstrapping refers to how to enroll the node, and the authentication is probably using standard mechanisms? Normally, the threats should be described independently of the specific mechanisms.

I'll work over the security considerations in the next step. Point taken :-)

Thanks a lot for the input Artur!

The github version now contains all the changes mentioned above.

Michael

> Regards
> artur

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 12 Oct 2017 08:18:23 +1300

On 12/10/2017 02:47, Michael H. Behringer wrote:
...> It's finally up to the other drafts (ACP, BRSKI, etc) to specify what is MUST
> and SHOULD.

Agreed. That's not to say that lower case must, should etc. are forbidden in
an informational document where they fit naturally in the text, but we should
not accidentally make the reference model normative.
...
> There are different ways of flooding,

Yes. It has sometimes been interpreted to simply mean broadcast (like ARP) but
I don't see it as a misleading word in this case.

...
> Information distribution is implemented as an ASA

That isn't entirely consistent with draft-liu-anima-grasp-distribution.
I know that's not a WG document, but it's what we have so far.
I think a better statement is:
  Information distribution is implemented as an ASA function.
The subtle difference is that it might be built into an existing
ASA. For example, in draft-ietf-anima-prefix-management we have
an objective "PrefixManager.Params" for distributing information.

However, I expect generic information such as Intent will be
handled by a generic ASA.

I think this can be fixed with a little wordsmithing of 6.3.3. 

    Brian

---

From: "Michael H. Behringer" <[email-masked]>
Date: Thu, 12 Oct 2017 09:53:17 +0200

> I think this can be fixed with a little wordsmithing of 6.3.3.

Brian, completely agree with you, will fix that in the text. Thanks for 
the note!

Michael