1. Organization of the meeting

1.1. Opening

The fourth session of the Expert Team on Communication Techniques and Structure (ET-CTS) was held in Geneva from 21-24 October 2010, under the chairmanship of Mr. Hiroyuki Ichijo.

1.2. Welcome

Mr. Peiliang Shi, Director of WIS, welcomed the participants, noting that the new team at the secretariat was taking over the ET-CTS and still catching up. He pointed out that he was looking forward to working with the group, adding that, having been an active member of the group itself before joining the secretariat, seeing new and old participants was especially heartwarming.

1.3. Agenda

The meeting adopted the provisional agenda as reproduced at the beginning of this report, pointing out that it would not be worked through chronologically but in order of priorities and to accommodate the joint session with the Expert Team on WIS-GTS Operation and Implementation (ET-OI). The RTH status reports were split over Tuesday 21th and Tuesday 23th morning, serving as warm-up for the more tough discussions ahead. Bearing in mind these, and the full schedule, the meeting agreed on a 9-12.30h and 2-5.30h schedule upon suggestion of the Chairman. Concerning the priorities, the Chairman pointed out that the agenda point 5.4 was of special importance, not having been touched over the previous years and that he expected tough discussions on agenda point 6.3, since the number of GISCs was a “hot potato”. Mr. Remy Giraud, Co-Chair, pointed out that on many issues the boundaries between the ET-CTS and the ET-OI were not clear, reinforcing the need for a joint session. Finally, on suggestion of Mr. Ashgar Noor, representative of the US, a discussion of the role of social networks for meteorological services was added to point 8.

2. RTH status reports

2.1. RTH Offenbach.

Ms. Ilona Glaser from DWD told the meeting that most of RTH Offenbach’s links to its partners were now realized using the RMDCN, with the internet serving as backup in case of non-availability of the RMDCN, and pointed out that FTP was the main means of file transfer. The meeting then discussed the connectivity between RTH Offenbach and RTH Tehran noting that in DWD’s opinion the occasional connectivity issues had their origin outside RTH Offenbach’s systems and, the internet being the means of realizing the connection, not much could be done. On the link to Nairobi, the meeting learned that communication was smooth as long as a VPN connection can be established, but that there seemed to be frequent VPN service outages attributed to a recent VPN provider switch in Nairobi. Finally, the meeting noted that RTH Offenbach’s GTS link with RTH Jeddah was now also realized using the Internet and that connectivity was still smooth, apart from occasional troubles. (also see RMDCN status)

2.2. RTH Melbourne.

Mr. Ian Senior from BoM informed the meeting that the GTS status at RTH Melbourne was generally stable, but that there were reliability issues with the links to Jakarta and the Maldives. He informed the meeting of a mayor incident, in which an unnamed country had accidentally re-introduced old GTS messages into the system and explained that since there was no month field in the GTS, other countries failed to detect that these were old messages. He continued that the issue was exacerbated by the fact that the messages did not pertain to the country in question but were messages from other countries. On changes in the 2008-2010 period, he explained that the mayor changes had been the retirement of the old frame relay links to Washington, Tokyo, Exeter and Jakarta which had been replaced by connections to the RMDCN and SingTel MPLS connections respectively. He told the participants that the other regional links were also progressively being migrated to this AMDCN and that this constituted a mayor improvement noting the greater bandwidth and reliability. He reminded the meeting of the limits of the GTS, notably the lack of subscription services, a catalogue and the struggle of having to handle three types of data (model, satellite and warnings) and a lack of a mechanism to request additional data on-line, but pointed out that these issues would eventually be resolved by WIS. He recommended that the following points in the filename convention be addressed at some stage: upper-case only data, limitation of character length to 69 and need to end all lines with two carriage returns and a line feed, with a view of not limiting new protocols and codes. The meeting was supportive of removing these limitations and asked the WMO secretariat to consider disseminating a questionnaire to members to find out more about operational problems.

