[CESG] Re: Results of CESG Polls closing 14 August 2015

Mon Aug 24 21:39:13 UTC 2015

Gents,

I too “feel your pain” re the registy situation, since I have been the one trying to bring order out of chaos.  We were stuck on the horns of a dilemma:

  1.  Fix the core CCSDS registries for persons and organizatins so that they were naturally extensible
  2.  Continue to willy-nilly add several more poorly formed organization and person registries, thereby making things worse

I think we need to fix this situation now, before it gets worse.  Instead of complaints I would really like some help since we are ALL, collectively, responsible for this situation.

I have been working with the SANA Steering Group (SSG), which is the organization that is responsible for guiding the efforts of the SANA operator where there are issues.  This situation is indeed one of those issues (or several, since it is MOIMS Nav, SOIS App, and CSS SM that are affected).  I have also been working directly with the SANA operator, the CCSDS web site operator, and the CCSDS Secreatariat to get things sorted out.

A short summary of the situation and a proposed path forward is provided here.  Given consensus that what is proposed makes sense I think we can actually get this resolved fairly quickly.  And I think that getting this resolved in a sensible fashion makes far more sense than creating three new poorly formed registries that are “cast in concrete” in the form of a Bllue Book, and also overlap existing registries that are well formed and can be used well into the future.

