[CESG] CESG-P-2020-12-005 Approval to publish CCSDS 921.1-B-2, Cross Support Transfer Service—Specification Framework ( Blue Book, Issue 2)

[CCSDS Secretariat]

Dear CESG Members,

Conditions for approval of CCSDS 921.1-B-2, Cross 
Support Transfer Service—Specification Framework 
(Blue Book, Issue 2) 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 publication.
-------------- next part --------------
From:	Shames, Peter M (US 312B) <peter.m.shames at jpl.nasa.gov>
Sent:	Monday, January 25, 2021 1:44 PM
To:	Wolfgang Hell; Barkley, Erik J (US 3970)
Cc:	Holger.Dreihahn at esa.int; Tom Gannett
Subject:	Re: [EXTERNAL] Fwd: Fwd: CESG-P-2020-12-005 Approval to publish CCSDS 
921.1-B-2, Cross Support Transfer Service—Specification Framework ( Blue 
Book, Issue 2)

Wolfgang and Erik,

I have read and carefully considered Wolfgang’s feedback.  And, as you know, I am really desirous that 
we get this SFW document, and FF-CSTS, which is based on it, out into the hands of developers.  That’s 
really something we have been awaiting for more than 10 years.

I was not aware of the “back-story” having to do with feedback from implementers during prototyping 
being one of the motivations of the expanded size of the document.  And I can understand how that 
might be the case.  The clearer we can make how this somewhat complicated framework is to work the 
better.  I do understand that the complexity is inherent in the complexity of the plethora of standards 
and options that this framework must accommodate.   

I also appreciate Wolfgang’s observation that the successful use of this document in the specification of 
MD-CSTS, TD-CSTS, FF-CSTS already has taken it out of the “doorstop” category and into the world of 
successful (if weighty) standards.  Applause is probably called for here.  ????

If the other issues have not raised concerns from others who have reviewed the document, including 
the Sec WG, then I will abide with them as they are.

I consider my PIDs to be satisfied and agree that the document should be published.

Best regards, Peter

From: Wolfgang Hell <wo_._he at t-online.de> 
Date: Saturday, January 23, 2021 at 1:53 AM 
To: Erik Barkley <erik.j.barkley at jpl.nasa.gov> 
Cc: Peter Shames <peter.m.shames at jpl.nasa.gov>, "Holger.Dreihahn at esa.int" 
<Holger.Dreihahn at esa.int> 
Subject: [EXTERNAL] Fwd: Fwd: CESG-P-2020-12-005 Approval to publish CCSDS 921.1-B-2, 
Cross Support Transfer Service—Specification Framework ( Blue Book, Issue 2)

Dear Erik,
For your information please find below Peter's comments / conditions with respect to the 
publication of the Blue-2 version of the CSTS Specification Framework (CCSDS 921.1) and my 
related response. For the time being, I did not receive a reply from Peter. Please let me know if 
you need any further information.
Best regards,
Wolfgang
 
 
-------- Weitergeleitete Nachricht -------- 
Betreff: 
Fwd: CESG-P-2020-12-005 Approval to publish CCSDS 921.1-B-2, Cross Support Transfer 
Service—Specification Framework ( Blue Book, Issue 2)
Datum: 
Thu, 21 Jan 2021 11:41:25 +0100
Von: 
Wolfgang Hell <wo_._he at t-online.de>
Antwort an: 
wo_._he at t-online.de
An: 
Shames, Peter M (312B) <peter.m.shames at jpl.nasa.gov>
Kopie (CC): 
Holger.Dreihahn at esa.int <Holger.Dreihahn at esa.int>, John Pietras <john.pietras at gst.com>

