Hi all, me and Jean had a conversation that happened to be "private", instead of "public" as in our intentions. My fault. So here it is... Augusto ---------- Forwarded message ---------- From: Jean Parpaillon <jean.parpaillon@free.fr> Date: 2013/11/12 Subject: Re: [occi-wg] xml for occi-monitoring To: Augusto Ciuffoletti <augusto@di.unipi.it> Le 12/11/2013 12:36, Augusto Ciuffoletti a écrit :

Ok, this is a roadmap item! Note that this discussion is now between me and you, though...

This is bad point. Would you mind transfer it to the ml ? Jean

2013/11/12 Jean Parpaillon <jean.parpaillon@free.fr <mailto:jean.parpaillon@free.fr>>

Hi

Le 06/11/2013 10:33, Augusto Ciuffoletti a écrit : > Replies are inline > > 2013/11/1 Jean Parpaillon <jean.parpaillon@free.fr <mailto:jean.parpaillon@free.fr> > <mailto:jean.parpaillon@free.fr <mailto:jean.parpaillon@free.fr>>> > > Hi Augusto, > I had a look at your document and I have some comments: > > 1) as of RFC2606, example.com <http://example.com> <http://example.com> and example.org <http://example.org> > <http://example.org> are reserved domain for > documentation purposes; > > > touché > > > 2/ While it's perfectly fine for me to let provider decide metrics he > wants to expose, I think a minimum of interoperability requires

a

> standardized list of them. > > It would be a hard task to make the job again which was done succesfully > over the years by SNMP community. I am thinking about a way to translate > SNMP MIB variables into OCCI. > We may define MIBs as a mixin to associate to a sensor, for instance: > > <occi:mixin title="SNMP MIB" > scheme="http://schemas.ogf.org/occi/monitoring#" term="mib" > use="optional" > > <occi:applies scheme="http://schemas.ogf.org/occi/monitoring#" > term="sensor" /> > <occi:attribute name="name" type="string" /><!-- eg IP-MIB --> > <occi:attribute name="id" type="string" /><!-- eg .1.3.6.1.2.1.4 --> > </occi:mixin> > > This is not complete, of course, but would rely on SNMP set of metrics > for providing a good level of interoperability between

monitoring

> providers. > > > Yes, this is true. The point for me is to what extent a *single* > standardization document has to detail. > > For instance, think to the RTP protocol: it is designed to transport > multimedia, but there is no effort to define what is a frame. All

this

> is demanded to extensions, and there are a lot, and more are coming. > > I have a similar idea of OCCI: include a definition only of concepts > (types) that are strictly needed to make it self contained. If I say > that an attribute is a number, I must say what a number is. In my case I > have time attributes, and I have to define what time is (note, I use > only strings and integers, since this seems to be the limited

toolset

> available). > > Extensions to the bare minimum should included in companion

documents:

> they can change over time, and the companion document may be superseded, > or deprecated. But the foundations are intact. > > So, in my mind it is ok to create a document "OCCI extension to > represent networks as MIB", and to take advantage of other long > elaborated results that aim at describing resources. But leaving

this

> distinct from a "foundational" document. >

I agree with that. Monitoring and OCCI<->MIB spec must be separated.

But

as the latter one would widely depend on monitoring categories, I

would

tend to begin this spec ASAP to validate the monitoring spec.

> Bye! > > Augusto

Ciao Jean

> > Best regards, > Jean > > Le 18/10/2013 15:48, Augusto Ciuffoletti a écrit : > > Dear all, > > > > I have added to the xml-data-format branch an example of the

xml

> that a > > provider (ACME) might add to specify the kind of monitoring options it > > offers. I recall that one of the key features of the approach is to > > leave the provider the freedom to define the available building blocks > > for the monitoring services. The file (occi-monitoring-acme.xml) is > > attached to this e.mail, together with an updated revision of the > > occi-monitoring.xml. > > > > I'll be happy to read any comment on this, especially on the > > appropriateness of the namespaces I have chosen: this is a > critical part > > that cannot be tested with xmllint... > > > > Augusto > > > > PS: apologies if a real ACME provider exists... > > > > -- > > Augusto Ciuffoletti > > Dipartimento di Informatica > > Università di Pisa > > 56100 - Pisa (Italy) > > > > > > _______________________________________________ > > occi-wg mailing list > > occi-wg@ogf.org <mailto:occi-wg@ogf.org> <mailto:occi-wg@ogf.org <mailto:occi-wg@ogf.org>> > > https://www.ogf.org/mailman/listinfo/occi-wg > > > > > -- > Jean Parpaillon > Open Source Consultant > Phone: +33 6 30 10 92 86 <tel:%2B33%206%2030%2010%2092%2086> <tel:%2B33%206%2030%2010%2092%2086> > im: jean.parpaillon@gmail.com <mailto:jean.parpaillon@gmail.com> <mailto:jean.parpaillon@gmail.com <mailto:jean.parpaillon@gmail.com>> > skype: jean.parpaillon > linkedin: http://www.linkedin.com/in/jeanparpaillon/en > > _______________________________________________ > occi-wg mailing list > occi-wg@ogf.org <mailto:occi-wg@ogf.org> <mailto:occi-wg@ogf.org <mailto:occi-wg@ogf.org>> > https://www.ogf.org/mailman/listinfo/occi-wg > > > > > -- > Augusto Ciuffoletti > Dipartimento di Informatica > Università di Pisa > 56100 - Pisa (Italy)

-- Jean Parpaillon Open Source Consultant Phone: +33 6 30 10 92 86 <tel:%2B33%206%2030%2010%2092%2086> im: jean.parpaillon@gmail.com <mailto:jean.parpaillon@gmail.com> skype: jean.parpaillon linkedin: http://www.linkedin.com/in/jeanparpaillon/en

-- Augusto Ciuffoletti Dipartimento di Informatica Università di Pisa 56100 - Pisa (Italy)

-- Jean Parpaillon Open Source Consultant Phone: +33 6 30 10 92 86 im: jean.parpaillon@gmail.com skype: jean.parpaillon linkedin: http://www.linkedin.com/in/jeanparpaillon/en -- Augusto Ciuffoletti Dipartimento di Informatica Università di Pisa 56100 - Pisa (Italy)