Working session schedule: http://www.gridforum.org/webevents/publish/webevent.cgi?cmd=listweek&ncmd=startup&token=guest%3A360ca0f3&d=24&m=09&y=2004&sb=1&cf=list&swe=1&set=1&sa=1&sort=t,m,e&ws=0&stz=Default&sib=1&de=1&tf=0&cal=cal61&encrypted=DKnvqqz.liW.6&cat= 21/09/2004 NMWG #1 ================== Mechanisms for: Allowing other systems to subscribe for data when it's made. Mark: we were initially just going to look at making the data available, then wait for WS-RF to look at discovery, streaming, notifications etc. RHJ: there are a lot of projects just about to start working on monitoring systems. This work should help stop them all reinventing the wheel, but it should be extensible. Eric: We do not yet have any business logic. Request is the input API, the Report + errors are the output API. The business logic hasn't been done. Report Schema ------------- Timestamp --------- The reason for discussing it at all, is that we've used timestamps for every measurement value. NTP timestamp: 64bit number, plus a resolution, plus accuracy. The accuracy isn't really defined, as it rather depends upon your system. ISO Timestamp: a time string. Single source timestamp: just a timestamp that comes from a particular source, but hasn't really got any relation to the outside world. Comes with an identifying name, so you know you're dealing with the same SST. RHJ: You can't really relate between a SST and a real timestamp Dan: you can, it's how NTP works: there's a certain accuracy limit. No worries about compactness: XML is by its very nature not compact. Should we disallow the ascii timestamp? RHJ: rejects the argument that we shouldn't specify, because everything else is a specification anyway. If everything gets left in now, with the proviso that it isn't used without good reason, then it can be dropped at a later date, unless it's been used in which case it's a useful thing. Yes? 21/09/2004 NMWG #2 ================== piPES web services, Eric Boyd & Warren Matthews ----------------------------------------------- Using request schema version 2004/09/01. Thier demo interface is just a Perl CGI script that dumps the response to the screen. They have implemented reportAll attribute. They get all sorts of data back. They can do pings and BWCTL. Next week there will be a new version of BWCTL that allows third party measurements. Notes from Warren: -> Why is there a port when specifying a node instead of a path? This needs to be cleaned up. -> You can have a source which is IPv4 and a destination which is IPv6. This is OK except that the address should have an address type field instead of the version. -> Matt: so we get a list of address family but we support but don't constrain it to that. What does the NONE value for methodology.endpoint mean? Warren can't use sequences in SOAP::Lite. Dan reckons that this is really broken. How do you include the disck in a measurement? Somehow thinks that it doesn't make sense to have includeDisk in the request. I think it does. Next steps ---------- Intercontinental tests. Discovery doesn't exist yet. There is a list of services available from internet2. Request and response schema differences --------------------------------------- Mostly this is just additions. There is a "?" in the request methodology but a "+" in the response. should be * or somehow "0,1,2". Time information is additional. The times should be timestamps instead of doubles. Params: just have extra attributes. It may be unnecessary to take this out in the report. TL: Is it useful to have the comment lines in the report? Dan can set up a Subversion server on his machine. Eric: make the reconciled version the next version. Then make the tweaks from this meeting. they can go on with the new style of request and response. Goal: normalise schema. It is impossible to enumerate all the possible statistical summaries. The idea is: all data can be uniquely identified by a key consisting of the target (subject), characteristics of the operation (verbs) parameters (adverbs) and an NMWG timestamp. eg: say two people sniffing the same network at the same time, the observer becomes part of the subject. Produce schemas for particular characteristics. For now characteristics the individuals involved can generate their own types then later the NMWG can standardise. Meta data can be reused: passed by reference. Use the same meta data in requests for new measurements, in requests for stored data and responses. Also break out the parts of the meta data so for example two tests between two hosts but with different parameters. Used WSDL to define the chain of functions. My Presentation --------------- Is is worth Warren trying to implement doc/lit? Next steps: Share code with Tanya. piPES stuff with doc/lit for next time. Richard: we need to know soon if we are going to have problems. Eric: might be worth thinking about an agenda for next time. Dan: how do we handle faults? ----------------------------- Hopefully it will be implementation agnostic. Standards for describing faults: The OASIS WSRF-TC already has a structure. The error code field could be anything: for POSIX it would be a textual representation of the field. Matt: suggests that NMWG should not say that particular code types Matt: would have just three errors to start with: disallowed, not available and broken. Dan: Would start with just the base calls. Tasks to do for NMWG -------------------- We all moved to the front of the room to be a little more personal. TODO: share stuff for doc/lit with the groupd. That is: point people at the combined schemas and write a bit of a HOWTO. TODO: validation of the response. Rather a lot of discussion on whether or not we should bother reconcisling the two shcemas just to throw them away when the new schema appears. Are sthr on to for usls in that case. It appears that tinkering with the old schemas and flting the changes into the new schemas as the changes are made would result in: -> an achdable current schema. -> a good replacement soon. Need good responses from the group whenever the iterate. TODO: Going to have to write a validation API. 22/09/2004 GHPN-WG #1 ===================== 22/09/2004 GHPN-WG #2 ===================== 22/09/2004 NMWG-RG ================== Presentation #2 --------------- They are also interested in visualisation.