Current Situation

  *   There is a “Space Agencies” registry created for the MACAO docs (http://sanaregistry.org/r/agencies/agencies.html), but it is limited to MACAO related topics
  *   There is a separate “Control Authority Office” registry created to the MACAO docs (http://sanaregistry.org/r/cao/cao.html) that has just the registerd CAO tied to space agencies
  *   There is a “Contacts” registry created for the MACAO & SCID docs (http://sanaregistry.org/r/contacts/contacts.html), and it is large, but somewhat incomplete
  *   There is an ISO Object Identifier (OID) registry created for the SLE specs (http://sanaregistry.org/r/oid/oid.html) but it only contains SLE service info
  *   And there are separate candidate registries for Organizations and Contacts that are being developed for to meet the identified future needs

These organization and contact registries contain separate, well formed, fields for names, addresses, phone numbers, contact info, etc, etc and they are quite well populated (even if they are not yet complete).  The three proposed “organization” registries were all of the form “organization is a 1024 character field”, with no other fields or identifying info.

Proposed Way Forward

  *   Rename the “Space Agencies” registry created to the MACAO to “MACAO Space Agencies” and leave it in place for the DAI WG to sort out.  It is out of date in any event and there is no existing Blue Book that references this SANA version by name.
  *   Make the candidate “Organizations” registry the official one.  Sync it with the CCSDS website version, add unique OID’s for all organizations, and differentiate member, observer, affiliate, and other org types.  Add any organizations and/or sub-organizations needed to meet current WG needs (CDM providers, SOS providers, EDS providers).
  *   Rename the MACAO & SCID “Contacts” registry to be the “MACAO & SCID Contacts” registry, and leave it in place for now.  There is no existing Blue Book that refines this registry in detail or that references the SANA version by name.
  *   Make the candidate “Contacts” registry the official one.  Sync it with the CCSDS website version, add unique OID’s for all persons, and differentiate member, observer, affiliate, and other roles including that of agency HoD, agency representative (for SCIDs and other requrests), and other roles.  Add any other persons needed to meet current WG needs (CDM providers, SOS providers, EDS providers, service provider contact persons).
  *   Update the OID registry to add all of the candidate CSTS OIDs and also to add the other OIDs types for persons, organizations, services, and assets.  Use these to add unambiguous tags to the other entries.

This probably sounds like more work than just “create a new special agency registry with an undeifned 1024 byte character field for each entry”.   It is more complicated than that.  But it it should be less complicated than creating three additional WELL FORMED registires for agencies and the relevant contact persons.  A registry with an entry that says “organization = JSPOC” is somewhat informative, but it alcks certain info such as the address, email, web site, and a contact person if needed.

If we are going to create any sort of formal SANA registries that are expected to be useful they really must be complete enough to truly be useful.

Regards, Peter

From: Erik Barkley <Erik.J.Barkley at jpl.nasa.gov<mailto:Erik.J.Barkley at jpl.nasa.gov>>
Date: Monday, August 24, 2015 at 11:31 AM
To: David Berry <David.S.Berry at jpl.nasa.gov<mailto:David.S.Berry at jpl.nasa.gov>>
Cc: Peter Shames <peter.m.shames at jpl.nasa.gov<mailto:peter.m.shames at jpl.nasa.gov>>, Tom Gannett <tomg at aiaa.org<mailto:tomg at aiaa.org>>, CCSDS Engineering Steering Group - CESG Exec <cesg at mailman.ccsds.org<mailto:cesg at mailman.ccsds.org>>
Subject: RE: Results of CESG Polls closing 14 August 2015

David,

Please see responses below.   Re conditions one 2 and 3 I can and will send you some potential text via a separate email.

-Erik

-----Original Message-----
From: Berry, David S (3920)
Sent: Sunday, August 23, 2015 8:12 AM
To: Barkley, Erik J (3970) <erik.j.barkley at jpl.nasa.gov<mailto:erik.j.barkley at jpl.nasa.gov>>
Cc: Shames, Peter M (312B) <peter.m.shames at jpl.nasa.gov<mailto:peter.m.shames at jpl.nasa.gov>>; Thomas Gannett <tomg at aiaa.org<mailto:tomg at aiaa.org>>; cesg at mailman.ccsds.org<mailto:cesg at mailman.ccsds.org>
Subject: FW: Results of CESG Polls closing 14 August 2015

Erik:

I have reviewed the conditions you have set upon the PRM for changes that must be made prior to an Agency Review.  I have the following proposals for addressing your conditions.  (NOTE:  Peter's conditions require a much more comprehensive response and I am unable to perform them myself... I have referred Peter's comments to the lead editor).

Erik(1): Due to the way in which the NDM/XML integrated schema is constructed, I think the namespace header you cite is actually correct.

The master schema referred to imports the required namespace.  Thus I don't think a change to the existing text is required.  I do agree that the structure of the NDM/XML integrated schema should be addressed; I think this structure has complicated and delayed my ability to respond to John Pietras' concerns about multiple schemas in the same namespace with the same "oemType".

I am a bit confused.   Are you saying that PRM is to be a part of the NDM specification?   As I read the draft recommendation, it indicates that PRM is  in fact is the “root” element of the schema meaning it strikes me as the “master” schema.  It seems to me that good practice would be keep the various bits and pieces in their namespaces so as to avoid confusion/collisions of terms definitions.   I will admit that the internal CCSDS policy for namespace is still lacking but to the extent that the PRM is a master schema, its seems to me there should be a PRM namespace assigned.

Erik(2):  I would say that it's a challenge keeping up with the policy changes "in progress" with the SANA and its registries. In particular, I have looked at the "Organization" registry that you cite and it is not nearly complete enough for Navigation WG needs (e.g., "JSpOC" is the major producer of CDM instantiations and OMM instantiations, the Space Data Center (SDC) also creates CDMs).  The abbreviation set seems incomplete as well... is "MSFC" enough? Why isn't "NASA/MSFC" included? Is "ESA" enough?

CDMs are planned for production by "ESA_ESAC", and OEMs are produced by "ESOC". I don't feel it is possible to refer to this "organization"

registry in a CCSDS Red Book until it is an "approved" registry; right now it is still a "candidate". What are the plans for "completing" this registry and moving it to approved status?  Nonetheless, I will provide some text for Tom to apply to the SANA annex.

I feel your pain.  It has been a rather arduous process for the CSS area to keep up with policy changes as well.   For the CSSM WG we had a similar issue – we have something like NASA/DSN to be included as well as ESA/ESOC, for example, as publisher of schedules of services.  This resulted in addition of needed attribute types to indicate schedule publisher. To the best of my knowledge, we will be adding sub-organizations as needed when publishers of schedules in standard format are added.

Erik(3): Maybe there should be a simple, standard registration rule that all registry change proposals are submitted to the SANA Operator, who will determine who will act upon them. Then if the WG still exists, the SANA refers the proposal to the WG Chair; if the WG does not still exist, the SANA sends the proposal to the applicable AD; if the Area no longer exists, the SANA sends the proposal to the CESG. Then everyone can have change proposals to any registry arbitrated by the SANA (can we assume it has persistence?). I will supply a new registration rule for Tom to apply to the Agency Review copy that indicates change requests should be

submitted to sanaregistry.org.   (Aside:  given what you say about WG's

not being standing bodies within the CCSDS, which I do acknowledge, it is a bit puzzling that the CESG Chair has requested WG Chairs to put "Draft Projects" into the project framework (http://cwe.ccsds.org/fm/Lists/Projects/AllOpenChartersWithDraftProjects.as

px), and also update 5 year plans at each Plenary... these provide an excellent vehicle for perpetuating a WG.  But OK...).

I feel your pain some more.   I think this will come down to the proposed “expert group” notion which is still in progress.   For the CSSM area, my thinking is that this will be the default option for this kind of thing in the future, but for the time being, for those items not properly addressed in a global registry sense, the next best option is to have the policy state that it is the Area that addresses registry updates, etc. The Areas are in fact constituted as standing bodies so that seems to me to be the proper locale for this kind of thing until we see the revised SANA policy.

Regards,

David

On 8/17/15, 2:07 PM, "Thomas Gannett" <tomg at aiaa.org<mailto:tomg at aiaa.org>> wrote:

>David:

>

>The CESG poll to approve release of CCSDS 509.0-R-1, Pointing Request

>Message (Red Book, Issue 1) for CCSDS Agency review concluded with

>conditions (stated below--Peter's markup of the PDF CESG approval copy

>is attached). I have also attached the Word file for the current

>version.

>

>I suggest you negotiate dispositions for the conditions directly with

>Peter and Erik; CC me and cesg at mailman.ccsds.org<mailto:cesg at mailman.ccsds.org> in all correspondence.

>

>(I had hoped we could complete the review before the fall meetings, but

>that is pretty unlikely now, unless conditions can be resolved this

>week.)

>

>Tom

>

>

>>CESG E-Poll Identifier: CESG-P-2015-07-006 Approval to release CCSDS

>>509.0-R-1, Pointing Request Message (Red Book, Issue 1) for CCSDS

>>Agency review Results of CESG poll beginning 31 July 2015 and ending

>>14 August 2015:

>>

>>                  Abstain:  1 (14.29%) (Calzolari)  Approve

>> Unconditionally:  4 (57.14%) (Merri, Behal, Suess, Barton)  Approve

>> with Conditions:  2 (28.57%) (Barkley, Shames)  Disapprove with

>> Comment:  0 (0%)

>>

>>CONDITIONS/COMMENTS:

>>

>>Erik Barkley (Approve with Conditions): Some conditions and some

>>comments.

>>

>>Conditions:

>>

>>1) CCSDS has defined a URN for, among other things, management of XML

>>Schemas. As such a no namespace schema is not really allowed.

>>The XML Schema (or sub-schemas depending on desired organization) need

>>to have a namespace definition.

>>

>>2) SANA considerations part 1: In addition to registering the schema

>>(which is good), the recommendation makes use of data items for which

>>there are controlled CCSDS registries. This includes such items as:

>>a) spacecraft name

>>(http://sanaregistry.org/r/spacecraftid/spacecraftid.html)

>>b) Originator -- there is a registry in progress for this

>>http://sanaregistry.org/r/organizations/organizations.html

>>

>>But these are not called out in the SANA considerations sections.

>>

>>3) SANA considerations part 2: -- by definition, WGs are not supposed

