[CESG] FW: Shall FF-CSTS implement the FOP? / Technical corrigendum option / Just one warning

Wed Apr 5 17:21:59 UTC 2017

Peter,
        note that discussing in the CESG was your proposal not mine......
For your list I also have a correction for  CCSDS 740.0-G-1 Mars Mission 
Protocol Profiles--Purpose and Rationale. Green Book. Issue 1. July 2008.
This book is not under SLS and according to Tom is under  SIS, produced by 
the Mars 2015 Interoperability Working Group.

Moreover I think that Green Books should be taken out from that list (it 
may be to a separate one) are they are not specifications.

Regards

Gippo

From:   "Shames, Peter M (312B)" <peter.m.shames at jpl.nasa.gov>
To:     "CCSDS Engineering Steering Group - CESG Exec" 
<cesg at mailman.ccsds.org>
Date:   05/04/2017 18:29
Subject:        [CESG] FW: Shall FF-CSTS implement the FOP? / Technical 
corrigendum option / Just one warning
Sent by:        "CESG" <cesg-bounces at mailman.ccsds.org>

Dear CESG colleagues,

I am forwarding this to the whole CESG so they are aware of the issues. 
Apologies to those who have already seen it.

Cheers, Peter

From: Peter Shames <peter.m.shames at jpl.nasa.gov>
Date: Wednesday, April 5, 2017 at 8:35 AM
To: Gian Paolo Calzolari <Gian.Paolo.Calzolari at esa.int>
Cc: Erik Barkley <erik.j.barkley at jpl.nasa.gov>, Keith Scott 
<kscott at mitre.org>, "Margherita.di.Giulio at esa.int" 
<Margherita.di.Giulio at esa.int>, Tom Gannett <thomas.gannett at tgannett.net>, 
Tim Pham <timothy.t.pham at jpl.nasa.gov>, Wolfgang Hell 
<wo_._he at t-online.de>, Nestor Peccia <Nestor.Peccia at esa.int>
Subject: Re: Shall FF-CSTS implement the FOP? / Technical corrigendum 
option / Just one warning

Hi Gippo,

The short answer to your question is that it is "in the queue", waiting 
for the resources to tackle this update and others, driven by changes such 
as USLP and optical.  We probably could use some sort of "queue" or 
"parking lot" to track these as they show up.

The longer answer is that I am fine with discussing this topic in the 
CESG.  I think it is important for us to keep all of our specs up to date, 
but also to keep them as stable as is practical.  This is an interesting 
balancing act since some of the new standards really need to evolve beyond 
where we started with TC, TM, and SPP, and that may involve accepting 
backward changes as well so as to not "hobble" the ones that are moving 
forward.  That said, when we do have this discussion I think we need to 
consider all of the "omnibus" type specs that we have, since they exist in 
more than one area and WG.  And some of the new specs have introduced 
features that should be retrofitted to older ones in order to keep the 
whole set aligned. 

Those that I identified in a quick search (probably not a complete list) 
are these:

1.      CSS SCCS-ADD & ARD (of course, the COP issue and new standards 
like USLP & optical)
2.      CSS Cross Support Concept ? Part 1: Space Link Extension (CSTS and 
deprecated specs)
3.      CSS Cross Support Reference Model?Part 1: Space Link Extension 
Services. (CSTS and deprecated specs)
4.      SLS OSCP (coding changes, USLP, & optical comm)
5.      SLS Coding Green Book
6.      SLS Telecommand Summary of Concept and Rationale (integrate AOS 
and USLP forward)
7.      SLS TM Channel Coding profiles (AOS & USLP, optical)
8.      SLS Mars Mission Protocol Profiles--Purpose and Rationale
9.      SIS SSI Architecture
10.  MOIMS Mission Operations Services Concept. Green Book
11.  MOIMS Mission Operations Reference Model
12.  MOIMS Navigation Data?Definitions and Conventions
13.  MOIMS Standard Formatted Data Units ? Control Authority Data 
Structures (align with RMP)
14.  MOIMS OAIS & PAIS (align with RMP)
15.  SOIS Spacecraft Onboard Interface Services. Green Book (deal with the 
slew of silver standards)
16.  Unique Identification of CCSDS Objects and Services (I forgot this 
even existed, RMP alignment)
17.  And the MOIMS and SOIS Application & Support Layer architecture that 
is now in work ?