2.3. RTH Tokyo.

Mr. Kenji Tsunoda (AKA Ken) from JMA informed the participants of the progress made in the 2008-2010 period. Under the auspices of JMA and operated by NTT, a new MPLS based region II AMDCN had been created replacing the old frame-relay based network which was discontinued in 2009. In the same year, JMA also established a new link with Exeter via the RMDCN and participated in the migration from the old cloud I frame-relay network provided by British Telecom to the RMDCN. He pointed out that RTH Tokyo had two load-shared 3Mbit/s connections to the RMDCN, bringing its total theoritical speed under normal operation conditions to 6Mbit/s. The participants expressed interest in the implementation of RTH Tokyo’s messages switching and learned that JMA was striving to use FTP only, and to use a single-file approach for urgent messages and had different switching systems for FTP and sockets. It also understood that the maximum filesize at JMA is an easy to extend 2GB, which leaves plenty of room to accumulate messages, the message size being limited to 500kb. The meeting also discussed the contractual setup of the Region II AMDCN, summarized under agenda point 6.5.

2.4. NMC-RSMC Montreal.

Mr. Jean-François Gagnon from Environnement Canada reminded the participants that Montreal was not an RTH, not part of any cloud and only had one official GTS link, via TCP/IP, to WMC Washington and an unofficial link to Exeter, with plans to connect to other RTHs in the medium-term. He informed the meeting of plans to upgrade both connections but pointed out that it did not seem viable to put all the traffic into the GTS, since the cost of this would be prohibitive. Reinforcing this argument, he remarked that much of Canada’s traffic was not inserted into the GTS but travels through the internet instead without problems. The meeting noted that FTP was used for the connections with Washington, USA-NEP and USA-NESDIS. Regarding the development of WIS, he informed the meeting that Canada was planning to be a NC and DCPC but that it had been difficult to get the necessary developments launched internally due to internal changes. He took a positive view of future WIS developments, since he had observed more WIS related activity lately.

2.5. ASECNA (Region I)

Mr. Ayina Hugues from ASECNA briefed the meeting on activities in the region. The participants noted that ASECNA had established two new GTS links with Toulouse and Dakar via VSAT and that the links with Njamina and Brazzaville had been migrated to TCP/IP. The meeting learned that ASECNA was in the process of establishing backup links with TCP/IP VPNs for the other ASECNA countries and that there were now no GTS X.25 links left. He continued that ASECNA policy was to migrate all GTS channels to TCP/IP and to use IPSEC based VPNs over the internet as backup. Newly established channels will use VPNs over the internet as main connection. The links to Toulouse are established via VSAT and IP, whereas the inner-toulouse connection between ASECNA and Meteo France was implemented with a cisco phylone radio. He also announced that the implementation of computerized systems was progressing thanks to innovative technologies such as GSM interfaces and solar panels. The meeting also learned that email was used to collect AMDAR aircraft observations. (XXX: check.. does that make sense?). Regarding WIS implementation plans, the participants noted that MTN member Dakar and Brazzaville will be DCPCs and that Dakar might be nominated as a regional GISC, depending on further political discussions in the region. The participants praised the work of ASECNA and the technological advances in the region, especially the innovations in IPv6, GSM and portable devices not seen in other regions.

2.6. WMC Washington:

Mr. Ashgar Noor from NWS/NOAA briefed the meeting that the US had improved the switching in its backbone and had now completely removed single points of failure, since all connections were redundant. The meeting noted that the US had increased the size of the cache of outgoing products and messages so that files as long as 10 days back can now be retrieved and examined. The participants learned that ECMWF had pointed out to NWS/NOAA the issue of the RMDCN connection in New York, which apparently constitutes a single point of failure in the connection to the RMDCN.

2.7. RTH Bunos Aires.

