This is a work in progress. Sections in red are yet to be filled out properly.
So far I have:
•	a section for concrete requirements for a monitoring service;
•	a section of use-cases for network monitoring (although these need to be extended);
•	a section brainstorming ideas for the required services;
•	a section on possible service components and their interactions, service data, operations and lifetimes.
1	Network Monitoring Service
1.1	Requirements
In this section, clients are taken to mean Grid middleware, user software and administrators.
Client/service interactions include discovery of further services, interaction with monitoring points to make new measurements, extraction of results.
Inter-service interactions include discovery of further services, interaction between monitoring points to make new measurements.
1.1.1	Client/service scheduling
1.	It should be possible to specify that new measurements are to be made, either by specifying particular times for measurements to be made, by specifying a repeating schedule of measurements, a combination of the two, or some other mechanism.
2.	It should be understood that measurements may not be made exactly when requested (see 1.1.4). Rules governing acceptable deviation from a schedule of measurements may be required.
3.	It should be possible to update or remove a particular schedule of measurements, given the proper authorisation.
4.	It should be possible to track the progress of measurements in a schedule. That is, it should be clear when a measurement:
a.	has not yet been made;
b.	has been delayed for some (any) reason;
c.	has been cancelled;
d.	has been made;
e.	or is in some other state.
Clearly, in a schedule, especially a repeating schedule, this reporting could be quite complicated.
5.	It should be possible to receive notification of the results whenever measurements in a schedule have been completed.
create new schedules of measurements
securely edit and delete individual schedules
Track the progress of a schedule
1.1.2	Client monitoring system querying
Ability to ask if anything is happening at a particular time.
1.1.3	Client extraction of results
1.	It should be possible to extract any characteristic as long as it is available. The service should not be constrained to those characteristics defined now.
2.	Results should be available encoding in the NM-WG NetworkMeasurement schema (or some other, later, standardised form).
3.	It should be possible to specify that results are transferred in any form supported by both the service and the client. This will allow large volumes of data to be transferred as efficiently as possible.
See NMWG examples
1.1.4	Inter-service scheduling
1.	Services must be able to negotiate the timing of a measurement such that it does not interfere with other measurements.
2.	Schedule negotiation need only happen on a last-minute basis. That is, the negotiation need only start at the time when the measurement is to be made.
3.	It should also be possible for two services to negotiate a schedule in advance of the actual measurement, if both services support this. This is, however, a difficult problem.
Last-minute only: advance resource scheduling is complicated and possibly unnec,essary. Requires lots of stateful stuff... but that isn't a problem with grid service instances.
1.1.5	AAA control
It must be possible to control which users are able to do: this includes setting the maximum lifetime for test schedules, disabling intrusive/damaging tests for certain groups
1.1.6	Delegation
1.	It must be possible for the negotiation of and taking of measurements to be delegated to other components within the system.
For example: in piPES, the MDI fields requests for new measurements, but other components, PMCs, themselves negotiate a free space. (In the real piPES system, the negotiation is done with other protocols). In this case, the PMC receives a measurement request much like the MDI does.
1.1.7	Discovery
1.	It must be possible to discover the services responsible for a particular host (given the proper authorisation).
2.	It should be possible to discover the types of measurement available (the characteristics available) from a particular service, and the parameters that can be set for those measurements and their acceptable values. This information is likely to be used in a resource discovery context when searching for services.
1.2	Requirement use cases
1.2.1	Administrative: scheduling of regular tests for status monitoring
An administrator wants to set all the monitoring points under his control making regular measurements of a particular type.
Later, due to a configuration change, he wants to add further monitoring points to the regular measurements, and increase the intervals between measurements made by all the original measuring points.
After some time, the administrator decides to delete all the schedules.
1.2.2	Administrative: use of a scheduling protocol such as EDG WP7's Point Coordination Protocol
An administrator wants to use the Point Coordination Protocol to schedule measurements. He assigns each measurement point to one or more cliques.
1.2.3	Administrative: scheduling of tests for problem-diagnosis
An administrator wants to start some regular measurements for a short period. The nodes involved are not necessarily under his direct control, though he has some permission (however administered) to make measurements.
The diagnosis takes longer than expected, so the administrator makes sure the measurements continue.
After a while, the administrator discoveres the fault involved, and stops making measurements.
1.2.4	Administrative: request a history of tests that were made, to see if anything could explain a particular facet
Make a request to the database, discard all the results.
1.2.5	Middleware: multiple requests for recent data, and often, for optimisation purposes
Note: get statistics about the number of requests to R-GMA from Franck
1.2.6	Middleware: scheduling of tests for problem diagnosis
1.3	Brainstorming
1.3.1	Requesting measurements and data
Certain data structures have already been defined by the NMWG relating to the requesting of tests, and the response to those tests.
•	A schema designed to meet many different projects’ needs for requesting new measurements…
•	A schema designed to present the results of any measurement in a generalised fashion.
These schemas should be used whenever possible.
1.3.1.1	Schedule service instances
Individual schedule sections are represented by individual service instances. 
Some factory service (not necessarily an OGSI Factory) is used to create new instances, possibly created with a schedule already assigned.
1.3.1.2	On-demand tests
A major use of network monitoring services will be as sources of information for resource brokers distributing jobs and data on a Grid. Resource brokers will expect reasonably recent measurements, and if none are available new measurements should be made.
It is expected that schedule service instances could handle this functionality assuming that simple “schedules” of this sort can be used to retrieve historical measurements, without excessive overheads.
1.3.1.3	Historical tests
It must be possible to request historical tests. Given the need for “on-demand tests”, the interface for requesting old and new measurements should be reasonably homogonous. Ideally the same interface(s) should be used for historical and future tests.
1.3.2	Administrative access
Administrative access to all aspects of the monitoring system is very important. It must be possible to find and access every schedule in the system, given the appropriate permissions.
This requires service types that do the following:
•	a registry of all schedule service instances (or a particular subset of them);
•	provide some sort of overview of all scheduled tests;
•	allow arbitrary subsets of those scheduled tests to be modified.
1.3.3	Measurement negotiation
Different monitoring systems in different administrative domains must communicate with each other to negotiate a number of things:
•	tools and versions to use
•	when to make new measurements
•	general authentication and authorisation
1.4	Possible components
The components presented here may not be entirely self-consistent. Some may preclude the use of others, so may require others to work.
1.4.1	Client interaction
1.4.1.1	Schedule
1.4.1.2	Scheduler
The schedule service(s) act as a factory for creating Schedules.
An overall schedule may be offered to allow administrative control, but this, of course, depends upon individual implementations.
1.4.1.3	Scheduler Group
This Service Group should allow discovery of the services associated with other services and hosts.
1.4.1.4	Schedule Group
This Service Group should allow administrative-level discovery of currently defined Schedule instances.
1.4.2	Monitoring system interaction
1.4.2.1	Measurement Endpoint
Instances of this type would represent one of the endpoints of a measurement while it’s running. This port type would include operations for negotiating the measurement, and would contain a (a list?) of other endpoints involved with the measurement.
The measurement endpoints should be able to negotiate over the making of a measurement; it seems difficult and not very useful to have exactly the same port type at both ends of a measurement (i.e. the initiator and acceptor ends). It seems better to have particular tasks assigned to each end of the measurement based on some (perhaps arbitrary) decision about who owns or wants to make the measurement.
1.4.2.2	Measurer
This is effectively a factory for generating measurement endpoints.
It’s conceivable that the same measurer type could be used for both the source and sink ends of a measurement, but perhaps this isn’t wise.