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

From: "Ciavaglia, Laurent (Nokia - FR/Paris-Saclay)" <[email-masked]>
Date: Thu, 1 Feb 2018 09:26:41 +0000

Hello,

We are currently 8 "co-authors" for this draft.
My preferences, in priority order, are:
	1) Michael as Editor, all other authors listed as authors, no contributors.
	2) Michael as Editor, all other authors listed as contributors.

Given how this document originated and has developed over time, this would reflect, from my viewpoint, a "fair representation".

We may discuss our approach for representation of contributors versus RFC editor guidelines.
I think it can be important for the "external readership" that the diversity of people that took part in this document is visible, although I understand (and fully support) that IETF is not affiliation-driven. Nevertheless, showing industry and academia mix is good, and also several vendors co-signing. But this may not be our only driver for deciding how to list authors.

Side question: how are contributors associated with an RFC in the datatracker? I mean if I search on the datatracker with someone's name, will the RFC where he has been contributors appear?

Thanks, Laurent.

-----Original Message-----
From: Anima [mailto:[email-masked]] On Behalf Of Brian E Carpenter
Sent: Wednesday, January 31, 2018 8:16 PM
To: Michael H. Behringer <[email-masked]>; [email-masked]
Subject: Re: [Anima] Review comments//RE: WGLC on draft-ietf-anima-reference-model-05 - Respond by January 22nd, 2018

On 30/01/2018 07:58, Brian E Carpenter wrote:
...
> 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:
>>
>> - 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...

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

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

---

From: "Michael H. Behringer" <[email-masked]>
Date: Fri, 23 Feb 2018 14:09:46 +0100

On 18/01/18 09:59, Sheng Jiang wrote:
>
> 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.
>

Hi Sheng,

First of all thanks for the thorough review. I am now finished with 
working your comments into the draft. I am just publishing version -06.

This version should address all your comments. I am not aware of any 
other outstanding comments, and believe we have addressed all open 
issues now.

Details below in line.

Michael

> 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?
>

There are really two meanings to the term "ACP". This has caused quite 
some confusion, and I agree it needs to be nailed once and for all. 
Thanks for raising it here.

1) The general term "control plane" refers to the sum of all protocols 
that control network behaviour. Like, in a traditional network, routing 
protocols, etc. Consequently, an "Autonomic Control Plane" is the sum of 
all protocols that controls the behaviour of an autonomic network. In 
draft-ietf-anima-stable-connectivity we now use the term "Generalized 
ACP" for this abstract concept.

2) In the ANIMA context, we use the term "ACP" also to describe a very 
specific implementation of the generic concept of an "Autonomic Control 
Plane".

I now cleared up the naming in the reference draft. Where we mean the 
abstract concept (3.1 for example), I now use "GACP", where we mean the 
implementation, I now use "ACP" and refer to the ACP draft.

Specifically, I changed in 3.1 from ACP to GACP. And re-worded section 
4.6, which is all about the implementation of the 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?
>

Well, the section is about the network element. I find it quite logic 
that you first discuss the architecture of the element, then how it 
behaves in a network. However, I added an explanatory intro at the 
beginning of that section to make it clearer. Thanks for pointing out 
that this wasn't clear!

> 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”?
>

Agree that needs to be fixed. Did some editorial changes for that. The 
sections with an (*) now start with a sentence like this:
     <t>... is not covered in the current implementation specifications. 
This section is for informational purposes, for following phases of 
standardization. </t>

As part of that fix, I also re-worded the abstract. It now reads:

This document describes a reference model for Autonomic Networking. It 
defines the behaviour of an autonomic node, how the various elements in 
an autonomic context work together, and how autonomic services can use 
the infrastructure.

Now, the word "charter" is no longer in the text at all.

Comments?

> 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.
>

I made the changes described above, to point out very explicitly that 
these sections are essentially for future study. I would prefer NOT to 
do any more editing beyond that. That should be done in a subsequent 
document, I think.

> 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”.
>

