Hello All,
Ok to take in the things discussed at ogf30 with regards to capabilities:
A very usefull comment was that SIP also modeled their response codes
in a similar way as http does
which we also basing ours off, so lets learn from both:
http://en.wikipedia.org/wiki/List_of_SIP_response_codes
Proposed changes from comments:
> http://perfsonar.net/status/
> informational/
> too_busy
> backend_service_not_available
> protocol_bridge
Too_busy, backend_service_not_available and protocol bridge seem like
they are errors. informational seems to be used in http to advertise
things that happened during the exchange but didn't have an effect
upon successfully completing it.
I'm guessing you could advertise deprecation here like "your still
using version '1.0' please move to '1.1' as this service supports it"
though the LS should iron this out.
SIP's ringing, queued etc seems to indicate that they are dealing with
more statefull connections.
> successful/
> query_accepted/
> echo/
> registration/
> deregistration/
> keepalive/
Could probably suffice with just an 'ok' here as a client know what he
sends he already knows
what was succesfull
> redirection/
not modified might be usefull for the LS, but thats completely subject
to the architecture which there is no consensus upon.
> clienterror/
> bad_request/
> unauthorized/
> method_not_allowed/
> not_acceptable/
> message_not_allowed/
> event_type_not_allowed/
> expected_response_tool_arge/
> servererror/
> internal_server_error/
the end of internal_server_error/ can probably be dropped as
http://perfsonar.net/status/servererror/internal/ gives you the same
amount of information as
http://perfsonar.net/status/servererror/internal_server_error/
> service_unavailable/
not sure if we could just say unavailable, do we have the notion of
more then one service at one spot?
> protocol_not_supported/
> unknown_version/
> data_fetch_error/
Could probably be data_fetching or processing
Categorizing should be like:
https://docs.google.com/drawings/pub?id=1IXUZUSmy83cAJlpiHR96BGkBdgajXKu5IO…
For every type of error one should assert if there is a usecase in
which it is recoverable and if there is a usecae where it's
unrecoverable.
Should there be usecases for both recoverable and unrecoverable then
there should also be two status codes for that single type of error,
this to allow a client to take a appropriate action.
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/netflowhttp://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/pinghttp://personar.net/capability/trend/netflowhttp://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
Hi all,
Would there be time at the OGF upcoming week to discuss how to deal with
multilayer E2E monitoring?
Basically, we have been trying to implement something like that, but got
stuck, since the current XML was not going to work no matter how we bend
it. Peter Tavenier (a colleague of mine) and I asked for opinions on the
perfsonar-dev list, explaining our rational for doing this.
See:
https://lists.internet2.edu/sympa/arc/perfsonar-dev/2010-09/msg00010.html and
more mails in that thread.
Frankly, the discussion that followed in our group at SARA reminded me a
bit on discussion we had on the NML list 3 years ago, and I'm not sure I
want to repeat that. Also I prefer to have a slightly faster time
progressing time. :~)
So I was hoping to get some feedback how to proceed and if other share
this interest.
Regards,
Freek
Hi,
I've started preparing the mappings. So far I've focused only on RRD MA,
PSPS commons and PSPS LS. This is just the beginning for the discussion
(to check if this is a good direction for all interested).
Cheers,
Roman
