(This list mostly from Susan's notes)
Mark Leese (Daresbury)
Paul Mealor (UCL)
Brian Tierney (LBL, former Co-Chair)
Dan Gunter (LBL, works for Brian)
Jeff Boote
Eric Boyd
Yang Xia (CalTech)
Les Cottrell (SLAC)
Susan Evett (scribe)


Agenda:
GGF12
Request/Response schema



Who will be able to attend GGF?
Brian, Dan, Mark, Eric

Will do an all day session.
NMWG and NMRG will have to coordinate somehow.
The NMRG is actually called NMA: Network Monitoring for Applications

NMA will have a single hour and a half session.

NMWG will try to have an all-day session.

Presentations: schema work. Follow up with some discussion.

Eric was at the I2 Joint Techs meeting. Will try to have the NMWG schemas working for GGF.
Hopefully will get Advisor to work with it.

Warren has got the Request Schema working for the OWAMP data.
Jouseph (sp?) has got MonaLisa requesting data with that.


They will try to do demos with various producers and consumers.

Brian: a new subject on more abstract schemas for presenting informatiuon


Dan Gunter:
Requesting stuff from Internet2 with a web page
Using XMLRPC
A student did all the work :)
The web page can query the I2 database, and the netlogger database.

There's a link to the web page being sent...http://dsd.lbl.gov/~mele/

Eric: Any problems with the schema:
Dan: it's "interesting".
It's difficult to do queries across multiple paths, because of how the database is set up.



What Dan and Martin were thinking for the response schema:

Been talking about is broader than that:

http://dsd.lbl.gov/~dang/nmwg_new_schemas/
Slide 4:
The first subject is the network path, as that's everything we've been talking about.
The operation is the operation o the path that gets the data.

The data then could be the subject of another operation, such as taking the mean of the data.

You can see that if an implementation could be split into these parts, you could do quite a lot with it.

Slide 6:
Shows what sort of thing can be a subject and what sort of thing can be an operation.

Eric: This might be a way of introducing a bit of state into the system?
Because there's ID in it?

Dan: don't think that this is the only way of implementing it. You could do all the stages in one go.
Also: if you wanted to do more on a result you've already got,
you can send the data back inline so that you can already get stuff.

Obviously there would have to be some agreement as to whether the data neesd to be sent back inline, or whether the server can maintain state.

This might radically change and simplify the schemas,
and move lots of parts into other parts.

You could use XSLT to transform between what we have at the moment, and what we get on this.



Looking at the request schema:

Section: How:
Part 1:.	To satisfy certain requests, the receiving system can decide to run on-demand tests...

Eric: If you aren't allowed to make new measurements and they get asked for, ther server has to be able to say so.
Paul: Well, this should be an intermediate message
Dan: maybe we could use HTTP error codes

Eric: maybe this should be an out-of-band error, or part of the report schema.

Part 2, 3:
Jeff: 
Jeff: if you're an implementor, then you can not support 3a and still remain legal?
Eric: so there has to be a response that says that one of those.
Eric really thinks that we need to have the command line

Result:
You can do either but not both of 2 and 3a in one request
You can also reply saying that you don't support one of the two forms, if you don't

Jeff: If you make an interface, and you only support 2, then if you add a new feature to a tool, you would have to add a whole new parameter.
This is a reason that the CLI parameters is useful.

Jeff: Maybe 2 should be required?  Not necessarily support all parameters, but the form should be required.

Yes! Horray!



Eric: suggestion:
Can Mark get the changes put in, and then we can continue.



Next meeting: two weeks from now.