[SLS] For Info & Reaction: [Cesg-all] Proposed guidelines for inclusion of documents in SCCS-ARD / Add refresh

Fri Nov 20 08:31:24 UTC 2020

Dear All,
        please consider the attached note specially with respect to items 
relevant to your working group.

The version in force of the document under review is available at 
file:///C:/Users/gcalzola/AppData/Local/Temp/901x1m1.pdf
You find in section 1.7 REFERENCES many documents produced/maintained in 
the SLS Area as e.g. 8,9, and 10 & 14 & 31, 32, 33, and 34 & 36 & 42, 43, 
44, 45, and 46 & 56 and 57
Other SLS documents are mentioned in ANNEX D INFORMATIVE REFERENCES as 
e.g.  D3, D8, D22

Thank you for coordinating your comments with Gilles and me.

Best regards and have a nice week end.

Gian Paolo

----- Forwarded by Gian Paolo Calzolari/esoc/ESA on 20-11-20 09:16 -----

From:   "Shames, Peter M\(US 312B\) via CESG-All" 
<cesg-all at mailman.ccsds.org>
To:     "CCSDS Engineering Steering Group - CESG All" 
<cesg-all at mailman.ccsds.org>
Date:   20-11-20 01:57
Subject:        [Cesg-all] Proposed guidelines for inclusion of documents 
in SCCS-ARD / Add refresh
Sent by:        "CESG-All" <cesg-all-bounces at mailman.ccsds.org>

Dear CESG – All members,

During the CESG meetings this week I mentioned that we want to include all 
of the most up-to-date standards in the Space Communication Cross Support 
Architecture (SCCS-ARD) update.  This is CCSDS 901.1-M-1.  The title says 
“cross support” and I guess that confused some of the CESG members.  It 
also says “space communication” and the current version covers fifty-seven 
(57) CCSDS and related standards, and another twenty-six (26) are in the 
non-normative set in Annex D.  This one “omnibus” specification covers all 
of four CCSDS areas: SLS, SIS, CSS, and SEA.  A separate document, the 
Application and Support Layer Architecture (ASL), CCSDS 371.0-G-1, that 
was just approved covers the other two areas (MOIMS & SOIS).

There’s an important point here.  Many of those standards referenced in 
the non-normative Annex D, from the 2015 edition, were marked in the text 
as [Future] at the time the spec was published.  Some, like TD-CSTS and 
SDLS, were not yet completed, even though they were already well on their 
way.  They are now published and no longer will be marked [Future]. 
Others, like DTN Network Management, are still “on their way”.  Still 
others, like USLP, were not even on the drawing boards at that time, but 
will now be included, along with optical comm and other standards.    And 
others, like coding for AOS forward links, are still hanging fire and only 
TC forward links are specified.

The point of this note is to do two things:

1.      Seek your support in ensuring that we have as complete a list of 
revised and “soon to be published” standards as is possible.
2.      Lay  out the  guidelines we used for inclusion of [Future] 
standards and seek your concurrence and support for these updates.

For item 1  we have this list which we showed in the CESG meeting:

Update existing viewpoints with new/modified standards 
SLS (USLP, coding, modulation, other changes to SPP)
SIS (DTN, routing, management, security, [Future] CFDP)
CSS (new CSTS & SM standards)
SEA (security, key management & D-DOR, SANA & RMP)
Incorporate new / missing work items 
Optical comm
Audio and video for human exploration
RFID
Time management

If you know of other standards in your WGs that are missing from this list 
please let me know and we will figure out how to incorporate them.  We 
want to ensure that all standards that are published, or that will be 
published between now and the time when this update is ready to be 
published, optimistically a year from now, will be included. 

For item 2 we realize that some of the standards you are working on may 
not be ready in this timeframe, or they may still be in development, but 
well understood.  In the currently published version we included this 
description of how we were using this [Future] designation:
Future CCSDS requirements (e.g., service interfaces, protocols, or data 
formats) that are planned, but still under development, are included for 
completeness so that the directions of CCSDS are clear; these are marked 
‘[Future]’ to avoid ambiguity. Any requirements that are considered 
optional are marked ‘[Opt]’. The [Opt] requirements are things like 
security, which may or may not be implemented by any given system. All 
other core standards, those that are expected to be used by the bulk of 
missions and implemented by the bulk of service providers, are defined as 
mandatory, with ‘shall’ rather than ‘should’ language. Any specific system 
deployment may treat these as ‘shall’ if they are required for that use. 
Any requirements marked ‘[Future]’ should not be relied upon in the design 
of current real SCCS systems. This Recommended Practice will be updated 
periodically. When updates of this document are published, any 
requirements now marked ‘[Future]’ whose conditions are met will be 
reviewed and evaluated for inclusion as full requirements. Many of these 
future specifications are completely applicable to either ABA or SSI 
deployments. 
 The guideline that we used for these “under development” standards was 
this:
1.      They should be Draft Red Books or White Books that are already 
quite mature and likely to be published in a year of two.
2.      They may be White Paper concepts that are relatively mature and 
not in flux, and can be expected in the five year timeframe.
3.      They may be position papers from other organizations, such as 
IOAG, where there is support for initiating and (nominally) completing the 
work within the 5 year lifetime of the revised standard.

This is a statement of the guidelines that we used in the current version 
of the document.  Leaving aside Green Book materials from that Informative 
References Annex, of the sixteen standards listed as [Future] in 2015 nine 
have already been published, four are on their way to be published in one 
form or another (one of these, the SM standard, is actually going to be 
five or six separate but related new  standards), and three have been 
deferred  for lack of resources (or interest).  We would like to strive 
for at least the same success rate going forward, so please keep that in 
mind. 

We want this document to  provide valuable guidance to our current and 
future users.

Accordingly, please provide your list of [Future] candidates, and even a 
list of [Proposed] docs, that you believe are viable even if they do not 
meet this maturity test.  We would like to have these by the end of 
December.

If you are still  puzzled as to why we need this standard, as opposed to 
just the list we now have on the CCSDS website, think of it this way.

·         The list on the CCSDS website is like a box of plumbing parts: 
there are water source pipes, and joints, and T-fittings, and faucets, and 
drain pipes, and they are all in a box. But that is what they are, a box 
of parts.  You figure it out.

·         This CCSDS SCCS architecture document is like a set of plumbing 
diagrams: if you want to install a kitchen sink do it like this, here is 
the diagram showing the right parts and how they fit together.    Oh yeah, 
and that bathroom shower, that is a different set of parts, and a 
different diagram.  And there are pictures provided both of how it is 
supposed to look and work, and how to assemble it.

Thanks, Peter
 _______________________________________________
CESG-All mailing list
CESG-All at mailman.ccsds.org
https://mailman.ccsds.org/cgi-bin/mailman/listinfo/cesg-all

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/sls/attachments/20201120/9bafe130/attachment-0001.htm>