Good point. I added an example to explain the concept. I thought of 
adding more, but then I think the intro would become too long.

> - As said in the general issues, paragraph 4 seems binding with the WG 
> charter too much.
>

That is resolved.
>
> 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.
>

Oh, it was not the intention to imply a hierarchy. Thanks for pointing 
this out. ASAs may or may not be hierarchical. I added a sentence to 
clarify: "ASAs may be standalone, or use other ASAs in a hierarchical way."

> - “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.
>

Fixed.

> 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.
>

I think this is fixed with the above text. Let me know if it is not 
clear enough.

> - Nits in Figure 2
>
> Synchronization -> synchronization
>

The RFC editor will fix all the UK vs US English issues. I'll leave it 
to them, since I'm not a native English speaker.

> 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?
>

Good catch. Fixed.

> - 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.
>

Note the "built". I think the sentence is correct. However, to clarify, 
I changed "built" to "constructed". And, we're really talking ACP here. 
I changed that as well.

> - 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.
>

Yes, this section is a bit ambiguous, I agree. But if we want to make it 
precise, it's going to explode the section and make it unreadable. 
Hmmm... I think the issue is really the phrase "This is described in 
[GRASP]". I re-phrase that to "The related standards track documents 
(GRASP, ACP, BRSKI) describe in detail how link local discovery is used."

> - 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.
>

I removed "discovery". "It will use GRASP" is correct.

> - 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”?
>

This discussion is not specific to 3.3.2. A node can reboot at any point 
in time. The important part is if it keeps its LDevID or not.

But you're right. This is not mentioned anywhere... Hmmm... Thinking 
more, this is just another transition in the state machine, for each 
state. I'll add that, I think it makes sense.

     "Powercycle event: The device loses all state tables, but not its 
domain identity (LDevID). Next state: 2."

I hope I'm not opening a can of worms here... It is possible to conceive 
a model where a device also loses its LDevID... I think that's going to 
be an extreme corner case, and would prefer to not even mention it here. 
Thoughts?

> 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?
>

I think the requirements are in the section, just not in a bulleted 
list. Frankly, I prefer not to change this at this stage of the 
document. Let me know if we're missing a requirement.

> - 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”.
>

OK, changed that to "in later phases also with ..."

> - 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.
>

Changed to "The "Autonomic Control Plane" carries the control protocols 
in an autonomic network."

> 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.
>

Done.

> Section 6 Autonomic Service Agents (ASA)
>
> - It might be good to reference draft-carpenter-anima-asa-guidelines?
>

Good point. Included.

> - 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?
>

I thought we were quite clear about that. In section 6.1 we say:

    o  A few 'infrastructure ASAs' that use basic ANI features in support
       of the ANI itself, which must run in all autonomic nodes.  These
       are outlined in the following sections.

I suggest we leave it at that.

> 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.
>

I agree with you, it is fairly generic. At the same time it provides 
some context to the APIs we use, and it's clearly marked with a (*) as 
being phase 2. I suggest we leave it in. If folks feel strongly, I think 
we could take out the entire section. For now I leave it.

> - Section 7.7 Data Model has the similar issue as above. It explains 
> the concept but lacks essential content related to ANI.
>

Dito. I suggest to leave it for now.

[end of reply]

> 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: Sheng Jiang <[email-masked]>
Date: Wed, 28 Feb 2018 14:36:53 +0000

Hi Michael,

Thanks for addressing my review comments. Below in lines for my further comments regarding to several points. None of them are major. So, I will start my document shepherd based on the current 06 version. It is up to you to do a quick update soon or addressing them together with the IESG review comments, which I am sure will have.

Regards,

Sheng