Mr. Jose Luis Gianni from RTH Buenos-Aires (Argentina) told the participants that the regional systems had for many years relied on VSAT,X.25 and IP, but that users were increasingly complaining about low speeds, however, upgrades were expensive. The goal was to move the network to a MPLS based one, but that the contract had been delayed because of a political decision to move the Headquarters to a new location, which was unfortunately lacking telecommunications facilities. Regarding the contact with INMET (Brazil), the meeting learned that Argentina was supportive of INMETs becoming a GISC. The participants noted the difficulties in the region to establish an AMDCN and were happy to learn that an Internet and VPN based network had been created using OpenVPN, noting the simplicity of usage and technical feasibility of any-to-any connectivity and now widely usage of FTP. Argentina’s last X.25 connection with Chile and the slow connection with Brasilia would also soon be replaced by OpenVPN links. The meeting expressed interest in the availability figures of the OpenVPN based AMDCN, noting that comparison with figures from other regions would be difficult due to regional differences. The particiants noted that Argentina switched its message switching systems to Moving Weather (IBL), using TCP/IP and a30Mbit/s internet connection. The meeting also noted that email was used to collect land and sea-based observations and to disseminate non-commercial and commercial products as well as to provide public services, and that it also served as backup for GTS links. Regarding the implementation of WIS, Argentina nominated 5 DCPCs and would focus on technical assistance to the region, leveraging its Geonetwork skills and relations with Brazil, as well as making sure the IBL technology likely to be employed by Brasilia would work throughout Argentina. The meeting learned that a lack of skilled staff was becoming a serious problem, especially as operations are moved from ICAO (airports) to the NMC.

2.8. the GTS and the Internet

During the status reports the meeting repeatedly discussed the role of the GTS and the Internet, summarized here as a separate agenda point. The meeting noted that the GTS was currently used to transport both high-priority and low-priority data, but that there was no clear distinction between essential / operational and the other data in the system noting the different meaning of the GTS in different communities. It also pointed out the twofold role of the Internet in the GTS, since the internet is both used as a GTS link and as a way to transport data outside the GTS. It observed that these distinctions would become less clear in the future since WIS constitutes an umbrella for any data communication. However, the meeting also noted that congress emphasized the importance of the GTS and its continuous and stable improvement. The meeting noted that the usage of the internet varied from region to region and that while only serving as backup in some regions, the Internet had become the main communication tool in Region I due to lack of other communication links, and an important, flexible and cost effective means of data transportation in other regions, notably Region III. The participants noted a need to balance the policy vis a vis the usage of the internet, bearing in mind that performance requirements vary from region to region. The meeting noted that there was uncertainty if a new interpretation of the historical rule of the internet as a suitable link in the absence of other technologies was needed and that it might be worth considering to use the GTS for high-priority messages only and to encourage the usage of the internet for high-volume low priority data.

3. Recommended practices for data communication techniques and procedures.

3.1. Development of Guidance on “push” and “pull” technologies for use in WIS.

The meeting struggled to define the exact scope of this point and there was a feeling that there was an overlap with agenda points 4.1 and 6.4. The respective discussion is summarized in the corresponding agenda points. The meeting identified the main scope of the discussion related to this agenda point to be data exchange between WIS centers, and proposed to treat the outreach to a larger user community, a task mainly pertaining to NCs, to agenda point 8. The meeting noted that in WIS there was two types of data transfer, the traditional GTS message flow and 24h essential data cache on one hand and the uploading of metadata records to the GISCs and the synchronization of the metadata catalogue on the other hand. It noted that each had different requirements, especially regarding timely exchange, requiring a different set of technologies. Regarding the synchronization of the 24h “cache”, the requirement of a GISC to store the set of date intended for global exchange for 24 hours, the participants decided that this would be implemented by changing the GTS routing tables so that every GISC receives all messages from its area of responsibility. The synchronization with the other GISCs would be realized by sending these messages to all other GISCs. Duplication would be avoided by not re-sending a message if it is received from another GISC. Synchronization and uploading of the metadata is covered under agenda point 6.4.

