Subject: [Anima] Naming discussion (Section 4.1 of the Reference-Model draft)

From: "Liubing (Leo)" <[email-masked]>
Date: Fri, 26 Jun 2015 10:27:34 +0000

Hi Dear all,

I've generated some text regarding to the naming of autonomic network devices. This is to fit the Section 4.1 in the Reference-Model draft.
Below is the content which includes some rough ideas. Please feel free to comment.

4.1.  Naming

4.1.1.  Naming requirements

   o  Representing each device
         Inside a domain, each autonomic device needs a domain specific
         identifier.
         [Open Questions] Are there devices that don't need names?  Do
         ASAs need names?

   o  Uniqueness
         The names MUST NOT collide within one autonomic domain.
         It is acceptable that the names in different domains collide,
         since they could be distinguished by domains.

   o  Semantic Encoding
         It is RECOMMENDED that the names encode some semantics rather
         than meaningless strings.  The semantics might be:
         +  Location
         +  Device type
         +  Functional role
         +  Ownership
         +  etc.
         This is for ease of management consideration that network
         administrators could easily recognize the device directly
         through the names.

   o  Consistency
         The devices' naming SHOULD follow the same pattern within a
         domain.

4.1.2.  Proposed Mechanisms

    o  Structured Naming Pattern
         The whole name string could be divided into several fields,
         each of which representing a specific semantic as described
         above.  For example: Location-DeviceType-FunctionalRole-
         DistinguisherNumber@NameofDomain.

         The structure should be flexible that some fields are optional.
         When these optional fields are added, the name could still be
         recognized as the previous one.  In above example, the
         "DistinguisherNumber" and "NameofDomain" are mandatory whereas
         others are optional.  At initial stage, the devices might be
         only capable of self-generating the mandatory fields and the
         "DeviceType" because of the lack of knowledge.  Later, they
         might have learned the "Location" and "FunctionalRole" and
         added the fields into current name.  However, the other devices
         could still recognize it according to the same
         "DistinguisherNumber".

   o  Advertised Common Fields
         Some fields in the structured name might be common among the
         domain (e.g.  "Location" "NameofDomain").  Thus, these part of
         the names could be advertised through Intent
         Distribution (Section 4.5).

   o  Self-generated Fields
         The mandatory fields SHOULD be self-generated so that one
         device could name itself sufficiently without any advertised
         knowledges.
         There should various methods for a device to extract/generate a
         proper word for each mandatory semantic fields (e.g.
         "DeviceType", "DistinguisherNum") from its self-knowledge.

   Detailed design of specific naming patterns and methods are out of
   scope of this document.

Best regards,
Bing

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 27 Jun 2015 13:37:09 +1200

>          since they could be distinguished by domains.

Well, yes, we have a system for that, which is the DNS. Is there any reason
not to use DNS names?

>          administrators could easily recognize the device directly

I'm generally against making this a formal recommendation. I understand
very well that it may be a common operational practice already, but it's
quite subject to human error and in a truly autonomic network nobody
should ever see the names anyway. Also, they would need to change
autonomically whenever the topology changes.

   Brian

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

---

From: John Strassner <[email-masked]>
Date: Sat, 27 Jun 2015 17:18:05 -0700

Dear Leo,

please see inline, look for <jcs>..</jcs>

regards,
John

4.1.  Naming

   o  Representing each device
         Inside a domain, each autonomic device needs a domain specific
         identifier.
         [Open Questions] Are there devices that don't need names?  Do
         ASAs need names?
<jcs>
I think that each **entity** that can potentially interact with other
entities
MUST HAVE a name. I think of ASAs as managed entities, so yes,
they do as well.
</jcs>

    o  Uniqueness
         The names MUST NOT collide within one autonomic domain.
         It is acceptable that the names in different domains collide,
         since they could be distinguished by domains.
