Subject: [Anima] Review comments//RE: WGLC on draft-ietf-anima-reference-model-05 - Respond by January 22nd, 2018

From: Sheng Jiang <[email-masked]>
Date: Thu, 18 Jan 2018 08:59:35 +0000

Hi, authors of anima-reference-model,

I have reviewed the draft as the document shepherd, see below comments. Overall, I feel this document is very useful and it is almost ready for be published. Please properly address my comments together with other WGLC comments you may receive. Another revised version of the document is needed to process the document further if it passed the WGLC.

General issues:
1.      In section 3.1, it says "The Autonomic Control Plane (ACP) is the summary of all interactions of the Autonomic Networking Infrastructure with other nodes and services." I'm a bit confused by this statement. In my understanding, the ACP itself is mostly a "channel", although some ANI functions (signaling, aggregated reporting etc.) are running within the channel, they should be parallel with ACP function in the architecture view.
At the same time, there are indeed some functions considered as sub-functions of the ACP, e.g. the addressing and routing, which are necessary to make the ACP runnable.
So, my questions to the co-authors:
1)      Do you see ACP as an individual function as I understood (mostly a channel), or a summary of a suite of functions running inside the ACP?
2)      What functions are sub-functions of ACP, and what are in parallel with ACP?
2.      I'm confused by the whole purpose of Section 3. The first sub-clause is describing the architecture of an Autonomic Network Element, while the rest sub-clauses (adjacency table, state machine etc.) seems more like "implementation considerations" or "procedures". I think both are useful content, but they are in two different dimensions, maybe separate them into different sections?
3.      Some texts (e.g. paragraph 4 of Section 1) are directly bind to the WG's charter, I'm not sure it is a good approach that an RFC normatively refer the WG charter which is dynamically changed along with the work going on in the WG. Maybe just simply re-phrase the "chartered work" as "Phase 1/near term work", and "non-chartered" as "Phase 2 long-term"?
4.      The whole Section 7 seems too theoretical and abstract. The described concepts are valuable, I'd suggest to have more texts mapping these concepts into the ANI/AN.

Specific comments:

Section 1 Introduction
-        Paragraph 3 claims "This reference model allows for this hybrid approach." I think it would be better to explain in what degree the "hybrid" could be. For example, the ANI actually doesn't support non-autonomic nodes to join in the same domain with the autonomic nodes; thus, in this deployment level, it is not "hybrid".
-        As said in the general issues, paragraph 4 seems binding with the WG charter too much.

Section 2 The Network View
-        In the figure, it seems the ASAs are hierarchical, but there is no relevant texts. My understanding is that, it is reasonable to distinguish layered ASAs, e.g., some ASAs might be very fundamental, and should be the future work of the Anima WG; while most of the specific ASAs are service/scenario relevant, that might not be suitable to do them case by case in Anima.
-        "The current charter of the ANIMA WG is to specify the ANI, using a few autonomic functions as use cases." Again, I'm not sure it is good to bind the RFC to the WG charter.

Section 3 The Autonomic Network Element
-        If Figure 1 means to make the ASAs hierarchical, then it is better to be consistent in Figure 2.
-        Nits in Figure 2
         Synchronization -> synchronization
         In the ANI part, the "Discovery, negotiation and synchronisation functions" looks like a sub-item of "Autonomic Node Addressing", I guess it should be typo?
-        Section 3.1 "The Autonomic Networking Infrastructure (ANI) is normally built on a hop-by-hop basis." It is true for ACP, but I don't think it applies for all the other ANI functions, e.g. negotiation/sync signaling.
-        Section 3.2, the first bullet point of paragraph 3 "link local discovery", it is ambiguous that what kind information is gathered through GRASP. I think there should be some basic information gathered through ND protocol.
-        Section 3.2, the third bullet point: "Once the node is part of the ACP of a domain, it will use GRASP discovery [I-D.ietf-anima-grasp] to find Registrar(s) of its domain and potentially other services." The later version of BRSKI changed to use a GRASP Flood message to actively broadcast the registrar service by the proxies in their link-local scope.
-        Section 3.3.2, I think it would be good to briefly discuss the situation that if an enrolled node re-boot from power cut or be attached to another network, how the transition state would be? Is it the same with "Factory reset"?

Section 4 The Autonomic Networking Infrastructure
-        Section 4.2 Addressing, there are a list of comprehensive requirements of addressing, which are good content. It might be better if Section 4.1 Naming also include such a requirement list?
-        Section 4.5 "All autonomic nodes in a domain must be able to communicate with each other, and with autonomic nodes outside their own domain." The cross-domain mechanism hasn't be covered yet, maybe it's better to note this feature is for "long term" work rather than "phase 1".
-        Section 4.6 "The totality of autonomic interactions forms the "Autonomic Control Plane". Again, it is the same as No.1 general issue as described above.

