<html>
<body>
Dear CESG Members,<br><br>
Conditions for approval of CCSDS 902.13-R-1, Abstract Event Definition
(Red Book, Issue 1) have been disposed to the satisfaction of the AD(s)
who voted to approve with conditions. The Secretariat will now proceed
with CMC polling to authorize release for Agency review. <br><br>
<b>From:</b> Shames, Peter M (US 312B)
[<a href="mailto:peter.m.shames@jpl.nasa.gov" eudora="autourl">
mailto:peter.m.shames@jpl.nasa.gov</a>] <br>
<b>Sent:</b> Thursday, July 18, 2019 12:21 PM<br>
<b>To:</b> Barkley, Erik J (US 3970)<br>
<b>Cc:</b> Colin Haddow; Tom Gannett; CCSDS Secretariat<br>
<b>Subject:</b> Re: SE AD Condtions re CESG-P-2019-06-005<br>
<br>
Erik,<br>
<br>
As we discussed in the NDSSC telecon, I am willing to let this document
go out for Agency Review with the understanding that all of the SANA
registry design will be worked right away and that it will be completed
and tested prior to any request for the document to be published.<br>
<br>
Please see Procedures for SANA Registry Specification, CCSDS
313.2-Y-1. This is an abbreviated 16 page document created to guide
Wg thru what they need to do to comply with the SANA guidelines and the
RMP. In sec 2.3 Area and WG Overview, it says this:<br>
<br>
The following describes the overall workflow for a WG to define and
develop a new registry. Depending on the WG and its familiarity with the
process the flow may differ considerably from what is described. <br>
a) Identify a need for a registry related to a new standard. <br>
b) Discuss the proposed registry requirements and design with the
SANA Operator (info@sanaregistry.org) and, if necessary, the SANA
Steering Group (SSG) (ssg@mailmain.ccsds.org). <br>
c) Explore the SANA to see if there is an existing registry that
either meets the need or that can be easily adapted to do the new task.
<br>
d) Evaluate how best to use or adapt existing registries, where
that appears to be feasible, and discuss the approach with the affected
organization. <br>
e) Develop an initial registry design prior to initial Red Book
finalization and describe it in the draft SANA Considerations section.
Work with the SANA Operator to create the candidate registry prior to the
start of interoperability testing, and exercise the registry during
testing. <br>
f) Document the registry policies, registration rules, and Review
Authority, and if necessary the Registration Authority. <br>
g) Include a completed SANA Considerations section in the final
document, pointing to the new registry and describing any other related
registry extensions such as new roles added to Organization or Contacts
Registries. <br>
h) Work with the SANA Operator to document the final registry
design prior to Red Book agency review. <br>
i) Work with the SANA Operator to promote the registry from
Candidate to Approved status prior to Blue Book publication. <br>
j) Participate, as needed, in any registry review or request for
extensions after it has been published. <br>
I think that is pretty clear and to the point. Let's work together
to get this sorted out now. According to e) and h) this should
already have been done, prior to Agency red Book review.<br>
<br>
Thanks, Peter<br>
<br>
<br>
<b>From: </b>Erik Barkley <erik.j.barkley@jpl.nasa.gov><br>
<b>Date: </b>Wednesday, July 17, 2019 at 11:00 AM<br>
<b>To: </b>Peter Shames <peter.m.shames@jpl.nasa.gov><br>
<b>Cc: </b>Colin Haddow <Colin.Haddow@esa.int>, Tom Gannett
<thomas.gannett@tgannett.net>, CCSDS Secretariat
<secretariat@mailman.ccsds.org><br>
<b>Subject: </b>RE: SE AD Condtions re CESG-P-2019-06-005<br>
<br>
Peter,<br>
<br>
Re PS-2 (2<sup>nd</sup> condition listed in your responses to the
CESG poll), the CSSA is willing to provide inputs for this. So yes,
discussion with SSG/SANA and CESG (if necessary) is certainly an
acceptable approach. We can and will add a note to indicate that
the details of management registry will be indicated in the final
published version. Can you please indicate if that addresses the
condition? And inputs on the other conditions would also be very much
appreciated.<br>
<br>
Thank you,<br>
-Erik<br>
<br>
<br>
<b>From:</b> Shames, Peter M (US 312B)
<peter.m.shames@jpl.nasa.gov> <br>
<b>Sent:</b> Tuesday, July 16, 2019 17:54<br>
<b>To:</b> Barkley, Erik J (US 3970)
<erik.j.barkley@jpl.nasa.gov><br>
<b>Cc:</b> Colin Haddow <Colin.Haddow@esa.int>; Tom Gannett
<thomas.gannett@tgannett.net>; CCSDS Secretariat
<secretariat@mailman.ccsds.org><br>
<b>Subject:</b> Re: SE AD Condtions re CESG-P-2019-06-005<br>
<br>
Hi Erik,<br>
<br>
Let's talk this through tomorrow. I raised the issue of AR roles
with CSS because CSS was creating these new registries and being, in my
mind, somewhat haphazard about how they ought to be managed. If we
need to kick this around in the SSG, and with the SANA, then we should do
that before finalizing this document.<br>
<br>
Having said that, we can probably send it out for agency review without
having this settled if there is a note to the effect that the details of
registry management is under discussion. I believe that the agency
reviewers are unlikely to care, or notice.<br>
<br>
And BTW, this is NOT a RID for agency review. It is a CESG and RMP
matter.<br>
<br>
Peter<br>
<br>
<br>
<b>From: </b>Erik Barkley
<<a href="mailto:erik.j.barkley@jpl.nasa.gov">
erik.j.barkley@jpl.nasa.gov</a>><br>
<b>Date: </b>Tuesday, July 16, 2019 at 5:19 PM<br>
<b>To: </b>Peter Shames
<<a href="mailto:peter.m.shames@jpl.nasa.gov">
peter.m.shames@jpl.nasa.gov</a>><br>
<b>Cc: </b>Colin Haddow
<<a href="mailto:Colin.Haddow@esa.int">Colin.Haddow@esa.int</a>>,
Tom Gannett
<<a href="mailto:thomas.gannett@tgannett.net">
thomas.gannett@tgannett.net</a>>, CCSDS Secretariat
<<a href="mailto:Secretariat@mailman.ccsds.org">
Secretariat@mailman.ccsds.org</a>><br>
<b>Subject: </b>SE AD Condtions re CESG-P-2019-06-005<br>
<br>
Dear Peter,<br>
<br>
The CSSM WG has taken a look at the conditions that you have stated re
poll CESG-P-2019-06-005, Abstract Event Definition (Red Book, Issue 1)
for CCSDS Agency review. Please see below for the consensus
responses to the conditions. Your timely response as to resolution
of the conditions will be appreciated.<br>
<br>
Best regards,<br>
-Erik<br>
<br>
--CSSM WG Responses--<br>
<br>
<div align="center">PS-1<br>
</div>
This document should be relevant to the MOIMS Planning group as
well. Please ensure that they review and comment upon it.<br>
Taken as a request, not a condition; yes, all interested parties are
encouraged to participate in agency reviews; MOIMS SM+C, MP
representatives (M. Sakarati, S. Cooper) were copied on emails prior to
resolution for agency review. <br>
<div align="center">PS-2<br>
</div>
In Annex A2.2: There should be a defined AR Role to permit a person to
update the Schema registry<br>
This seems like a general SE consideration re role definitions in SANA --
for the CSS Area it makes more sense to have these kind of role
definitions defined more globally for CCSDS rather than the CSS Area
making them up on the fly so to speak. Note that role of
"Schedule Publisher" was questioned long after the SSF (Simple
Schedule Format) was published. The CSS Area is willing to provide
inputs on role-types, but reluctant to define them for all of CCSDS.
<br>
<div align="center">PS-3<br>
</div>
In Annex A2.3: Plese reconsider whether updates to the Epoch_Time_Systems
registry should be a fre for all or managed, as in controlled by the WG
or by the CSS Area in the absence of an active WG.<br>
1) "Fre for all" taken to mean "free for all".
<br>
2)Epoch systems appear to be fundamental to all of CCSDS. Note that it
was the NAV WG that requested some sort of open ended mechanism for
future time systems. It seems that the CSS Area would not be the
proper area for controlling Epoch definitions; this will likely require
inter-area negotiations. <br>
3) Suggest that this be treated as RID for the agency review as
negotiation of conditions involving multiple areas does not seem
appropriate as a condition for proceeding to review. <br>
<div align="center">PS-4<br>
</div>
In Annex B2: The Schemas all have White Book "w" names, they
should have Blue Book names. The XML schema registry
"service_management_xml_schemas/902Schema/902x13" is "Not
found".<br>
When this is a published recommendation, these will indeed have blue book
associated schema names. However, they are not yet published and to
have blue book naming at this time is deemed as to be potentially
confusing. Clarifying text will be added to the review copy that
indicates that when this book is published the schema will be at the SANA
location indicated and that until such time the schema is available for
review in the CSSM WG public CWE. A directory in the CSSM CWE
public space for schemas relating to books currently under review already
exists and it's URL will be supplied. <br>
<br>
<br>
<br>
<br>
<br>
-----Original Message-----<br>
From: CCSDS Secretariat
<<a href="mailto:thomas.gannett@tgannett.net">
thomas.gannett@tgannett.net</a>> <br>
Sent: Monday, July 15, 2019 10:19<br>
To: <a href="mailto:Colin.Haddow@esa.int">Colin.Haddow@esa.int</a>;
Barkley, Erik J (3970)
<<a href="mailto:erik.j.barkley@jpl.nasa.gov">
erik.j.barkley@jpl.nasa.gov</a>><br>
Cc: <a href="mailto:Mario.Merri@esa.int">Mario.Merri@esa.int</a>; Shames,
Peter M (312B)
<<a href="mailto:peter.m.shames@jpl.nasa.gov">
peter.m.shames@jpl.nasa.gov</a>><br>
Subject: [EXTERNAL] Fwd: Results of CESG Polls closing 12 July 2019<br>
<br>
Colin, Erik:<br>
<br>
The CESG poll to approve release of CCSDS 902.13-R-1, Abstract Event
Definition (Red Book, Issue 1) for CCSDS Agency review concluded with
conditions. Please negotiate disposition of the conditions directly with
the AD(s) who voted to approve with conditions and CC the Secretariat on
all related correspondence.<br>
<br>
Best regards,<br>
Tom<br>
<br>
<br>
<br>
>CESG E-Poll Identifier: CESG-P-2019-06-005 Approval to release
CCSDS <br>
>902.13-R-1, Abstract Event Definition (Red Book, Issue 1) for CCSDS
<br>
>Agency review Results of CESG poll beginning 30 June 2019 and ending
12 <br>
>July 2019:<br>
> <br>
>
Abstain: 1 (16.67%) (Calzolari) Approve <br>
>Unconditionally: 3 (50%) (Barkley, Burleigh, Wilmot) Approve
with <br>
>Conditions: 2 (33.33%) (Merri, Shames) Disapprove with
Comment: 0 <br>
>(0%)<br>
>CONDITIONS/COMMENTS:<br>
> <br>
> Mario Merri (Approve with Conditions):
The comment associated <br>
> with the Identifier field in Table 3-1 states: "NOTE If the
planning <br>
> information is regenerated, then the identifier for a particular
event <br>
> may change."<br>
> <br>
>This is not consistent with the needs of a Planning System <br>
>(particularly a partially or fully automated one) that needs to <br>
>correlate the events from one event file to the next generation of
that <br>
>file covering the same or an overlapping period of time. Despite the
<br>
>standard does not preclude the same ID being used, it should instead
<br>
>recommend that the ID remains constant across multiple <br>
>generations/iterations of the same event.<br>
> <br>
>If this were not the case, there would be an additional (possibly
<br>
>manual) process required to correlate successive instances of the
same <br>
>event exchanged between FDS and MPS which is far from ideal.<br>
> <br>
> Peter Shames (Approve with<br>
> Conditions): This document should be relevant to the MOIMS
Planning <br>
> group as well. Please ensure that they review and comment upon
it.<br>
> <br>
>In Annex A2.2: There should be a defined AR Role to permit a person
to <br>
>update the Schema registry<br>
> <br>
>In Annex A2.3: Plese reconsider whether updates to the <br>
>Epoch_Time_Systems registry should be a fre for all or managed, as in
<br>
>controlled by the WG or by the CSS Area in the absence of an active
WG.<br>
> <br>
>In Annex B2: The Schemas all have White Book "w" <br>
>names, they should have Blue Book names. The XML schema
registry <br>
>"service_management_xml_schemas/902Schema/902x13" is
"Not found".<br>
> <br>
> Scott Burleigh (Approve<br>
> Unconditionally): A comment, not a condition: <br>
> in 3.2.20.2, I think it would improve clarity to change from
"The <br>
> TimeParameter class shall contain one and only one instance of a
time <br>
> parameter specialized from the AbstractEventTime class (see
3.2.14)" <br>
> to "Each instance of the TimeParameter class shall contain one
and <br>
> only one instance of a time parameter specialized from the <br>
> AbstractEventTime class (see 3.2.14)."<br>
> <br>
> Jonathan Wilmot (Approve<br>
> Unconditionally): Nothing in addition to other reviewer's
comments<br>
> <br>
> <br>
>Total Respondents: 6<br>
> <br>
>All Areas responded to this question.<br>
> <br>
> <br>
> <br>
>SECRETARIAT INTERPRETATION OF RESULTS: Approved with
Conditions<br>
>PROPOSED SECRETARIAT
ACTION:
Generate <br>
>CMC poll after conditions have been addressed<br>
> <br>
>* * * * * * * * * * * * * * * * * * * * * * * *<br><br>
<b><a name="_MailOriginal"></a>From:</b> Mario.Merri@esa.int
[<a href="mailto:Mario.Merri@esa.int" eudora="autourl">
mailto:Mario.Merri@esa.int</a>] <br>
<b>Sent:</b> Thursday, July 18, 2019 4:28 AM<br>
<b>To:</b> CCSDS Secretariat (thomas.gannett@tgannett.net)<br>
<b>Cc:</b> Colin.Haddow@esa.int; Secretariat@mailman.ccsds.org; Barkley,
Erik J (US 3970); brigitte.behal@cnes.fr<br>
<b>Subject:</b> RE: [EXTERNAL] Re: MOIMS AD Condition re
CESG-P-2019-06-005<br>
<br>
Hi Tom, <br><br>
indeed, my condition is satisfied. <br><br>
Regards, <br><br>
__Mario <br><br>
<br><br>
From: "Barkley, Erik J (US
3970)" <erik.j.barkley@jpl.nasa.gov> <br>
To:
"Mario.Merri@esa.int" <Mario.Merri@esa.int> <br>
Cc:
"Colin.Haddow@esa.int" <Colin.Haddow@esa.int>,
"Secretariat@mailman.ccsds.org"
<Secretariat@mailman.ccsds.org>, "CCSDS Secretariat
(thomas.gannett@tgannett.net)" <thomas.gannett@tgannett.net>
<br>
Date: 17/07/2019 19:04 <br>
Subject: RE: [EXTERNAL] Re:
MOIMS AD Condition re CESG-P-2019-06-005 <br>
<div align="center"><br>
</div>
<br><br>
Hello Mario,<br><br>
<br><br>
The revised wording for the note is fine with me. May I
suggest a quick note to Tom indicating that the condition is satisfied?
<br><br>
<br><br>
Thank you,<br><br>
-Erik<br><br>
<br><br>
<b>From:</b> Mario.Merri@esa.int <Mario.Merri@esa.int> <br>
<b>Sent:</b> Wednesday, July 17, 2019 08:02<br>
<b>To:</b> Barkley, Erik J (US 3970)
<erik.j.barkley@jpl.nasa.gov><br>
<b>Cc:</b> Colin.Haddow@esa.int; Secretariat@mailman.ccsds.org; CCSDS
Secretariat (thomas.gannett@tgannett.net)
<thomas.gannett@tgannett.net><br>
<b>Subject:</b> [EXTERNAL] Re: MOIMS AD Condition re
CESG-P-2019-06-005<br><br>
<br><br>
Hi Erik <br><br>
I discussed the matter with Colin and we agreed with a formulation of the
note along these lines: "NOTE -- this standard does not impose any
requirement on persistence of identifiers. Should it be required, this
shall be specified in the document that adopts the Abstract Event
Definition." <br><br>
I hope this is fine with you. <br><br>
Regards, <br><br>
__Mario <br><br>
<br><br>
From: "Barkley, Erik J (US
3970)"
<<a href="mailto:erik.j.barkley@jpl.nasa.gov">
erik.j.barkley@jpl.nasa.gov</a>> <br>
To:
"'Mario.Merri@esa.int'"
<<a href="mailto:Mario.Merri@esa.int">Mario.Merri@esa.int</a>>
<br>
Cc:
"<a href="mailto:Colin.Haddow@esa.int">Colin.Haddow@esa.int</a>
"
<<a href="mailto:Colin.Haddow@esa.int">Colin.Haddow@esa.int</a>>,
"CCSDS Secretariat
(<a href="mailto:thomas.gannett@tgannett.net">
thomas.gannett@tgannett.net</a>)"
<<a href="mailto:thomas.gannett@tgannett.net">
thomas.gannett@tgannett.net</a>>,
"<a href="mailto:Secretariat@mailman.ccsds.org">
Secretariat@mailman.ccsds.org</a>"
<<a href="mailto:Secretariat@mailman.ccsds.org">
Secretariat@mailman.ccsds.org</a>> <br>
Date: 17/07/2019 02:02 <br>
Subject: MOIMS AD Condition re
CESG-P-2019-06-005 <br>
<div align="center"><br>
</div>
<br><br>
<br>
Dear Mario,<br><br>
The CSSM WG has taken a look at the condition of you have stated re poll
CESG-P-2019-06-005, Abstract Event Definition (Red Book, Issue 1) for
CCSDS Agency review. Please see below for the consensus as the
response to the condition. Your timely response as to resolution of
the condition will be appreciated.<br><br>
Best regards,<br>
-Erik<br><br>
--CSSM WG Response--<br>
CCSDS 902.13-R-1, is not a service specification. It is a data
format specification. As a data format, 902.13 has no
"understanding" of services that that employ the data format
and therefore cannot and should not impose behavior requirements,
especially with regard to retaining globally unique identifiers, etc.
Service specifications that choose to adopt the data format are
completely at liberty to state behavioral requirements as needed to
specify the service. The WG further agreed that in fact the
existing note can be stated more correctly. The revised note will
now read "NOTE -- this standard does not impose any requirements on
persistence of identifiers."<br><br>
<br>
-----Original Message-----<br>
From: CCSDS Secretariat
<<a href="mailto:thomas.gannett@tgannett.net">
thomas.gannett@tgannett.net</a>> <br>
Sent: Monday, July 15, 2019 10:19<br>
To: <a href="mailto:Colin.Haddow@esa.int">Colin.Haddow@esa.int</a>;
Barkley, Erik J (3970)
<<a href="mailto:erik.j.barkley@jpl.nasa.gov">
erik.j.barkley@jpl.nasa.gov</a>><br>
Cc: <a href="mailto:Mario.Merri@esa.int">Mario.Merri@esa.int</a>; Shames,
Peter M (312B)
<<a href="mailto:peter.m.shames@jpl.nasa.gov">
peter.m.shames@jpl.nasa.gov</a>><br>
Subject: [EXTERNAL] Fwd: Results of CESG Polls closing 12 July
2019<br><br>
Colin, Erik:<br><br>
The CESG poll to approve release of CCSDS 902.13-R-1, Abstract Event
Definition (Red Book, Issue 1) for CCSDS Agency review concluded with
conditions. Please negotiate disposition of the conditions directly with
the AD(s) who voted to approve with conditions and CC the Secretariat on
all related correspondence.<br><br>
Best regards,<br>
Tom<br><br>
<br><br>
>CESG E-Poll Identifier: CESG-P-2019-06-005 Approval to release
CCSDS <br>
>902.13-R-1, Abstract Event Definition (Red Book, Issue 1) for CCSDS
<br>
>Agency review Results of CESG poll beginning 30 June 2019 and ending
12 <br>
>July 2019:<br>
><br>
>
Abstain: 1 (16.67%) (Calzolari) Approve <br>
>Unconditionally: 3 (50%) (Barkley, Burleigh, Wilmot) Approve
with <br>
>Conditions: 2 (33.33%) (Merri, Shames) Disapprove with
Comment: 0 <br>
>(0%)<br>
>CONDITIONS/COMMENTS:<br>
><br>
> Mario Merri (Approve with Conditions):
The comment associated <br>
> with the Identifier field in Table 3-1 states: "NOTE If
the planning <br>
> information is regenerated, then the identifier for a particular
event <br>
> may change."<br>
><br>
>This is not consistent with the needs of a Planning System <br>
>(particularly a partially or fully automated one) that needs to <br>
>correlate the events from one event file to the next generation of
that <br>
>file covering the same or an overlapping period of time. Despite the
<br>
>standard does not preclude the same ID being used, it should instead
<br>
>recommend that the ID remains constant across multiple <br>
>generations/iterations of the same event.<br>
><br>
>If this were not the case, there would be an additional (possibly
<br>
>manual) process required to correlate successive instances of the
same <br>
>event exchanged between FDS and MPS which is far from
ideal.<br>
><br>
> Peter Shames (Approve with<br>
> Conditions): This document should be relevant to the MOIMS
Planning <br>
> group as well. Please ensure that they review and comment upon
it.<br>
><br>
>In Annex A2.2: There should be a defined AR Role to permit a person
to <br>
>update the Schema registry<br>
><br>
>In Annex A2.3: Plese reconsider whether updates to the <br>
>Epoch_Time_Systems registry should be a fre for all or managed, as in
<br>
>controlled by the WG or by the CSS Area in the absence of an active
WG.<br>
><br>
>In Annex B2: The Schemas all have White Book "w" <br>
>names, they should have Blue Book names. The XML schema
registry <br>
>"service_management_xml_schemas/902Schema/902x13" is
"Not found".<br>
><br>
> Scott Burleigh (Approve<br>
> Unconditionally): A comment, not a condition: <br>
> in 3.2.20.2, I think it would improve clarity to change from
"The <br>
> TimeParameter class shall contain one and only one instance of a
time <br>
> parameter specialized from the AbstractEventTime class (see
3.2.14)" <br>
> to "Each instance of the TimeParameter class shall contain one
and <br>
> only one instance of a time parameter specialized from the <br>
> AbstractEventTime class (see 3.2.14)."<br>
><br>
> Jonathan Wilmot (Approve<br>
> Unconditionally): Nothing in addition to other reviewer's
comments<br>
><br>
><br>
>Total Respondents: 6<br>
><br>
>All Areas responded to this question.<br>
><br>
><br>
><br>
>SECRETARIAT INTERPRETATION OF RESULTS: Approved with
Conditions<br>
>PROPOSED SECRETARIAT
ACTION:
Generate <br>
>CMC poll after conditions have been addressed<br>
><br>
>* * * * * * * * * * * * * * * * * * * * * * * *<br><br>
This message is intended only for the recipient(s) named above. It may
contain proprietary information and/or<br><br>
protected content. Any unauthorised disclosure, use, retention or
dissemination is prohibited. If you have received<br><br>
this e-mail in error, please notify the sender immediately. ESA applies
appropriate organisational measures to protect<br><br>
personal data, in case of data privacy queries, please contact the ESA
Data Protection Officer
(<a href="mailto:dpo@esa.int">dpo@esa.int</a>).<br><br>
<pre>This message is intended only for the recipient(s) named above. It
may contain proprietary information and/or
protected content. Any unauthorised disclosure, use, retention or
dissemination is prohibited. If you have received
this e-mail in error, please notify the sender immediately. ESA applies
appropriate organisational measures to protect
personal data, in case of data privacy queries, please contact the ESA
Data Protection Officer (dpo@esa.int).
</body>
</html>