Telechat Review of draft-ietf-anima-reference-model-07
review-ietf-anima-reference-model-07-rtgdir-telechat-hopps-2018-08-26-00

Subject: RtgDir review: draft-ietf-anima-reference-model-07.txt

Hello,

I have been selected as the Routing Directorate reviewer for this draft. The
Routing Directorate seeks to review all routing or routing-related drafts as
they pass through IETF last call and IESG review, and sometimes on special
request. The purpose of the review is to provide assistance to the Routing ADs.
For more information about the Routing Directorate, please see
​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs, it would
be helpful if you could consider them along with any other IETF Last Call
comments that you receive, and strive to resolve them through discussion or by
updating the draft.

Document: draft-ietf-anima-reference-model-07.txt
Reviewer: Christian E. Hopps
Review Date: 2018-08-26
Intended Status: Informational

Summary:

I have a couple minor major concerns, and a couple minor concerns about this
document that I think should be resolved before publication.

I found the document very well written.

Minor Major Issues:

- Virtualization is mentioned once in "4.2 addressing" section. To quote:

  TEXT: "Support for virtualization: Autonomic Nodes may support Autonomic
  Service Agents in different virtual machines or containers. The addressing
  scheme should support this architecture."

  The special casing of VM/containers here seems to indicate that virtual
  devices are not "1st class citizens" in an autonomic network. In particular I
  could easily imagine virtual machines being full blown autonomic nodes
  themselves. Assuming the intent is not to restrict virtual devices in this
  manor something needs to be said (somewhere) to make that clear.

- Robust programming techniques. I think the intention here is to say that the
  design of ASAs must have robustness as a top design principle. I think in
  doing that it should talk about what being robust means; however, it should
  not be talking about how to accomplish that as there are multiple ways to
  achieve this goal.

  In particular I feel saying that restarting is the *last* thing an ASA should
  do is way overreaching into engineering the solution rather than specifying
  the requirement. Indeed plenty of people think that overly complex recovery
  mechanisms that try everything under the sun to *not* restart often have more
  bugs and are less robust than KISS solutions that "fail" simply but recover
  quickly with minimal or no disruption.

  I feel this section reads a bit more like someones idea of how to design a
  robust system instead of talking about what robust means which is the intent I
  believe.

  Perhaps better is just to focus on robust design ideas (some are already
  stated in the text):

  - must deal with discovery and negotiation failure as routine.
  - recovering from failures should be minimally disruptive.
  - must not leak resources.
  - must monitor for and deal with hung code.
  - must include security analysis

- 7.4: When text talks about feedback loop, it mentions "allow the intervention"
  of human admin or control system; however, it then describes the feedback loop
  as presenting default actions and allowing for override. This is fine, but it
  seems to leave out the common case where something is misbehaving and would
  not be presenting any choices to the administrator (using the feedback loop),
  so the admin must forcefully intervene.

Minor Issues:

- 6.1 TEXT: "It must be possible to run ASAs as non-privileged (user space)
  processes except for those (such as the infrastructure ASAs) that necessarily
  require kernel privilege. Also, it is highly desirable that ASAs can be
  dynamically loaded on a running node."

  ISSUE: Discussing implementation details like user-space, kernel privilege and
  dynamic loading seems unnecessary and outside the scope of this document. Does
  this document care if I implement my ASA on a real-time architecture with no
  "user space" etc..?

- 4.6 Why call out global routing and overlay networks in particular? Is the
  real intention to just say that the ACP implementation is not restricted to
  any specific type of networking?

- TEXT: 6.3.1.2 "on a given LAN"

  NIT: Everyone knows what a LAN is; however, I wonder if the text should be
  more generic and actually describe what it really requires here which is a
  broadcast or multicast network?

Questions/Comments:

- QUESTION: IoT and node requirements. There a couple node ASA requirements. I
  found myself wondering if a very simple IoT things like thermostats might ever
  be an AN and if so did they all really need to have joining assistent ASAs? It
  could be that the answer is "Yes, they do or they can't be nodes". I was just
  curious.

- COMMENT: For the types of ASAs: simple (run anywhere), complex (resource
  restricted), and infra (run everywhere), I was reminded of Kubernetes/cloud
  orchestration, and the concept of DaemonSets (pods that run everywhere) and
  Deployments (pods that can run anywhere, possibly be scaled replicated, and
  may also have requirements that restrict where they can run). I imagine that
  folks in Anima have also looked at this, but if not it would be good to as
  they seem to be solving very similar problems.

Nits:

- TEXT: 3.2 "However, the information is tracked independently of the status of
  the peer nodes; specifically, it contains information about non-enrolled
  nodes, nodes of the same and other domains. "

  QUESTION: What are peer nodes? Is this another name for adjacent nodes? If so
  "s/peer/adjacent/".

- TEXT: 3.3.1 "enrols"
  CHANGE: "enrolls"

- TEXT: 3.3.3 "In this state, the autonomic node has at least one ACP channel to
  another device. It can participate in further autonomic transactions, such as
  starting autonomic service agents. For example it must now enable the join
  assistant ASA, to help other devices to join the domain.

  NIT: "For example foo" is not a sentence on it's own, also "It" is not a good
  subject as there are multiple nouns in the previous sentence that could serve
  as antecedents.

  SUGGEST: 3.3.3 "In this state, the autonomic node has at least one ACP channel
  to another device. The node can now participate in further autonomic
  transactions, such as starting autonomic service agents (e.g., it must now
  enable the join assistant ASA, to help other devices to join the domain).

- TEXT: 4.1 "Names are typically assigned by a Registrar at bootstrap time and
  persistent over the lifetime of the device."

  NIT: s/persistent/and persist/

- TEXT: "Out of scope are addressing approaches for the data plane of the
  network, which may be configured and managed in the traditional way, or
  negotiated as a service of an ASA. One use case for such an autonomic function
  is described in [I-D.ietf-anima-prefix-management]."

- NIT: Sounds sort of Yoda-like, and the compounding makes things less clear.

  SUGGEST: "Addressing approaches for the data plane of the network are outside
  the scope of this document. These addressing approaches may be configured and
  managed in the traditional way, or negotiated as a service of an ASA. One use
  case for such an autonomic function is described in
  [I-D.ietf-anima-prefix-management]."

- TEXT: 6.1: "Following an initial discovery phase, the device properties and
  those of its neighbors are the foundation of the behavior of a specific
  device. A device and its ASAs have no pre-configuration for the particular
  network in which they are installed."

  NIT: Why suddenly lose the "node" abstraction and start talking about devices
  here? I think it continues to work well to say "node" (e.g., "node
  properties", "specific node" and "A node and its ASAs...").

- TEXT: 6.2 "install ASA: copy the ASA code onto the host and start it,"
  NIT: "s/host/node/"