[nm-wg] summary of 10th Aug 2004 request schema tele conf

["Leese, MJ (Mark)" <M.J.Leese@dl.ac.uk>]

Folks,

For anyone who's interested, notes from yesterday's schema conference call.
Feel free to mail me any comments, especially if you were there and I
mis-recorded something!

Next call will likely be in three weeks: Tuesday 31st August

Cheers,

Mark.



NMWG Request Schema Telephone Conference: Tuesday 10th August 2004
------------------------------------------------------------------

Present: Loukik Kudarimoti (Dante), Mark Leese (Daresbury Laboratory), Eric
Boyd and Jeff Boote (Internet2), Dan Gunter (LBL), Tanya Brethour (NSCA) and
Paul Mealor (UCL).

Contents: Version 1c of the requirements document has just become available.
People will need time to consider the main requirements, but it was deemed
useful to review the "Outstanding Issues" section immediately.

Resulting Actions:
* Jeff to summarise thoughts on interim communication in an email
* Dan, Mark and Paul to look at commonalities between request and
publication schemas, with view to sharing common components
* Eric and Jeff to define fixed list of test parameter specific tags
* Mark to email NM-WG list over use cases



1. Interim communication (that taking place inbetween initial request and
final results response) - wait for WSRF or produce our own interim
solutions?:

Jeff wasn't convinced that this was a big issue. Having considered this for
piPEs, he thought the following was sufficient:

	requestor		responder
	---------		---------
	request---------->
		<---------- yes/no/not now
		<---------- result (if yes)

Loukik didn't think this was adequate, believing it important for the
requestor to know why a request may have been rejected. Jeff will summarise
his thoughts in an email, and some time will be allocated for discussion at
GGF12 in Brussels.


2. Supporting more complex queries, combining requests for both raw data and
statistical summaries e.g. "Give me the last five raw values of this
characteristic and the average over the last day":

One way to achieve this would be the "NMWG Schema Abstractions" work
outlined by Dan in the last call
(http://www-didc.lbl.gov/NMWG/schemas/normalized/). It's probably also
possible with small changes to the existing schema. However, Eric believes
that this is a fairly radical change from what we have now, and that we
finalise what we already have, and introduce this as a new concept later on.

So, it's on the "to do" list for later.


3. Share common components between request and publication (response)
schemas:

Eric would like this looked at before Brussels. Dan suggested producing a
"side-by-side" representation of both schemas, not using the actual schema
text, but an abstract representation that people can more easily understand.
He will take the token on this first, before passing to Mark and Paul.
Others are encouraged to get involved!


4. Allowing wildcards, such as path.delay.* to match against
path.delay.oneWay and path.delay.roundTrip:

It was suggested that this would only make sense for historical queries. In
the case of future tests, if a system could measure all matching metrics
(e.g. OWD AND RTT), which should the system measure? A user requiring both
to be measured is an unlikely scenario.

Dan, Tanya and Jeff were keener on wildcards being used to implement an
capability discovery mechanism, with a star character implicitly indicating
to the request receiver that the request was a query about its capability.
E.g....

	<characteristic>path.delay.*</characteristic>

....would be understood by the receiver to mean "What delay measurements can
you make, and what delay measurements may you already have stored?"


5. List of predefined test parameter tags (e.g. <tcpBufferSize>):

Eric will aim to complete this with Jeff in time for Brussels.


6. Do we need two sets of test parameter tags - one for the source and one
for the destination end?: 
If we consider the simple example that people may want to specify differing
ports to use at each end of a test, then it's not obvious how to do that
with single <port></port> tags. So that suggests separate src and dest tags.

As an schema implementation issue, we could use separate tags, or the same
tags with an attribute:

<tool>iperf</tool>				<tool>iperf</tool>
<srcPort>5001</srcPort>		OR		<port
endpoint="src">5001</port>
<destPort>10000</destPort>			<port
endpoint="dest">10000</port>

Using attributes has the advantage that if the parameter is shared between
the src and dest end, you could signify this by using one pair of tags, and
omitting the attribute. So, attributes is what we'll try. It's not a crucial
part of the schema, and can be changed later if necessary.


AOB:

Mark raised the issue of use cases, saying that it would be useful to have
some informal cases to prove that what we are doing is both valid and
useful. He will email the NM-WG list.