3.2. Review of the status and advice on adoption of IPv6.

The participants were briefed on the history of IPv6, a short summary of its main features and the current global adoption of IPv6, as well as IPv6 studies conducted by various sites (ECMWF, ASECNA). The meeting noted that IPv6 support with vendors was now very good, and that adoption with providers, although not users, was now considerable. However, it noticed that there was no reason warranting a quick migration of the GTS to IPv6, since there was no tangible business case for WMO. It expected introduction to be gradual with no sense of urgency currently not needing a centrally coordinated migration. The participants learned that address shortage in Region I might lead to a more quick adoption of IPv6 there. The meeting decided to create an IPv6 task-team and tasked it with considering future implementation strategies and migration plans for IPv6 as well as identifying IPv6 business cases for NMHSs. It also decided to develop IPv6 guidelines, maintained collaboratively in the WISWIKI.

4. Review and develop updates to recommended practices for data-communication and data access procedures

4.1. Study procedure for priority messages (e.g. tsunami warnings) (GTS and WIS).

The meeting noted that WMO requirement is to deliver high-priority messages within 2 minutes within the GTS but that the current manual on the GTS could lead to transmission times longer than 2 min between GISC nodes. It noticed that the speed of delivery of priority messages in the GTS depends on two factors. First, the topology of the network, since each additional message switch along the route adds an additional delay. Second, the implementation of the message switch, the main issue being the time a message remains queued before being transmitted to the next hop. On the first point the meeting observed that the introduction of WIS would gradually remove the number of hops, since the WIS architecture envisages a hierarchical flow of messages from the AMDCN to the GISC, leading to a more flat structure. On the second point, the meeting decided to change the manual in the GTS so that message switches are required to transmit an incoming message no later than 15 seconds after reception. It also recommended that the sending centre keep the FTP session connected for 10 minutes or until the connection had been idle for 2 minutes.

4.2. Blog technologies.

The meeting learned about studies at JMA of blog technologies and noted that blog technologies did not constitute a suitable means for WIS Part A, mainly due to the pull character of the technologies involved. On the other hand, blog technologies are useful for reaching out to a large audience in the internet and could thus be used for telling users both about availability of new products and messages.
It recommended that blog technologies continue to be studied in the view of WIS Part B and summarized as a guide which may be contributed to the Guide on Internet Technologies.

5. Review of guidance materials for implementation of data communication facilities at www centers

5.1. Guide on Information Technology Security.

The meeting integrated the remaining sections of this guide not already covered in the Guide on IT security, into the latter and decided to discontinue the Guide on Information Technology Security.

5.2. Review of Guide on Internet Practices.

The participants noted that the guide had not been updated for a long time and did not constitute a help for WMO members in its current form. However, it observed that the internet offered opportunities to WMO members, citing the role of social networks and the fact that over 20 countries did not have a website at this point. However, the dynamic and quick development of technology needed a more ad-hoc updating of the guide. The meeting decided that the guide would in the future be maintained in the WISWIKI, allowing for collaborative and more frequent updates, noting that translation issues would have to be considered.

5.3. VPN security guide.

The participants updated the guide, clarifying and updating several paragraphs and adding section of the DMVPN (RMDCN backup operated by ECMWF) and the Open VPN based Region III AMDCN. The meeting discussed the merits of updating the generic technical section whose information is also available elsewhere on the internet, and expressed interest in usage statistics of the guide. It decided to move the current version of the guide to the WISWIKI to allow for more frequent and collaborative updates.

5.4. Update of the Manual on the GTS

The meeting discussed the relevance of the description of X.25 protocols and procedures, considering that the great majority of countries have already converted away from X.25. It was suggested that this material was now obsolete and should be removed. The participants proposed updates to the Manual on the GTS, Part II, section 2.12.1 & section 2.12.2, as well as to the Attachment II‑6, II-9, II-13 and II-14 to the effect of removing references to X.25 as of November 2011.

5.5. Update the Attachment II-15 of the Manual on the GTS.

The participants discussed the recommendations from the first session of the Inter Program Expert Team on Metadata and Data Interoperability (IPET-MDI) on filenames of metadata files in the GTS. They noted the need to clearly identify the type of message using the filename only and to introduce an .xml extension, but decided after consultation with the IPET-MDI, to use the PFLAG field to distinguish between data and metadata, since the suggestion to introduce an additional dot-separated file extension to identify the message type would break existing implementations. It hence introduced three new PFLAG values: TM, WM and ZM which correspond to the metadata associated with the historical A and T, both using TM, W and Z messages.

5.6. Update the Attachment II-16 of the Manual on the GTS.

The participants (ET-CTS & ET-OI) noted that there were issues with improperly encoded MIME messages on the GTS. They observed that the reason for this were Quoted Printable encoded email messages containing NO-BREAK SPACE (NBSP) not being decoded properly by some RTH gateways. The meeting decided to remind email to GTS senders that not all characters were acceptable to the GTS and that the usage of NO-BREAK SPACE was discouraged. It also decided that email to GTS gateways should understand and decode all MIME standards, namely Quoted Printable and Base64, and should ensure that the content of messages is in ITU international reference alphabet. The participants also discussed the location of email security strings, currently allowed to be both in the body and subject parts of an email, and decided that a recommendation be made to place the security string into the subject only. The meeting also decided to replace references to the superseded IA5 standard and to replace it by T.50 in the Manual on the GTS and to use the UN recommended notion to refer to Electronic Email (“email”,”eMail”…).

6. Develop the organization and design principles for the WIS data communication structure, and related consideration matter

6.1. Review and further develop the organizational and design document for WIS data communication structure.

The participants learned that at the early stage of WIS development two options for a telecommunication structure had been considered. First, a global network (GMDCN) used by everybody. Second, a network of regional networks (ADMCN), with each region having its own approach. Finally, the second option had been chosen. The meeting considered the future communication strategy of WIS. On the backup of the network connectivity, it noted that in that case of managed network services, there was the option of having a second managed service as backup, or to rely on the internet for backup. It noted that due to cost considerations, currently the internet backup solution was chosen by regions. The participants observed that multicast over terrestrial networks could play an important role in the future and felt that this fact needed to be distinguished from traditional satellite based multicast. The meeting also noted that there was currently no governance body overseeing traffic flows in the GTS and recommended that a governance structure be created in the Manual on WIS, to make sure that local decisions on data insertion would not negatively influence operations of other centers. It added that the governance body would need to be in a position to make decisions in a quarterly timescale. On the WIS communication structure, the participants noted that for WIS an AMDCN model was recommended and that AMDCNs could be managed by GISCs in cooperation with DCPCs concerned. The WIS core network can be considered as an evolution of the IMTN and that in the future, it could support multicast. VPNs over the internet were a practical backup solution for the backup of the WIS core network and for operational links with non-NMHs.

6.2. Report on the consolidation of two IMTN clouds.

The participants learned that the members of the IMTN cloud I (Frame Relay by BT) had moved to the IMTN cloud II (MPLS network by OBS) in 2009, due to the discontinuation of the Frame Relay Service provided by BT, and that thus currently most MTN members were connected to the RMDCN. The participants noted that the Service Level Agreements (SLA) of the OBS MPLS network (RMDCN in RA VI) had so far been met every month, with only two month less than 100% availability. They also noted that according to the ECMWF Council’s policy on expansion of the network, ECMWF member and Co-operating states, RA VI countries not currently connected to the network, GISCs and countries operating MTN centers and countries outside RA VI connected to a RA VI center as part of the GTS, upon request of the RA VI country were eligible for joining. This capped the maximum number of countries at around 60. Regarding the situation of the GISC candidate centers, the participants learned that with the exception of Iran, Saudi Arabia and South Africa currently all candidate centers were connected to the RMDCN. They noted that Saudi Arabia had successfully been connected to the network but was currently suspended as contractual obligations were not met. On South Africa the meeting learned that the country considering joining the RMDCN in the very near future to connect to the other GISCs. On Iran, the meeting noted that OBS, the current network provider for the RMDCN, did not have a license to operate in Iran and that export and import restrictions prevented the availability of the necessary equipment in the country, and discussed various options to guarantee the ability of Tehran to join the WIS core network.

6.3. Study the reasonable maximum number of GISCs from the view of necessary bandwidth based on estimate traffic volume.

The participants discussed a study of bandwidth requirements between GISCs. The meeting noted that the amount of bandwidth required of each GISC increases linearly in the number of total GISCs, since each GISC has to upload its data again to each new GISC. It observed that this would mainly be a problem for high-volume sites such as the US or Europe, but that smaller GISCs would have to prepare bandwidth enough to at least download the global exchange volume. Based on a bandwidth calculation tool available at http://tiny.cc/wis it noted that the minimum required bandwidth was currently about 768kbps, but would be over 3 Mbps in 5 years. The meeting praised the study and calculation tool developed at JMA and ECMFW respectively, and came to the conclusion that given the current conditions, namely regional unbalance of global volume and 24h cache synchronization using unicast, the consequence of a high number of GISCs would be very high bandwidth demands of GISCs having large datasets, in the absence of technical remedies such as unicast or change in the cache synchronization strategy. The figure below shows how required bandwidth in 2015 increases linearly in the number of GISCs, assuming a realistic unbalanced model and a 15 GBytes/days global volume.

6.4. Develop a list of synchronization protocols among GISCs

The participants learned about the ongoing OAI-PMH metadata synchronization long term test by CMA, DWD, INMET and JMA organized by the WMO secretariat and the 24h cache synchronization tests that had been performed by DWD with JMA and INMET. The meeting then discussed protocols for transfer of data and metadata between WIS centers. On GTS data transfer, it noted that SFTP/FTPS had file-integrity and security features not available in plain FTP at the cost of being slower, and discussed UFTP, a multicast file transfer protocol, likely to be useful for copying data between GISCs in the WIS core network. On metadata synchronization between GISCs on one hand and DCPC’s and NC’s on the other, the meeting noted that the WIS technical specifications leave it up to them to negotiate metadata upload protocols bilaterally. For GISC to GISC metadata synchronization, the meeting noted that the Expert Team on GISCs and DCPCs (ET-WISC) decided that OAI-PMH 2.0 shall be used for the initial implementation. Not having studied any protocols for GISC to GISC synchronization itself, the participants did not feel they were in a position to make further recommendations.

6.5. Guidance on administrative and contractual aspects of data communication services for WIS implementation.

The meeting discussed two alternatives for establishing AMDCNs, the RMDCN model in Region VI on one hand, and a part of AMDCN established by JMA in Region II on the other hand. On the Region VI approach, the meeting noted a paper relating the history of the development of the RMDCN and the conclusions drawn from this analysis, presented in form of hints. The main advantages of this approach were identified to be end-to-end Service Level Agreements (SLAs) and the one-vendor approach. However, contractually such an approach was difficult to handle, since all members are obliged to sign a contract with the same vendor. On the Region II MPLS-based AMDCN the meeting noted that each participating country had signed an accession contract with a local operator, allowing for payments in local currency and adherence to local regulations. Additionally JMA had also signed the top-level contract with NTT, which interconnects the local operators. The participants pointed out that the contractual, technical and political situation in this AMDCN was different from the one-vendor approach in Region VI, noting SLAs were contractually and technically more difficult to enforce due to the range of operators involved, but emphasized that the intention of AMDCNs is to adapt to local conditions, and welcomed JMAs efforts to try to establish the AMDCN. The chair emphasized the need for guidelines to establish AMDCNs and the meeting decided that different models for the creation of a regional network could be integrated.