Seems pretty obvious that there is a slew of CCSDS docs of various flavors 
that need to be brought up to date to ensure alignment with our evolving 
set of standards.  There is also a significant cost involved in doing 
this, along with the "churn" that will be involved in what has been a 
stable, if now somewhat out of date and inconsistent, full set of 
standards.

As I said before, I don't have a good answer re how we plan to keep all of 
this up to date and also develop new standards, but it is a topic that 
should be discussed.  And it is clearly broader than just a tweak to COP 
in the SCCS ADD.

Thanks, Peter

From: Gian Paolo Calzolari <Gian.Paolo.Calzolari at esa.int>
Date: Wednesday, April 5, 2017 at 6:18 AM
To: Peter Shames <peter.m.shames at jpl.nasa.gov>
Cc: Erik Barkley <erik.j.barkley at jpl.nasa.gov>, Keith Scott 
<kscott at mitre.org>, "Margherita.di.Giulio at esa.int" 
<Margherita.di.Giulio at esa.int>, Tom Gannett <thomas.gannett at tgannett.net>, 
Tim Pham <timothy.t.pham at jpl.nasa.gov>, Wolfgang Hell 
<wo_._he at t-online.de>, Nestor Peccia <Nestor.Peccia at esa.int>
Subject: Re: Shall FF-CSTS implement the FOP? / Technical corrigendum 
option / Just one warning

Peter, 
        where do we stand with this update to  <CCSDS 901.1-M-1 Space 
Communications Cross Support--Architecture Requirements Document. Magenta 
Book. Issue 1. May 2015>? 
I admit that I got somehow lost as at a certain point I had the impression 
that the Technical corrigendum option was considered suitable but I 
haven't seen further activity on this. 

Nestor, 
        as Peter states that "CESG needs to come to agreement on how these 
sorts of "omnibus" specs are to be updated" should this become an agenda 
item for CESG Meeting/Discussion? 

Regards 

Gian Paolo 

From:        "Shames, Peter M (312B)" <peter.m.shames at jpl.nasa.gov> 
To:        "Barkley, Erik J (3970)" <erik.j.barkley at jpl.nasa.gov>, 
"Gian.Paolo.Calzolari at esa.int" <Gian.Paolo.Calzolari at esa.int> 
Cc:        "Keith Scott" <kscott at mitre.org>, 
"Margherita.di.Giulio at esa.int" <Margherita.di.Giulio at esa.int>, "Tom 
Gannett" <thomas.gannett at tgannett.net>, "Pham, Timothy T (3300)" 
<timothy.t.pham at jpl.nasa.gov>, "wo_._he at t-online.de" <wo_._he at t-online.de> 

Date:        16/11/2016 20:49 
Subject:        Re: Shall FF-CSTS implement the FOP? / Technical 
corrigendum option / Just one warning 

Yes. 

But more than that, the CESG needs to come to agreement on how these sorts 
of "omnibus" specs are to be updated.  We are also in the midst of, at CMC 
request, generating another one for the other two CCSDS areas, SOIS and 
MOIMS. 

Peter 

From: Erik Barkley <erik.j.barkley at jpl.nasa.gov>
Date: Wednesday, November 16, 2016 at 11:47 AM
To: Peter Shames <peter.m.shames at jpl.nasa.gov>, Gian Paolo Calzolari 
<Gian.Paolo.Calzolari at esa.int>
Cc: Keith Scott <kscott at mitre.org>, "Margherita.di.Giulio at esa.int" 
<Margherita.di.Giulio at esa.int>, Tom Gannett <thomas.gannett at tgannett.net>, 
Tim Pham <timothy.t.pham at jpl.nasa.gov>, Wolfgang Hell 
<wo_._he at t-online.de>
Subject: RE: Shall FF-CSTS implement the FOP? / Technical corrigendum 
option / Just one warning 

I think we have identified about as good a plan as we can for the moment. 
I think it may be a CESG "problem" to the extent that CESG should, 
collectively, have, and work towards maintaining, a good idea of the 
architecture against which the CCSDS standards are being developed.   

