[CESG] Re: Results of CESG poll CESG-P-2015-07-006 Approval to release CCSDS 509.0-R-1, Pointing Request Message (Red Book, Issue 1) for CCSDS Agency review

CCSDS Secretariat tomg at aiaa.org
Mon Dec 14 20:33:03 UTC 2015


Dear CESG Members:

Conditions for approval to release CCSDS 
509.0-R-1, Pointing Request Message (Red Book, 
Issue 1) for CCSDS Agency review have been 
addressed to the satisfaction of the ADs who 
posited them. The Secretariat will now initiate CMC polling.


>From: "Berry, David S (3920)" <david.s.berry at jpl.nasa.gov>
>To: "Shames, Peter M (312B)" <peter.m.shames at jpl.nasa.gov>, "Barkley, Erik J
>  (3970)" <erik.j.barkley at jpl.nasa.gov>, CCSDS Secretariat <tomg at aiaa.org>
>CC: Fran Martínez Fadrique <fmartinez at gmv.com>,
>         "frank.dreger at esa.int" <frank.dreger at esa.int>
>Subject: Re: CCSDS Pointing Request Message with Conditional Approval
>  Dispositions
>
>Peter:  I think the version you have modified is 
>fine for proceeding to Agency Review. Thanks for good suggestions...
>
>Regards,
>David
>
>From: "Shames, Peter M (312B)" 
><<mailto:peter.m.shames at jpl.nasa.gov>peter.m.shames at jpl.nasa.gov>
>Date: Friday, December 11, 2015 at 10:32 AM
>To: David Berry 
><<mailto:David.S.Berry at jpl.nasa.gov>David.S.Berry at jpl.nasa.gov>, 
>"Barkley, Erik J (3970)" 
><<mailto:erik.j.barkley at jpl.nasa.gov>erik.j.barkley at jpl.nasa.gov>, 
>CCSDS Secretariat <<mailto:tomg at aiaa.org>tomg at aiaa.org>
>Cc: Fran Martínez Fadrique 
><<mailto:fmartinez at gmv.com>fmartinez at gmv.com>, 
>"<mailto:frank.dreger at esa.int>frank.dreger at esa.int" 
><<mailto:frank.dreger at esa.int>frank.dreger at esa.int>
>Subject: Re: CCSDS Pointing Request Message with 
>Conditional Approval Dispositions
>
>David, et al,
>
>Thanks for being so responsive to these 
>requests.  I think that the new text is much 
>clearer, and particularly think that the 
>addition of the text in Sec 3.2.2 pointing to 
>the definitions in Table 3.1 and Sec 3.3.2 is a 
>big help.  That ties it all together.
>
>I did note a few typos that I fixed in the attached version.
>
>The last item, which I had missed before, is 
>that while the intro section, 3.2.1 talks about 
>two sections, the <header> and the <body>, only 
>the structure of the <body> is addressed at all 
>in the intro.  The <header> and it’s fields do 
>not get described at all until sec 5.3.   I 
>admit that this is a bit of an issue with me, 
>but I am suggesting the inclusiion of the 
>provided new text for sec 3.2.1.10 that defines 
>the header contents up front, along with the 
>body contents.   I think this is a logically 
>sound construct and it also scratches my 
>particular itch about the role of the SANA.
>
>If you agree that this does not do violence to 
>the document structure, and you can accept it, 
>then I think we have agreement to send it out 
>for agency review.  If this is a significant 
>issue for you I would allow the document to go 
>out for review without this change, but this 
>topic will arise again before the document is approved for final publication.
>
>Best regards, Peter
>
>From: David Berry 
><<mailto:David.S.Berry at jpl.nasa.gov>David.S.Berry at jpl.nasa.gov>
>Date: Thursday, December 10, 2015 at 3:36 PM
>To: Peter Shames 
><<mailto:peter.m.shames at jpl.nasa.gov>peter.m.shames at jpl.nasa.gov>, 
>Erik Barkley 
><<mailto:Erik.J.Barkley at jpl.nasa.gov>Erik.J.Barkley at jpl.nasa.gov>, 
>Tom Gannett <<mailto:tomg at aiaa.org>tomg at aiaa.org>
>Cc: Fran Martínez Fadrique 
><<mailto:fmartinez at gmv.com>fmartinez at gmv.com>, 
>"<mailto:frank.dreger at esa.int>frank.dreger at esa.int" 
><<mailto:frank.dreger at esa.int>frank.dreger at esa.int>
>Subject: FW: CCSDS Pointing Request Message with 
>Conditional Approval Dispositions
>
>
>Peter et al.:
>
>Fran Martinez (lead PRM editor) has addressed 
>Peter's recent conditions in the attached PRM 
>draft.  His notes on these items are immediately below.
>
>In the spirit of the recent CESG directions we 
>have been attempting to reduce the reliance on ICDs in 3.2.2 and 3.2.3.5.
>
>Regards,
>David
>
>
>
>
>From: Fran Martínez Fadrique <<mailto:fmartinez at gmv.com>fmartinez at gmv.com>
>Date: Thursday, December 10, 2015 at 3:29 PM
>To: David Berry 
><<mailto:David.S.Berry at jpl.nasa.gov>David.S.Berry at jpl.nasa.gov>
>Subject: RE: CCSDS Pointing Request Message with 
>Conditional Approval Dispositions
>
>Hi David,
>I have reviewed the document taking the comments into account.
>1.7: references added
>3.2.2: I have removed the ICD and reworked the 
>requirements a bit. Also section 3.2.1 required 
>some rework to make it consistent (and not repeating) with section 3.2.2
>3.2.3.5: the original comment was in the 
>direction to remove the need for the ICD. I 
>agreed with that but it is certain that the mere 
>removal was not best by itself. I have 
>rearranged the requirements a bit to make clear 
>that a number of timelines are defined that 
>contain time blocks. With the new setup I think 
>that the need for ICD disappears and so does the 
>note (the old one and the new proposed one).
>I think that now the reservations should be 
>cleared. If the understanding of these two 
>sections is still difficult I think that will 
>pop out during the review and we may reconsider to review them again.
>Best regards,
>Fran
>
>
>From: Berry, David S (3920) 
>[<mailto:david.s.berry at jpl.nasa.gov>mailto:david.s.berry at jpl.nasa.gov]
>Sent: 10 December 2015 20:40
>To: Fran Martínez Fadrique <<mailto:fmartinez at gmv.com>fmartinez at gmv.com>
>Subject: FW: CCSDS Pointing Request Message with 
>Conditional Approval Dispositions
>
>
>Fran:
>
>Below are a few additional comments from Peter Shames...
>
>1.7:  The comment on Sec 1.7 seems very easy to satisfy.
>
>3.2.2: I think perhaps Peter is not 
>understanding the <definition> concept. Is there 
>any need for these to be agreed in advance and 
>specified in an ICD? Can they simply be defined 
>in the PRM without additional documentation?
>
>3.2.3.5:  Adding the NOTE seems OK with me, but 
>again, maybe an ICD is not really necessary?
>
>What do you think?
>
>Once we agree to these in some fashion, I think 
>the Agency Review can proceed...
>
>Regards,
>David
>
>
>
>From: "Shames, Peter M (312B)" 
><<mailto:peter.m.shames at jpl.nasa.gov>peter.m.shames at jpl.nasa.gov>
>Date: Wednesday, December 9, 2015 at 3:03 PM
>To: David Berry 
><<mailto:David.S.Berry at jpl.nasa.gov>David.S.Berry at jpl.nasa.gov>, 
>"Barkley, Erik J (3970)" 
><<mailto:erik.j.barkley at jpl.nasa.gov>erik.j.barkley at jpl.nasa.gov>, 
>CCSDS Secretariat <<mailto:tomg at aiaa.org>tomg at aiaa.org>
>Cc: Fran Martínez Fadrique 
><<mailto:fmartinez at gmv.com>fmartinez at gmv.com>, 
>"<mailto:frank.dreger at esa.int>frank.dreger at esa.int" 
><<mailto:frank.dreger at esa.int>frank.dreger at esa.int>
>Subject: Re: CCSDS Pointing Request Message with 
>Conditional Approval Dispositions
>
>Hi David & Tom,
>
>I have reviewed the changes to the document and 
>concur with all of the ones that were 
>applied.  I do note a few conditions that still 
>have not been satisfied that I believe should be:
>
>Sec 1.7 References
>
>There should be references here to the SANA 
>registries for spacecraft and organizations
>
>Sec 3.2.2
>
>This section describes how to create a 
><definition> section of a PRM, but I still do 
>not find a well defined table of 
>definitions.  Sec 3.2.3 may provide such a set 
>of definitions, but it is not referenced.  If 
>this is where the minimal, interoperable, set of 
>definitions is located it should be pointed to 
>here.  If there is no such minimal, 
>interoperable, set of definitions then I humbly 
>submit that this spec should define some or risk 
>not being interoperable and specified only by bi-lateral ICDs.
>
>Sec 3.2.3.5
>
>There was a section in the earlier draft that 
>had an issue.  This was resolved by removing it 
>instead of fixing it.  I propose the text be included as a NOTE.
>
>That’s it.  If the WG can agree to clean up 
>these conditions then I approve the final version.
>
>Thanks, Peter
>
>
>
>From: "Barkley, Erik J (3970)" <erik.j.barkley at jpl.nasa.gov>
>To: "Berry, David S (3920)" <david.s.berry at jpl.nasa.gov>, "Shames, Peter M
>  (312B)" <peter.m.shames at jpl.nasa.gov>, CCSDS Secretariat <tomg at aiaa.org>
>CC: Fran Martínez Fadrique <fmartinez at gmv.com>,
>         "frank.dreger at esa.int" <frank.dreger at esa.int>
>Subject: RE: CCSDS Pointing Request Message with Conditional Approval
>  Dispositions
>Date: Wed, 9 Dec 2015 01:53:36 +0000
>
>David,
>
>Thank you for the updates. My conditions are retired.
>
>A couple of follow-on comments for consideration 
>when the recommendation goes to a publication poll.
>
>1) removal of the XML schema in favor of 
>"templates" will likely make implementations 
>more difficult as there will not be the ability 
>to validate XML messages via the XML 
>schema.     Although I do recall having had a 
>conversation at the Darmstadt meetings I may 
>need a refresher as to the rationale. It does 
>seem to me that having had all of the long work 
>to finally get the CCSDS URN defined and 
>registered with IETF that it would be quite 
>straightforward to have a namespace assigned for a RPM XML Schema.
>
>2) for the originator metadata which is to make 
>use of the organization registry, we may wish to 
>coordinate that further prior to the formal 
>publication poll. In the cross support services 
>area we have a similar bit of metadata and are 
>making use of the same organization registry. 
>However, in this case, (for the schedule 
>publication format), we are also adding an 
>attribute  "ServiceProvider" which is an 
>enumerated list that will have an initial set of 
>two values, a null value, and the value of 
>"SchedulePublisher".  The idea is then to 
>provide the ability to quickly see what the 
>various organizations can do in terms of service 
>provision if they do any of that. This would 
>presumably allow for a quick scan sorting 
>between PRM providers vs those organization that 
>publish schedules, etc through the registry for 
>humans as well as implementation systems to 
>validate against registry entries (eventually in 
>some sort of cached manner).  Multiple 
>attributes along these lines (e.g, a publisher 
>of schedules and a PRM originator, etc) I don't 
>think has been addressed in any emerging SANA 
>information model(s).   Of course, this is not 
>at all obvious given that we have essentially 
>moving targets and recent developments with 
>regard to the registry management policy and 
>this does speak to the broader question of when 
>a particular recommendation adds an attribute to 
>particular registry how that attribute is then made known to all of CCSDS.
>
>So, in summary, conditions okay/done as far as 
>I'm concerned for going to agency reviews, but I 
>think there may be some further considerations/discussions down the road.
>
>Best regards,
>
>-Erik
>
>
>-----Original Message-----
>From: Berry, David S (3920)
>Sent: Monday, December 07, 2015 5:10 PM
>To: Shames, Peter M (312B) 
><peter.m.shames at jpl.nasa.gov>; Barkley, Erik J 
>(3970) <erik.j.barkley at jpl.nasa.gov>; CCSDS Secretariat <tomg at aiaa.org>
>Cc: Fran Martínez Fadrique <fmartinez at gmv.com>; frank.dreger at esa.int
>Subject: CCSDS Pointing Request Message with Conditional Approval Dispositions
>
>
>Peter, Erik, Tom:
>
>The attached MS Word version of the Pointing 
>Request Message incorporates changes designed to 
>address the conditions you placed on releasing 
>the book for Agency Review.  This email will 
>provide the dispositions to the conditions.  I 
>also attached Peter's mark up of the original CESG Approval Copy.
>
>I request that you review the dispositions as 
>soon as possible given that I would like to have 
>a completed Agency Review of the PRM in time for 
>the Spring 2016 CCSDS Meetings at Cleveland so 
>the Nav WG can address RIDs most efficiently. 
>The available time between now and then is rather constrained.
>
>Thanks
>David
>
>
>DISPOSITIONS
>============
>
>Barkley (1) - CCSDS URN & Namespace:  As 
>mentioned at Darmstadt, the WG has determined 
>that XML schemas for the PRM templates are not necessary.
>We will register the XML templates that comprise 
>the heart of the PRM in a SANA Registry, whence 
>they may be used directly by interested parties.
>This addresses the namespace issue cited by Erik.
>
>Barkley (2) - SANA Registries:  Per Erik's 
>suggestion, the SANA annex has been updated to 
>state that spacecraft ID's and message 
>originators should be drawn from the applicable SANA registries.
>
>Barkley (3) - SANA Rule for New 
>Registrations:  The rule for new requests has 
>been genericized so it no longer refers to any particular CCSDS Area or WG.
>
>Shames (1) - Normative/Informative 
>Annexes:  Annexes that were formerly marked 
>"informative" but contained normative material 
>have been properly marked "normative".
>
>Shames (2) - ICD:  The WG has attempted to 
>reduce the need to rely on an ICD and use SANA 
>registries, however, there remain multiple 
>points where use of an ICD seems 
>necessary.  Note that use of an ICD has 
>generally been required in other Navigation WG 
>standards, and thia has not stopped previous Agency Reviews.
>
>Shames (3) - SANA Registries:  Same as Barkley (2) above.
>
>Shames (4) - Term Definitions:  It is difficult 
>to address this comment given lack of specificity.
>
>Shames (5) - ICS:  An ICS Annex has been added.
>
>
>The following dispositions relate to comments 
>that Peter Shames made directly in the 
>document.  All page references are relative to 
>the PDF that Peter commented upon (attached) 
>since some of the sections have necessarily moved in the revised document:
>
>Shames (p.1-3) - Use of NAIF IDs:  SPICE is 
>widely used in space operations and science. 
>Using NAIF IDs for natural bodies does not seem 
>particularly problematic, but if there's a 
>problem it should emerge in a RID. I don't think 
>it would be desirable to try to duplicate all 
>the SPICE natural body numbers in SANA. We've 
>changed the document to recommend data from SANA for spacecraft identifiers.
>
>Shames (p.2-2):  Both suggestions implemented.
>
>Shames (p.3-2) - "ORIGINATOR":  Peter just had a 
>question here. We have recommended that this 
>data value be taken from the SANA "organizations"
>registry.  There is no inherent restriction on 
>who can create these (different from CDM, where 
>there was a desire to have stronger trail of provenance.
>
>Shames (p.3-2) - Time systems:  Peter just had a 
>question here... yes, there is a prescribed set 
>of time systems, and they are documented in Annex A.
>
>Shames (p.3-3) - "Stream" form: It was made 
>clear that the PRM is in a file. No stream form 
>is envisioned (but that doesn't mean someone 
>won't do it). In general the Nav WG has not made 
>restrictions on the transfer method.
>
>Shames (p.3-3) - "Definitions":  A pointer to 
>section 3.2.2 where definitions are discussed was added.
>
>Shames (p.3-3) - Frames:  A pointer to Annex H 
>where frames are discussed in detail was added.
>
>Shames (p.3-3) - Attitude Timeline:  Section 
>3.2.3 was revised to clarify that the attitude 
>timeline is the attitude of a spacecraft or any 
>of its articulate parts over a period of time.
>
>Shames (p.3-4) - ICD "cop out": The applicable 
>section has been revised such that there is no longer a reference to an ICD.
>
>Shames (p.3-4) - Use of "obligatory":  All uses of the word "obligatory"
>have been changed to "mandatory" in line with 
>Peter's suggestion. Note that we are starting to 
>observe this ICS-related terminology throughout 
>the Nav WG standards in development and revision 
>stages. Prior to this comment, there has never 
>been a problem cited with the use of "obligatory"
>(but I think this is a good catch).
>
>Shames (p.3-6) - Generic Element Name:  Note 
>clarified, table column corrected.
>
>Shames (p.3-7) - Duplicate table:  The duplicate 
>table was removed... not sure how this happened.
>
>Shames (p.3-11) - Interpolation algorithm:  New 
>tags have been added to accommodate description 
>of the interpolation algorithm, and the reference to ICD is eliminated.)
>
>Shames (p.3-12) - Operations on List of 
>Reals:  The operations are defined in Annex E (new "normative" sequence).
>
>Shames (p.3-13) - Use of "obligatory":  Corrected... See above.
>
>Shames (p.3-13) - Orbit & Target:  No further 
>clarification necessary. See "Orbit Entity" type for clarification.
>
>Shames (p.3-15) - NAIF IDs:  SPICE is widely 
>used in space operations and science. Using NAIF 
>IDs for ephemeris objects does not seem 
>particularly problematic, but if there's a 
>problem it should emerge in a RID. I don't think 
>it would be desirable to try to duplicate all 
>the SPICE natural body numbers in SANA.
>
>Shames (p.3-17) - baseFrame = 'none':  This is a 
>reasonable way of defining the root frame in a chaining of reference frames.
>
>Shames (p.3-22) - "Name Assignation":  Suggestion to use "Name Assignment"
>incorporated.
>
>Shames (p.3-22) - Types Defined in 0:  This is 
>some type of MS Word cross-referencing error.
>
>Shames (p.4-1) - Awkward wording:  Wording clarified.
>
>Shames (p.A-2) - MRT/MET comment:  Good 
>point.  In general, MRT and MET are problematic 
>in this regard, but missions persist in using 
>them. If need be, a special tag can be added here (and in several other Nav WG
>standards) that contains data that never 
>changes. We've always previously assumed this 
>was the type of information that would be placed 
>in an ICD since it never changes.
>
>Shames (p.B-1), B1.2:  This text has been copied 
>from other published Navigation WG 
>standards.  It may be the case that a "default" 
>Security section of CCSDS standards should be 
>added by the Secretariat to the White Book 
>templates so that it meets the requirements of the CESG.
>
>Shames (p.B-1, B1.3):  Suggested change added.
>
>Shames (p.B-1, B1.4): This text has been copied 
>from other published Navigation WG 
>standards.  It may be the case that a "default" 
>Security section of CCSDS standards should be 
>added by the Secretariat to the White Book 
>templates so that it meets the requirements of the CESG.
>
>Shames (p.B-3, B2) - SANA Considerations:  The 
>SANA Considerations have been modified significantly.
>
>Shames (p.G-1) - List of Operators:  This Annex 
>has been made normative (and moved before all informative annexes).
>
>Shames (p.H-1) - Supported Units:  This Annex 
>has been made normative (and moved before all informative annexes).

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


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


More information about the CESG mailing list