[Nmc-wg] Capabilities

[Michael Bischoff]

Hello All,

Ok to take in the things discussed at ogf30 with regards to capabilities:
(this time for real in my last email it should have said status/error codes)

We touched upon Service types, for backwards compatibility reasons at
least it was favored to have them around, this caused us to reiterate about
nmc and fixing things that are in current use. It was suggested to have an
appendix/supplement or attachment. With what we fixed and why we fixed it.

I'm not sure how complete the consensus was but from what I could gather
was that as long as there is still information offered that allows us to the
things that we previously used the service types for they can be removed.

So we need to make sure that we identify how they are used currently and
make sure that we end up with a form of advertising capabilities that suffices
for those usages.

EventTypes(in requests) where touched upon I indicated that I completely
ignored servicestypes and relied strictly upon event types. Now as commented
in our calls: As clients and services should support whole scenario's which
could entail more then one request/response, eventypes do not completely
define the capabilities as you also need to define the message
exchange patterns.

The direction was that we could summarize both patterns and eventypes used
in those patterns as a 'protocol'*.

*should we come up with a different label for 'protocol' in this context?
Fine graininess

As such a  'protocol' would be extension of an other protocol(except
for the base)
you would end up with a tree now for the ls you'd probably have to
advertise the
whole path from root(base protocol) to leaf(protocol x) If you want to avoid
adversing all of those one could mark protocols as abstract and
concrete and not
allow advertisement of abstract protocols and not allowing extending concrete
ones.

it probably depends on the fine-graininess what works here. as well as
how well a
tree structure works what if a protocol has a scenario where it want
to combine two
branches to enable something new - or is this too theoretical as we
currently can
fit everything in here then again there aren't many scenarios that go beyond
request/response atm.

Perhaps the following should be in a different email: (warning length)

- thinking about it now though it might not be too much of a problem
as you could
just advertise:

perfsonar/base/ma/rrd
or
http://personar.net/capability/ma/rrd
or
http://personar.net/capability/archive/rrd

and
http://personar.net/capability/archive/netflow
http://personar.net/capability/real-time/netflow

though I already notice again that the notion of mp ma is limiting us
we should really
view it as read/write/time context or perhaps better formulated
query/store/time.

Also our notion of rrd and sql service is perhaps the wrong
perspective as it tells me
nothing about the information I can obtain from it. You can store
sales data in both of
them which might not be network measurement data to begin with. Well
what are you
quering from a rrd service? it's trend data right? Perhaps we should
rename the rrd to
trendservice, at least that way we know something about the data we
can obtain from
it rather then how it gets stored.

http://personar.net/capability/archive/trend

Though trends are always about the past, so something we obtain from archives:

http://personar.net/capability/trend

though it's incomplete as we do not know what the trend is of, sure
when we add a
network element in the mix we know something more specific about it
but it could still
be ping data, netflow data, throughput, utilization

http://personar.net/capability/trend/ping
http://personar.net/capability/trend/netflow
http://personar.net/capability/trend/utilization

ping data an aspect of the of the characteristic 'responsiveness'
http://personar.net/capability/trend/responsiveness
netflow is probably dataflow
http://personar.net/capability/trend/dataflow
utilization can go unchanged.
http://personar.net/capability/trend/utilization

now is ping data the only aspect of responsiveness? should we add another level?
http://personar.net/capability/trend/responsiveness/ping ?

it gets fuzzy.

same with the ordering you could also go:

http://personar.net/capability/responsiveness/ping/trend

I'le leave it up to you all to figure out what kind of issues present
themselves here.

Best regards,

Michael