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.