>>to be standing bodies within CCSDS. That being the case a different

>>management policy for registration control authority for controlled

>>information that can outlive a working group other than communication

>>the WG chair should to be stated. It is suggested to contact the CCSDS

>>SE Area for a better definition of this as SANA registry policy is

>>currently being revised by the SE Area.

>>

>>Comments (not conditions):

>>1) Although the principal investigator and relay communications are

>>cited as use cases, its not clear how this fits a with a bigger

>>picture of mission operations in general. Is the PRM really something

>>to be emitted by a PI? Presumably the antenna pointing on-board the

>>spacecraft is in fact then further sequenced as part of an overall

>>spacecraft operations planning taking into account keep-out zones,

>>spacecraft fault protection etc. Perhaps this may just be an issue of

>>terminology -- its seems that is not really a request to point an

>>antenna but really a request to have the spacecraft antenna track a

>>particular target or motion pattern? It would be interesting to learn

>>more of the conceptual background and how this fits with the overall

>>MOIMS architecture.

>>

>>Peter Shames (Approve with Conditions): This document is quite mature,

>>but it contains a significant number of issues that should be resolved

>>before it goes out for agency review. Key issues:

>>1) Two annexes are marked information but contain what appears to be

>>normative materials

>>2) There are a number of points at which references are made to "do it

>>in an ICD" instead of providing clear definitions. A means of

>>providing extensibility points, and even a SANA registry, would be

>>prefered.

>>3) There are a number of items, such as "originator", "spacecraft", or

>>other identifiers that are weakly specified. Where possible existing

>>SANA registries should be referenced.

>>4) There are many terms used in this spec that are not defined or not

>>adequately defined.

>>5) There is no ICS.

>>

>>See the attached document for additional comments and specific

>>suggestions for remedying these issues.

>>

>>

>>Total Respondents: 7

>>No response was received from the following Area(s):

>>

>>SIS

>>

>>SECRETARIAT INTERPRETATION OF RESULTS:  Approved with Conditions

>>PROPOSED SECRETARIAT ACTION:            Generate CMC poll after

>>conditions have been addressed

>>

>>* * * * * * * * * * * * * * * * * * * * * * * *

>>

>>

>>

>>_______________________________________________

>>CESG-all mailing list

>>CESG-all at mailman.ccsds.org<mailto:CESG-all at mailman.ccsds.org>

>>http://mailman.ccsds.org/mailman/listinfo/cesg-all

>>

>>_______________________________________________

>>Secretariat mailing list

>>Secretariat at mailman.ccsds.org<mailto:Secretariat at mailman.ccsds.org>

>>http://mailman.ccsds.org/mailman/listinfo/secretariat

>

>Thomas Gannett

>+1 443 472 0805

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/cesg/attachments/20150824/1999db2d/attachment.html>