Subject: [Anima] Reference Model Issues

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Thu, 24 Mar 2016 17:52:37 +0000

I just read through the entire document again, noting down things that need fixing, or discussion. The below is my personal view, for discussion. I cleaned up the github repository, and created a new file, corresponding to the latest version plus some small edits I made today while reading through again. 

One important point: Our chairs want us to take out or reduce drastically all the stuff that doesn't belong into the current charter. I agree that it is not always 100% clear if something is out of charter. But I'm having a hard time reducing some sections. What if we make a new section "Future work" (which clearly indicates out of scope for this charter), where we collect those points, but then are a bit more liberal about the volume of each section? I think that would be a good compromise. Sheng? 

I'll summarise the below points in the WG meeting in BA. Maybe we can already clarify some stuff before. 

Michael

Reference model issues
24 Mar 2016

4.1 Naming: 
- "It is recommended that the names are generated by the autonomic nodes
   themselves." - how? Should names / addresses not come from the registrar? 
   Suggestion: Name *and* ACP address should be assigned by the registrar
   at enrolment time. zone-id is dynamic, rest is fixed. 

- "a specific naming convention is out of scope": 
   Suggestion: We define a default naming and addressing scheme. 
   1st we settle on an addressing scheme from the ACP draft. 
   That defines a "device-ID" (last n bits of ACP address). 
   convert that to a string, and use it as a name. This would result in
   something like: 0123-4567-89ab-0001.example.com. 
   The name would go into the domain certificate --> need to put this into 
   the bootstrap draft as well. 
   
- to write in the doc: "registrar picks a naming scheme; all registrars 
  in a domain must use the same scheme. Example is: ... 
   
4.4 ACP
- should move to the end of section 4, it breaks the flow where it is right now. 

4.7 Intent Distribution
- This section should only explain the basics, real work is out of scope for this phase.
- should point to the intent distribution draft
- should explain that intent is flooded to all nodes in a domain (if we agree), 
  or other methods (if not). 
- should explain that we expect Intent to have a long life time (months), thus
  Intent distribution is expected to be very infrequent. 
- should explain that the entire Intent file is flooded in one go (if we agree). 

5. Functional Overview
- title is not good. This section really describes how an autonomic node behaves. maybe call it "Behaviour of an autonomic node"? 
- we need to describe the bring-up better, specifically insecure discovery, 
  ACP negotiation, ACP bringup, and subsequent operations, and which protocols to use
  where. Or should this go into the ACP draft?? 

6. Security and Trust Infrastructure
- needs a review from someone in the security space.
- we need to describe the certificate format; this should likely go into bootstrap draft. This draft should explain where the certificate format is described. 
- the domain certificate should also contain the ACP IP address (where the zone bits are set to zero). 

7.1 
- broken paragraph; needs fixing. 
- there is a mention of constrained devices - take out. 

7.2 Specific ASAs
- should explain MUST implement
- generally, need to work through text in this section; relate back to section 5. 

8.1 
- remove last reference to RFC7575. 

8.2 Intent
- explain not part of current charter first. 
- not sure whether we should keep this level of detail, or shorten further? 

8.3 Aggregated Reporting
- explain not part of current charter first. 
- my feeling: Should be reduced to 1-2 paragraphs, only high level idea.

General: 
- should we combine all items that are not part of the current charter into a separate section "Future Topics" or something like that? Then all (*) topic would be nicely contained. Yes, I think I'd prefer that to taking them out completely, or shortening them to next-to-nothing.

10. Security Considerations
- needs to be worked over. 

General: 
- uppercase Intent everywhere in the doc.

---

From: Laurent Ciavaglia <[email-masked]>
Date: Fri, 25 Mar 2016 00:00:29 +0100

Dear Michael, all,

Thanks for your continuous care of the document and taking some hindsight!

I am also more in favor of grouping non-chartered aspects into a future 
work section, and allow the text there to be meaningful for 1) the 
relationship with (chartered) ANIMA components, 2) the overall picture, 
and 3) describing the implications of these future items with enough depth.

I think the reference document is a pivot one in ANIMA to prepare what 
will come next (in ANIMA or elsewhere) and improve our collective 
understanding on future areas to investigate.
I think it would be a mistake to neglect this opportunity by restricting 
the document on chartered items.

