[CESG] Some responses from IOAG Service Catalogue Group

Wed May 3 07:30:04 UTC 2017

Dear all,

As I did receive some comments during the last IOAG-20  face-2-face 
meeting on CESG issues with SC#1 and #2 (e.g. reference docs, SANA, etc,) 
I consulted again with the SC WG Chairs (Jean Marc Soula and Gippo)  for 
an additional confirmation.

You will see below their feedback (i.e. no reference docs., no reference 
to SANA, removal of slids references, etc)

We will discuss it during our San Antonio meeting

ciao
nestor
========================================

You will find below their response
Do SC# 1 and SC#2 deserve a section on Reference Documents ? 
If affirmative, and as already addressed in the IOAG meeting in Montreal, 
(for the 1st one)  the following documents needs to be referenced 
1.      CCSDS 901.1-M-1, Space Communications Cross Support--Architecture 
Requirements Document. Magenta Book. Issue 1. May 2015. 
2.      CCSDS 901.0-G-1, Space Communications Cross Support--Architecture 
Description Document. Green Book. Issue 1. November 2013. 
3.      CCSDS 313.0-Y-2, Space Assigned Numbers Authority (SANA)--Role, 
Responsibilities, Policies, and Procedures. Yellow Book - CCSDS Normative 
Procedures. Issue 2. May 2016. 
4.      CCSDS 313.1-Y-1, CCSDS SANA Registry Management Policy. Yellow 
Book - CCSDS Normative Procedures. Issue 1. June 2016.
Note 1: Doc 3 and 4 are important due to the reference to SLIDs in both 
SCs (see below) 
Note 2: IOAG rejected our CCSDS comment saying that no reference docs. are 
compulsory in the SCs
Reply ==> Service Catalogs are written as input from IOAG to CCSDS as such 
it is considered that CCSDS is fully aware of their internal documents and 
procedures. Therefore - as discussed at IOAG-20 Meeting -  it is 
considered there is no need to reference those CCSDS documents in IOAG 
Service Catalogs. 
SLIDs or not SLIDs ?? 
In the case of the SANA the IOAG SC 1 & SC 2 both identify a reference 
named "[SLID]" that then points to the top level of the SANA Registry. 
 There are three issues here: 
1.      The pointer is to the whole of the SANA, not to the specific list 
of Space Link identifier registries (
http://sanaregistry.org/r/space_link_id/space_link_id.html) 
2.      The text of the SCs does not make mention of this reference, so 
there is a missing reference in the body of the documents 
3.      The SANA, which stores these registries, and the IOAG managed RF 
Assets registry ([XSCA] (IOAG) RF Communication Assets 
http://sanaregistry.org/r/rf_assets/rf_assets.html ) is not directly 
referenced nor identified.
Note: Is the reference to SLIDs adequate ? or is it a leftover ?  
Reply ==> Service Catalog 1 section 1.1.3 includes a reference to [SLID] 
?Registries.? Space Assigned Number Authority. http://sanaregistry.org/r/. 
This replaces CCSDS 135.0-B Space Link Identifiers. Silver Book. However 
[SLID] is never called in Catalog 1 and it will be removed whenever 
possible (as this is an approved version). 
[XSCA] in called in Service Catalog 1 section 1 and in Service Catalog 2 
section 1.1. 
In Service Catalog 2  [SLID] will also be removed.
Does SANA need to be mentioned in SC#1 and #2: 
SANA has a role in supporting space operations, starting with assignment 
of SCIDs for spacecraft and registration of their RF assets. Furthermore, 
the CCSDS RMP, which defines the policies for management of all the SANA 
registries, should be identified as relevant for the IOAG operating 
agencies.  This affect the agency HoD, Agency named PoC (Agency 
Representative, AR), and the RF & Assets registry which is used by both 
the IOAG and the CCSDS SM standards.  These should appear in these service 
catalogs since they are intended to be a part of providing operational 
services and the IOAG, representing the operational arm of these agencies, 
should be familiar with them and understand their role in maintaining 
them.
Reply ==> It is fully agreed that SANA has a BIG role in supporting space 
operations. Service Catalogs are written as input from IOAG to CCSDS as 
such it is considered that CCSDS is fully aware of their internal 
procedures involving SANA. Therefore it is considered there is no need to 
reference SANA in IOAG Service Catalogs.
In general the first three comments show that SANA would like to make the 
IOAG community more aware of what they are and which items they maintain. 
However this is not the purpose of the SC#?s. The confusion may come from 
the IOAG Communication assets which were agreed to be hosted by CCSDS web 
site and ended up with the SANA. 
in SC#2, the only Service Management reference is to the obsolescent [SM] 
spec, CCSDS 910.11-B Space Communication Cross Support - Service 
Management - Service Specification. Blue Book.  The SC#1 correctly 
includes the whole set of new SM specs that are under development, some of 
which, like the Simple Schedule, are well advanced.  These should appear 
in the SC#2 as well.  
Reply ==> Service Catalog 2 does correctly include the whole set of new SM 
specs that are under development as Service Catalog 1 does.
Service Catalog 2 explicitly calls (in section 5 ) the set of CCSDS Cross 
Support Service Management Specifications (including SM-SSF etc.)  through 
reference to IOAG Service Catalog #1 [IC1]. Understating that this 
implicit referencing can be cryptic/misleading the set of  9 documents 
[SM-ACC], [SM-ACP], [SM-AUT], [SM-CAT], [SM-ESF], [SM-PDF], [SM-SPF], 
[SM-SSF], [SM-URF] will be added to section 1.4 of Catalog 2. In section 5 
the repetition of SM-SPF will also be deleted. 

This message and any attachments are intended for the use of the addressee or addressees only.
The unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its
content is not permitted.
If you received this message in error, please notify the sender and delete it from your system.
Emails can be altered and their integrity cannot be guaranteed by the sender.

Please consider the environment before printing this email.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/cesg/attachments/20170503/4ae86f6a/attachment.html>