1. CCSDS Registry Re-Engineering Organizations & Persons SCIDs, Assets (new) & OID Tree Peter Shames, Erik Barkley Marc Blanchet, Brian Oliver, Tom Gannett 13 July 2015

2. CCSDS Registry Re-engineering Several issues with the current CCSDS registries have been identified A study has been performed to develop an approach to remove issues and to clarify the common / core registries for re-use The following pages describe the proposed approach, registry contents, and relationships It also adds unique identifiers for all objects, following CSS approach, that permits unambiguous cross-referencing when needed

3. Top Level CCSDS Registry Issues The CCSDS registries, counting both the SANA and the CCSDS Web Site, now include the following; – Ten separate "organization" type registries (member, observer, affiliate, operator, originator) with different levels of completeness and accuracy, ranging from a full spec (name, address, point of contact, email, etc) to a "1024 character string” Includes two new "organization type registries” proposed by SOIS and CSS, with weak “1024 character string” type specs, more are surely on the way – Four different "contacts" registries (contacts, PoC, HoD) with different levels of completeness and accuracy Two new, weakly specified, ”contact" type registries were just proposed by SOIS and CSS, more are surely on the way – Two different antenna and station registries (plus future optical assets and a new, weakly specified, station registry from CSS) There is little real guidance for creators of new registries, and none about re-use of existing ones 1 June 2015

4. SEA/SSG Registry Proposal Identify a defined set of categories of registries with some well defined policies Initial set of categories: – Enterprise registries with information managed (or requested) by agencies and other participating organizations – Global registries with cross-cutting information that is “owned” at CESG level but curated by SANA with guidance from one or more Expert Groups – Registries with information that is local and managed by Areas (or WG) Require WGs to re-use existing well specified registries instead of inventing new, weakly specified, ones: – Add new organizations and contacts as needed to existing registries – Add new roles and other attributes as needed Following charts describe the SANA roles and these categories in more detail along with some examples 1 June 2015

5. CCSDS SANA Databases

6. CCSDS Org & Person Registry Management Approach CCSDS Website (Brian) – Retain curation of existing CCSDS organization and person registries – Use assigned OID (from SANA) as unique tags for organizations and persons – Provide updated organization and person data to SANA via programmatic or “data dump” interface (TBD) SANA (Marc & team) – Retain curation of all other registries – Provide unique OIDs for organizations, persons, RF Assets, and other objects, as needed – Acquire organizations and persons data from CCSDS Website whenever it is updated – Merge into operational & extensible SANA registries that have programmatic interfaces, using the unique OID “handle”

7. CCSDS Enterprise (Org & Person) Registries Patterned after the existing SCID and MACAO registries Use the same pattern of requiring: – An agency to identify a Head of Delegation (HoD, also the CMC member) – The Agency HoD to appoint one or more Agency Representatives (AR) to request changes to the different kinds of agency data – One AR may handle one or more different kinds of data – Member Agencies to sponsor Observer agencies in their country – Member or observer agencies to sponsor affiliates or data providers in their country Adds: – Unique OIDs for all organizations, persons, or objects that are registered – Requires tagging all data, uniformly, with the date of any changes and the ID of the persons requesting and performing the change

8. Organization Relationships

9. Organization Type Database

10. Person Relationships

11. Person Type Database

12. CCSDS SCID Registry Extends the existing SCID registry Uses the same pattern of requiring: – A designated AR from a Member or observer agency, or from an affiliate, to request SCID assignment or relinquishment Adds: – Unique OIDs for all Spacecraft that are registered, in addition to the SCID – Requires tagging all data, uniformly, with the date of any changes and the ID of the persons requesting and performing the change – Adds spacecraft name, abbreviation, and alias attributes – Permits assignment of an OID without a SCID and makes OIDs permanent tags for the spacecraft

13. SCID Registry Relationships

14. Spacecraft Registry

15. RF Asset Registry Extends the existing IOAG RF Asset registry Adopts the same pattern as the SCID and MACAO of requiring: – A designated AR from a Member or observer agency, or from an affiliate, to request RF Asset registry changes – Requires that site and asset names be unique Adds: – Unique OIDs for all RF Assets that are registered and assigns a unique OID for the site as well – Requires tagging all data, uniformly, with the date of any changes and the ID of the persons requesting and performing the change – Adds Asset name abbreviation and alias attributes

16. RF Asset Registry

17. Service Site & Aperture Registry Registry Defines a new Service Site and Aperture registry – Tied to the RF Asset Registry using the Aperture OIDs as the unique ID – A spacecraft (that does relay or PSLT) may be a Site too Uses the same pattern of requiring: – A designated AR from a Member or observer agency, or from an affiliate, to request registry changes Adds: – Unique OIDs for all Sites that are registered, in addition to the Apertures at a Site – A Site may have zero or more Apertures and zero or more Services – A Site may be a static place on the Earth’s surface, or on another planetary body (PSLT), or in orbit (relay spacecraft) – Requires tagging all data, uniformly, with the date of any changes and the ID of the persons requesting and performing the change – Adds Site name, abbreviation, and alias attributes

18. Service Site & Aperture Registry Relationships

19. Service Site & Aperture Internal Relationships

20. Service Site & Asset Registry

21. Objects that need unique OIDs Organizations (and sub-elements) Persons Spacecraft Sites (including spacecraft) & Apertures (Antennas) Service Provider Sites All CSS assigned identifiers Roles (both org & person role types) Countries (use ISO-3166-1 code)

22. OID Tree proposal (flattened)

23. CCSDS Registry Update Summary Uses patterns from the existing SCID and MACAO registries All organizations have responsibility for managing updates to their own data – The Agency HoD (or Org PoC) must appoint one or more Agency Representatives (AR) to request changes to their data – Only the appointed AR(s) can request changes – A member of the SANA staff will make the actual changes Adds: – Unique OIDs for all organizations, persons, or objects that are registered – Requires tagging all data, uniformly, with the date of any changes and the ID of the persons requesting and performing the change