Best regards, 
-Erik 
From: Shames, Peter M (312B) 
Sent: Wednesday, November 16, 2016 10:03 AM
To: Gian.Paolo.Calzolari at esa.int; Barkley, Erik J (3970) 
<erik.j.barkley at jpl.nasa.gov>
Cc: Keith Scott <kscott at mitre.org>; Margherita.di.Giulio at esa.int; Tom 
Gannett <thomas.gannett at tgannett.net>; Pham, Timothy T (3300) 
<timothy.t.pham at jpl.nasa.gov>; wo_._he at t-online.de
Subject: Re: Shall FF-CSTS implement the FOP? / Technical corrigendum 
option / Just one warning 

I think Gippo makes a good point about the intended scope of TC's.  While 
I disagree that the document is "unstable by nature" I do agree that it is 
fundamentally a different kind of document than any others that we have 
published.  Most standards address one layer.  Some, like utilization 
profiles, may address 2 or three layers.  This one addresses 90 separate 
standards, services, seven layers of protocol stacks, component features, 
and end-to-end deployments. 

I think we need to find a way to deal with the evolution of the four CCSDS 
areas of work that are covered by this and do it in a way that is 
effective and that also makes this document effective and credible.  This 
is not an issue we have had to face before and we did not, to be honest, 
think it all through ahead of time. 

I do not have a good answer to offer at this moment, but I do think that 
gathering the edits, in a well documented form, agreeing on them, and 
queuing them up for "batch" is one way to achieve a level of stability. If 
that results in needing to periodically invoke the usual, more formal, 
Pink Sheet process then that may be the best way forward. 

Any other ideas on how to best handle the general case presented by this 
document?  Maybe this is a CESG topic? 

Thanks, Peter 

From: Gian Paolo Calzolari <Gian.Paolo.Calzolari at esa.int>
Date: Wednesday, November 16, 2016 at 2:16 AM
To: Erik Barkley <erik.j.barkley at jpl.nasa.gov>
Cc: Keith Scott <kscott at mitre.org>, "Margherita.di.Giulio at esa.int" <
Margherita.di.Giulio at esa.int>, Peter Shames <peter.m.shames at jpl.nasa.gov>, 
Tom Gannett <thomas.gannett at tgannett.net>, Tim Pham <
timothy.t.pham at jpl.nasa.gov>, Wolfgang Hell <wo_._he at t-online.de>
Subject: RE: Shall FF-CSTS implement the FOP? / Technical corrigendum 
option / Just one warning 

Dear All, 
       I have just one warning. 
IMO a Technical Corrigendum is appropriate for a limited number of 
corrections (and indeed the F-Frame case - 2 clauses and 1 note - falls 
into this classification). 
If we expect to collect many items together we may exit from the Technical 
Corrigendum case. 
If this would happen we would realize that there is a need for a formal 
Pink Review and also the easy correction will be queued up and delayed. 

I can also agree that making several corrections may give the impression 
that a document is unstable but - on the other hand - this document is 
somehow "unstable by nature" with so many references to future 
needs/solutions. 

Just my cent......................... 

Regards 

Gian Paolo 
this message and any attachments are intended for the use of the addressee 
or addressees only. 
The unauthorised disclosure, use, dissemination or copying (either in 
whole or in part) of its 
content is not permitted. 
If you received this message in error, please notify the sender and delete 
it from your system. 
Emails can be altered and their integrity cannot be guaranteed by the 
sender. 

Please consider the environment before printing this email. 
This message and any attachments are intended for the use of the addressee 
or addressees only.
The unauthorised disclosure, use, dissemination or copying (either in 
whole or in part) of its
content is not permitted.
If you received this message in error, please notify the sender and delete 
it from your system.
Emails can be altered and their integrity cannot be guaranteed by the 
sender.

Please consider the environment before printing this email.
 _______________________________________________
CESG mailing list
CESG at mailman.ccsds.org
https://mailman.ccsds.org/cgi-bin/mailman/listinfo/cesg

This message and any attachments are intended for the use of the addressee or addressees only.
The unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its
content is not permitted.
If you received this message in error, please notify the sender and delete it from your system.
Emails can be altered and their integrity cannot be guaranteed by the sender.

Please consider the environment before printing this email.

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