2022-05-09 ET-W2AT Meeting

 Date

May 9, 2022 13:30-15:30UTC

 Participants

  • @Jeremy Tandy (Unlicensed)

  • @Peter Silva (Unlicensed)

  • @Baudouin Raoult (Unlicensed)

  • @Kai Wirt (Unlicensed)

  • @thorsten.buesselberg (Unlicensed)

  • @Kenji Tsunoda (Unlicensed)

  • @Tom Kralidis

  • Weiqing QU

 

WMO Secretariat

  • @Enrico Fucile

  • @HADDOUCH Hassan

  • @Xiaoxia Chen

  • @Timo Proescholdt

  • @David Berry

 Goals

Approve the message and topic structure

 Discussion topics

Item

Presenter

Notes

Item

Presenter

Notes

Message structure

Jeremy

Jeremy > presents the slides related the message structure:

 

  1. country code

  • WIGOS uses 3-digit numeric ISO country codes; this was for encoding reasons (in BUFR?)

  • WIGOS users find use of numeric country codes problematic

recommend WIS2 adopts 3-digit alpha-numeric country codes; easier to understand in mass market [agreed]

2. data policy?

  • use of "core" and "recommended" in the topic tree

  • allows for use of WMO Res 1 vocabulary for categorizing data

  • recognize that this may introduce the need for additional transitions to manage movement of data from "recommended" to "core"

  • there is also Canadian experience where users perceived a mix of open and restricted data in their message feed as problematic

  • Canadian practice is to use separate channels for open and restricted data; the ground-rules for data access is set at the channel level

  • alternative vocab for "core" and "recommended"? how about "public" and "restricted"?

  • lots of discussion about the "core" and "recommended" terms in SG-DIP; also - they're approved by Cg; best to keep consistent terminology

  • can we move {data-policy} up the hierarchy?

  • no - the domain sub-categories (level 9) differ between core and recommended data-policy; "recommended" data sub-categories are (by design) much less defined

  • mixing open and restricted data in the same message feed?

  • for example, the following subscriptions would provide a mix of open and restricted data to a subscriber:

  • wis2/CAN/*/data/*/weather/*

  • wis2/CAN/+/data/+/weather/#

  • this concern is all about access control; given our drive to separate concerns, we shouldn't mix data policy with access control; we should use a specific mechanism to deal with access control issues

suggest:

  1. we could use channels to distinguish between open and restricted data; e.g. [ open | restricted | cache | … ]

  2. provide guidance for client applications about how to manage HTTP 400 response codes (e.g. HTTP 401 Unauthorized) where they need to authenticate

but - we don't know if we'll need these mitigations yet, so let's try out the current proposal in the pre-operational phase now is the time to build some prototypes!

the message structure and topic structure are sufficiently agreed for us to continue [agreed]

Outstanding discussions

 

  1. What gets added to the Global Cache

  2. Defining the domain subcategories (topic structure level 9)

  • need to start with a strawman proposal and ask domain experts for their endorsement

  • make things simple; e.g. only use hyphenated phrases (no "+" or "4") such as "global-analysis-prediction"

  • WMO No 386 Manual on GTS may provide some re-usable vocabulary in how TTAAii are described

  • albeit that it's very fine-grained and we want to avoid coupling WIS2 to GTS concepts like TTAAii!

ACTION (Jeremy, Enrico): develop a first draft of level 9 sub-categories for Core data

  1. Feasibility and design of GTS-to-WIS2 and WIS2-to-GTS gateways >> prioritize this for next week

  2. Supplementary Global Services; e.g. "Replay Service"

  3. And other decisions/recommendations/pending discussions circa 1-April-2022

 Action items

Jeremy, Enrico: develop a first draft of level 9 sub-categories for Core data

 Decisions

  1. the message structure and topic structure are agreed and approved

Â