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

Barkley, Erik J (3970) erik.j.barkley at jpl.nasa.gov
Mon Aug 24 18:31:40 UTC 2015


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


-----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>
Cc: Shames, Peter M (312B) <peter.m.shames at jpl.nasa.gov>; Thomas Gannett <tomg at aiaa.org>; cesg at mailman.ccsds.org
Subject: FW: Results of CESG Polls closing 14 August 2015


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.



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



>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



>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






>>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%)




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





>>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


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



>>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


>>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):





>>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>




>>Secretariat mailing list

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



>Thomas Gannett

>+1 443 472 0805

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

More information about the CESG mailing list