Re: [Anima] Review draft-ietf-anima-reference-model-04

Thanks for your comments, Artur. I'm in the middle of vacations, but 
will incorporate your comments when back, in the next version!

Brian, seen your response, too. Will catch up...

Michael

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
>
> 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.
>
> 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."
>
> 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.
>
> 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?
>
> 5. Page 17, Section 7.1: "How an AN Network Is Managed"
> a) Please consider changing the title. AN is "autonomic network" network network :-)
> 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).
>
> 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)
>
> 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.
>
> 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.
>
> 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).
>
> 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).
>
> 10. Page 22, Section 8.1:
> s/mechanisms exists/mechanisms exist.
>
> 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.
>
>
>
> Regards
> artur
>
> _______________________________________________
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima