Hey folks, The next call is PROVISIONALLY set for Tuesday 11th January at the usual time (8am PST, 10am US CST, 11am US EST, 4pm GMT, 5pm CET etc etc). I'll check people's progress before the call, and will postpone it by a week if there isn't a great deal to report. If you hear nothing, please assume it's on :) Dial-in info will be: (Inside the U.K.) 0871 271 2900 (Outside the U.K.) +44 (0)870 050 6800 Enter the meeting code 255404 when asked. U.K. users are charged at 8.51p per minute (plus VAT) per minute. Non-U.K. users will be charged according to their local telecom providers. Agenda: 1. Continue discussing the new/"normalised" schemas: + progress from Dan + any new examples (e.g. iperf example from Mark) 2. Review Mark and Paul's progress in stabilising the current schemas Notes from the last conference call are below. Please let me know if I've made any mistakes. Actions (all for Mark :-( are at the end. Three point summary: * At the moment the developer's doc only includes a traceroute example. Everyone should look producing examples themselves (e.g. ping or iperf) as a way of getting to grips with the work. * Mark and Paul had nothing to report on stabilising the current schemas. Will be something for after Christmas. * This was Paul's last call - he's now left UCL. Mark thanked him for his hard work on the schemas over the last 12-18 months. Cheers, Mark. NMWG Conference Call: Tuesday 21st December 2004, 16:00-16:50 GMT ----------------------------------------------------------------- Present: Mark Leese (Daresbury Laboratory), Dan Gunter (LBL), Jim Ferguson (NLANR), Paul Mealor (UCL). Agenda: 1. Continue discussing the draft developers guide from Dan, Jason and Martin (Dan mailed out the lastest version on the day of the call). 2. Review any progress Mark and Paul have been able to make stabilising the current schemas. 3. Finalise date for next face-to-face meeting, so people can book flights. Also discussed: 4. the next few GGFs. Contents: 1. Draft Developer's Guide: Something has come up which will absorb quite a lot of Martin's time, so he'll be available less than we previously hoped. We're mutually keen to continue working together, things will just take a little longer. Dan: Any more questions? Mark: Timestamps are defined as consisting of a value and a type. The type is defined as being of datatype "token", which is essentially a non-whitespace string, meanign users could stick virtually anything in there. I was wondering if this should be an enumeration instead with some predefined values, like "secsSinceEpoch" or "NTP", and a default. I know there's a problem with some tooling to make us want to avoid enumeration types, but Dan: Yeah. We would eventually define some valid names, together with what they signify. We could actually get rid of the "type" field if we wanted to. You can tell from the text of the "value" field what format a timestamp is in. Mark: So this was really for clarity and completeness really? Dan: Yeah. The advantage of interpreting the format from the actual timestamp is that, with a timestamp as a single field, you can add it to all sorts of tags as a simple attribute of that tag. Although I actually prefer separate "type" and "value" fields as it makes it easier for whatever software is parse it. It can just look at the "type" field to see what it should expect. Jim: Yes, I'd go with that. It's better to make it easier for the system having to parse all this. Mark: Either is fine with me. I suggest I flag it as a minor issue to be settled later. Probably at the next f2f. Mark: In the schemas you have a "TimeRange" with "start" and "end" elements. The "end" time can be a time or the keyword "empty". Can you explain that? Dan: "Empty" is a special RelaxNG keyword, meaning that that element is allowed to be empty. We're using it in this case to indicate an open ended time period. The start time to infinity is a way to look at it. Does that make sense? Mark: Think so. Would be worth adding that to the document. Dan: What we need are some more examples. At the moment we have a traceroute example, but only placeholders for ping and iperf. Although, I think one of us (Dan, Jason, Martin) is looking at ping. Trying to produce examples would also be a really good way of people getting to grips with this anyway. Mark: Okay, I'll have a look at an iperf example for next time. You're right, that's probably the best way to learn this. Dan: Jason and Martin also hope to have an example implementation in Perl done soon. I can look at a Python example. Mark: Doubt I'll have time to look at this myself in the *immediate* future, but I can look at other resourcing in Europe. 2. Stabilising the current schemas: Mark: Paul and I have done enough on this to report anything. We'll be doing more tomorrow, and I hope to be able to report back after Christmas. Mark: I'd like to re-iterate that this work needs doing. Some people probably had doubts after the last call. Dan, Jason and Martin had done such a good job with their work that it looked like the new/"normalised" schemas would be ready 2/3/4 months ahead of schedule, begging the question "why bother any further with the current versions?". However, there's people using it now that NEED it stabilised, e.g. Advisor, DANTE and EGEE. Jim: What plans are there for documenting this? Mark: We're going to look at putting everything into a GGF "Informational Document" (requirements, business logic etc.). This getting everything down in black and white, it will also show that we've been active. 3. Finalise date for next f2f: Based on available flights, the latest suggestions were the morning of Sunday 13th February and the evening of Wednesday 16th, both during Joint Techs (http://jointtechs.ornl.gov/SLC2005). Paul will not be at SLC, and Mark is aiming to join by phone. Neither option was better for Dan or Jim. So Mark will discuss with Eric... ...It was decided following the call to opt for the evening of Wednesday 16th February, as this gives the opportunity to advertise our meeting during the other JT's sessions. 4. The next few GGFs: Dan asked what plans the group has for the next few GGFs. Mark: The next three meetings are Seoul in March, Chicago in June, and (probably) Boston in October. * Seoul: Based on feedback it looks like we will not have enough of "the regulars" available to make this a full working meeting. I think it's still important for us to have some presence there however. We need to demonstrate what we've been up to GGF attendees from Asia-Pacific, to encourage participation and "buy-in" from Asia-Pacific. They need to know what we've been up to, and similarly it would be good for us to hear what they've been doing. * Chicago: This is a good central location for the US folks, and after the demo only session(s) in Seoul, it will definitely be time for a full day working session. * Boston: This is a real "wait and see" issue. It's only really separated from the Chicago meeting by the summer, when people tend to be on holiday, so we may not have made enough progress to warrant a meeting. Then again, after Boston it could be 5-6 months before the next GGF, as it will be between Brussels and Seoul (GGF12 and 13), and we wouldn't want to wait that long. This was Paul's last call, as he leaves UCL on 24th December. Mark thanked him for all his hard work on the schemas over the last 12-18 months. Job offers can be sent to paul.mealor@... just kidding ;-) Actions: -------- * Mark to flag as an issue: separate "value" and "type"(time format) fields for timestamps, or a single "value" with the format interpreted from the appearence of "value". * Mark to look at an iperf example using the new/"normalised" schemas. * Mark to look at resourcing in Europe for producing an example Java implementation of the new/"normalised" schemas.