September 2005 - nm-wg - lists.ogf.org

RE: [nm-wg] Specifying units
by Andrea Westerinen (andreaw) 29 Sep '05

29 Sep '05

Dan, As background ... Retrieving the model/schema is one of the basic operations of CIM - just like getting a property value. Also, changing units between minor releases of the schema is not allowed. Andrea ________________________________ From: owner-nm-wg(a)ggf.org [mailto:owner-nm-wg@ggf.org] On Behalf Of Dan Gunter Sent: Wednesday, September 28, 2005 9:01 AM To: nm-wg(a)ggf.org Subject: Re: [nm-wg] Specifying units Andrea Westerinen (andreaw) wrote: In the DMTF, we address the units issue by defining it in the meta-data/schema and requiring that implementations return the dictated units (btw, percent is a type of "unit"). So, having the schema definition provides the unit information. This has required implementations to convert kbps to bps, etc. but saves the client from doing instance-level conversions. Thanks for the input, Andrea, it is good to know how other groups are handling this issue. My $0.02. To me, this is a somewhat XML-schema-centric view of the world. Other schema languages, e.g. Relax-NG schemas, do not modify the infoset (do not define default values for attributes). The disadvantage is potentially redundant information in each message. The advantage is that the converse of the above, that not having the schema means you don't have the unit information, is not a problem (also consider what happens when the units change between schema versions). Martin has also argued that whether the sender or receiver is the more natural (convenient and/or correct) place for unit conversion depends on the situation. To throw a spanner into the works, I would even argue that just because you have two measurements with the same units and value does not necessarily mean that you have, even approximately, the same result without considering issues of resolution, accuracy, and precision. Oh dear, I've said too much, I can hear the black helicopters circling overhead.. :-) -Dan Andrea -----Original Message----- From: owner-nm-wg(a)ggf.org [mailto:owner-nm-wg@ggf.org] On Behalf Of Martin Swany Sent: Monday, September 26, 2005 3:54 PM To: nm-wg(a)ggf.org Subject: Re: [nm-wg] Specifying units Hi Loukik, It has come to our notice that the messages in v2 responses do not specify units while giving back measurement data (ex: Bandwidth Utilization and Capacity). Specifying such units is necessary and messages should be enhanced to support this. I think that what you've actually saying is that the PerfSONAR prototype doesn't return units. The NM-WG v2 schema dated 20050802 actually includes the units in almost every measurement and this has been in the schema for a long time. We've talked a lot about the way to do it. The current examples feature units in the datum element, but as you note, that wastes space. Some of the examples also depict it as part of the metadata (which is what I've been mostly in favor of as the least offensive current option.) There are definitely issues with that -- mainly that the way that the data is stored is really different than the way in which it is collected. So, it can go in parameters, but it might be nice if it were able to be presented in the data section, but not in every datum. We've discussed this one as well, and thus far there have been no good solutions (or none that we found generally workable.) we could specify it just once..maybe like this: <perfsonar:data dataUnits="bps"> This really requires the data element to be in a specific namespace or to become an omnibus for all the things that might be common in the enclosed datum elements. There could be other numeric values in the datum that require unit information and we'd have to add support for each of them to data. For example, from the current schema: <iperf:datum interval="2.0-3.0 sec" numBytes="231" numBytesUnits="MBytes" value="1.94" valueUnits="MBytes/sec"/> There are multiple numeric values that need unit qualification. <perfsonar:data> <perfsonar:units dataUnits="bps"/> This one is even more thorny. We referred to this as the "older sibling" model as it makes siblings dependent on order, and we decided to avoid that so we could use things like hashes. or something else... Something else is really where we are now. What we have discussed is a general way to "factor out" common attributes or elements from a set of datum elements. CommonTime is an example of this, but a general mechanism would be nice. I proposed something before where an enclosed element in a datum could enclose a set of datum elements indicating that this value was common. It was greeted with a mixture of animosity and indifference, often coexisting in the same person's reaction. Actually, I think that the newly-discussed "bag of parameters" might be a partial solution to this problem but it still doesn't help when the things common to a set of datums are complex and not simple attributes (like a time range.) The second comment is: Choice of units. After a chat with Jeff on this, I can list out two options Jeff suggested that: Service uses the units that the data is already in (for ex. in rrd tool, data is in octets per second. Hence service continues to provide data in octets per second) and continues to return data in the same units. However, the units in use should be clearly specified using any of the above suitable methods. Data in RRDTool is not necessarily in octets per second, BTW. Interface utilization data is generally fetched from an octet counter (just to be pedantic.) An option that I would like to propose is usage of units used in common practice. For example, bandwidth, as known to me, is more commonly expressed in bps (and their factors). A service should hence *reasonably* strive to use the units that are in common practice. Either way, specification of units using any of the suitable methods mentioned previously is absolutely necessary. I agree that reasonably trying to use units in common practice is a good goal. Many discussions over many years have led me to believe that in many cases, common practices aren't so common. For instance bandwidth is in bits per second when talking about link capacity or sending bogus test data, but in often in bytes per second when an application is using the data. I think that trying to mandate a "best practice" is a slippery slope. I vote for unambiguous specification and easy translation. Nevertheless, if a service returns capacity and utilization in the same message, it would be nice to have them both in the same units (unlike the current case with Perfsonar prototype where capacity is bps and utilization is octets per second) Question here is: Which option is ideal? Should we provide capacity and utilization in the same units in our prototype? We can let everyone else weigh in, but if the units are specified (as they can easily be) then why not just divide and convert? That seems easier to me than forcing one or the other into a less-than-natural format. martin

1 0

RE: [nm-wg] Specifying units
by Andrea Westerinen (andreaw) 28 Sep '05

28 Sep '05

In the DMTF, we address the units issue by defining it in the meta-data/schema and requiring that implementations return the dictated units (btw, percent is a type of "unit"). So, having the schema definition provides the unit information. This has required implementations to convert kbps to bps, etc. but saves the client from doing instance-level conversions. Andrea > -----Original Message----- > From: owner-nm-wg(a)ggf.org [mailto:owner-nm-wg@ggf.org] On > Behalf Of Martin Swany > Sent: Monday, September 26, 2005 3:54 PM > To: nm-wg(a)ggf.org > Subject: Re: [nm-wg] Specifying units > > Hi Loukik, > > > > It has come to our notice that the messages in v2 responses do not > > specify units while giving back measurement data (ex: Bandwidth > > Utilization and Capacity). Specifying such units is necessary and > > messages should be enhanced to support this. > > > > I think that what you've actually saying is that the > PerfSONAR prototype doesn't return units. The NM-WG v2 schema dated > 20050802 actually includes the units in almost every > measurement and this has been in the schema for a long time. > > We've talked a lot about the way to do it. The current > examples feature units in the datum element, but as you note, > that wastes space. Some of the examples also depict it as > part of the metadata (which is what I've been mostly in favor > of as the least offensive current option.) There are > definitely issues with that -- mainly that the way that the > data is stored is really different than the way in which it > is collected. > > So, it can go in parameters, but it might be nice if it were > able to be presented in the data section, but not in every datum. > We've discussed this one as well, and thus far there have > been no good solutions (or none that we found generally workable.) > > > > we could specify it just once..maybe like this: > > > > <perfsonar:data dataUnits="bps"> > > > > This really requires the data element to be in a specific > namespace or to become an omnibus for all the things that > might be common in the enclosed datum elements. There could > be other numeric values in the datum that require unit > information and we'd have to add support for each of them to data. > > For example, from the current schema: > <iperf:datum interval="2.0-3.0 sec" numBytes="231" > numBytesUnits="MBytes" value="1.94" valueUnits="MBytes/sec"/> > > There are multiple numeric values that need unit qualification. > > > > <perfsonar:data> > > <perfsonar:units dataUnits="bps"/> > > > > This one is even more thorny. We referred to this as the > "older sibling" model as it makes siblings dependent on > order, and we decided to avoid that so we could use things > like hashes. > > > > or something else... > > > > Something else is really where we are now. What we > have discussed is a general way to "factor out" common > attributes or elements from a set of datum elements. > CommonTime is an example of this, but a general mechanism > would be nice. I proposed something before where an > enclosed element in a datum could enclose a set of datum > elements indicating that this value was common. It was > greeted with a mixture of animosity and indifference, often > coexisting in the same person's reaction. > > Actually, I think that the newly-discussed "bag of parameters" > might be a partial solution to this problem but it still > doesn't help when the things common to a set of datums are > complex and not simple attributes (like a time range.) > > > > The second comment is: Choice of units. > > > > After a chat with Jeff on this, I can list out two options > > > > Jeff suggested that: Service uses the units that the data > is already > > in (for ex. in rrd tool, data is in octets per second. > > Hence service continues to provide data in octets per second) and > > continues to return data in the same units. However, the > units in use > > should be clearly specified using any of the above suitable methods. > > > > Data in RRDTool is not necessarily in octets per second, BTW. > Interface utilization data is generally fetched from an > octet counter (just to be pedantic.) > > > > An option that I would like to propose is usage of units used in > > common practice. For example, bandwidth, as known to me, is more > > commonly expressed in bps (and their factors). A service > should hence > > *reasonably* strive to use the units that are in common practice. > > Either way, specification of units using any of the > suitable methods > > mentioned previously is absolutely necessary. > > > > I agree that reasonably trying to use units in common > practice is a good goal. Many discussions over many years > have led me to believe that in many cases, common practices > aren't so common. > For instance bandwidth is in bits per second when talking > about link capacity or sending bogus test data, but in often > in bytes per > second when an application is using the data. I think that trying to > mandate a "best practice" is a slippery slope. I vote for > unambiguous specification and easy translation. > > > > Nevertheless, if a service returns capacity and utilization in the > > same message, it would be nice to have them both in the same units > > (unlike the current case with Perfsonar prototype where capacity is > > bps and utilization is octets per second) > > > > Question here is: Which option is ideal? Should we provide capacity > > and utilization in the same units in our prototype? > > > > We can let everyone else weigh in, but if the units are > specified (as > they > can easily be) then why not just divide and convert? That > seems easier > to me than forcing one or the other into a less-than-natural format. > > martin >

2 1

Boston Discussion Points
by Jason Zurawski 27 Sep '05

27 Sep '05

All; Here is a loose list of topics that should be addressed in Boston: - Schema Versioning - I will be making a proposal for PerfSONAR on this topic very soon, but the NMWG community should have a crack at this as well. We are leaning to a namespace structure such as this: http://ggf.org/ns/0.0.1/nmwg/ This idea allows for mix/matching of versioned elements (if this is what you require). Of course arguments can be made to replace the periods with slashes, although this complicates the directory structure. Another issue for discussion is what to do in the default case (when a version is not specified). - Response Codes, Exceptions, etc. - There is a simple proposal going around on the sonar mailing list suggesting that codes (perhaps textual responses) can be returned as datum elements in some sort of 'response' namespace. To simplify data transmission codes only can be enforced, and lookup calls can be implemented by the client software to expand error messages (http like). Regardless, this allows for a data element to be returned with various (or singular) datum representations of server state. - Characteristic as optional element in metadata - We think bringing this back in will not harm anything (still rely on the namespace when applicable), and it can also be used for response codes, versioning, etc. - Bag of parameters for message and store - A 'bag' of parameters is as such: <nmwg:parameters id="id1"> <nmwg:parameter name="units" value="Mb/s" /> <select:parameter name="time" operation="gte" value="1127250485" /> <select:parameter name="time" operation="lt" value="1127255485" /> </nmwg:parameters> The generic 'name/value' (optional 'operation' in some namespaces) attributes allow arbitrary specification of requirements. We are using these in sonar for SQL like statements to limit data representation; the concept can be extended to the 'common' element idea (such as for units or time), or just as a way to specify arbitrary ideas (message keepalive, message authentication, etc.). The parameters block can be instantiated at any level (we are thinking) such as inside of a metadata, data, or message block. - Munging GridFTP logs into a schema - If anyone has a pointer to some real logs I can rough something out. - Community involvement in schema design - We have wanted this all along, but the question remains how we can ensure new schemas conform to our general format. Some sort of 'translation' system can be devised using known schemas and perhaps xslt? Still a lot to talk about on this one. -jason

1 0

Re: [nm-wg] Specifying units
by Martin Swany 26 Sep '05

26 Sep '05