<jcs>
I dislike name collisions, unless there is a good reason to have them
(and please don't say "because it is easier" :-) ). That being said, I
would expect them to be registered in the DNS.
</jcs>

    o  Semantic Encoding
         It is RECOMMENDED that the names encode some semantics rather
         than meaningless strings.  The semantics might be:
         +  Location
         +  Device type
         +  Functional role
         +  Ownership
         +  etc.
         This is for ease of management consideration that network
         administrators could easily recognize the device directly
         through the names.
<jcs>
I am a big fan of semantics. I actively work on ontologies, different
types of logic, metadata-based systems, etc. However, I would NOT
recommend this. First, I guarantee you that we will rathole on defining
a canonical representation for generating strings. Second, if I was an
ASA (I've been called worse :s), I wouldn't pay attention to the name
of an object as much as I would its connections or its metadata. I
would expect the metadata to be well structured, and not just consist
of meaningless text. Hence, I would recommend (pun intended) that
we instead concentrate on defining semantics of metadata
</jcs>

    o  Consistency
         The devices' naming SHOULD follow the same pattern within a
         domain.
<jcs>
s/domain/autonomic domain. You can't rename legacy systems.
</jcs>

    o  Structured Naming Pattern
         The whole name string could be divided into several fields,
         each of which representing a specific semantic as described
         above.  For example: Location-DeviceType-FunctionalRole-
         DistinguisherNumber@NameofDomain.
<jcs>
Why not use metadata to encode the semantics, and standardize the
metadata object taxonomy instead? Also, if I look at the modern
router or switch, the name is useless. What I see is a chassis
containing a set of cards, where each card can play one or more roles.
I would search on roles (which is, of course, a type of metadata). In
this way, I get real information, not abbreviated strings concatenated
together.
</jcs>

          The structure should be flexible that some fields are optional.
         When these optional fields are added, the name could still be
         recognized as the previous one.  In above example, the
         "DistinguisherNumber" and "NameofDomain" are mandatory whereas
         others are optional.  At initial stage, the devices might be
         only capable of self-generating the mandatory fields and the
         "DeviceType" because of the lack of knowledge.  Later, they
         might have learned the "Location" and "FunctionalRole" and
         added the fields into current name.  However, the other devices
         could still recognize it according to the same
         "DistinguisherNumber".
<jcs>
Yikers!
First, having a node that is changing its name is annoying. Of course,
this is a good filter for robust coding :s.
Second, an autonomic domain will add new data all the time (or else
it's probably dead). How do we determine what data is "name-worthy"?
</jcs>

    o  Advertised Common Fields
         Some fields in the structured name might be common among the
         domain (e.g.  "Location" "NameofDomain").  Thus, these part of
         the names could be advertised through Intent
         Distribution (Section 4.5).
<jcs>
I would hope that intent would be smarter and more abstract. If a field
is common, then intent can be abstract and the translation to a common
field is much easier. In other words, being common is not a good reason
to be included in intent.
</jcs>

    o  Self-generated Fields

On Fri, Jun 26, 2015 at 3:27 AM, Liubing (Leo) <[email-masked]>
wrote:

> Hi Dear all,
>
> I've generated some text regarding to the naming of autonomic network
> devices. This is to fit the Section 4.1 in the Reference-Model draft.

-- 
regards,
John

---

From: "Liubing (Leo)" <[email-masked]>
Date: Mon, 29 Jun 2015 07:13:25 +0000

Hi Brian,

Thanks for your comments, pls see inline.

> -----Original Message-----
> From: Anima [mailto:[email-masked]] On Behalf Of Brian E
> Carpenter
> Sent: Saturday, June 27, 2015 9:37 AM
> To: [email-masked]
> Subject: Re: [Anima] Naming discussion (Section 4.1 of the Reference-Model
> draft)
> 
> very well that it may be a common operational practice already, but it's quite
> subject to human error
[Bing] The described pattern isn't for manual configuration. I was imagining the semantic fields could be generated by the autonomic devices themselves. 
The name space of the semantics don't necessarily need to be standardized, the vendors could set vocabulary by themselves. Since the goal is human-readable, human could understand different vocabularies.

> and in a truly autonomic network nobody should ever
> see the names anyway. 
[Bing] When we discussed AN management in the Reference Model draft with Michael B. We all agreed that traditional management would co-exist with autonomic management.
In this sense, do you think the naming is useful for the traditional management part?

> Also, they would need to change autonomically
> whenever the topology changes. 
[Bing] Yes, this would probably happen. John also mentioned the naming change is "annoying" in the other thread. 
So I was just thinking, maybe we could divide the name into two parts: one part is the "basic-name" which should be permanent; the other part is "name-tags" (e.g. Location, Functional Role, Ownership etc.) which are some info that might be useful for administration but might probably changes. 

Best regards,
Bing

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Mon, 29 Jun 2015 07:38:58 +0000

I guess we need to take a step back here. There is indeed a big question on whether naming discussed in this framework is meant for "human" consumption, or not. 

In our pre-standard implementation we chose to pick names automatically, and they are at this point clearly NOT for human consumption. We just make sure they're unique. The admin provides the domain name, which is the same for all devices. 

In a SOHO environment, I claim things should just happen automatically, and the name really doesn't matter much to humans. 

In an SP, we could either use the same model, or allow for operator input. So an SP can provide a mapping between unique device identifier (UDI) and a name that he'd like this device to have. This mapping can be provided in a number of different forms, let's leave that for further considerations. 

But I think, from the ANIMA point of view, we should say: During the enrolment process the admin can provide a name for a device (and a domain name, btw). If a name is provided, it is used (in the certificate for example). If not, a unique, autonomically created name is used. We need an algorithm that creates the autonomic name. (I tried to explain that in the addressing doc, but it was clearly not clear enough). 

Personally, I think we shouldn't define how the name is constructed, if the operator puts one in. 

So, in summary: 
- case 1: Admin provides UDI to name mapping, then that name is used. (we don't care what's inside the name)
- case 2: name is created autonomically, using algorithm x 

Thoughts? 
Michael

> From: Anima [mailto:[email-masked]] On Behalf Of Liubing (Leo)
> Sent: 29 June 2015 09:13
> To: Brian E Carpenter; [email-masked]
> Subject: Re: [Anima] Naming discussion (Section 4.1 of the Reference-
> Model draft)
> 
> Hi Brian,
> 
> > > Below is the content which includes some rough ideas. Please feel
> > > free to
> > comment.
> > >
> > > 4.1.  Naming
> > >
> > Well, yes, we have a system for that, which is the DNS. Is there any
> > reason not to use DNS names?
> >
> > >    o  Semantic Encoding
> > I'm generally against making this a formal recommendation. I
> > understand very well that it may be a common operational practice
> > already, but it's quite subject to human error
> [Bing] The described pattern isn't for manual configuration. I was imagining
> the semantic fields could be generated by the autonomic devices
> themselves.
> The name space of the semantics don't necessarily need to be standardized,
> the vendors could set vocabulary by themselves. Since the goal is human-
> readable, human could understand different vocabularies.
> 
> > and in a truly autonomic network nobody should ever see the names
> > anyway.
> [Bing] When we discussed AN management in the Reference Model draft
> with Michael B. We all agreed that traditional management would co-exist
> with autonomic management.
> > Also, they would need to change autonomically whenever the topology
> > changes.
> [Bing] Yes, this would probably happen. John also mentioned the naming
> change is "annoying" in the other thread.
> So I was just thinking, maybe we could divide the name into two parts: one
> part is the "basic-name" which should be permanent; the other part is
> "name-tags" (e.g. Location, Functional Role, Ownership etc.) which are
> some info that might be useful for administration but might probably
> changes.
> 
> Best regards,
> Bing
> 
> >    Brian
> >
> > >    o  Consistency
> > >          There should various methods for a device to
> > > extract/generate
> > a

---

From: "Liubing (Leo)" <[email-masked]>
Date: Mon, 29 Jun 2015 08:31:04 +0000

Hi Michael and all,

Regarding to "human", I think there are two aspects:
1. Human get involved in generating names. I guess it's what you meant by "human consumption".
2. The names are generated by the devices automatically and also human readable. So that it might be easier for the administrators, e.g. when they're analyzing/debugging a network issue.

For no.1, I also agree human should not participate in the name generation procedure (except the special cases you discussed below).
For no.2, of course it needs a more complex algorithm/molding than only ensuring the uniqueness. My proposed text was trying to discuss the possibility a bit in this direction. 
But from the AN management requirement perspective, do you think no.2 make sense?

Best regards,
Bing

> From: Anima [mailto:[email-masked]] On Behalf Of Michael
> Behringer (mbehring)
> Sent: Monday, June 29, 2015 3:39 PM
> To: Liubing (Leo); Brian E Carpenter; [email-masked]
> I guess we need to take a step back here. There is indeed a big question on
> whether naming discussed in this framework is meant for "human"
> consumption, or not.
> 
> In our pre-standard implementation we chose to pick names automatically,
> and they are at this point clearly NOT for human consumption. We just make
> sure they're unique. The admin provides the domain name, which is the same
> for all devices.
> 
> In a SOHO environment, I claim things should just happen automatically, and
> the name really doesn't matter much to humans.
> 
> In an SP, we could either use the same model, or allow for operator input. So
> an SP can provide a mapping between unique device identifier (UDI) and a
> name that he'd like this device to have. This mapping can be provided in a
> number of different forms, let's leave that for further considerations.
> 
> But I think, from the ANIMA point of view, we should say: During the
> enrolment process the admin can provide a name for a device (and a domain
> name, btw). If a name is provided, it is used (in the certificate for example).
> If not, a unique, autonomically created name is used. We need an algorithm
> that creates the autonomic name. (I tried to explain that in the addressing
> doc, but it was clearly not clear enough).
> 
> > > >          It is RECOMMENDED that the names encode some
> semantics
> > > rather
> > [Bing] The described pattern isn't for manual configuration. I was
> > imagining the semantic fields could be generated by the autonomic
> > devices themselves.
> > The name space of the semantics don't necessarily need to be
> > standardized, the vendors could set vocabulary by themselves. Since
> > the goal is human- readable, human could understand different
> vocabularies.
> >
> > with Michael B. We all agreed that traditional management would
> > co-exist with autonomic management.
> > So I was just thinking, maybe we could divide the name into two parts:
> > one part is the "basic-name" which should be permanent; the other part
> > is "name-tags" (e.g. Location, Functional Role, Ownership etc.) which
> > are some info that might be useful for administration but might
> > probably changes.
> >
> > Best regards,
> > Bing
> >
> > >    Brian
> > >
> > > >    o  Consistency
> > > >          "DistinguisherNumber" and "NameofDomain" are
> mandatory
> > > whereas
> > > >          Some fields in the structured name might be common
> among
> > > the

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Mon, 29 Jun 2015 08:49:01 +0000

> From: Liubing (Leo) [mailto:[email-masked]]
> Sent: 29 June 2015 10:31
> To: Michael Behringer (mbehring); Brian E Carpenter; [email-masked]
> Subject: RE: [Anima] Naming discussion (Section 4.1 of the Reference-Model
> draft)
> 
> Hi Michael and all,
> 
> 2. The names are generated by the devices automatically and also human
> readable. So that it might be easier for the administrators, e.g. when they're
> analyzing/debugging a network issue.
> 
> For no.1, I also agree human should not participate in the name generation
> procedure (except the special cases you discussed below).
> For no.2, of course it needs a more complex algorithm/molding than only
> ensuring the uniqueness. My proposed text was trying to discuss the
> possibility a bit in this direction.

Bing, 
Let me be more verbose in my proposal: 

- case 1: Admin provides UDI to name mapping, then that name is used. 
  (we don't care what's inside the name)
  I suggest that in this case we treat the name as opaque, i.e., ANIMA 
  doesn't care how it's made. 
  I think case 1 is relatively easy to agree on. Right?

- case 2: name is created autonomically, using algorithm x
  Here, I suggest that we don't even try to do something "intelligent". 

Reasoning: What can we figure out automatically, really? Well, device type, vendor can be derived from some h/w information. What else? 
topology - NOT! (not one that's useful to an admin). Frankly I think it is impossible to come up with an automated naming scheme that is 1) completely automatic and 2) admins will be happy with. Let's not even try ;-) 

BTW, I suggest we put UDI info into a field of the certificate, so that it's available when needed, but not onto the name. So in the cert, you do find info on, e.g.,  device type if needed. 

BTW, I think I never mentioned this explicitly, but I think the "autonomic name" we're talking about here should NOT be the hostname of the device. Again, this is to keep traditionally maintained config and autonomic information as clearly separated as possible.

Michael

---

From: Laurent Ciavaglia <[email-masked]>
Date: Mon, 29 Jun 2015 11:58:38 +0200

Hello,

1) Which elements require identification?
     . AF, ASA, AN, something else?
     For me, the only base element in ANIMA that would need an new 
identifier is the AF.
     And a clear relationship map among the AF, ASA, AN, etc. should be 
defined/available at deployment-/run-time (cf coupling / deployment 
models discussion).

2) What's the visibility of the identifier?
     . Should all identifiers be discoverable, advertisable, maintained 
consistently (where/how)?
     For me, the AF is the (only) logical point of interaction, and thus 
should be domain-wide visible.
     The AF provides the redirection mechanism to its ASAs, i.e. if an 
entity needs to talk directly to an ASA, it should have first interacted 
with the corresponding AF. In some cases, the communication between 
entity-x and ASA could be made direct / optimized (such as in the 
knowledge/information plane flows).

3) An identifier to do what / for what purpose?
     . Should the identifier be used for bootstrapping, routing, 
