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