Hi Loukik, > It has come to our notice that the messages in v2 responses do not > specify units while giving back measurement data (ex: Bandwidth > Utilization and Capacity). Specifying such units is necessary and > messages should be enhanced to support this. > I think that what you've actually saying is that the PerfSONAR prototype doesn't return units. The NM-WG v2 schema dated 20050802 actually includes the units in almost every measurement and this has been in the schema for a long time. We've talked a lot about the way to do it. The current examples feature units in the datum element, but as you note, that wastes space. Some of the examples also depict it as part of the metadata (which is what I've been mostly in favor of as the least offensive current option.) There are definitely issues with that -- mainly that the way that the data is stored is really different than the way in which it is collected. So, it can go in parameters, but it might be nice if it were able to be presented in the data section, but not in every datum. We've discussed this one as well, and thus far there have been no good solutions (or none that we found generally workable.) > we could specify it just once..maybe like this: > > <perfsonar:data dataUnits="bps"> > This really requires the data element to be in a specific namespace or to become an omnibus for all the things that might be common in the enclosed datum elements. There could be other numeric values in the datum that require unit information and we'd have to add support for each of them to data. For example, from the current schema: <iperf:datum interval="2.0-3.0 sec" numBytes="231" numBytesUnits="MBytes" value="1.94" valueUnits="MBytes/sec"/> There are multiple numeric values that need unit qualification. > <perfsonar:data> > <perfsonar:units dataUnits="bps"/> > This one is even more thorny. We referred to this as the "older sibling" model as it makes siblings dependent on order, and we decided to avoid that so we could use things like hashes. > or something else... > Something else is really where we are now. What we have discussed is a general way to "factor out" common attributes or elements from a set of datum elements. CommonTime is an example of this, but a general mechanism would be nice. I proposed something before where an enclosed element in a datum could enclose a set of datum elements indicating that this value was common. It was greeted with a mixture of animosity and indifference, often coexisting in the same person's reaction. Actually, I think that the newly-discussed "bag of parameters" might be a partial solution to this problem but it still doesn't help when the things common to a set of datums are complex and not simple attributes (like a time range.) > The second comment is: Choice of units. > > After a chat with Jeff on this, I can list out two options > > Jeff suggested that: Service uses the units that the data is > already in (for ex. in rrd tool, data is in octets per second. > Hence service continues to provide data in octets per second) and > continues to return data in the same units. However, the units in > use should be clearly specified using any of the above suitable > methods. > Data in RRDTool is not necessarily in octets per second, BTW. Interface utilization data is generally fetched from an octet counter (just to be pedantic.) > An option that I would like to propose is usage of units used in > common practice. For example, bandwidth, as known to me, is more > commonly expressed in bps (and their factors). A service should > hence *reasonably* strive to use the units that are in common > practice. Either way, specification of units using any of the > suitable methods mentioned previously is absolutely necessary. > I agree that reasonably trying to use units in common practice is a good goal. Many discussions over many years have led me to believe that in many cases, common practices aren't so common. For instance bandwidth is in bits per second when talking about link capacity or sending bogus test data, but in often in bytes per second when an application is using the data. I think that trying to mandate a "best practice" is a slippery slope. I vote for unambiguous specification and easy translation. > Nevertheless, if a service returns capacity and utilization in the > same message, it would be nice to have them both in the same units > (unlike the current case with Perfsonar prototype where capacity is > bps and utilization is octets per second) > > Question here is: Which option is ideal? Should we provide capacity > and utilization in the same units in our prototype? > We can let everyone else weigh in, but if the units are specified (as they can easily be) then why not just divide and convert? That seems easier to me than forcing one or the other into a less-than-natural format. martin

1 0

Specifying units
by Loukik Kudarimoti 26 Sep '05

26 Sep '05