signaling, AF-to-AF communication?
     . A unique identifier is certainly necessary for monitoring, 
forensic...
     . Should the identifier be "human-friendly"? I don't think it 
should, but we can certainly devise some mechanisms to make identifier / 
group of identifiers (e.g. by roles) appear in an elegant/intelligible 
manner to a (human-)user interface. Please note that if we consider 
systems with thousands of elements the human-friendliness of information 
representation goes well-beyond (actually against) having human-friendly 
identifiers.

4) Do we consider that the elements we want to identify have a unique 
identifier or multiple ones? Are the identifier summarizable (reached as 
a group, reached as a role?)

5) On Leo's initial proposition: the naming structure makes me think 
more of the notion of a descriptor attached to the autonomic element, 
describing various aspects of it. The identifier being one. Many other 
information could be present in such a descriptor (will post 
specifically on that later).

What do you think?

Best regards, Laurent.

-- 

Bien cordialement, Best regards,

*Laurent Ciavaglia*

Secure Cloud Networking

Bell Labs | Alcatel Lucent

phone: +33 160 402 636

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

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

address: Route de Villejust | 91620 Nozay | France

---

From: "Liubing (Leo)" <[email-masked]>
Date: Mon, 29 Jun 2015 10:08:36 +0000

Hi John,