Peter,
Given that the Framework document shall serve as the basis for the development of CSTSes, it is 
inevitably quite comprehensive because it has to cover the needs of a fairly wide range of 
transfer services. If we had not included enough procedures for covering most if not all kind of 
procedures needed for the implementation of CSTSes, this would have defeated the purpose of 
the Framework. I can confirm that it has been a challenge to keep all this material consistent, but 
now that it's done, I can only see two cases where that document has to be digested in its 
entirety: (1) during the review, and (2) when an organization opts for implementing a CSTS API 
similar to the SLE API we have. 
The book is of course needed in conjunction with individual CSTSes, but each CSTS 
specification identifies the subset of the Framework procedures adopted by that service and one 
only needs to read that relevant subset of the Framework document. As opposed to the infamous 
910.11 document, the Framework has been used in practice in the specification of MD-CSTS, 
TD-CSTS, FF-CSTS und hopefully soon SC-CSTS. In my mind this clearly shows that the 
Framework document does not fall into the "door stop" category. It may also be noteworthy that 
the wordiness of the document is at least in part the result of the associated prototyping activities 
where the questions we got from the prototype implementers revealed that we still needed to add 
material to the original version which we have done and now all these ambiguities should be 
removed.
The repetitiveness you observe is intended. In particular the structure of the specification of each 
of the procedures is the same. Once one is familiar with that structure it is pretty easy to navigate 
to the place where one finds the information one may need. That was also helpful when certain 
changes had been agreed by the WG because it was obvious which subsections needed to be 
touched.    
Unfortunately I do not have the version of the Framework document that you have been looking 
at. However, John and I in close interchange with Tom did a final cleanup of annex M and 
therefore I would be very surprised if there were still editorial issues. Please be specific where 
you see editorial issues. Just in case: You may be mislead by the "strikethrough" in various 
ASN.1 types. These are *NOT* editorial issues, but as explained in the text the strikethrough - 
as an aide to the reader - is used to clearly indicate which parts of the ASN.1 type specifications 
are not relevant in the specific case being discussed.
As regards the security annex, I would be reluctant to change it at this point for the following 
reasons: (1) Security is not part of my core expertise and therefore I would not be the right 
person to implement such update. We should in any case involve the Security WG. (2) The 
present security annex has been discussed with and approved by the Security WG and is used in 
all the transfer service specifications (SLE and CSTS). Changing this annex in the Framework 
only might introduce inconsistencies among the CSTS documents. (3) Going to a detailed 
discussion of the security options will make the document even longer. Given all that I concur 
that probably the best way forward is to deal with this as part of the Agency review. Perhaps it is 
good enough to reference the relevant CCSDS 35x Recommendations where and as appropriate.
Please let me know if in the light of the above explanations you can agree that the publication 
can go ahead.
Thanks and best regards,
Wolfgang    
 
 
-------- Weitergeleitete Nachricht -------- 
Betreff: 
Re: CESG-P-2020-12-005 Approval to publish CCSDS 921.1-B-2, Cross Support Transfer 
Service—Specification Framework ( Blue Book, Issue 2)
Datum: 
Tue, 19 Jan 2021 17:49:12 -0500
Von: 
Thomas Gannett <thomas.gannett at tgannett.net>
An: 
Holger.Dreihahn at esa.int, wo_._he at t-online.de, john.pietras at gst.com
Kopie (CC): 
Peter.M.Shames at jpl.nasa.gov
 
 
Dear Document Rapporteur, 
 
The CESG poll to approve publication of CCSDS 921.1-B-2, Cross Support Transfer Service—Specification 
Framework (Blue Book, Issue 2) 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. 
 
CESG E-Poll Identifier:  CESG-P-2020-12-005 Approval to publish CCSDS 921.1-B-2, Cross Support 
Transfer Service—Specification Framework (Blue Book, Issue 2) 
Results of CESG poll beginning 18 December 2020 and ending 7 January 2021: 
 
                Abstain:  1 (16.67%) (Calzolari) 
Approve Unconditionally:  4 (66.67%) (Barkley, Merri, Burleigh, Wilmot) 
Approve with Conditions:  1 (16.67%) (Shames) 
Disapprove with Comment:  0 (0%)  
CONDITIONS/COMMENTS: 
 
[NOTE: The purpose of the poll was to approve publication of the document, not agency review.] 
 
    Peter Shames (Approve with Conditions):   This is a comprehensive (i.e. large) document that 
describes a framework that can support development of services for a wide range of comm standards 
from four CCSDS Area (SLS, SIS, CSS, and SEA).  As such, at 364 pages in length, I am somewhat 
concerned that it may fall into the "door stop" category, much like the infamous 910.11 document.  It 
has a lot of careful explanations, whch also render it somewhat wordy, and due to inclusion of specs, 
text, and ANS.1 it feels very repetitive.  I am not suggesting that we not send it out for review, but I am 
noting issues that may be a concern. 
 
I do have a condition before it goes out for review and that is that the editorial issues on pgs M-3 thru 
M-10 be fixed.  I will also note that some of the Security sections in H-2, having to do with Privacy and 
Integrity are not as strong as they might be.  
CSTS fits into the middle of the comm stack as a sort of terrestrial to space "gateway".  It has its own 
security aspects, but it also supports, without hinderance. all of the other CCSDS security mecahinisms, 
such as data encryption, SDLS, BPSec, etc.  This ought to be stated explicitly since they are features of 
this framework.  I am willing to allow this to be handled as a part of the Agency review processing. 
 
    Jonathan Wilmot (Approve Unconditionally):   I share Peter's concerns about length. It would have 
been better to split sections into separate books. Understood that it is too late now as this poll is for 
publication. 
 
Spelling-  RCF Return Chanel Frame (SLE)  should be Channel 
 
 
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 
 
* * * * * * * * * * * * * * * * * * * * * * * *
Thomas Gannett 
thomas.gannett at tgannett.net 
+1 443 472 0805