Subject: [i2rs] format for information models

From: Alia Atlas <[email-masked]>
Date: Wed, 23 Jan 2013 16:44:18 -0500

As part of  the proposed i2rs charter, the WG would need to produce
information models.  I know there's
lots of interest in this and it would be great to agree on a format that
we'd like to see the information models
in.

>From my perspective (learning all the time), an information model is to
describe the information and purpose
of the data needed in the model, without all the details that make the
reasoning and structure hard to understand
(and also take lots of time to develop).  Of course, there's Wikipedia's
definition (http://en.wikipedia.org/wiki/Information_model)
and various RFCs that include information models (RFC 5102, 3585, etc).
 Frequently, the information model
can just be in English.

Based on some side conversations, I'd like to see if we can discuss and
agree on a format to try for the information
models.  What I'd suggest is basically a data-tree (similar to the
TreeOutput from pyang - seen at
http://code.google.com/p/pyang/wiki/TreeOutput) and then information per
data item.  The required information would
be a description, a type, and, if appropriate, a reference (to where else
the concept is defined).

What do you all think?  Any better/different ideas?

Alia

---

From: "Alexander Clemm (alex)" <[email-masked]>
Date: Wed, 23 Jan 2013 22:00:19 +0000

For an overview of information and data models (and the distinction between them), there is also RFC 3444 http://www.ietf.org/rfc/rfc3444.txt

Just as a comment, I like the pyang-ish data tree as a summary of the model structure as well. A short-hand for some of the "cornerstones" of the model, then more specifics can be found in the more formal definition.  I would think what is currently there should provide more or lesswhat is needed, hence I'd hope the group would be able to just reuse that (building any extensions on top if and when needed, but not introducing a new variation).

Kind regards
--- Alex

From: [email-masked] [mailto:[email-masked]] On Behalf Of Alia Atlas
Sent: Wednesday, January 23, 2013 1:44 PM
To: [email-masked]
Subject: [i2rs] format for information models

As part of  the proposed i2rs charter, the WG would need to produce information models.  I know there's
lots of interest in this and it would be great to agree on a format that we'd like to see the information models
in.

>From my perspective (learning all the time), an information model is to describe the information and purpose
of the data needed in the model, without all the details that make the reasoning and structure hard to understand
(and also take lots of time to develop).  Of course, there's Wikipedia's definition (http://en.wikipedia.org/wiki/Information_model)
and various RFCs that include information models (RFC 5102, 3585, etc).  Frequently, the information model
can just be in English.

Based on some side conversations, I'd like to see if we can discuss and agree on a format to try for the information
models.  What I'd suggest is basically a data-tree (similar to the TreeOutput from pyang - seen at
http://code.google.com/p/pyang/wiki/TreeOutput) and then information per data item.  The required information would
be a description, a type, and, if appropriate, a reference (to where else the concept is defined).

Alia

---

From: Alia Atlas <[email-masked]>
Date: Wed, 23 Jan 2013 17:09:44 -0500

Alex,

Thanks for the pointer to RFC3444; I'd read it about 6 months ago to
clarify in my own mind the difference between an information model and a
data model.  I think it's very useful.

On Wed, Jan 23, 2013 at 5:00 PM, Alexander Clemm (alex) <[email-masked]>wrote:

>  For an overview of information and data models (and the distinction
> between them), there is also RFC 3444 http://www.ietf.org/rfc/rfc3444.txt
> ****
>
> ** **
>
> Just as a comment, I like the pyang-ish data tree as a summary of the
> model structure as well. A short-hand for some of the “cornerstones” of the
> model, then more specifics can be found in the more formal definition.  I
> would think what is currently there should provide more or lesswhat is
> needed, hence I’d hope the group would be able to just reuse that (building
> any extensions on top if and when needed, but not introducing a new
> variation).
>

Agreed - I'd prefer to avoid a variation.

Alia

>
> Kind regards****
>
> --- Alex****
>
> ** **
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Alia Atlas
> *Sent:* Wednesday, January 23, 2013 1:44 PM
> *To:* [email-masked]
> *Subject:* [i2rs] format for information models****
>
> ** **
>
> information models.  I know there's****
>
> we'd like to see the information models****
>
> in.****
>
> ** **
>
> describe the information and purpose****
>
> reasoning and structure hard to understand****
>
> definition (http://en.wikipedia.org/wiki/Information_model)****
>
>  Frequently, the information model****
>
> can just be in English.****
>
> ** **
>
> agree on a format to try for the information****
>
> TreeOutput from pyang - seen at ****
>
> data item.  The required information would ****
>
> the concept is defined).****
>
> ** **
>
> What do you all think?  Any better/different ideas?****
>
> ** **
>
> Alia****
>
> _______________________________________________
> i2rs mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i2rs
>
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 24 Jan 2013 12:58:19 -0000

Information provided without comment...
 
draft-ietf-ipfix-information-model-rfc5102bis has approached the problem of an
information model without a modelling language. I think the problem it is
solving is simpler than in I2RS.
 
You might ask the Ops ADs for input on this topic.
 
A
 
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alia
Atlas
Sent: 23 January 2013 21:44
To: [email-masked]
Subject: [i2rs] format for information models
 
As part of  the proposed i2rs charter, the WG would need to produce information
models.  I know there's
lots of interest in this and it would be great to agree on a format that we'd
like to see the information models
in.
 
>From my perspective (learning all the time), an information model is to describe
the information and purpose
of the data needed in the model, without all the details that make the reasoning
and structure hard to understand
(and also take lots of time to develop).  Of course, there's Wikipedia's
definition (http://en.wikipedia.org/wiki/Information_model)
and various RFCs that include information models (RFC 5102, 3585, etc).
Frequently, the information model
can just be in English.
 
Based on some side conversations, I'd like to see if we can discuss and agree on
a format to try for the information
models.  What I'd suggest is basically a data-tree (similar to the TreeOutput
from pyang - seen at 
http://code.google.com/p/pyang/wiki/TreeOutput) and then information per data
item.  The required information would 
be a description, a type, and, if appropriate, a reference (to where else the
concept is defined).

Alia

---

From: Alia Atlas <[email-masked]>
Date: Thu, 24 Jan 2013 10:47:11 -0500

Sure - I'd, of course, be interested in their suggestions.

Alia

On Thu, Jan 24, 2013 at 7:58 AM, Adrian Farrel <[email-masked]> wrote:

> Information provided without comment...****
>
> ** **
>
> draft-ietf-ipfix-information-model-rfc5102bis has approached the problem
> of an information model without a modelling language. I think the problem
> it is solving is simpler than in I2RS.****
>
> ** **
>
> You might ask the Ops ADs for input on this topic.****
>
> ** **
>
> A****
>
> ** **
>
> *Sent:* 23 January 2013 21:44
>
> *To:* [email-masked]

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 24 Jan 2013 17:00:50 +0100

> solving is simpler than in I2RS.

RFC 5102 and RFC 5102bis are in my view not good example for
information models. They essentially defines some core data types and
the mechanisms to define derived data types, called 'Information
Elements' in IPFIX. The core of IPFIX does not even know about
structured data types (RFC 6313 added this capability). So yes, the
problem IPFIX initially addressed was rather simple.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Alia Atlas <[email-masked]>
Date: Thu, 24 Jan 2013 11:13:44 -0500

Juergen,

What would you recommend for an information model for i2rs?

Alia

On Thu, Jan 24, 2013 at 11:00 AM, Juergen Schoenwaelder <
[email-masked]> wrote:

> of an

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 24 Jan 2013 17:26:07 +0100

> What would you recommend for an information model for i2rs?

Frankly, I do not know. I am still unsure what the scope/complexity of
i2rs really is. To find out, I guess people just have to pick
something and get started. YANG tree diagrams are fine to get a quick
overview of YANG data models, they likely won't be the right tool if
many of data model items with more complex interrelationships are
involved - then you need additional diagrams.

/js

---

From: "Jan Medved (jmedved)" <[email-masked]>
Date: Thu, 24 Jan 2013 16:31:11 +0000

+1 for YANG tree diagrams to start with.

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 24 Jan 2013 17:36:55 +0100

> involved - then you need additional diagrams.

I like the approach of RFC 6728 which combines UML with YANG.

Lada 

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: Alia Atlas <[email-masked]>
Date: Thu, 24 Jan 2013 11:41:16 -0500

I was just thinking that UML might be good to show the interrelationships,
if
those get complex.  I'll take a look at RFC 6728.

Alia

On Thu, Jan 24, 2013 at 11:36 AM, Ladislav Lhotka <[email-masked]> wrote:

>
> On Jan 24, 2013, at 5:26 PM, Juergen Schoenwaelder <

---

From: Thomas Nadeau <[email-masked]>
Date: Thu, 24 Jan 2013 16:42:30 +0000

+2

---

From: Edward Crabbe <[email-masked]>
Date: Thu, 24 Jan 2013 10:28:15 -0800

+1 here.  If the relationships are hierarchical / acyclic then YANG would
be a good choice /but/  we also have draft-amante-irs-topology-use-cases-0
on the table, and potentially some related documents incoming;  if these
efforts move forward (ie: modelling inter layer relationships and the
physical plant) we may want to look at other alternatives.

I think this is an interesting discussion to have; it's a bit premature to
settle on a solution given the current uncertainty in the use case set,
*but* it's almost never too early to start experimenting.

---

From: Alia Atlas <[email-masked]>
Date: Thu, 24 Jan 2013 13:33:49 -0500

I'm hearing that a combination of YANG (treeOutput) for hierarchical and
UML for relationships would be good.
It is early to discuss this, but since I've heard of drafts in progress and
have had the question about info-model vs.
data-model asked, I think it is useful to discuss and agree on the basic
way to write-up an info model for i2rs.

Alia

---

From: Thomas Nadeau <[email-masked]>
Date: Thu, 24 Jan 2013 18:33:57 +0000

From: Edward Crabbe <[email-masked]<mailto:[email-masked]>>
Date: Thursday, January 24, 2013 1:28 PM
To: Juergen Schoenwaelder <[email-masked]<mailto:[email-masked]>>, Alia Atlas <[email-masked]<mailto:[email-masked]>>, Adrian Farrel <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [i2rs] format for information models

+1 here.  If the relationships are hierarchical / acyclic then YANG would be a good choice /but/  we also have draft-amante-irs-topology-use-cases-0 on the table, and potentially some related documents incoming;  if these efforts move forward (ie: modelling inter layer relationships and the physical plant) we may want to look at other alternatives.

I think this is an interesting discussion to have; it's a bit premature to settle on a solution given the current uncertainty in the use case set, *but* it's almost never too early to start experimenting.

That is my (implied) point for supporting the Yang approach. Specifically, to me it is about picking an approach (that seems to have a lot of support) and just working with it until someone finds something better to use.   At this point we need to stop talking about which hammer to pick, and instead pick one and build something. Call it experimental or exploratory, but I would like us to start building some examples.  We can tear them down later, but its clear we won't get anywhere until we start somewhere.

--Tom

On Thu, Jan 24, 2013 at 8:26 AM, Juergen Schoenwaelder <[email-masked]<mailto:[email-masked]>> wrote:

/js

--
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587<tel:%2B49%20421%20200%203587>         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103<tel:%2B49%20421%20200%203103>         <http://www.jacobs-university.de/>
_______________________________________________
i2rs mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/i2rs

---

From: Abdussalam Baryun <[email-masked]>
Date: Thu, 24 Jan 2013 19:53:30 +0100

> What would you recommend for an information model for i2rs?

I would want that we do new model for the i2rs, because these models
are different only if they have different purposes, and the i2rs has
different purposes I think.

I usually don't start with the IM or DM before the functions. I need
to understand the functions then the information. So the question that
I need to answer first is;

What functions of I2RS do you have necessary or optional?
after answering this I will be able to find my best information model.

I hope this input has a good point, if not please ignore it, it was my
thoughts to answer,

AB

---

From: Nikolay Milovanov <[email-masked]>
Date: Thu, 24 Jan 2013 21:00:50 +0200

Hi, 

I also agree with Edward's position. If I understood correctly the goal is architecture of a framework for application based forwarding plane control of routing systems. In that sense there will be some work to model the hierarchical structure of the devices but also most likely there might be a need to model the topology of the network or even the topology on different network layers. 

Obviously there is a difference between data and information model and if I understood correctly the difference is in the formality of the model. I would like to make a bridge between the network architecture modeling and software architecture modeling. 
So in Software Architecture there could be quite formal architecture modeling languages (for example ACME, ALLOY,WRIGHT), semi-formal (Like UML) and informal for example visio drawings. 
From those ACME might be interesting for topology based modeling. It based on the idea that the topology consists of components and connectors and each component has ports and each connector roles. Acme is also good for modeling the properties of different components, connectors, ports and roles. I find it good compared to other languages including UML because it allows definition of families of systems and more importantly putting constrains on them. For example connector X, with roles Y can't go in Component Z with Port H. I find ACME quite nice for modeling systems and even system of systems. The good part of it is that it also comes with a tool that is handy for modeling. 

ALLOW and WRIGHT are AMLs(Architecture Modeling Languages) that are good for modeling the behavior of the certain software intensive systems. I am not sure is behavior modeling among the i2rs goals so won't comment on that. 

Regarding UML what about the typical OSS/BSS based modeling based on the TMForm SID model? SID is quite common in telecom industry. It is based on UML class diagrams and already contains classes that model network resources and network services. Personally (as a network engineer) I find SID and UML a bit horrible but this is personal opinion (for example the developers from my team find it nice and easy to understand). 

The last sentence reminds me also that there might be different stakeholders that will benefit from i2rs results (e.g engineers from software community and network engineers) and it might be good if the working group produces views of the models  that will allow different stakeholders to reason about them. 

BR, 
Nikolay Milovanov 
New Bulgarian University 
[email-masked] 

On Jan 24, 2013, at 8:28 PM, Edward Crabbe wrote:

> On Thu, Jan 24, 2013 at 8:26 AM, Juergen Schoenwaelder <[email-masked]> wrote:

---

From: Edward Crabbe <[email-masked]>
Date: Thu, 24 Jan 2013 11:09:04 -0800

I could not agree with your agreeing with me more.  ;)

On Thu, Jan 24, 2013 at 10:33 AM, Thomas Nadeau <[email-masked]> wrote:

>
>
>   From: Edward Crabbe <[email-masked]>
> To: Juergen Schoenwaelder <[email-masked]>, Alia
> Atlas <[email-masked]>, Adrian Farrel <[email-masked]>, "
> [email-masked]" <[email-masked]>
>   +1 here.  If the relationships are hierarchical / acyclic then YANG
> would be a good choice /but/  we also have draft-amante-irs-topology-use-cases-0
>  I think this is an interesting discussion to have; it's a bit premature
> to settle on a solution given the current uncertainty in the use case set,
>  That is my (implied) point for supporting the Yang approach.
> Specifically, to me it is about picking an approach (that seems to have a
> lot of support) and just working with it until someone finds something
> better to use.   At this point we need to stop talking about which hammer
> to pick, and instead pick one and build something. Call it experimental or
> exploratory, but I would like us to start building some examples.  We can
> tear them down later, but its clear we won't get anywhere until we start
> somewhere.
>
>  --Tom
>
>

---

From: Abdussalam Baryun <[email-masked]>
Date: Thu, 24 Jan 2013 20:09:56 +0100

>From your text I think I don't understand it. IMO, we don't need
modeling software or hardware, just define architecture, because it is
all about that. I think we will have one architecture and framework
not many, so one IM

AB

On 1/24/13, Nikolay Milovanov <[email-masked]> wrote:
> Hi,
>
> I also agree with Edward's position. If I understood correctly the goal is
> architecture of a framework for application based forwarding plane control
> of routing systems. In that sense there will be some work to model the
> hierarchical structure of the devices but also most likely there might be a
> need to model the topology of the network or even the topology on different
> network layers.
>
> Obviously there is a difference between data and information model and if I
> understood correctly the difference is in the formality of the model. I
> would like to make a bridge between the network architecture modeling and
> software architecture modeling.
> So in Software Architecture there could be quite formal architecture
> modeling languages (for example ACME, ALLOY,WRIGHT), semi-formal (Like UML)
> and informal for example visio drawings.
> From those ACME might be interesting for topology based modeling. It based
> on the idea that the topology consists of components and connectors and each
> component has ports and each connector roles. Acme is also good for modeling
> the properties of different components, connectors, ports and roles. I find
> it good compared to other languages including UML because it allows
> definition of families of systems and more importantly putting constrains on
> them. For example connector X, with roles Y can't go in Component Z with
> Port H. I find ACME quite nice for modeling systems and even system of
> systems. The good part of it is that it also comes with a tool that is handy
> for modeling.
>
> ALLOW and WRIGHT are AMLs(Architecture Modeling Languages) that are good for
> modeling the behavior of the certain software intensive systems. I am not
> sure is behavior modeling among the i2rs goals so won't comment on that.
>
> Regarding UML what about the typical OSS/BSS based modeling based on the
> TMForm SID model? SID is quite common in telecom industry. It is based on
> UML class diagrams and already contains classes that model network resources
> and network services. Personally (as a network engineer) I find SID and UML
> a bit horrible but this is personal opinion (for example the developers from
> my team find it nice and easy to understand).
>
> The last sentence reminds me also that there might be different stakeholders
> that will benefit from i2rs results (e.g engineers from software community
> and network engineers) and it might be good if the working group produces
> views of the models  that will allow different stakeholders to reason about
> them.
>
> BR,
> Nikolay Milovanov
> New Bulgarian University
> [email-masked]
>
>
>> On Thu, Jan 24, 2013 at 8:26 AM, Juergen Schoenwaelder

---

From: Thomas Nadeau <[email-masked]>
Date: Thu, 24 Jan 2013 19:12:26 +0000

LoL!

From: Edward Crabbe <[email-masked]<mailto:[email-masked]>>
Date: Thursday, January 24, 2013 2:09 PM
To: Thomas Nadeau <[email-masked]<mailto:[email-masked]>>
Cc: Juergen Schoenwaelder <[email-masked]<mailto:[email-masked]>>, Alia Atlas <[email-masked]<mailto:[email-masked]>>, Adrian Farrel <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [i2rs] format for information models

On Thu, Jan 24, 2013 at 10:33 AM, Thomas Nadeau <[email-masked]<mailto:[email-masked]>> wrote:

--Tom

/js

---

From: Abdussalam Baryun <[email-masked]>
Date: Thu, 24 Jan 2013 20:15:42 +0100

> physical plant) we may want to look at other alternatives.

Thoes documents are still not done yet just thoughts written, so the
condition is still not clear, yes they are on the table for work and
changes, I don't think they are even agreed on,

AB

---

From: Alia Atlas <[email-masked]>
Date: Thu, 24 Jan 2013 14:35:11 -0500

The information models are to describe what needs to be modeled in terms of
data
that can be specified, read, notifications, etc.

The architecture and framework are about the role and functionality of i2rs
- so a bit
different.

Alia

On Thu, Jan 24, 2013 at 2:09 PM, Abdussalam Baryun <
[email-masked]> wrote:

> would
> to

---

From: Alia Atlas <[email-masked]>
Date: Thu, 24 Jan 2013 14:37:02 -0500

AB,

What belongs in the IMs will be driven by the use-cases.  I believe we're
discussing how to document them.

Alia

---

From: Alia Atlas <[email-masked]>
Date: Thu, 24 Jan 2013 14:42:04 -0500

Hi Nikolay,

I wouldn't describe the difference between an IM and a DM as simply
formality, but also details and potentially
abstraction layer.

It sounds like you have a few different ideas from YANG and UML.  Can you
write-up something giving more
insight into the pros & cons of each?  And pointers to them so we can learn
more independently.

I don't think we are trying for behavior modeling here.  Nor do I think
we're looking for excessive formality,
but something that can be less ambiguously understood and easily turned
into a data-model (or derived from
one as has been suggested) and is consistent would be good.

Alia

On Thu, Jan 24, 2013 at 2:00 PM, Nikolay Milovanov <[email-masked]>wrote:

> Obviously there is a difference between data and information model and if
> I understood correctly the difference is in the formality of the model. I
> on the idea that the topology consists of components and connectors and
> each component has ports and each connector roles. Acme is also good for
> modeling the properties of different components, connectors, ports and
> roles. I find it good compared to other languages including UML because it
> allows definition of families of systems and more importantly putting
> constrains on them. For example connector X, with roles Y can't go in
> Component Z with Port H. I find ACME quite nice for modeling systems and
> even system of systems. The good part of it is that it also comes with a
> tool that is handy for modeling.
>
> ALLOW and WRIGHT are AMLs(Architecture Modeling Languages) that are good
> for modeling the behavior of the certain software intensive systems. I am
> not sure is behavior modeling among the i2rs goals so won't comment on
> that.
>
> UML class diagrams and already contains classes that model network
> resources and network services. Personally (as a network engineer) I find
> SID and UML a bit horrible but this is personal opinion (for example the
> developers from my team find it nice and easy to understand).
>
> The last sentence reminds me also that there might be different
> stakeholders that will benefit from i2rs results (e.g engineers from
> software community and network engineers) and it might be good if the
> working group produces views of the models  that will allow different
> stakeholders to reason about them.
>
> BR,
> Nikolay Milovanov
> New Bulgarian University
> [email-masked]
>
>

---

From: Abdussalam Baryun <[email-masked]>
Date: Thu, 24 Jan 2013 21:14:51 +0100

Hi Alia,

I think driven not only the use case, but also the i2rs functions

AB

---

From: Nikolay Milovanov <[email-masked]>
Date: Fri, 25 Jan 2013 01:02:17 +0200

Hi Alia, 

Regarding the abstraction and formality. I guess when somebody defines an architecture of something in general one of the difficulties is to determine the level of abstraction. Regarding formality it is good but comes on a price. Usually that price is complexity. 

In my initial post I have used incorrectly the term AML. It is better to change it with Architecture Description Languages (ADLs). So some time ago I was exposed to an ADL called ACME. 
ACME is a language and a also a tool defined by prof. David Garlan (and by his Phd students) from CMU. I guess this is one of the initial publications regarding ACME. http://www.cs.cmu.edu/afs/cs/project/able/ftp/acme-fcbs/acme-fcbs.pdf

So ACME allows you to define a component and connector models of different systems.  It was done for defining software architecture not for defining network architecture. However one of the good definitions of Software Architecture is "A software architecture of computing system is the set of structures needed to reason about the system, which comprise elements, relationships among them and properties of both" [*Documenting Software Architecture: Views and Beyond, 2nd Ed. Clements et al. 2010.] To me this sounds like a network isn't it... 

As a visiting faculty member in CMU I spent some months with David's group and start wondering where are the differences between Network and Software Architecture and can't we (I still consider myself more of a network engineer than a software one) use also languages as ACME. What I found in particular interesting is the fact that  ADLs allows you to create a style. A good definition of a style is "An architectural style is a coordinated set of architectural constraints that restricts the roles/features of architectural elements and the allowed relationships among those elements within any architecture that conforms to that style."  

This sounds fancy but in fact an architectural style in software is the same as in building architecture. When you see certain building somehow in your mind comes that this follows that style. For example when you see Guggenheim museum in New york and some other building of Frank Lloyd Wright you will instantly recognize the style. 
As a good reading on those I consider Roy T. Fielding dissertation. http://www.ics.uci.edu/~fielding/pubs/dissertation/software_arch.htm  

In ACME the style is expressed as a family. The family allows you to instantiate a number of similar systems that comply to the style e.g comply with constrains.

So having those in my head and reading the initial discussions on i2rs I wondered won't something like this be useful also here. For example we might put some models in the framework but also to define certain constrains on how it should be used and implemented. 

Just to finish for ACME I did a relatively simple model of a 3 host network (2 end hosts and a router). To highlight the approach I also defined a simple family. My system complies to my family. 

I have attached the sources. The constraints are expressed as rules in IPfamily. Attached is also a screenshot from ACME.  

Finally as PROS:
I would say that it is formal. It allows integration between the information model and constraints. It is good for dynamic perspective of the systems (e.g systems or network that are up and running). In particular I liked the idea behind the styles and constraints.  

As a CONS:
Information/data model relates more to a static perspective/view of the system/network and a YANG or UML class diagram will be better. Also from UML or YANG might be easier to generate an exact data model. An example is TM-FORUM SID model used widely in OSS/BSS industry [http://www.tmforum.org/InformationFramework/1684/home.html]. 
I would say that it is definitely not popular among networking society. 
It is not that easy to get used to it and get it working. In fact software society is using much more UML which is considered as semi-formal. 
However I guess despite that  ACME  is not common for regular developers but it has influenced many scientists including people such a Roy Fiedling and the people that has invented UML. 

Nikolay   

PS: Congrats for the i2rs  working group initiation!  

On Jan 24, 2013, at 9:42 PM, Alia Atlas wrote:

> Hi Nikolay,
> 
> I wouldn't describe the difference between an IM and a DM as simply formality, but also details and potentially
> abstraction layer.
> 
> It sounds like you have a few different ideas from YANG and UML.  Can you write-up something giving more
> insight into the pros & cons of each?  And pointers to them so we can learn more independently.
> 
> I don't think we are trying for behavior modeling here.  Nor do I think we're looking for excessive formality,
> but something that can be less ambiguously understood and easily turned into a data-model (or derived from
> On Thu, Jan 24, 2013 at 2:00 PM, Nikolay Milovanov <[email-masked]> wrote:
> Hi, 
>

---

From: David Meyer <[email-masked]>
Date: Thu, 24 Jan 2013 17:19:54 -0800

Agreed that YANG seems a reasonable  place to start.   --dmm

Sent from my iPhone

---

From: Jeff Tantsura <[email-masked]>
Date: Fri, 25 Jan 2013 01:28:06 +0000

Agree with David, at least we are not reinventing the wheel and using well defined data model. 

Regards,
Jeff

---

From: t.petch <[email-masked]>
Date: Fri, 25 Jan 2013 15:26:38 +0000

... although we do get posts on the Netmod WG list saying what on earth
are all these strange characters, so the format of YANG tree diagrams is
not intuitive to all; there is probably an assumption of some (arcane?)
piece of computer science in there somewhere.

Tom Petch

----- Original Message -----
From: "Thomas Nadeau" <[email-masked]>
To: "Jan Medved (jmedved)" <[email-masked]>; "Juergen Schoenwaelder"
<[email-masked]>; "Alia Atlas" <[email-masked]>
Cc: "Adrian Farrel" <[email-masked]>; <[email-masked]>
Sent: Thursday, January 24, 2013 4:42 PM
Subject: Re: [i2rs] format for information models

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 25 Jan 2013 16:50:13 +0100

> piece of computer science in there somewhere.

It is certainly advisable to accompany such diagrams with some kind of caption. In any case, I find these diagrams pretty useful and see nothing really arcane, let alone computer science, in the output of

pyang --tree-help

Lada

---

From: Andy Bierman <[email-masked]>
Date: Fri, 25 Jan 2013 09:16:50 -0800

> I like the approach of RFC 6728 which combines UML with YANG.
How about both?. The first step is to understand the data structures
at a high level and how they relate to each other. The IPFIX approach
is best for that. The next step is understanding each data structure
in more detail and YANG tree diagrams are good for that. I agree with Tom
that the syntax is not completely intuitive.

> Lada
Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Sat, 26 Jan 2013 10:20:38 +0100

> is best for that. The next step is understanding each data structure

I agree. The authors of 6728 use a semi-formal procedure for mapping UML diagrams to YANG structures: object properties are represented as YANG groupings, aggregated components as
subordinate nodes and unidirectional associations as leafrefs. And then they fill in the details in YANG.

Lada