Thanks for your elaborate review and comments, please see replies inline.

From: John Strassner [mailto:[email-masked]]
Sent: Sunday, June 28, 2015 8:18 AM
To: Liubing (Leo)
Cc: Anima WG
Subject: Re: [Anima] Naming discussion (Section 4.1 of the Reference-Model draft)

Dear Leo,

regards,
John

4.1.  Naming

   o  Representing each device
         Inside a domain, each autonomic device needs a domain specific
         identifier.
         [Open Questions] Are there devices that don't need names?  Do
         ASAs need names?
<jcs>
I think that each **entity** that can potentially interact with other entities
MUST HAVE a name. I think of ASAs as managed entities, so yes,
they do as well.
</jcs>
[Bing] OK, thanks for your opinion. I don’t have a strong feeling on this. I haven’t figured out the necessity of naming ASAs, but meanwhile I couldn’t deny it either.

    o  Uniqueness
         The names MUST NOT collide within one autonomic domain.
         It is acceptable that the names in different domains collide,
         since they could be distinguished by domains.
<jcs>
I dislike name collisions, unless there is a good reason to have them
(and please don't say "because it is easier" :-) ). That being said, I
would expect them to be registered in the DNS.
</jcs>
[Bing] Ideally, we surely prefer that names never collide, even across domains. But my concern was that it might be difficult to ensure uniqueness across multiple domains than only within one domain.
If DNS is introduced to the ANI, then I guess this issue is done. But would introducing DNS bring some unavoidable human consumption?

    o  Semantic Encoding
[Bing] Thanks for the technical suggestion. Would you mind elaborating a bit more on what did you mean by “metadata”? Sorry for my foolish☺

    o  Consistency
         The devices' naming SHOULD follow the same pattern within a
         domain.
<jcs>
s/domain/autonomic domain. You can't rename legacy systems.
</jcs>
[Bing] Agreed. Thanks for correction.

[Bing] The same “metadata” question as above.

[Bing] As I replied to Brian in another thread: maybe we could divide the name into two parts: one part is the "basic-name" which should be permanent; the other part is "name-tags" (e.g. Location, Functional Role, Ownership etc.) which are some info that might be useful for administration but might probably changes.
How do you think about it?

[Bing] In the perspective of concise concept, I also think Intent might not be proper to carry this kind of info. But Intent Distribution is the only thing I can tell to advertise the common info to the AN.
Any other approaches?

Best regards,
Bing

    o  Self-generated Fields

On Fri, Jun 26, 2015 at 3:27 AM, Liubing (Leo) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Dear all,

4.1.  Naming

   o  Uniqueness

   o  Semantic Encoding

   o  Consistency

   o  Self-generated Fields

Best regards,
Bing

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

--
regards,
John

---

From: Michael Richardson <[email-masked]>
Date: Mon, 29 Jun 2015 21:34:47 -0400

Michael Behringer (mbehring) <[email-masked]> wrote:
    > In our pre-standard implementation we chose to pick names
    > automatically, and they are at this point clearly NOT for human
    > consumption. We just make sure they're unique. The admin provides the
    > domain name, which is the same for all devices.

Were the names related in any way to serial numbers, MAC addresses, or
something that could be inspected physically by a human on the outside of the
device?

I think that this is pretty important, particularly in a SOHO environment.

    > In a SOHO environment, I claim things should just happen automatically,
    > and the name really doesn't matter much to humans.

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

---

From: John Strassner <[email-masked]>
Date: Mon, 29 Jun 2015 20:50:06 -0700

Hi Leo,

regards,
John

 > > Below is the content which includes some rough ideas. Please feel free
to
 > >          Inside a domain, each autonomic device needs a domain
 > >          specific identifier.
 > >          [Open Questions] Are there devices that don't need names?
 > >          Do ASAs need names?
 > >
 > >    o  Uniqueness
reason
 > not to use DNS names?
 >
 > >    o  Semantic Encoding
 > >          It is RECOMMENDED that the names encode some semantics
  > >         rather than meaningless strings.  The semantics might be:
 > >          +  Location
 > >          +  Device type
 > >          +  Functional role
 > >          +  Ownership
 > >          +  etc.
quite

 [Bing] The described pattern isn't for manual configuration. I was
imagining the semantic fields could be generated by the autonomic devices
themselves.
 The name space of the semantics don't necessarily need to be standardized,
the vendors could set vocabulary by themselves. Since the goal is
human-readable, human could understand different vocabularies.

<jcs>
The problem with this is the complexity of the vocabulary. There
have been decades of research on standardizing vovabularies. It
is still not a solved problem. However, if you want to do this,
then I strongly recommend that you consider using ontologies to
establish a formal lexicon (in the computational linguistics
sense of the word).
</jcs>

 > and in a truly autonomic network nobody should ever
 [Bing] When we discussed AN management in the Reference Model draft with
Michael B. We all agreed that traditional management would co-exist with
autonomic management.
 In this sense, do you think the naming is useful for the traditional
management part?

<jcs>
Names are typically only meaningful for human users. Otherwise,
objectIDs are a LOT simpler for a machine to use. I'm confused
as to what the goal is here...and for the "traditional" part, I
think that an autonomic network MUST NOT force any name changes
on legacy environments.
</jcs>

 [Bing] Yes, this would probably happen. John also mentioned the naming
change is "annoying" in the other thread.
 So I was just thinking, maybe we could divide the name into two parts: one
part is the "basic-name" which should be permanent; the other part is
"name-tags" (e.g. Location, Functional Role, Ownership etc.) which are some
info that might be useful for administration but might probably changes.

<jcs>
I strongly recommend that you use metadata to gain information
about a node of interest. Names are a bad way to do this.
</jcs>

 Best regards,
 Bing

On Mon, Jun 29, 2015 at 12:13 AM, Liubing (Leo) <[email-masked]>
wrote:

> > > Below is the content which includes some rough ideas. Please feel free
> to
> > comment.
> > >
> > > 4.1.  Naming
> > >
> quite
> imagining the semantic fields could be generated by the autonomic devices
> themselves.
> the vendors could set vocabulary by themselves. Since the goal is
> human-readable, human could understand different vocabularies.
>
> [Bing] When we discussed AN management in the Reference Model draft with
> Michael B. We all agreed that traditional management would co-exist with
> autonomic management.
> "name-tags" (e.g. Location, Functional Role, Ownership etc.) which are some
> info that might be useful for administration but might probably changes.
>
> Best regards,
> Bing
>
> >    Brian
> >
> > >    o  Consistency

-- 
regards,
John

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 30 Jun 2015 16:25:18 +1200

On 30/06/2015 15:50, John Strassner wrote:
...
> about a node of interest. Names are a bad way to do this.

When I think about more carefully, I agree with John on this.
DNS names must be unique at any one time, but they may change
autonomically, and I think they could be misleading after
topology changes.**

It seems to me that Node Information metadata would be very suitable
to be treated as a Technical Objective like any other (in Anima
signaling jargon), subject to discovery and synchronization like any
other complex parameter. A node's current DNS name and its current IP
address(es) could be considered as part of its Node Information.

I think that each node's constant ID will emerge from the security
bootstrap work.

** OK, it was me who refused categorically to allow the name info.cern.ch
to be assigned to a machine at MIT, when Tim Berners-Lee moved from
CERN to MIT. I thought it would be very misleading, and I still think
that.

  Brian

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Tue, 30 Jun 2015 06:51:04 +0000

> something that could be inspected physically by a human on the outside of
> the device?
> 

Yes, the issue is that there can be (should be) more than one registrar, and we wanted a scheme where the admin really doesn't have to do ANYTHING. Thus our scheme, where the registrar ID is the length of the MAC address: 

The 64 bit  device ID is then composed as:

   o  48 bit: Registrar ID, a number unique inside the domain that
      identifies the registrar which assigned the name to the device.  A
      MAC address of the registrar can be used for this purpose.

   o  16 bit: Device ID, a number which is unique for a given registrar,
      to identify the device.  This can be a sequentially assigned
      number.

Each registrar keeps track of the devices it assigned. Now you have a domain wide unique addressing scheme, and the admin didn't need to do anything. And the zoning / aggregation is optional, and really independent of the base scheme. 

Now my question: I think the text isn't clear enough on this yet - can you let me know how we can make it clearer, or what wasn't clear when you first read it. 

Michael

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Tue, 30 Jun 2015 12:06:34 +0000

Agree with the below sentiments: 

AN should assign a permanent node name to a node, which is, from an AN perspective independent of its current role, location and function. This is independent of the "hostname" used today, which remains as is, and an operator can do with that one what he likes. To encode role, location, function, etc, we use other metadata. 

The AN node name will be part of the node certificate, which is permanent. Also because of this, there should be no role, function or location encoded into that name. 

Now, up to here, I believe we're reaching a consensus. Right? 

The following statement will undoubtedly raise interesting debates: I claim the address assignment should follow the same principles, such that a node IP address is permanent, and essentially an identifier. Now, we all know that sometimes aggregation is needed, for that we brought in the "zones". But the addressing scheme now in the reference doc (https://tools.ietf.org/html/draft-behringer-anima-reference-model-03#section-4.2) is meant to allow for exactly this: The "device ID" remains constant, as an identifier, the zone ID can be used to aggregate, if needed. Thoughts? 

Michael 

> Sent: 30 June 2015 06:25
> To: John Strassner; Liubing (Leo)
> Cc: [email-masked]
> Subject: [Anima] Metadata [was Naming discussion (Section 4.1 of the
> Reference-Model draft)]
> 
> >  > Also, they would need to change autonomically  > whenever the
> > topology changes.
> >  [Bing] Yes, this would probably happen. John also mentioned the
> > naming change is "annoying" in the other thread.
> >  So I was just thinking, maybe we could divide the name into two
> > parts: one part is the "basic-name" which should be permanent; the
> > other part is "name-tags" (e.g. Location, Functional Role, Ownership
> > etc.) which are some info that might be useful for administration but
> might probably changes.
> >
> > <jcs>
> > I strongly recommend that you use metadata to gain information about a
> > node of interest. Names are a bad way to do this.
> > </jcs>
> 
> autonomically, and I think they could be misleading after topology
> changes.**
> 
> It seems to me that Node Information metadata would be very suitable to
> be treated as a Technical Objective like any other (in Anima signaling
> jargon), subject to discovery and synchronization like any other complex
> parameter. A node's current DNS name and its current IP
> I think that each node's constant ID will emerge from the security bootstrap
> work.
> 
> CERN to MIT. I thought it would be very misleading, and I still think that.
> 
>   Brian
>

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 01 Jul 2015 12:02:10 +1200

On 01/07/2015 00:06, Michael Behringer (mbehring) wrote:
> The following statement will undoubtedly raise interesting debates: I claim the address assignment should follow the same principles, such that a node IP address is permanent, and essentially an identifier. 

I think you'll need to define "permanent". If there is some kind of major
event (like a long power cut, for example) you might end up with a
complete cold start of the network and re-creation of the ACP, and then
I think renumbering would probably occur. But certainly the address
should not change as a routine matter.

> Now, we all know that sometimes aggregation is needed, for that we brought in the "zones". But the addressing scheme now in the reference doc (https://tools.ietf.org/html/draft-behringer-anima-reference-model-03#section-4.2) is meant to allow for exactly this: The "device ID" remains constant, as an identifier, the zone ID can be used to aggregate, if needed. Thoughts?

For large networks, yes. Small networks can flat-route anyway.

   Brian

---

From: John Strassner <[email-masked]>
Date: Tue, 30 Jun 2015 17:18:42 -0700

Hi Michael, et al.,

I'm confused as to why there is a question.

One of the principal goals of autonomics is to reduce the administrative
burden on humans. When I combine this with the WG's desire to use "intent",
then why would a name be necessary at all? Why wouldn't the preferred model
be to talk in terms of roles or user-friendly aliases (e.g.,
MyInternetGateway)? Do I really need to call the AAA server that I use
'Fred'? :-) And, with all due respect, naming a device
WiringCloset3Rack2Chassis7-Router-InternetGateway... doesn't really help
(and that's assuming you could get everyone to agree on a taxonomy like
that).

Plus, legacy environments aren't going to care how we name our devices -
they will have their own names, and will also don't care if we like them or
not.

This is why I keep asking why naming is important. If you are using a name
for locating something (boo! hiss!), then you SHOULD instead use metadata,
which can do a much more thorough job and give you many more options. If
you are using a name for programming something ((boo!)^2) then you SHOULD
instead be using a much richer means to identify the (hint) object that you
are trying to interact with. If you are using it for something else, then
let's focus on that and see why it is needed. BTW, I'm obviously guessing
at the first two use cases, and am hoping that I am wrong on both. :-)

I have nothing against names, but I would rather use the right tool for the
right job. In addition, as I said previously, if this really is an
autonomic system, and the name changes, what good is it? Wouldn't it be
better to describe the role the object plays (i.e., the role-object
pattern), or metadata that can be used to hunt the little bugger down? Both
of these are independent of change, since they describe behavior of the
thing, and not an (arbitrary) name that was tacked on to the thing.

> But I think, from the ANIMA point of view, we should say: During
> the enrolment process the admin can provide a name for a
> device (and a domain name, btw). If a name is provided, it is used
> (in the certificate for example). If not, a unique, autonomically
> created name is used. We need an algorithm that creates the
> autonomic name. (I tried to explain that in the addressing doc,
> but it was clearly not clear enough).

Agreed, but I would argue that this should be automatically created
not autonomically created. :-)

