[Smwg] CSSM SoS book and in-progress new CCSDS registration policy -- analysis and comment
Barkley, Erik J (3970)
erik.j.barkley at jpl.nasa.gov
Wed Jun 3 01:32:18 UTC 2015
Peter,
The proposed modifications to the candidate SoS Blue book were discussed at the CSSM WG telecon this morning. I believe it is fair to say that there was some consensus that emerged at the meeting. Note that I am copying the WG so that they can provide corrections if needed. In general, there is support for taking an approach that supports the broader CCSDS goals of better registry management. At the same time there are some concerns, resulting in a counter proposal of sorts. A summary follows immediately below. There are also more detailed comments.
In summary the WG is willing to
a) Point to the registries identified by you
b) Define attributes to be added to the registries (with enumerations as the preferred approach)
c) Is willing to produce a limited information model (scope of only the SoS attributes needed for registries)
But the WG
a) Does not see the SoS as the proper "home" for the policy of the various steps outlined in the proposal
b) Strongly prefers to point to a policy sanctioned at much higher level than that of an "in-the-trenches" recommendation such as the SoS for adding contacts, etc to CCSDS "root" registries
c) Would like to see an overall information model so that the name of attributes, etc is well known
d) Recommends registering private reserved values that can be used as a convention for naming, formally identifying, what is not in a registry thereby allowing recommendations to be used in contexts other than 100% CCSDS compliance, while at the same time providing a formal mechanism for recognizing this
e) Is concerned that whatever registry machinery results that it be relatively quick and painless for CCSDS implementations/users so as not to dissuade compliant implementations
Embedded below are some more detailed comments (in red font) which I hope will assist in understanding the summary.
Best regards,
-Erik
From: Shames, Peter M (312B)
Sent: Wednesday, May 13, 2015 12:06 PM
To: colin.haddow at esa.int; Barkley, Erik J (3970)
Cc: Space Assigned Numbers Authority
Subject: Re: CCSDS - Creation of new registries.
Importance: High
Colin, et al,
I understand the sense of urgency to create this new Simple Schedule document and the associated registries. That said, I am really concerned that we create yet more registries of type "orginating organization" and "user" and "station and antenna" when perfectly servicable registries of exactly these types already exist. Furthermore, the existing registries already provide name, address, PoC, phone, email, etc, etc fields instead of what are really rather vague "a string of text between 1 and 1024 characters in length" types of specifications.
Instead of just continuing down this path, and thereby perpetuating and worsening an already poor situation, I have an alternative proposal. The SANA is designed to allow registries to be modified by newly published Blue or Magenta Books.
I believe that it is in your power to make your standard state something like the following:
1) Change Sec E2.2 of the Simple Schedule (henceforth SS) to state the following:
* The SCCS SM originating Organization shall be one of the organizations registered in the CCSDS Organizations registry (http://sanaregistry.org/r/organizations/organizations.html
* If an Organization does not exist in the Organization registry the identified Agency Head of Delegation or Organization official Point of Contact may request of the SANA that it be added, using the existing SANA procedures for that registry
* The CCSDS Organizations registry shall be modified to add a boolean attribute indicating that the Organization may be of type "serviceProvider"
* For all Organizations that indicate that they offer services this attribute shall be set "TRUE", otehrwise it shall be set "FALSE"
* Addition of any new organization shall require sponsorship by the CCSDS Member Agency for it's country of origin or by the Secretariat if there is no CCSDS Member agency for it's country of origin.
* The Agency Head of Delegation or Organization official Point of Contact shall be added to the CCSDS Contacts registry (http://sanaregistry.org/r/contacts/contacts.html)
* The Agency Head of Delegation or Organization official Point of Contact may appoint an Agency Representative (AR) as the point of contact for SCCS SM requests.
* The SCCS SM AR shall be added to the CCSDS Contacts registry (http://sanaregistry.org/r/contacts/contacts.html)
* The CCSDS Contacts registry shall be modified to add a boolean attribute indicating that the person may be of type "serviceProviderContact"
* For all Contacts that are identified as a serviceProviderContact this attribute shall be set "TRUE", otherwise it shall be set "FALSE"
Comment about proposed policy implications. The WG has no objections to the various steps and procedures outline for entries to the various "root" registries per se (CCSDS Organizations, CCSDS Contacts, CCSDS SCID, RF Communication Asset) but significant concern that the recommendation on publication of TTC network schedules is not the proper locus for this type of policy. This approach requires that every blue book that touches one of the root registries has to diligently state the same policy and this is in fact counter to the spirit of having coherent CCSDS wide registry management policy The WG will welcome a well-defined reference that can be called out as this seems to be very much a CCSDS fundamental registry concern. A general updated yellow book seems the most likely for this.
Comment about addition of attributes: The use of Boolean flags does not seem like the best long term approach for this. A more proper information modeling technique here is the use of enumeration lists. If everything is simply made a Boolean flag it seems like we will not have gone as far as we can to contain the proliferation problem (albeit it will be somewhat more manageable) as instead of a proliferation of registries we have proliferation of Boolean flags. The use of an enumeration list seems like it would be more to the point and should reduce the amount of maintenance meaning that "FALSE" will not have to be added to every entry in the registry simply to accommodate (what may be a few) new "TRUE" values. Granted there is the maintenance issue of the deletion or re-naming of an enumeration value that is in the "middle" of a list but this is probably no more onerous than having to remove various Boolean flags that no longer apply.
Comments on lack of information model: In general the lack of any information model is also troubling to the working group as it seems like we are essentially adding attributes "in the dark". The working group will welcome an information model that helps us to navigate the various attributes and help to reason where new attributes do or do not belong. The working group is willing to put together an information model for the sets of attributes that the simple schedule of services defines but in return would expect that this information model be incorporated into a larger system engineering end-to-end view for CCSDS.
2) Change Sec E2.3 of the SS to state the following:
* The SCCS SM "user" shall be the Spacecraft Name of one of the spacecraft registered in the CCSDS SCID registry (http://sanaregistry.org/r/spacecraftid/spacecraftid.html<http://sanaregistry.org/r/organizations/organizations.html>, or the field "UNALLOCATED" or the field "PROVIDER-CSSS".
* If the user spacecraft does not exist in the Spacecraft registry the identified SCID Agency Representative shall request of the SANA that one be assigned, following the SCID request procedures
* If there is not a current SCID Agency Representative, or if the user agency is not yet registered, the SCID registration procedures must be followed to create these entries
Pre-defined reserved private values: The WG identified a need for a convention for naming what is not in the registry. From a pragmatic point of view of an implementation wanting to adopt some set of CCSDS recommendation and not others (but perhaps on a path to standardization) a convention that could be used in values in an ICD following this convention will help to ensure no confusion with CCSDS sanctioned values. A simple-minded example that may help to illustrate would be to prefix private values with "PV_" for "Private" or something like NOR_ for "not officially registered". Use cases here include those mission that do not show up in the GSCID registiry (not flying CCSDS spacelinks) but still want to use things like CCSDS SoS. Another example could be something like a spacecraft emergency where there may be a need to have some agreed upon identifiers used quickly and not go through all the formal registry policy.
3) Change Sec E2.4 of the SS to state the following:
* The SCCS SM "stationAndAntennaRef" shall use the Station Name and the Antenna Name of one of the communication assets registered in the CCSDS RF Communication Assets registry http://sanaregistry.org/cgi/registry-auth?id=rf_assets.
* If the Station Name or Antenna Name does not exist in the RF Communication Assets registry the identified Assets Agency Representative shall request of the SANA that one be assigned, following the Agency Assets request procedures
* If there is not a current Assets Agency Representative, or if the user agency is not yet registered, the Agency (SCID) registration procedures must be followed to create these entries
NOTE: At the present time the RF Communication Assets registry is under development and it is locked for access. This registry should be completed and at least the fields for station and antenna names (and probably sizes and frequency coverage) made available to any registered user. The full registry should be open to any registered service provider organization (see Sec E3.2).
Correct, the WG cannot presently access this to determine how the information for RF Comm Assets is modeled. It's not clear then how the schedule of services ground station/antenna reference hierarchy would or would not fit/map into this registry. The schedule of services has the notion that a ground station can contain one too many antennas and they are not necessarily named the same thing. This is where some of the unease in terms of just defining attributes without having the information model available is uncomfortable. It may be that it fits just fine but we really don't know at the moment.
With regard to the overall set of suggested changes the WG expressed a concern that whatever policies, etc are in place that this not present road blocks such that SANA cannot clearly process/define new attributes causing agency to abandon adoption and implementation of recommendations as impractical. There is a concern that we are already at risk for this and do not want to see the SoS book release as a Blue Book delayed.
As best I can tell all of the fields that you need, save those two attribute fields, are already in the identified registries. All of the procedures for registering agencies, agency (or org) HoD or PoC, and for registering Agency Representatives are already in place as part of the SCID registries. All that is needed for E2.2 and E2.3 is to add the identified attribute fields that they need.
For E2.4 there is already a registry that exists , but is under construction. We will have to negotiate with the IOAG to gain access, but it is hosted on the CCSDS provided SANA site, and they support the CCSDS service and SM standards, so standing in the way of this, modulo dealing with any security concerns, seems really counter productive.
Are you willing to move in this direction? It will help you (I think) and will also get this ball moving in the right direction.
And I think that the SANA Operator guys will be more than willing to help out.
Best regards, Peter
On 5/13/15, 10:24 AM, "Space Assigned Numbers Authority" <info at sanaregistry.org<mailto:info at sanaregistry.org>> wrote:
Dear Dr. Haddow,
We would like to know when will the book be submitted for publication.
Thank you.
--
Best regards,
Audric Schiltknecht
Space Assigned Numbers Authority
Le 2015-05-08 à 05:23, colin.haddow at esa.int<mailto:colin.haddow at esa.int>
<mailto:colin.haddow at esa.int> a écrit :
Hi Marc,
I'm currently working on the CCSDS Simple Schedule Format
Book (CCSDS 902.1) and in the context of this book we would like the
following registries set up in SANA;
CSS Originating Organization
The registry named 'CSS Originating Organization' consists of a
list of
organizations along with a description:
|--------------------------+-----------------------------------------------|
| |
|
| |
|
| originatingOrganization | a string of between 1 and 1024
characters in |
| : | length.
|
|--------------------------+-----------------------------------------------|
| |
|
| |
|
| Description: | a string of text of between 1
and 1024 |
| | characters in length
describing the |
| | originatingOrganization.
|
|--------------------------+-----------------------------------------------|
CSS User
The registry named 'CSS User' consists of a list of users along
with a
description:
|-------------------------+-----------------------------------------------|
| |
|
| |
|
| user: | a string of between 1 and 1024
characters in |
| | length.
|
|-------------------------+-----------------------------------------------|
| |
|
| |
|
| description: | a string of text of between 1
and 1024 |
| | characters in length describing the
user. |
|-------------------------+-----------------------------------------------|
The initial registry should be filled with the following values:
|
|
user | Description
-------------------------+-----------------------------------------------
|
|
UNALLOCATED | Indicates that the time is
unallocated.
-------------------------+-----------------------------------------------
|
|
PROVIDER-CSSS | Indicates that the time is allocated
for the
| Provider CSSS.
CSS Station and Antenna Reference
The registry named 'CSS Station and Antenna Reference' consists of a
list of
station references with associated antenna references along
with a
description:
|-------------------------+-----------------------------------------------|
| |
|
| |
|
| stationRef: | a string of between 1 and 1024
characters in |
| | length.
|
|-------------------------+-----------------------------------------------|
| |
|
| |
|
| antennaRef: | a string of between 1 and 1024
characters in |
| | length.
|
|-------------------------+-----------------------------------------------|
| |
|
| |
|
| description: | a string of text of between 1
and 1024 |
| | characters in length
describing the |
| | stationRef and antennaRef.
|
|-------------------------+-----------------------------------------------|
In addition we'd also like the following registry created in SANA to hold
related XML schema files;
SCCS-SM Information Entity XML Schemas
The registry named 'SCCS-SM Information Entity XML Schemas'
consists of a
list of XML schema files with references to the CCSDS books where
these are
defined and a description of the schema.
|-------------------------+-----------------------------------------------|
| |
|
| |
|
| file | The schema file [Type: FILE]
|
|-------------------------+-----------------------------------------------|
| |
|
| |
|
| reference: | A string*16 containing the
reference number |
| | of the appropriate book where the
schema is |
| | defined.
|
|-------------------------+-----------------------------------------------|
| |
|
| |
|
| description: | a string of text of between 1
and 1024 |
| | characters in length describing the
schema |
|-------------------------+-----------------------------------------------|
If you require any more information in setting up these registries
please do
not hesitate to contact me.
Thanks in advance.
Cheers for now,
Colin
---------------------------------------------------------------------------------------------------------
Dr. Colin R. Haddow,
HSO-GI, European Space Agency,
European Space Operations Centre,
Robert-Bosch-Str 5,
64293 Darmstadt,
Germany.
Phone; +49 6151 90 2896
Fax; +49 6151 90 3010
E-Mail; colin.haddow at esa.int<mailto:colin.haddow at esa.int> <mailto:colin.haddow at esa.int>
---------------------------------------------------------------------------------------------------------
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/smwg/attachments/20150603/b3bd5691/attachment.html>
More information about the SMWG
mailing list