<html>
<body>
Dear CESG Members:<br><br>
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.<br><br>
<br>
<blockquote type=cite class=cite cite="">From: "Berry, David S
(3920)" <david.s.berry@jpl.nasa.gov><br>
To: "Shames, Peter M (312B)"
<peter.m.shames@jpl.nasa.gov>, "Barkley, Erik J<br>
(3970)" <erik.j.barkley@jpl.nasa.gov>, CCSDS Secretariat
<tomg@aiaa.org><br>
CC: Fran Martínez Fadrique <fmartinez@gmv.com>,<br>
<x-tab> </x-tab>
"frank.dreger@esa.int" <frank.dreger@esa.int><br>
Subject: Re: CCSDS Pointing Request Message with Conditional
Approval<br>
Dispositions<br><br>
Peter: I think the version you have modified is fine for proceeding
to Agency Review. Thanks for good suggestions...<br><br>
Regards,<br>
David<br><br>
From: "Shames, Peter M (312B)"
<<a href="mailto:peter.m.shames@jpl.nasa.gov">
peter.m.shames@jpl.nasa.gov</a>><br>
Date: Friday, December 11, 2015 at 10:32 AM<br>
To: David Berry
<<a href="mailto:David.S.Berry@jpl.nasa.gov">
David.S.Berry@jpl.nasa.gov</a>>, "Barkley, Erik J (3970)"
<<a href="mailto:erik.j.barkley@jpl.nasa.gov">
erik.j.barkley@jpl.nasa.gov</a>>, CCSDS Secretariat
<<a href="mailto:tomg@aiaa.org">tomg@aiaa.org</a>><br>
Cc: Fran Martínez Fadrique
<<a href="mailto:fmartinez@gmv.com">fmartinez@gmv.com</a>>,
"<a href="mailto:frank.dreger@esa.int">frank.dreger@esa.int</a>
"
<<a href="mailto:frank.dreger@esa.int">frank.dreger@esa.int</a>><br>
Subject: Re: CCSDS Pointing Request Message with Conditional Approval
Dispositions<br><br>
David, et al,<br><br>
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.<br><br>
I did note a few typos that I fixed in the attached version.<br><br>
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.<br><br>
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.<br><br>
Best regards, Peter<br>
<br>
From: David Berry
<<a href="mailto:David.S.Berry@jpl.nasa.gov">
David.S.Berry@jpl.nasa.gov</a>><br>
Date: Thursday, December 10, 2015 at 3:36 PM<br>
To: Peter Shames
<<a href="mailto:peter.m.shames@jpl.nasa.gov">
peter.m.shames@jpl.nasa.gov</a>>, Erik Barkley
<<a href="mailto:Erik.J.Barkley@jpl.nasa.gov">
Erik.J.Barkley@jpl.nasa.gov</a>>, Tom Gannett
<<a href="mailto:tomg@aiaa.org">tomg@aiaa.org</a>><br>
Cc: Fran Martínez Fadrique
<<a href="mailto:fmartinez@gmv.com">fmartinez@gmv.com</a>>,
"<a href="mailto:frank.dreger@esa.int">frank.dreger@esa.int</a>
"
<<a href="mailto:frank.dreger@esa.int">frank.dreger@esa.int</a>><br>
Subject: FW: CCSDS Pointing Request Message with Conditional Approval
Dispositions<br><br>
<dl><br>
<dd>Peter et al.:<br><br>
<dd>Fran Martinez (lead PRM editor) has addressed Peter's recent
conditions in the attached PRM draft. His notes on these items are
immediately below.<br><br>
<dd>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.<br><br>
<dd>Regards, <br>
<dd>David<br><br>
<br><br>
<br>
<dd>From: Fran Martínez Fadrique
<<a href="mailto:fmartinez@gmv.com">fmartinez@gmv.com</a>><br>
<dd>Date: Thursday, December 10, 2015 at 3:29 PM<br>
<dd>To: David Berry
<<a href="mailto:David.S.Berry@jpl.nasa.gov">
David.S.Berry@jpl.nasa.gov</a>><br>
<dd>Subject: RE: CCSDS Pointing Request Message with Conditional Approval
Dispositions<br><br>
<dd>Hi David,<br>
<dd>I have reviewed the document taking the comments into account.<br>
<dd>1.7: references added<br>
<dd>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<br>
<dd>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).<br>
<dd>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.<br>
<dd>Best regards,<br>
<dd>Fran<br>
<dd> <br>
<dd> <br>
<dd>From:</b> Berry, David S (3920)
[<a href="mailto:david.s.berry@jpl.nasa.gov">
mailto:david.s.berry@jpl.nasa.gov</a>] <br>
<dd>Sent:</b> 10 December 2015 20:40<br>
<dd>To:</b> Fran Martínez Fadrique
<<a href="mailto:fmartinez@gmv.com">fmartinez@gmv.com</a>><br>
<dd>Subject:</b> FW: CCSDS Pointing Request Message with Conditional
Approval Dispositions<br>
<dd> <br>
<dd> <br>
<dd>Fran:<br>
<dd> <br>
<dd>Below are a few additional comments from Peter Shames...<br>
<dd> <br>
<dd>1.7: The comment on Sec 1.7 seems very easy to satisfy.<br>
<dd> <br>
<dd>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?<br>
<dd> <br>
<dd>3.2.3.5: Adding the NOTE seems OK with me, but again, maybe an
ICD is not really necessary?<br>
<dd> <br>
<dd>What do you think?<br>
<dd> <br>
<dd>Once we agree to these in some fashion, I think the Agency Review can
proceed...<br>
<dd> <br>
<dd>Regards,<br>
<dd>David<br>
<dd> <br>
<dd> <br>
<dd> <br>
<dd>From: </b>"Shames, Peter M (312B)"
<<a href="mailto:peter.m.shames@jpl.nasa.gov">
peter.m.shames@jpl.nasa.gov</a>><br>
<dd>Date: </b>Wednesday, December 9, 2015 at 3:03 PM<br>
<dd>To: </b>David Berry
<<a href="mailto:David.S.Berry@jpl.nasa.gov">
David.S.Berry@jpl.nasa.gov</a>>, "Barkley, Erik J (3970)"
<<a href="mailto:erik.j.barkley@jpl.nasa.gov">
erik.j.barkley@jpl.nasa.gov</a>>, CCSDS Secretariat
<<a href="mailto:tomg@aiaa.org">tomg@aiaa.org</a>><br>
<dd>Cc: </b>Fran Martínez Fadrique
<<a href="mailto:fmartinez@gmv.com">fmartinez@gmv.com</a>>,
"<a href="mailto:frank.dreger@esa.int">frank.dreger@esa.int</a>
"
<<a href="mailto:frank.dreger@esa.int">frank.dreger@esa.int</a>><br>
<dd>Subject: </b>Re: CCSDS Pointing Request Message with Conditional
Approval Dispositions<br>
<dd> <br>
<dd>Hi David & Tom,<br>
<dd> <br>
<dd>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:<br>
<dd> <br>
<dd>Sec 1.7 References<br>
<dd> <br>
<dd>There should be references here to the SANA registries for spacecraft
and organizations<br>
<dd> <br>
<dd>Sec 3.2.2<br>
<dd> <br>
<dd>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.<br>
<dd> <br>
<dd>Sec 3.2.3.5<br>
<dd> <br>
<dd>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.<br>
<dd> <br>
<dd>That’s it. If the WG can agree to clean up these conditions
then I approve the final version.<br>
<dd> <br>
<dd>Thanks, Peter<br>
<dd> <br>
<dd> <br>
</dl><br>
From: "Barkley, Erik J (3970)"
<erik.j.barkley@jpl.nasa.gov><br>
To: "Berry, David S (3920)" <david.s.berry@jpl.nasa.gov>,
"Shames, Peter M<br>
(312B)" <peter.m.shames@jpl.nasa.gov>, CCSDS Secretariat
<tomg@aiaa.org><br>
CC: Fran Martínez Fadrique <fmartinez@gmv.com>,<br>
<x-tab> </x-tab>
"frank.dreger@esa.int" <frank.dreger@esa.int><br>
Subject: RE: CCSDS Pointing Request Message with Conditional
Approval<br>
Dispositions<br>
Date: Wed, 9 Dec 2015 01:53:36 +0000<br><br>
David,<br><br>
Thank you for the updates. My conditions are retired. <br><br>
A couple of follow-on comments for consideration when the recommendation
goes to a publication poll.<br><br>
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.<br><br>
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.<br>
<br>
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. <br><br>
Best regards,<br><br>
-Erik<br><br>
<br>
-----Original Message-----<br>
From: Berry, David S (3920) <br>
Sent: Monday, December 07, 2015 5:10 PM<br>
To: Shames, Peter M (312B) <peter.m.shames@jpl.nasa.gov>; Barkley,
Erik J (3970) <erik.j.barkley@jpl.nasa.gov>; CCSDS Secretariat
<tomg@aiaa.org><br>
Cc: Fran Martínez Fadrique <fmartinez@gmv.com>;
frank.dreger@esa.int<br>
Subject: CCSDS Pointing Request Message with Conditional Approval
Dispositions<br><br>
<br>
Peter, Erik, Tom: <br><br>
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.<br><br>
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.<br><br>
Thanks<br>
David<br><br>
<br>
DISPOSITIONS<br>
============<br><br>
Barkley (1) - CCSDS URN & Namespace: As mentioned at Darmstadt,
the WG has determined that XML schemas for the PRM templates are not
necessary.<br>
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.<br>
This addresses the namespace issue cited by Erik.<br><br>
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.<br><br>
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.<br><br>
Shames (1) - Normative/Informative Annexes: Annexes that were
formerly marked "informative" but contained normative material
have been properly marked "normative".<br><br>
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.<br><br>
Shames (3) - SANA Registries: Same as Barkley (2) above.<br><br>
Shames (4) - Term Definitions: It is difficult to address this
comment given lack of specificity.<br><br>
Shames (5) - ICS: An ICS Annex has been added.<br><br>
<br>
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:<br>
<br>
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.<br><br>
Shames (p.2-2): Both suggestions implemented.<br><br>
Shames (p.3-2) - "ORIGINATOR": Peter just had a question
here. We have recommended that this data value be taken from the SANA
"organizations"<br>
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.<br><br>
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.<br><br>
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.<br><br>
Shames (p.3-3) - "Definitions": A pointer to section
3.2.2 where definitions are discussed was added.<br><br>
Shames (p.3-3) - Frames: A pointer to Annex H where frames are
discussed in detail was added.<br><br>
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.<br><br>
Shames (p.3-4) - ICD "cop out": The applicable section has been
revised such that there is no longer a reference to an ICD.<br><br>
Shames (p.3-4) - Use of "obligatory": All uses of the
word "obligatory"<br>
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"<br>
(but I think this is a good catch).<br><br>
Shames (p.3-6) - Generic Element Name: Note clarified, table column
corrected.<br><br>
Shames (p.3-7) - Duplicate table: The duplicate table was
removed... not sure how this happened.<br><br>
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.)<br><br>
Shames (p.3-12) - Operations on List of Reals: The operations are
defined in Annex E (new "normative" sequence).<br><br>
Shames (p.3-13) - Use of "obligatory": Corrected... See
above.<br><br>
Shames (p.3-13) - Orbit & Target: No further clarification
necessary. See "Orbit Entity" type for clarification.<br><br>
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. <br><br>
Shames (p.3-17) - baseFrame = 'none': This is a reasonable way of
defining the root frame in a chaining of reference frames.<br><br>
Shames (p.3-22) - "Name Assignation": Suggestion to use
"Name Assignment"<br>
incorporated.<br><br>
Shames (p.3-22) - Types Defined in 0: This is some type of MS Word
cross-referencing error.<br><br>
Shames (p.4-1) - Awkward wording: Wording clarified.<br><br>
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<br>
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.<br><br>
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.<br><br>
Shames (p.B-1, B1.3): Suggested change added.<br><br>
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.<br><br>
Shames (p.B-3, B2) - SANA Considerations: The SANA Considerations
have been modified significantly.<br>
<br>
Shames (p.G-1) - List of Operators: This Annex has been made
normative (and moved before all informative annexes).<br><br>
Shames (p.H-1) - Supported Units: This Annex has been made
normative (and moved before all informative annexes).</blockquote><br>
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<br>
Results of CESG poll beginning 31 July 2015 and ending 14 August
2015:<br><br>
Abstain: 1 (14.29%) (Calzolari)<br>
Approve Unconditionally: 4 (57.14%) (Merri, Behal, Suess,
Barton)<br>
Approve with Conditions: 2 (28.57%) (Barkley, Shames)<br>
Disapprove with Comment: 0 (0%)<br><br>
CONDITIONS/COMMENTS:<br><br>
Erik Barkley (Approve with Conditions): Some conditions and some
comments.<br><br>
Conditions:<br><br>
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.<br><br>
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:<br>
a) spacecraft name
(<a href="http://sanaregistry.org/r/spacecraftid/spacecraftid.html" eudora="autourl">
http://sanaregistry.org/r/spacecraftid/spacecraftid.html</a>)<br>
b) Originator -- there is a registry in progress for this
<a href="http://sanaregistry.org/r/organizations/organizations.html" eudora="autourl">
http://sanaregistry.org/r/organizations/organizations.html<br><br>
</a>But these are not called out in the SANA considerations
sections.<br><br>
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.<br><br>
Comments (not conditions):<br>
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.<br><br>
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:<br>
1) Two annexes are marked information but contain what appears to be
normative materials<br>
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.<br>
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.<br>
4) There are many terms used in this spec that are not defined or not
adequately defined.<br>
5) There is no ICS.<br><br>
See the attached document for additional comments and specific
suggestions for remedying these issues.<br><br>
<br>
Total Respondents: 7<br>
No response was received from the following Area(s):<br><br>
SIS<br><br>
SECRETARIAT INTERPRETATION OF RESULTS: Approved with
Conditions<br>
PROPOSED SECRETARIAT
ACTION:
Generate CMC poll after conditions have been addressed<br><br>
<br>
</body>
</html>