Thanks, Laurent.
ps: of course my above support has nothing to do with the fact that I'm 
too lazy busy to condense the section I am editing ;)

On 24/03/2016 18:52, EXT Michael Behringer (mbehring) wrote:
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima
>

-- 

Laurent Ciavaglia

Senior Research Manager

Bell Labs, Nokia

+33 160 402 636

Route de Villejust | 91620 Nozay | France

LinkedIn: laurentciavaglia <http://fr.linkedin.com/in/laurentciavaglia/>

---

From: Jéferson Campos Nobre <[email-masked]>
Date: Fri, 25 Mar 2016 14:16:54 +0000

Hi.
+ 1 for the grouping.
Michael, are you thinking in maintaining subsections in the future work
section?
Best.
Jéferson

Em qui, 24 de mar de 2016 às 20:00, Laurent Ciavaglia <
[email-masked]> escreveu:

> relationship with (chartered) ANIMA components, 2) the overall picture, and
> 3) describing the implications of these future items with enough depth.
>
Thanks, Laurent.
> Anima mailing [email-masked]://www.ietf.org/mailman/listinfo/anima
>
>
> --
>
> Laurent Ciavaglia
>
> Senior Research Manager
>
> Bell Labs, Nokia
>
>
>
> +33 160 402 636
>

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Fri, 25 Mar 2016 14:23:20 +0000

Yes, I’m thinking that we move EVERYTHING that isn’t in the current charter into a “futures” section. So that would include:

-          Intent

-          feedback loops

-          aggregated reporting

-          APIs

-          current section 9

-          constrained devices

-          cross-domain behaviour

-          etc

This way the document would be very clearly structured, and we could still keep the current content, which, frankly, I don’t want to lose.

Michael

From: Jéferson Campos Nobre [mailto:[email-masked]]
Sent: 25 March 2016 15:17
To: Laurent Ciavaglia <[email-masked]>; Michael Behringer (mbehring) <[email-masked]>; [email-masked]
Subject: Re: [Anima] Reference Model Issues

Hi.
+ 1 for the grouping.
Michael, are you thinking in maintaining subsections in the future work section?
Best.
Jéferson

Em qui, 24 de mar de 2016 às 20:00, Laurent Ciavaglia <[email-masked]<mailto:[email-masked]>> escreveu:
Dear Michael, all,

I am also more in favor of grouping non-chartered aspects into a future work section, and allow the text there to be meaningful for 1) the relationship with (chartered) ANIMA components, 2) the overall picture, and 3) describing the implications of these future items with enough depth.

I think the reference document is a pivot one in ANIMA to prepare what will come next (in ANIMA or elsewhere) and improve our collective understanding on future areas to investigate.
I think it would be a mistake to neglect this opportunity by restricting the document on chartered items.
Thanks, Laurent.
ps: of course my above support has nothing to do with the fact that I'm too lazy busy to condense the section I am editing ;)

Michael

Reference model issues

24 Mar 2016

4.1 Naming:

   something like: 0123-4567-89ab-0001.example.com<http://0123-4567-89ab-0001.example.com>.

4.4 ACP

4.7 Intent Distribution

5. Functional Overview

7.1

7.2 Specific ASAs

8.1

8.2 Intent

8.3 Aggregated Reporting

General:

General:

Anima mailing list

[email-masked]<mailto:[email-masked]>

--
Laurent Ciavaglia
Senior Research Manager
Bell Labs, Nokia

+33 160 402 636
Route de Villejust | 91620 Nozay | France
LinkedIn: laurentciavaglia<http://fr.linkedin.com/in/laurentciavaglia/>

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

---

From: Jéferson Campos Nobre <[email-masked]>
Date: Sat, 26 Mar 2016 00:46:54 +0000

Hi Michael.
I agree with your proposal to move everything that is outside the charter
into a future work/steps section.
I can further short the section I wrote (intent and aggregated reporting).
If you need additional help in other sections, just let me know.
Best.
Jéferson

Em sex, 25 de mar de 2016 às 11:23, Michael Behringer (mbehring) <
[email-masked]> escreveu:

> Yes, I’m thinking that we move EVERYTHING that isn’t in the current
> charter into a “futures” section. So that would include:
>
> -          Intent
>
> -          feedback loops
>
> -          aggregated reporting
>
> -          APIs
>
> -          current section 9
>
> -          constrained devices
>
> -          cross-domain behaviour
>
> -          etc
>
>
>
> This way the document would be very clearly structured, and we could still
> keep the current content, which, frankly, I don’t want to lose.
>
>
>
> Michael
>
>
>
>
>
> *From:* Jéferson Campos Nobre [mailto:[email-masked]]
> *Sent:* 25 March 2016 15:17
> *To:* Laurent Ciavaglia <[email-masked]>; Michael Behringer
> (mbehring) <[email-masked]>; [email-masked]
> *Subject:* Re: [Anima] Reference Model Issues
>
>
>
> Hi.
>
> + 1 for the grouping.
>

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 26 Mar 2016 13:48:41 +1300

On 25/03/2016 06:52, Michael Behringer (mbehring) wrote:

...
>    themselves." 

Just before that, it says
"Inside a domain, each autonomic device should be assigned a name."

I have a heretical question: why do autonomic nodes need names?

They clearly need ACP addresses and they need cryptographic identities.
But what is the purpose of a human-readable name?

The answer should tell us what sort of naming system we need.

     Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 26 Mar 2016 13:51:12 +1300

>   where. Or should this go into the ACP draft?? 

I think the full description belongs in the ACP draft,and when that is reasonably
stable, there should be a short summary here.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 26 Mar 2016 13:57:52 +1300

> 7.2 Specific ASAs [for the Enrolment Process]

And that they MUST be present in all nodes by default. In particular
the Proxy ASA MUST discover whether it needs to be active (see discussion
yesterday). I suppose the same applies to the Registrar ASA but
possibly that needs to be configured "on" by the NOC?

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 26 Mar 2016 13:59:34 +1300

> - should we combine all items that are not part of the current charter into a separate section "Future Topics" or something like that? Then all (*) topic would be nicely contained. Yes, I think I'd…

Agreed. Could even be an Appendix but we should not lose this material.

   Brian

---

From: John Strassner <[email-masked]>
Date: Sun, 27 Mar 2016 10:32:24 -0700

HI Michael,

I agree. I'll work on detailed responses after Easter.

regards,
John

-- 
regards,
John

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Tue, 29 Mar 2016 09:02:20 +0000

> -----Original Message-----
> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: 26 March 2016 01:58
> To: Michael Behringer (mbehring) <[email-masked]>; [email-masked]
> Subject: 7.2 Specific ASAs [was Reference Model Issues]
> 
> And that they MUST be present in all nodes by default. In particular the
> Proxy ASA MUST discover whether it needs to be active (see discussion
> yesterday). I suppose the same applies to the Registrar ASA but possibly that
> needs to be configured "on" by the NOC?

Yes, agree, that's what I meant. Switching the proxy ASA off if not needed is an optimisation, in my view. (Also, once enrolled, you can switch off the enrolment ASA of course). 

The registrar is effectively a policy definition point (PDP), thus MUST be set up manually. 

That still needs to be explained better in the draft, was what I was trying to say :-) 

Michael

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Tue, 29 Mar 2016 09:08:35 +0000

> Sent: 26 March 2016 01:51
> Subject: 5. Functional Overview [was Reference Model Issues]
> 
> > - title is not good. This section really describes how an autonomic node
> behaves. maybe call it "Behaviour of an autonomic node"?
> I think the full description belongs in the ACP draft,and when that is
> reasonably stable, there should be a short summary here.

I'm not sure about this one yet. I think the "behaviour of an autonomic node" has a lot to do with the ACP, but not exclusively. 
- There is the case of an enrolled node, which finds itself with no AN neighbour of the same domain --> not an ACP issue! We still need to describe what it should do when it sees a new node, for example? 
- There is also the case of, once the ACP is up, how Intent gets distributed; I think that is also based on the adjacency table, and that's not directly linked to the ACP either... 

As I said, not sure yet... 

Michael

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 30 Mar 2016 08:17:36 +1300

> The registrar is effectively a policy definition point (PDP), thus MUST be set up manually. 

Yes, that seems reasonable in a "professionally managed network" which is the
Anima target. I wouldn't exclude an election process in a completely unmanaged
network, but that's out of scope here.

   Brian