Hello Gang, It has come to our notice that the messages in v2 responses do not specify units while giving back measurement data (ex: Bandwidth Utilization and Capacity). Specifying such units is necessary and messages should be enhanced to support this. Also, there is scope for optimization in such specification. For example, while returning back data instead of <perfsonar:datum timeValue="1127183580" value="7.620117028888889E7" units ="bps"/> <perfsonar:datum timeValue="1127183640" value="1.4989345286805557E7" units ="bps"/> <perfsonar:datum timeValue="1127183700" value="1.50811390446627E7" units ="bps"/> we could specify it just once..maybe like this: <perfsonar:data dataUnits="bps"> <perfsonar:datum timeValue="1127183580" value="7.620117028888889E7"/> <perfsonar:datum timeValue="1127183640" value="1.4989345286805557E7"/> <perfsonar:datum timeValue="1127183700" value="1.50811390446627E7"/> </perfsonar:data> or like this: <perfsonar:data> <perfsonar:units dataUnits="bps"/> <perfsonar:datum timeValue="1127183580" value="7.620117028888889E7"/> <perfsonar:datum timeValue="1127183640" value="1.4989345286805557E7"/> <perfsonar:datum timeValue="1127183700" value="1.50811390446627E7"/> </perfsonar:data> or something else... The second comment is: Choice of units. After a chat with Jeff on this, I can list out two options Jeff suggested that: Service uses the units that the data is already in (for ex. in rrd tool, data is in octets per second. Hence service continues to provide data in octets per second) and continues to return data in the same units. However, the units in use should be clearly specified using any of the above suitable methods. An option that I would like to propose is usage of units used in common practice. For example, bandwidth, as known to me, is more commonly expressed in bps (and their factors). A service should hence *reasonably* strive to use the units that are in common practice. Either way, specification of units using any of the suitable methods mentioned previously is absolutely necessary. However, it can be remarked that 'bps' is not necessarily common. Netflow measurements might prefer to use something else which are in common practice in the netflow domain. In such cases, specification of units should suffice. Nevertheless, if a service returns capacity and utilization in the same message, it would be nice to have them both in the same units (unlike the current case with Perfsonar prototype where capacity is bps and utilization is octets per second) Question here is: Which option is ideal? Should we provide capacity and utilization in the same units in our prototype? Loukik. -- ______________________________________________________________________ Loukik Kudarimoti Network Engineer DANTE - www.dante.net Tel: +44 (0)1223 371 300 Fax: +44 (0)1223 371 371 Email: loukik.kudarimoti(a)dante.org.uk City House, 126-130 Hills Road Cambridge CB2 1PQ UK _____________________________________________________________________

4 3

Re: [I2G2-Proto] [nm-wg] Specifying units
by Jeff W. Boote 26 Sep '05

26 Sep '05

Martin Swany wrote: > I think that trying to mandate a "best practice" is a slippery slope. I vote > for unambiguous specification and easy translation. I agree with this completely. >> Nevertheless, if a service returns capacity and utilization in the same >> message, it would be nice to have them both in the same units (unlike the >> current case with Perfsonar prototype where capacity is bps and utilization >> is octets per second) >> >> Question here is: Which option is ideal? Should we provide capacity and >> utilization in the same units in our prototype? > > > We can let everyone else weigh in, but if the units are specified (as they > can easily be) then why not just divide and convert? That seems easier to me > than forcing one or the other into a less-than-natural format. I believe this is the only possible long-term solution. But, I do think we need to work on the way the units information is communicated. (I think this boils down to the same issue we have been grappling with everywhere else. How do we normalize? If we can solve that in the general case, I think this can be solved in the same way.) jeff

1 0

ggf sessions and tomorrow's call
by Leese, MJ (Mark) 26 Sep '05

26 Sep '05

Hi folks, Just a reminder that we have a call tomorrow, at which we'll expand on the rough agendas for the sessions at GGF15 in Boston next week. The call will be at the usual time on the usual number: http://nmwg.internet2.edu/meetings.html Our sessions at GGF are now confirmed as: When | Session | Purpose ------------------------------------------------------------------------------------- Mon 3rd October, 14:00-15:30 | NM-WG #1 | Detailed group discussion | | Mon 3rd October, 16:00-17:30 | NM-WG #2 | Detailed group discussion | | Mon 3rd October, 18:00-19:30 | NM-WG #3 | Open session to demonstrate software | | making use of the NM-WG schemas | | Tue 4th October, 10:45-11:30 | NM-WG #4 | General, open session to present | | progress to wider GGF community | | Wed 5th October, 11:00-15:30 | WS for | Web Services psuedo-tutorial | NM apps | We have a phone line requested for most of the meetings just in case anyone wants to join by phone. Speak to you tomorrow, Mark.

1 0

***SPAM*** Congratulations!
by Martin Evans 20 Sep '05

20 Sep '05