> Personally, I think we shouldn't define how the name is
> constructed, if the operator puts one in.

Completely agree. The operator will ignore us anyway. :-)

regards,
John

On Mon, Jun 29, 2015 at 12:38 AM, Michael Behringer (mbehring) <
[email-masked]> wrote:

> I guess we need to take a step back here. There is indeed a big question
> on whether naming discussed in this framework is meant for "human"
> consumption, or not.
>
> In an SP, we could either use the same model, or allow for operator input.
> So an SP can provide a mapping between unique device identifier (UDI) and a
> name, btw). If a name is provided, it is used (in the certificate for
> example). If not, a unique, autonomically created name is used. We need an
> algorithm that creates the autonomic name. (I tried to explain that in the
> addressing doc, but it was clearly not clear enough).
>
> > > specific
> > > Do
> imagining
> standardized,
> one

-- 
regards,
John

---

From: John Strassner <[email-masked]>
Date: Tue, 30 Jun 2015 20:44:53 -0700

Agreed, good points.

regards,
John

On Tue, Jun 30, 2015 at 5:02 PM, Brian E Carpenter <
[email-masked]> wrote:

> > AN should assign a permanent node name to a node, which is, from an AN
> perspective independent of its current role, location and function. This is
> independent of the "hostname" used today, which remains as is, and an
> operator can do with that one what he likes. To encode role, location,
> function, etc, we use other metadata.
> >
> > The AN node name will be part of the node certificate, which is
> permanent. Also because of this, there should be no role, function or
> location encoded into that name.
> >
> > The following statement will undoubtedly raise interesting debates: I
> claim the address assignment should follow the same principles, such that a
> node IP address is permanent, and essentially an identifier.
>
> > Now, we all know that sometimes aggregation is needed, for that we
> brought in the "zones". But the addressing scheme now in the reference doc (
> https://tools.ietf.org/html/draft-behringer-anima-reference-model-03#section-4.2)
> is meant to allow for exactly this: The "device ID" remains constant, as an
> identifier, the zone ID can be used to aggregate, if needed. Thoughts?
>
> bootstrap

-- 
regards,
John