Section 5 Security and Trust Infrastructure
-        Section 5.2 describes domain certificate; I think the device certificate, which is pre-set by the manufacture also needs to be mentioned.

Section 6 Autonomic Service Agents (ASA)
-        It might be good to reference draft-carpenter-anima-asa-guidelines?
-        Section 6.3 is interesting, it actually unveils the ANI functions (except GRASP) are yet ASAs. It is no problem for me, but I have a bit concern that new readers might be confused about the "overlap/mixture" between ANI and ASAs?

Section 7 Managing a (Partially) Autonomic Network
-        Section 7.6 APIs: this section are too abstract for me, I just couldn't really get the point. It seems like a general design pattern rather than specific mechanisms related to autonomic networks.
-        Section 7.7 Data Model has the similar issue as above. It explains the concept but lacks essential content related to ANI.

Thanks and regards,

Sheng

From: Anima [mailto:[email-masked]] On Behalf Of Sheng Jiang
Sent: Tuesday, January 09, 2018 2:26 PM
To: [email-masked]
Cc: [email-masked]
Subject: [Anima] WGLC on draft-ietf-anima-reference-model-05 - Respond by January 22nd, 2018

Hi all,

This message starts the two-week ANIMA Working Group Last Call to advance draft-ietf-anima-reference-model-05, A Reference Model for Autonomic Networking. This document's intended status is Informational. At present, there is no IPR file against this document.

Please send your comments by January 22nd, 2018. If you do not feel this document should advance, please state your reasons why.

Sheng JIANG is the assigned document shepherd.

Regards,

Sheng (co-chair, Toerless who as a co-author stayed neutral on the content side)

---

From: Michael Richardson <[email-masked]>
Date: Thu, 18 Jan 2018 13:34:25 -0500

> Hi, authors of anima-reference-model,

{contributor speaking}

    > 1. In section 3.1, it says "The Autonomic Control Plane (ACP) is the
    > summary of all interactions of the Autonomic Networking Infrastructure
    > with other nodes and services.

    > In my understanding, the ACP itself is mostly a "channel", although
    > some ANI functions (signaling, aggregated reporting etc.) are running
    > within the channel, they should be parallel with ACP function in the
    > architecture view.

I concur with you, I'm also confused by the word "summary"
While we think of the ACP as the channel on which control functions occur, I
can also see that more generically (at the Dilbert's boss' level), the ACP is
the channel + all the interactions.  Perhaps we need a new term.

    > 1) Do you see ACP as an individual function as I understood (mostly a
    > channel), or a summary of a suite of functions running inside the ACP?

I also think it's worth thinking of the ACP as being a very special ASA that
creates the secure channel.  Maybe that's too recursive for some people, but
I think that doing so will encourage us to design the right management
functions for the ACP itself.

    > 2) What functions are sub-functions of ACP, and what are in parallel

That's a good question.
(/me looks distantly and tries to change the subject :-)

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: "Michael H. Behringer" <[email-masked]>
Date: Mon, 29 Jan 2018 10:03:07 +0100

OK, the time for the last call is over.
I'll produce a -06 version, working through the following issues:

- Sheng's review from 18 Jan (Thanks Sheng)

- Michael's response to Sheng's mail.

- the author issue. I think I'll follow Brian's suggestion,
listing me as editor and all other co-authors under contributors.
At least I see no better way...

I think those are all the open comments I saw. Did I miss
anything?

Michael

On 18/01/18 19:34, Michael Richardson wrote:

{contributor speaking}

That's a good question.

_______________________________________________
Anima mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/anima

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 30 Jan 2018 07:58:29 +1300

Michael,

Sounds good to me. One minor point is whether to mention the distinction
between *the* ACP and the abstract Generic ACP that Toerless introduced:
https://mailarchive.ietf.org/arch/msg/anima/2hxcRbAWu-dkGCQQu9UFvcmF6LM

In section we have this sentence:
"The Autonomic Control Plane (ACP) is the summary
of all interactions of the Autonomic Networking Infrastructure with
other nodes and services."
That's actually a rather strange sentence. How about this instead:
"The Autonomic Control Plane (ACP) is a secure substrate used for
all interactions of the Autonomic Networking Infrastructure with
other autonomic nodes and services. It is a generic concept but
a specific implementation is described in
[I-D.ietf-anima-autonomic-control-plane]."

Regards
   Brian

On 29/01/2018 22:03, Michael H. Behringer wrote:
> OK, the time for the last call is over. I'll produce a -06 version, working 
> through the following issues:
> 
> - the author issue. I think I'll follow Brian's suggestion, listing me as editor 
> and all other co-authors under contributors. At least I see no better way...
> 
> I think those are all the open comments I saw. Did I miss anything?
> 
> Michael
> 
> 
>> Sheng Jiang<[email-masked]>  wrote:
>> Michael Richardson<[email-masked]>, Sandelman Software Works

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 29 Jan 2018 21:00:28 +0100

