[CESG] CESG-P-2019-06-005 Approval to release CCSDS 902.13-R-1, Abstract Event Definition (Red Book, Issue 1) for CCSDS Agency review
CCSDS Secretariat
thomas.gannett at tgannett.net
Thu Jul 18 18:15:24 UTC 2019
Dear CESG Members,
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.
From: Shames, Peter M (US 312B) [mailto:peter.m.shames at jpl.nasa.gov]
Sent: Thursday, July 18, 2019 12:21 PM
To: Barkley, Erik J (US 3970)
Cc: Colin Haddow; Tom Gannett; CCSDS Secretariat
Subject: Re: SE AD Condtions re CESG-P-2019-06-005
Erik,
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.
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:
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.
a) Identify a need for a registry related to a new standard.
b) Discuss the proposed registry requirements
and design with the SANA Operator
(info at sanaregistry.org) and, if necessary, the
SANA Steering Group (SSG) (ssg at mailmain.ccsds.org).
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.
d) Evaluate how best to use or adapt existing
registries, where that appears to be feasible,
and discuss the approach with the affected organization.
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.
f) Document the registry policies, registration
rules, and Review Authority, and if necessary the Registration Authority.
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.
h) Work with the SANA Operator to document the
final registry design prior to Red Book agency review.
i) Work with the SANA Operator to promote the
registry from Candidate to Approved status prior to Blue Book publication.
j) Participate, as needed, in any registry
review or request for extensions after it has been published.
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.
Thanks, Peter
From: Erik Barkley <erik.j.barkley at jpl.nasa.gov>
Date: Wednesday, July 17, 2019 at 11:00 AM
To: Peter Shames <peter.m.shames at jpl.nasa.gov>
Cc: Colin Haddow <Colin.Haddow at esa.int>, Tom
Gannett <thomas.gannett at tgannett.net>, CCSDS
Secretariat <secretariat at mailman.ccsds.org>
Subject: RE: SE AD Condtions re CESG-P-2019-06-005
Peter,
Re PS-2 (2nd 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.
Thank you,
-Erik
From: Shames, Peter M (US 312B) <peter.m.shames at jpl.nasa.gov>
Sent: Tuesday, July 16, 2019 17:54
To: Barkley, Erik J (US 3970) <erik.j.barkley at jpl.nasa.gov>
Cc: Colin Haddow <Colin.Haddow at esa.int>; Tom
Gannett <thomas.gannett at tgannett.net>; CCSDS
Secretariat <secretariat at mailman.ccsds.org>
Subject: Re: SE AD Condtions re CESG-P-2019-06-005
Hi Erik,
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.
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.
And BTW, this is NOT a RID for agency review. It is a CESG and RMP matter.
Peter
From: Erik Barkley
<<mailto:erik.j.barkley at jpl.nasa.gov>erik.j.barkley at jpl.nasa.gov>
Date: Tuesday, July 16, 2019 at 5:19 PM
To: Peter Shames
<<mailto:peter.m.shames at jpl.nasa.gov>peter.m.shames at jpl.nasa.gov>
Cc: Colin Haddow
<<mailto:Colin.Haddow at esa.int>Colin.Haddow at esa.int>,
Tom Gannett
<<mailto:thomas.gannett at tgannett.net>thomas.gannett at tgannett.net>,
CCSDS Secretariat
<<mailto:Secretariat at mailman.ccsds.org>Secretariat at mailman.ccsds.org>
Subject: SE AD Condtions re CESG-P-2019-06-005
Dear Peter,
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.
Best regards,
-Erik
--CSSM WG Responses--
PS-1
This document should be relevant to the MOIMS
Planning group as well. Please ensure that they review and comment upon it.
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.
PS-2
In Annex A2.2: There should be a defined AR Role
to permit a person to update the Schema registry
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.
PS-3
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.
1) "Fre for all" taken to mean "free for all".
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.
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.
PS-4
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".
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.
-----Original Message-----
From: CCSDS Secretariat
<<mailto:thomas.gannett at tgannett.net>thomas.gannett at tgannett.net>
Sent: Monday, July 15, 2019 10:19
To:
<mailto:Colin.Haddow at esa.int>Colin.Haddow at esa.int;
Barkley, Erik J (3970)
<<mailto:erik.j.barkley at jpl.nasa.gov>erik.j.barkley at jpl.nasa.gov>
Cc:
<mailto:Mario.Merri at esa.int>Mario.Merri at esa.int;
Shames, Peter M (312B)
<<mailto:peter.m.shames at jpl.nasa.gov>peter.m.shames at jpl.nasa.gov>
Subject: [EXTERNAL] Fwd: Results of CESG Polls closing 12 July 2019
Colin, Erik:
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.
Best regards,
Tom
>CESG E-Poll Identifier: CESG-P-2019-06-005 Approval to release CCSDS
>902.13-R-1, Abstract Event Definition (Red Book, Issue 1) for CCSDS
>Agency review Results of CESG poll beginning 30 June 2019 and ending 12
>July 2019:
>
> Abstain: 1 (16.67%) (Calzolari) Approve
>Unconditionally: 3 (50%) (Barkley, Burleigh, Wilmot) Approve with
>Conditions: 2 (33.33%) (Merri, Shames) Disapprove with Comment: 0
>(0%)
>CONDITIONS/COMMENTS:
>
> Mario Merri (Approve with Conditions): The comment associated
> with the Identifier field in Table 3-1 states: "NOTE If the planning
> information is regenerated, then the identifier for a particular event
> may change."
>
>This is not consistent with the needs of a Planning System
>(particularly a partially or fully automated one) that needs to
>correlate the events from one event file to the next generation of that
>file covering the same or an overlapping period of time. Despite the
>standard does not preclude the same ID being used, it should instead
>recommend that the ID remains constant across multiple
>generations/iterations of the same event.
>
>If this were not the case, there would be an additional (possibly
>manual) process required to correlate successive instances of the same
>event exchanged between FDS and MPS which is far from ideal.
>
> Peter Shames (Approve with
> Conditions): This document should be relevant to the MOIMS Planning
> group as well. Please ensure that they review and comment upon it.
>
>In Annex A2.2: There should be a defined AR Role to permit a person to
>update the Schema registry
>
>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.
>
>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".
>
> Scott Burleigh (Approve
> Unconditionally): A comment, not a condition:
> in 3.2.20.2, I think it would improve clarity to change from "The
> TimeParameter class shall contain one and only one instance of a time
> parameter specialized from the AbstractEventTime class (see 3.2.14)"
> to "Each instance of the TimeParameter class shall contain one and
> only one instance of a time parameter specialized from the
> AbstractEventTime class (see 3.2.14)."
>
> Jonathan Wilmot (Approve
> Unconditionally): Nothing in addition to other reviewer's comments
>
>
>Total Respondents: 6
>
>All Areas responded to this question.
>
>
>
>SECRETARIAT INTERPRETATION OF RESULTS: Approved with Conditions
>PROPOSED SECRETARIAT ACTION: Generate
>CMC poll after conditions have been addressed
>
>* * * * * * * * * * * * * * * * * * * * * * * *
From: Mario.Merri at esa.int [mailto:Mario.Merri at esa.int]
Sent: Thursday, July 18, 2019 4:28 AM
To: CCSDS Secretariat (thomas.gannett at tgannett.net)
Cc: Colin.Haddow at esa.int;
Secretariat at mailman.ccsds.org; Barkley, Erik J
(US 3970); brigitte.behal at cnes.fr
Subject: RE: [EXTERNAL] Re: MOIMS AD Condition re CESG-P-2019-06-005
Hi Tom,
indeed, my condition is satisfied.
Regards,
__Mario
From: "Barkley, Erik J (US 3970)" <erik.j.barkley at jpl.nasa.gov>
To: "Mario.Merri at esa.int" <Mario.Merri at esa.int>
Cc: "Colin.Haddow at esa.int"
<Colin.Haddow at esa.int>,
"Secretariat at mailman.ccsds.org"
<Secretariat at mailman.ccsds.org>, "CCSDS
Secretariat (thomas.gannett at tgannett.net)" <thomas.gannett at tgannett.net>
Date: 17/07/2019 19:04
Subject: RE: [EXTERNAL] Re: MOIMS AD Condition re CESG-P-2019-06-005
Hello Mario,
The revised wording for the note is fine with
me. May I suggest a quick note to Tom
indicating that the condition is satisfied?
Thank you,
-Erik
From: Mario.Merri at esa.int <Mario.Merri at esa.int>
Sent: Wednesday, July 17, 2019 08:02
To: Barkley, Erik J (US 3970) <erik.j.barkley at jpl.nasa.gov>
Cc: Colin.Haddow at esa.int;
Secretariat at mailman.ccsds.org; CCSDS Secretariat
(thomas.gannett at tgannett.net) <thomas.gannett at tgannett.net>
Subject: [EXTERNAL] Re: MOIMS AD Condition re CESG-P-2019-06-005
Hi Erik
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."
I hope this is fine with you.
Regards,
__Mario
From: "Barkley, Erik J (US 3970)"
<<mailto:erik.j.barkley at jpl.nasa.gov>erik.j.barkley at jpl.nasa.gov>
To: "'Mario.Merri at esa.int'"
<<mailto:Mario.Merri at esa.int>Mario.Merri at esa.int>
Cc:
"<mailto:Colin.Haddow at esa.int>Colin.Haddow at esa.int"
<<mailto:Colin.Haddow at esa.int>Colin.Haddow at esa.int>,
"CCSDS Secretariat
(<mailto:thomas.gannett at tgannett.net>thomas.gannett at tgannett.net)"
<<mailto:thomas.gannett at tgannett.net>thomas.gannett at tgannett.net>,
"<mailto:Secretariat at mailman.ccsds.org>Secretariat at mailman.ccsds.org"
<<mailto:Secretariat at mailman.ccsds.org>Secretariat at mailman.ccsds.org>
Date: 17/07/2019 02:02
Subject: MOIMS AD Condition re CESG-P-2019-06-005
Dear Mario,
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.
Best regards,
-Erik
--CSSM WG Response--
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."
-----Original Message-----
From: CCSDS Secretariat
<<mailto:thomas.gannett at tgannett.net>thomas.gannett at tgannett.net>
Sent: Monday, July 15, 2019 10:19
To:
<mailto:Colin.Haddow at esa.int>Colin.Haddow at esa.int;
Barkley, Erik J (3970)
<<mailto:erik.j.barkley at jpl.nasa.gov>erik.j.barkley at jpl.nasa.gov>
Cc:
<mailto:Mario.Merri at esa.int>Mario.Merri at esa.int;
Shames, Peter M (312B)
<<mailto:peter.m.shames at jpl.nasa.gov>peter.m.shames at jpl.nasa.gov>
Subject: [EXTERNAL] Fwd: Results of CESG Polls closing 12 July 2019
Colin, Erik:
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.
Best regards,
Tom
>CESG E-Poll Identifier: CESG-P-2019-06-005 Approval to release CCSDS
>902.13-R-1, Abstract Event Definition (Red Book, Issue 1) for CCSDS
>Agency review Results of CESG poll beginning 30 June 2019 and ending 12
>July 2019:
>
> Abstain: 1 (16.67%) (Calzolari) Approve
>Unconditionally: 3 (50%) (Barkley, Burleigh, Wilmot) Approve with
>Conditions: 2 (33.33%) (Merri, Shames) Disapprove with Comment: 0
>(0%)
>CONDITIONS/COMMENTS:
>
> Mario Merri (Approve with Conditions): The comment associated
> with the Identifier field in Table 3-1 states: "NOTE If the planning
> information is regenerated, then the identifier for a particular event
> may change."
>
>This is not consistent with the needs of a Planning System
>(particularly a partially or fully automated one) that needs to
>correlate the events from one event file to the next generation of that
>file covering the same or an overlapping period of time. Despite the
>standard does not preclude the same ID being used, it should instead
>recommend that the ID remains constant across multiple
>generations/iterations of the same event.
>
>If this were not the case, there would be an additional (possibly
>manual) process required to correlate successive instances of the same
>event exchanged between FDS and MPS which is far from ideal.
>
> Peter Shames (Approve with
> Conditions): This document should be relevant to the MOIMS Planning
> group as well. Please ensure that they review and comment upon it.
>
>In Annex A2.2: There should be a defined AR Role to permit a person to
>update the Schema registry
>
>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.
>
>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".
>
> Scott Burleigh (Approve
> Unconditionally): A comment, not a condition:
> in 3.2.20.2, I think it would improve clarity to change from "The
> TimeParameter class shall contain one and only one instance of a time
> parameter specialized from the AbstractEventTime class (see 3.2.14)"
> to "Each instance of the TimeParameter class shall contain one and
> only one instance of a time parameter specialized from the
> AbstractEventTime class (see 3.2.14)."
>
> Jonathan Wilmot (Approve
> Unconditionally): Nothing in addition to other reviewer's comments
>
>
>Total Respondents: 6
>
>All Areas responded to this question.
>
>
>
>SECRETARIAT INTERPRETATION OF RESULTS: Approved with Conditions
>PROPOSED SECRETARIAT ACTION: Generate
>CMC poll after conditions have been addressed
>
>* * * * * * * * * * * * * * * * * * * * * * * *
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
(<mailto:dpo at esa.int>dpo at esa.int).
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 at esa.int).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/cesg/attachments/20190718/05cd25e8/attachment-0001.html>
More information about the CESG
mailing list