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