If its ok. with the other contributors,
i would appreciate if i could be listed as well as an editor.

Thank you
    Toerless

On Mon, Jan 29, 2018 at 10:03:07AM +0100, Michael H. Behringer wrote:
> <html>
>   <head>
>     <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
>   </head>
>   <body text="#000000" bgcolor="#FFFFFF">
>     <div class="moz-cite-prefix">OK, the time for the last call is over.
>       <br>
>       <br>
>       - Sheng's review from 18 Jan (Thanks Sheng)<br>
>       - Michael's response to Sheng's mail.<br>
>       At least I see no better way...<br>
>       <br>
>       anything? <br>
>       <br>
>       Michael<br>
>       <br>
>       <br>
>       On 18/01/18 19:34, Michael Richardson wrote:<br>
>     </div>
>     <blockquote type="cite"
>       cite="mid:[email-masked]">
>       <pre wrap="">
> Sheng Jiang <a class="moz-txt-link-rfc2396E" href="mailto:[email-masked]">&lt;[email-masked]&gt;</a> wrote:
>     &gt; Hi, authors of anima-reference-model,
> 
> {contributor speaking}
> 
>     &gt; General issues:
> 
>     &gt; 1. In section 3.1, it says "The Autonomic Control Plane (ACP) is the
>     &gt; summary of all interactions of the Autonomic Networking Infrastructure
>     &gt; with other nodes and services.
> 
>     &gt; In my understanding, the ACP itself is mostly a "channel", although
>     &gt; some ANI functions (signaling, aggregated reporting etc.) are running
>     &gt; within the channel, they should be parallel with ACP function in the
>     &gt; architecture view.
> 
>     &gt; 1) Do you see ACP as an individual function as I understood (mostly a
>     &gt; channel), or a summary of a suite of functions running inside the ACP?
> 
>     &gt; 2) What functions are sub-functions of ACP, and what are in parallel
>     &gt; with ACP?
> 
> That's a good question.
> Michael Richardson <a class="moz-txt-link-rfc2396E" href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>, Sandelman Software Works
> </pre>
>       <br>
>       <fieldset class="mimeAttachmentHeader"></fieldset>
>       <br>
>       <pre wrap="">_______________________________________________
> Anima mailing list
> <a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>
> <a class="moz-txt-link-freetext" href="https://www.ietf.org/mailman/listinfo/anima">https://www.ietf.org/mailman/listinfo/anima</a>
> </pre>
>     </blockquote>
>     <br>
>   </body>
> </html>
> 

-- 
---
[email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 30 Jan 2018 10:24:54 +1300

> i would appreciate if i could be listed as well as an editor.

It's always a judgment call. Who's done most of the editing?
Certainly Michael Behringer.
(See https://github.com/mbehring/ANIMA-Reference-Model/commits/master)

My view of this tricky topic:
https://tools.ietf.org/html/draft-carpenter-whats-an-author

   Brian

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 31 Jan 2018 01:29:27 +0100

Brian:

The commits do not show all contributions to text.
I often provided text in email to michael to merge in the past
when i didn't want to bother about github.  But i am not insisting
on editor status, but as indicated only author status, and
for that the question of direct editing on github is irrelevant.

I suggest we move everyone who explicitly wants to be
listed as contributor into that section, otherwise we keep
the list of authors (including Michael as only
editor) as it is right now and we will see what happens during
IESG review.

There are also new RFCs coming out with 8 authors, eg: rfc8321. 

Cheers
    Toerless

---

From: Jéferson Campos Nobre <[email-masked]>
Date: Wed, 31 Jan 2018 02:08:58 +0000

Dear All.
It seems that we have the same "author information" as RFC 8321. I had
understood reading a previous email that this was not possible.
Thus, I suggest to maintain our current configuration (Michael as Editor
and everybody else as authors) and wait for the IESG review.
Best.
Jéferson

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 31 Jan 2018 16:13:32 +1300

I don't know the background to RFC8321. I do know that we'll spend a
lot of time on this issue if it goes forward with more than 5 authors.
Been there, done that, don't want to do it again...

Regards
   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 1 Feb 2018 08:16:12 +1300

On 30/01/2018 07:58, Brian E Carpenter wrote:
...

On looking at that again, please consider that what I actually wrote was:

>> To answer to Brian comments on co-authors: if we have one or more Editors, should all other "authors" be listed as contributors?
> 
> That is the option suggested by the RFC Editor site, and Michael has been the editor all along.
> Personally I would be quite happy to be listed as a contributor.

I think it's perfectly fine to list one or two editors, then three or four authors of
substantial text, to a maximum of 5, and then list the rest as contributors. If you
really can't cut the list at 5, we'd need to justify it to the AD.

   Brian