[Smwg] Re: CSSM SoS book and in-progress new CCSDS registration policy -- analysis and comment
Shames, Peter M (312B)
peter.m.shames at jpl.nasa.gov
Tue Jun 16 20:47:25 UTC 2015
Hi Erik,
Somehow I missed this diagram, glad you pointed me to it today. I think it's a great start. I took the liberty of embellishing it so that the picture now aligns with the revised text in the SCID, MACAO and SANA doc draft updates. It now shows all of the org types, how they get created, who they appoint as reps, and how the rest of the core registry machinery fits together. It still needs more details, but this is the rough shape of the whole picture of these core registries that I was trying to paint.
This shifts a few things around from what you showed, but not too much. Assume that the attribute models for orgs and persons gets replicated (and embellished) as needed and that the other registry types get fleshed out as well based on the stuff in those draft docs.
Does this start to make more sense to everyone?
I actually think that the SANA and Secretariat folks are already moving in this direction, so I do not think that the overal framework will take that long to get sorted out. They have realized, I believe, that having 10 of these registries and four of those registries just does not make sense and they are moving to fix it. I did not try and show which of those orgs "owns" all of these registries, since the locaiton of the Organization and Person / Contacts registries are still somewhat fluid. All of the others, however, are already in the SANA. The biggest issue in my mind at this point is how to parse and handle the OID namespace (aside from what the SMWG and CSTS have already done).
Thanks, Peter
From: <Barkley>, Erik Barkley <Erik.J.Barkley at jpl.nasa.gov<mailto:Erik.J.Barkley at jpl.nasa.gov>>
Date: Thursday, June 11, 2015 at 6:34 PM
To: Peter Shames <peter.m.shames at jpl.nasa.gov<mailto:peter.m.shames at jpl.nasa.gov>>, "colin.haddow at esa.int<mailto:colin.haddow at esa.int>" <colin.haddow at esa.int<mailto:colin.haddow at esa.int>>
Cc: Space Assigned Numbers Authority <info at sanaregistry.org<mailto:info at sanaregistry.org>>, SMWG <smwg at mailman.ccsds.org<mailto:smwg at mailman.ccsds.org>>, Brian Oliver <briano at aiaa.org<mailto:briano at aiaa.org>>, Kelvin Nichols <kelvin.nichols at nasa.gov<mailto:kelvin.nichols at nasa.gov>>
Subject: RE: CSSM SoS book and in-progress new CCSDS registration policy -- analysis and comment
Peter,
With regard to having a new CCSDS Registry Management Policy book (option 2) that covers all the details including extension points, I agree, and that is probably the better approach long term. As far as getting the schedule of services published, I'm okay with either option 1 or 2 and is just a matter of putting the proper policy reference in place.
To make some progress and take a more concrete step, I drew up a 1st cut of more of a model just with the SoS “origniatingOrganisation” in mind. Please see the attached file. Is this how you see it working out? Note that I took the liberty of adding OIDs – that would be its own information model. I just wanted to put down what I saw as the overall picture at least as a trail for one registry need of the SoS (and probably many other “client” books). What is your take ?
Best regards,
-Erik
From: Shames, Peter M (312B)
Sent: Wednesday, June 03, 2015 4:48 PM
To: Barkley, Erik J (3970); colin.haddow at esa.int<mailto:colin.haddow at esa.int>
Cc: Space Assigned Numbers Authority; CCSDS Service Mgmt WG; Brian Oliver; Kelvin Nichols
Subject: Re: CSSM SoS book and in-progress new CCSDS registration policy -- analysis and comment
Hi Erik, et al,
Thanks for the thoughtful feedback. I think we are starting to move in a good direction, but will have a better read on that after tomorrow's telecon with the two implementing organizations, the SANA Operator and the Secretariat web site folks. I'll provide further feeback after that telecon.
At this point I have spent another day hacking at the registry undergrowth and have identified two different, but related, paths forward:
1. Modify the current SANA YB, SCID BB, and MACAO BB to clarify the existing agency & person registries and policies, and to add a clear info model and also extension points where needed (supporting an enumerated set).
2. Move all of the existing agency and person registry specs, policies, procedures, and info models into a new CCSDS Registry Management Policy book that would cover all of the details including extension points.
I think that either of these can be made to work. The first is probably more expedient for now, but more of an issue in the long run. The second will take longer to get in place, but the end result will be having only one place to go look to find all of the info on these key CCSDS registries. I think the second is the best long term path, but the first may be quicker and I already have produced the draft set of mods for these docs. (I also have a draft of the second, by the by).
Other comments in-line, below.
Thanks, Peter
From: <Barkley>, Erik Barkley <Erik.J.Barkley at jpl.nasa.gov<mailto:Erik.J.Barkley at jpl.nasa.gov>>
Date: Tuesday, June 2, 2015 at 6:32 PM
To: Peter Shames <peter.m.shames at jpl.nasa.gov<mailto:peter.m.shames at jpl.nasa.gov>>, "colin.haddow at esa.int<mailto:colin.haddow at esa.int>" <colin.haddow at esa.int<mailto:colin.haddow at esa.int>>
Cc: Space Assigned Numbers Authority <info at sanaregistry.org<mailto:info at sanaregistry.org>>, SMWG <smwg at mailman.ccsds.org<mailto:smwg at mailman.ccsds.org>>
Subject: CSSM SoS book and in-progress new CCSDS registration policy -- analysis and comment
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
Point to the registries identified by you (great)
Define attributes to be added to the registries (with enumerations as the preferred approach) (agreed. See proposed set)
Is willing to produce a limited information model (scope of only the SoS attributes needed for registries) (great, see proposed set)
But the WG
Does not see the SoS as the proper “home” for the policy of the various steps outlined in the proposal (agreed, I think all you should need to do is to state the nature and policy for the things you want to change)
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 (agreed. See the proposed changes)
Would like to see an overall information model so that the name of attributes, etc is well known (agreed, see the proposed changes)
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 (hmm. I get the point, but worry that then everything will devolve to bi-lateral, or uni-lateral "exception cases")
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 (agreed. But please tell me what would be acceptable as "quick and painless". And Please tell me what you think the implementors / users will tolerate in exchange for having a single, authoritative, source for all this kind of info.)
And f) You really should also be worried about having a single, authoritative, and updated, source of this info that can be readily accessed. And are you planning to adopt OIDs more broadly as being an unambiguous reference for people, agencies, spacecraft, ground stations, and all that other cruft needed to actually plan, schedule, configure, and service space missions?
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<mailto: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.
(Agreed)
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.
(Agreed)
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.
(Agreed. I have started this in the revised doc drafts.)
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.
(Agreed, but … I really worry about these "private" or "NOR" annotations. I proposed instead that we allow any agency / org that registers with us to request just an OID instead of the SCID. That would provide an unambiguous reference that could be used as OID_ if need be. Does that work? My proposal was also that every request for a SCID also return an OID as a mater of course. Heck, you guys invoked the OID in CCSDS, eat your own dog food.)
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.
(I sent what I had on this yesterday. I think if we can get our act together within CCSDS that we should be able to get the IOAG to go along. Just which fields to you guys need in addition to what is already there? Does a GSS OID and a GS OID help in any way? Do we need to propose some sort of canonical Agency.GSSName.GS# naming format?)
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.
(Understood. I think we will understand this better once we have the SANA & Secretariat telecon (tomorrow). One aspect will be to sort out the 10 existing "agency & org" registries and the 4 existing "HoD, PoC, and person" registries. I think that a viable path forward is to do what I proposed, even though it adds "machinery" to the SoS that you would like to avoid in the long run, for all the right reasons. That will prompt the discussion, it still lets you get the SoS out the door for review, and we can always excise it during the reviews if/when this other stuff gets settled.)
Thanks, Peter
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/20150616/3f53df91/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: d1-SoSRegistries-AlignmentNewSANA-RegistriesPolicy-16-Jun-2015.pptx
Type: application/vnd.openxmlformats-officedocument.presentationml.presentation
Size: 343308 bytes
Desc: d1-SoSRegistries-AlignmentNewSANA-RegistriesPolicy-16-Jun-2015.pptx
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20150616/3f53df91/attachment.pptx>
More information about the SMWG
mailing list