7. WIS Plan and Roadmap

7.1. Manual on WIS

The participants (ET-CTS & ET-OI) were briefed on the development of the manual on WIS conducted by the WMO secretariat. They noted that to institute WIS officially, WMO Technical Regulations (WMO-No. 49), Volume I, Section A.3 needs to be amended and a new annex added as the Manual on WIS. The Manual on WIS (WMO No. 1060) will consist of already agreed material, drawing from the WIS center designation procedures, WIS compliance specifications, WIS required functions, etc. The Manual on WIS will also reference a new Guide to WIS (WMO No. 1061), consisting also of already agreed guidance material drawn from sources such as the WIS functional diagrams, WIS Centre questionnaire guidance, etc. The meeting discussed the possibility to maintain guindace material in a dynamic environment such as a WIKI and considered options to link to it from the formally published Guide to WIS. The meeting noted that the Manual on WIS needs to be translated in the first half of October. Consequently, comments are most timely if offered before the end of the ICT-ISS and ICG-WIS meetings next week. Therafter, oportunites for comments to be considered would occur at the CBS Extraordinary Session in November 2010, and then at Congress in May 2011.

7.2. CAP messages.

The participants noted that there was requirement to exchange CAP messages in xml through the GTS with a GTS header. The meeting agreed that CAP should be handled as not AN but binary message by Message Switching and The T1 value of the header could be X”which was used for regional GRID, but is no longer used. Furthermore the meeting suggested that it could be desirable to exchange CAP as a file with the WMO filename convention.

7.3. WIS monitoring.

The meeting noted the need for performance monitoring in WIS, but struggled to define the exact extend of monitoring. On traffic monitoring, it noted the importance of traffic statistics between WIS centers, pointing out that the extent of the contributions would be voluntary and that WIS centers should provide the statistics on a quarterly basis. It noted that ECMWF could provide these statistics for members of the RMDCN and that other members could extract these statistics from their communication routers. It recommended that the statistics be provided through the RAs. The meeting also discussed performance monitoring of the switching time in the GTS, notably to meet the 2minute distribution target, pointing out that it should be automatic and in real-time, and noted that one problem to an accurate monitoring in the second range, was the time differences between clocks on different machines. The meeting agreed that work on monitoring would have to be continuous and referred the subject back to the expert teams for further studying.

8. AoB

8.1. Working structure:

The meeting noted that the ET-CTS had tried to keep associated members on board since the distinction between core and associated members had been made by CBS, but that only limited success had been reached. The participants discussed the distribution of the tasks resulting from this meeting between core members and associated members, and noted that there was a risk that the ET-CTS, nominally having 30 associated members but only 8 core members, be overloaded by ICT-ISS. The issue was identified to be generic to all OPAG-ISS working groups and it was decided to discuss the matter further during the ICT-ISS meeting. On the usage of collaborative software such as the WISWIKI, the meeting decided to maintain the Guides under its responsibility in the WISWIKI with a view of updating them more frequently and to involve other experts. It noted that currently the permissions were rather strict and that to be useful for collaborative work, experts would need to be given editing permissions. The participants also discussed other collaboration tools, such as google docs or google wave but noted that these tools were not available from all NMHs and that the secretariat’s policy was to centralize information on its webpages. In terms of the upcoming work-plan, the meeting noted that two task-teams, one on multicast with volunteers from Germany, Canada (maybe), ECMWF, the US (maybe) and China (need to check), and another one on IPv6 (ASECNA, China) had been created. The plan for the multicast task team would be to agree on a list of sites, possibly extending to members not represented in the ET-CTS and to have some deliverables until the next session. For the IPv6, the task-members were invited to elaborate a work-plan and to report back in two months’ time. The Chairs invited everybody to participate in the task-teams and the other pending work and decided to hold a regular conference call to keep abreast of developments and tentatively scheduled the first call to take place in two months.

9. Closure.

The meeting was closed at 16.30h.