> From: Anima [mailto:[email-masked]] On Behalf Of Michael H.
> Behringer
> Sent: Friday, February 23, 2018 9:10 PM
> To: Sheng Jiang <[email-masked]>; [email-masked]
> Cc: [email-masked]
> Subject: Re: [Anima] Review comments//RE: WGLC on draft-ietf-anima-
> reference-model-05 - Respond by January 22nd, 2018
> 
> other outstanding comments, and believe we have addressed all open issues now.
> 
> Details below in line.
> 
> Michael
> 
> > General issues:
> >
> > summary of all interactions of the Autonomic Networking 
> > Infrastructure with other nodes and services.” I’m a bit confused by this statement.
> > some ANI functions (signaling, aggregated reporting etc.) are 
> > running within the channel, they should be parallel with ACP 
> > function in the architecture view.
> >
> > 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?
> >
> that control network behaviour. Like, in a traditional network, routing protocols, etc.
> Consequently, an "Autonomic Control Plane" is the sum of all protocols 
> that controls the behaviour of an autonomic network. In 
> draft-ietf-anima-stable- connectivity we now use the term "Generalized ACP" for this abstract concept.
> 
> specific implementation of the generic concept of an "Autonomic Control Plane".
> 
> abstract concept (3.1 for example), I now use "GACP", where we mean 
> the implementation, I now use "ACP" and refer to the ACP draft.
> 

[Sheng] My original comment implied two aspects:
1. As you explained, the "General" control plane vs. the "specific" implementation (ACP). So, as I understood, the ACP is an instance of GACP. I have no problem on this.
2. The specific ACP actually serves as a management channel for the underlay network, in this sense, the ACP could be seen as a "management plane" for the underlay network; in other words, the ACP is a "Virtual DCN(Data communication network)". Thus, there could be a summary of management functions running inside the ACP, and this summary doesn't belong to ACP itself. If you agree with it, I think this also needs to be clarified.

> > 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 
> defines the behaviour of an autonomic node, how the various elements 
> in an autonomic context work together, and how autonomic services can 
> use the infrastructure.
> 

> > - As said in the general issues, paragraph 4 seems binding with the 
> > WG charter too much.
> >
> 
> That is resolved.
> >

> > - “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.
> >
> 
> Fixed.
> 

> > 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.
> Note the "built". I think the sentence is correct. However, to 
> clarify, I changed "built" to "constructed". And, we're really talking ACP here.
> I changed that as well.
> > through GRASP. I think there should be some basic information 
> > gathered through ND protocol.
> >
> 
> Yes, this section is a bit ambiguous, I agree. But if we want to make 
> it precise, it's going to explode the section and make it unreadable.

> > 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 
> > attached to another network, how the transition state would be? Is 
> > it the same with “Factory reset”?
> >
> 
> This discussion is not specific to 3.3.2. A node can reboot at any 
> point in time. The important part is if it keeps its LDevID or not.
> 
> I hope I'm not opening a can of worms here... It is possible to 
> conceive a model where a device also loses its LDevID... I think 
> that's going to be an extreme corner case, and would prefer to not even mention it here.
> Thoughts?

[Sheng] The added texts are good for me. But please pardon me for opening the can even a bit more:
When one device has enrolled, maybe it is good to keep the domain certificate as well as the LDevID? In this way, the network won't suffer too much in a power outage event.
If it is plugged into another domain, it should not be difficult to detect the abnormity. 

> > requirements of addressing, which are good content. It might be 
> > better if Section 4.1 Naming also include such a requirement list?
> >
> 
> > "Autonomic Control Plane". Again, it is the same as No.1 general 
> > issue as described above.
> >
> 
> Changed to "The "Autonomic Control Plane" carries the control 
> protocols in an autonomic network."
> 
> > (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?
> >
> 
> > couldn’t really get the point. It seems like a general design 
> > pattern rather than specific mechanisms related to autonomic networks.
> >
> 
> being phase 2. I suggest we leave it in. If folks feel strongly, I 
> think we could take out the entire section. For now I leave it.

[Sheng] I think Section 7.6 (APIs) is related to drfat-ietf-anima-grasp-api, I couldn't exactly tell whether the GRASP API design consists with the design principles described in this section.
If this section doesn't mean that API related work "MUST" follow the design principles, I'd suggest to add a sentence to clarify it.

Regards,

Sheng