THE COORDINATOR, NATIONAL LOTTERY UK. INTERNATIONAL PROMOTIONS/PRIZE AWARD DEPARTMENT. NATIONAL LOTTERY UNITED KINGDOM. DEAR SIR/MADAM, SECOND CATEGORY HIGH STAKES DRAW Congratulations to you as we bring to your notice, the Results of lottery Draw of the NATIONAL LOTTERY UNITED KINGDOM. We are happy to inform you that you have emerged a winner under the Second Category High Stakes Draw, Which is part of our promotional draws. The draws were held 3RD SEPTEMBER, 2005 and results are being officially announced today. Participants were selected through a computer ballot system drawn from 30,000 names/email addresses of individuals and companies from Africa, America, Asia, Australia, Europe, Middle East, and Oceania as part of our International Promotions Program. You/Your Company, attached to ticket number 55-4-123, with serial number 57-10 drew the winning numbers 14 26 34 35 36 45 (32) and consequently won in the Second Category. You have therefor been awarded a lump sum payout of £500,000 GBP (Five Hundred Thousand Great Britain Pounds), which is the winning payout for Second Category Winners. This is from the total prize money of £2,500,000 shared amongst five(5) winners in the B Category. CONGRATULATIONS! Your fund has been deposited with our International Funds Transfer agents "FINANCE SOURCE INVESTMENT LTD" and has been insured in your name. In your best interest and also to avoid mix up of numbers and names of any kind, we request that you keep the entire details of your award strictly from public notice until the process of transferring your claims has been completed, and your funds remitted to your account. This is part of our security protocol to avoid double Claiming or unscrupulous acts by Participants/non-participants of this program. We also wish to bring to your notice, the December 2005 Lotto-Extra Draw where you stand a chance of Winning up to £25 Million that will be shared Amongst 10 winners worldwide, we hope that with a part of your prize you will participate. Please contact your claims agent immediately for due processing and remittance of your prize money to a designated bank account of your choice; MR JAMES ELLES FINANCE MANAGER. FINANCE SOURCE INVESTMENT LTD. 294 COLDHARBOUR ROAD, BRIXON LONDON E113AA, UK TEL: 44-704-012-5189 FAX: 44-709-286-8074 Email: jelles(a)financesourceinvst.com You are advised to contact your claims agent by email and/or fax within a week of receiept of this notice. Failure to do so may warrant immediate disqualification. NOTE: For easy reference and identification, find Below your reference and Batch numbers. Remember to Quote these numbers in every one of your correspondence with your claims agent. REFERENCE NUMBER: NLUK/05/3456/7564/GL256 BATCH NUMBER: NL5/BZO7-6 Congratulations once again from all our staff and thank you for being part of our promotions program. Sincerely, MR MARTIN EVANS. THE COORDINATOR, NATIONAL LOTTERY UK 13 EDGEWARE ROAD LONDON SW25LL UNITED KINGDOM. TEL: 44-704-012-5186 FAX: 44-709-286-9677 N/B: Any breach of confidentiality on the part of the winners will result to disqualification. Please do not reply to this mail. Contact your claims agent immediately.(TERMS AND CONDITION APPLYS).

1 0

Re: [nm-wg] next call: tuesday 13th Sept, usual time
by Jim Ferguson 13 Sep '05

13 Sep '05

I can't get thru on both numbers listed on the web site... -Jim At 09:27 AM 9/6/2005, you wrote: >Hi folks, > >The next call will be next week, Tuesday 13th September 2005 at the usual >time (11am EDT, 4pm in the UK). Dial-in info is unchanged, and can be seen >at: http://nmwg.internet2.edu/meetings.html > >There's nothing concrete on the agenda; the call is really just an >opportunity to get together and see how people's preparations for the >demos at GGF15 (Boston, 3-6 September) are going. Please let me know if >you have anything else you'd like to discuss. > >Good news to report is that our proposal for a Web Services >psuedo-tutorial for GGF15 has been accepted. Many thanks to Marlon Pierce >and Shrideep Pallickara from Indiana for agreeing to present at this. You >can see the details here: >http://www.ggf.org/GGF15/ggf_events_schedule_NMApps.htm. I'll say more >when I have the days and times for all our GGF15 sessions. > >Hope to hear you next week :) > >Mark. > > >Mark Leese > >Network Development Engineer tel: +44 (0)1925 603730 >CCLRC, Daresbury Laboratory http://gridmon.dl.ac.uk/~mjl

3 3

Note phone number ...
by Eric L. Boyd 13 Sep '05

13 Sep '05

Note the phone number on the website is wrong too. --Eric eboyd(a)internet2.edu has invited you to a conference call. Starting Time: Aug 10, 2004 at 10:45 AM US/Eastern Occurs: Every Tuesday from Aug 10, 2004 to Aug 4, 2009 Duration: 1 hour, 30 minutes To join the call, do one of the following: a. Dial +1-734-615-7474 (NON-US/CA USERS MUST USE THIS NUMBER - SYSTEM WILL NOT CALL OUT), +1-866-411-0013 (toll free US/Canada Only) or +1-800-392-6130 (alternate toll free US/Canada Only) and enter access code 0142286, or b. To have the system call you, click here: https://edial.internet2.edu/call/0142286

1 0