[nm-wg] Notes from Wednesday's call

[Dan Gunter]

Susan Evett wrote:

> Attached are the notes in .rtf and .doc formats.
>
> --Susan


Also, in plain text.

-Dan

--

GGF NM WG Notes 02/16/05
Call began at 2:00 pm MST.

Attendees:
Mark Leese (remote)
Martin Swany (remote)
Jason Zurawski (remote)
Les Cottrell (remote)
Brian Hughes-Jones (remote)
Jim Ferguson
Jeff Boote
Eric Boyd
John Estabrook
Dan Gunter
Tanya Brethour
Warren Matthews
Connie Logg
Brian Tierney
Matt Zekauskas
Russ Hobby
Susan Evett (scribe)


AGENDA
Current Schema (Mark) [EML]
Schema Status (Dan) [PPT]

Mark gave an overview of the status of the 'current' schema
development. He covered recently resolved issues (high level
overview), from the simple to the semi-difficult ones.  He provided an
example of route results that will provide hop information - if you
have 5 hops in a path, you get 5 sections in this output-that includes
host information and data for the hop. Connie asked if there was a way
to represent UDP or ICMP, for example, or if it is responded - denied
for x reason? Mark responded that this was still undecided - he
considered putting in a * value; there is a methodology section of the
schema that shows how to plug in UDP and ICMP, for example.

Mark covered a list of unresolved issues - his colleague is looking at
implementing some of this (not on-demand but using historic data) -
including some items that were not implemented by UCL. Richard
commented that the parameter lists are very important. Connie noted
that the parameters portion would also be very important. Martin
thinks that the parameter section is very important - so that the
designer can really specify AA issues. Connie noted that there is a
difference between what you request (for a window size) and what you
get - she hoped that the information about what you actually received
would be included within the results. Mark agreed that this
information needs to be reported; if users are unhappy about including
this information, they can refuse the request. Martin noted that the
same tag can mean several different things, based on the order in
which it is entered on the command line (this can be represented in
the schema) - this was generally agreed.

Mark asked for a vote for a parameter list; this would be optional,
not mandatory - vote passed with participants either being for or
abstained. (1)

A brief discussion ensued over the second item in the request schema
(packet types). Should the schema require or make this optional? And,
if it is required but not specified, what would the 'default' response
be? Would the default be specified by the schema or by the tool
requesting the data? There was a discussion of whether this would be
handled by the business logic section. Jeff asked 'what breaks if we
make it implementation-defined?' Richard felt that you get undefined
behavior (the client is saying 'do what you want'); if you want to
control the behavior, you have to specify it. Eric suggested that a
volunteer type up a strawman proposal, send it to the list, and people
need to respond with agreement/disagreement (this was selected
vs. voting on consensus). (2)

Very brief discussion of item three; group agreed that all elements of
TimeInformation are non-mandatory. (3)

Issue 4: specific parameters could be marked (with attribute) as
'required' or 'optional' - does it have any effect on querying
historic data? Group agreed that this would not have a negative effect
and should be allowed for specific parameters (NB: are the 'specific
parameters' some sub-set of known parameters or does this refer to
'any parameter you want to specify"?) (4)

Issue 5: regarding standard expression for expressing units - Richard
will go to the standard body (i.e., NIST) to get an international
'standard'. (5)

Issue 6: nm_params units for numPackets -- take it out. (6)

Then Mark moved into a series of "where next" scenarios: 1) 'new'
schemas were originally release in 10/04 - where next? 2)
Stabilization? Answers may depend on available effort, expected
lifetime of schemas, and business logic. If we document the work,
would we include requirements, corresponding business loic, and the
Relax-NW. Regarding question 2, Eric didn't want to 'do nothing' - he
wasn't sure on whether to put into the GGF pipeline (though it would
show the GGF that the WG is doing something and the GGF would have
proof that its WG are getting something done). Brian gave an alternate
view that, by putting it through the pipeline, we'd get lots of
comments that we might ignore. The GGF has a series of metrics (number
of calls, emails, etc.) to show 'WG value'. Brian noted that the
legitimacy would be greatly enhanced by having a well-designed web
page (current page is not) vs. putting effort into getting a finished
document. Eric suggested posting the document on the web site, let the
area directors know about it, and inform folks that the group would be
interested in comments but, since the group is working on version 2.0
and would most likely ignore any comments received. (7)

Group agreed that the final document will include: requirements,
corresponding business logic, Relax-NG schemas themselves. (8)

Group discussed whether or not to stop documenting schemas? Should the
group create a reference implementation? How is it released? Eric
suggested that Mark continue working on his implementation (EGEE JRA4
prototype) and we call that 'a reference implementation'. Others can
be added to the list of 'implementations' as they are developed.

BREAK

Dan gave an overview of the Version 2.0 schemas (the request/response
schemas similarities/differences) - metadata will include
characteristic, subject, and parameters for both the Request and
Response; on the Response side, the data/results depend upon the
characteristic. This way, you don't have to repeat the metadata over
and over. Dan noted that you can have multiple metadata sections (any
or all of the three) in either the request or the response, although
the response needs to match the request.

Dan ran a demo on his local server in Delaware (not in the slides) to
give an example of the output of a live query (ping). Connie wanted to
know if there was any way to return error conditions as the 'result';
Dan said this could use '-1' for errors but it wouldn't identify which
error it is. Connie asked about if you ping and get a 'Host Unknown'
from a well-known location, the assumption is a problem with a DNS; to
use this for diagnostics, you need to be able to specify what error
code is encountered. Brian suggested adding response codes for each
tool that returns specific error codes for that tool within the
Results schema for the tool. The group agreed to define the event
types to specify what output would be produced (delay, rtt, raw ping
output). (9)

He showed the schemas for ping, iperf, and several others. The 'url'
within the schemas are not valid URLs; instead, they are 'unique
names', identifying the version of a specific tool that is being used
(with a range of parameters specified). If you used a slightly
different version of the tool, or a version with different parameters,
you need to change this 'url' at the beginning.  There was a brief
discussion of how to translate the 'url' into a parameter; such that,
'http://www.ggf.org/nmwg/tools/iperf/" becomes 'nmwg.iperf'; Martin
suggested importing the other "IANA" table?? (didn't catch this - Matt
Z and Martin not speaking loudly).

Connie asked if there was a way to query a flat file (without using
all these parameters)? Suppose I had a gif, could I return that file?
Jeff agreed that, with some tools, you need to request binary data and
to translate the binary response into something more compact, return
it, and then have the requestor re-translate the data back into binary
seems more effort than necessary. The option to return data in binary
should be available. Dan agreed.

Dan wants to finish the developer's guide (including the examples
shown today), add the language + toolkit notes (experiences), and WSRF
(Web Services Resource Framework - a layer on top of SOAP) integration
plans (feature negotiation, etc.). Eric asked when it would be
complete? Martin said it would be based on agreement with approach -
does he have group approval? - a couple of weeks from the completion
of the implementation and the developer's guide. Schema document
(first slide in Dan's presentation) needs to be created as a
standalone document. Output will be a base schema document and a
'profile' document. Eric asked, if Warren was going to use the schema,
how long? Dan felt 2 weeks to firm it up and have documents ready for
review.  Next demo will be Jason's client interoperating with Warren's
server.  Warren asked Martin, Dan, and Jason to send the output and
code from the tools that were demo'd. (10)

Group agreed to reach consensus on delay.rtt, bw.achievable,
delay.oneWay, and link.utilization via the list. (11)

Tanya asked if you could ask for a specific piece of information and
either get a) just that characteristic data or b) the data related to
the characteristic and whatever other useful data is collected (by
default). If the metadata that came out was not requested/read by the
tool, it would be ignored.

Richard suggested that he and Mark give a brief report on the 
development of the schema at the next GGF meeting - he requested that 
Martin send him information on the state-of the-art at that point. (12)

Richard suggested the group meet for a day's session at the GGF
meeting in Chicago (June). Richard (and co-chairs) will request the
meeting.

ACTION ITEM:

1. Mark to incorporate a parameter list - based on the group agreement.

2. Mark to draft a strawman proposal regarding the second unresolved
issue (packet types - required or optional?) and send it to the list
for comment.

3. Mark to note that all elements of TimeInformation are non-mandatory
- based on the group agreement.

4. Mark will include the option for specific parameters to be marked
as 'required' or 'optional'.

5. Richard will go to the standard body (i.e., NIST) to get an
international 'standard' for Mbps, Mb/s, etc.

6.Mark to take nm_params units for numPackets out of the document.

7. Brian and Dan will provide Eric and Susan with information ;
Internet2 will host the GGF NM-WG page. It will be redesigned and
vetted by the group. Brian will continue to host the page until it is
ready and then will create a redirect. Susan will ensure that WG
chairs (Richard, Eric, and Mark) have editing authority to the
page. (Page to be up before mid-March, next GGF).

8. Group agreed that the final document will include all three
elements listed above.

9. Group agreed to expand the schema to define the event types by
specifying what output would be produced (delay, rtt, raw ping
output).

10. Martin to send the output and code from the tools that were demoed
to the list.

11. Group agreed to reach consensus on delay.rtt, bw.achievable,
delay.oneWay, and link.utilization via the list.

12. Martin will send Richard/Mark information on the state-of-the-art
at that point. Discussion to be held off-line.

13. Richard (and co-chairs) will request the meeting at the GGF
Chicago meeting (June).

14. Implementers of the schema should report back to the mailing list
on the reasons items were included/changed to document problems.

Next call is scheduled for March 1 at the usual time. Eric will send
out invitations and call information.  Call/meeting ended at 5:36
p.m. MST.