[nm-wg] immediate future of current schemas

["Leese, MJ (Mark)" <m.j.leese@dl.ac.uk>]

Hi folks,

We had an NM-WG call last week, for which Dan has already circulated some
notes. It was proposed that we put *some* effort into stabilising the
current schemas. This would allow people to press ahead with the
implementation work they had planned, BUT in the knowledge that Martin and
Dan's new, more powerful framework will be available in the future. It would
also allow us to create some sensible business logic.

This was agreed by those in the call, which from a "we have implementations
planned" point of view included Eric for piPEs, Jim Ferguson for Advisor,
and me for the UK, and European efforts of EGEE-JRA4 and DANTE. In terms of
groups we believe are planning to use the schemas, AMP, MonAlisa and SLAC
were not represented on the call. 

So, in summary the proposal was:

1. stabilise the current schemas soon, with suggestions for Document-Literal
implementations (doc-literal allows messages to be validated against the
schema, and provides easier interoperability between services)
2. then X months in future, we release the 'new' schemas

***** PLEASE SHOUT IF YOU ARE NOT HAPPY WITH THIS DECISION, or you have
questions! *****



It's also possible that we will put the requirements for the current schemas
through the "GGF process", perhaps as "informational" or "community
practice" documents. However, Eric and I need to investigate this more
thoroughly first.



The minimum set of outstanding issues that would need to be resolved is
given below. There are some issues, such as investigating adding custom tags
to messages, that I think we can leave till later:

1. Harmonise the request and response schemas.

2. Create the pre-defined set of tags for specifying test (tool) parameters,
e.g. <tcpBufferSize>. We also need to decide which of these parameters can
differ between the source and destination ends of a test path. 

3. Decide whether it should be possible to specify source parameters using
parameter specific tags, and destination parameters using a list of
parameters, and vice-versa.

4. Discuss the inclusion of a field for transaction IDs in both the request
and existing publication
schema [1], to allow better tracking of interactions (ties in wirh whether
we want stateful or stateless batching of results).

5. Investigate Warren's comments from his talk (presented by Eric) at the
last GGF. MANY thanks to Warren for coming up with these!:
	+ Why does an address
(networkMeasurementRequest.request.subject.node.address.port) have a port?
	+ As a result of Warren's question on whether it was legal to have
one address is IPv4 and the other as IPv6, we decided in Brussels that
addresses should have an address type field instead of a version.
	+ For networkMeasurementRequest.request.methodology.endpoint what is
the purpose of option endpoint=none?
	+ How do you request a test that includes the disk, e.g.
disk-to-disk iperf test?

6. A few minor tweaks for Paul and I to make, e.g. we now make parameter
specific tags specific to one end of a test path (source or destination)
using an attribute, e.g. <port endpoint="source">10000</port>. So why do we
have the parameter lists as <srcParameterList> and <destParameterList>. For
consistency they should perhaps be changed to <parameterList endpoint="">.



If there are no objections to this approach, I hope that we can start
resolving these during the next call (next Tuesday, the 26th).

Cheers,

Mark.