<html>
<body>
Dear CESG Members,<br><br>
Conditions for approval CCSDS 921.1-B-1, Cross Support Transfer
Service—Specification Framework (Blue Book, Issue 1) have been addressed
to the satisfaction of the ADs who voted to approve with conditions. The
Secretariat will now proceed with CMC polling.<br><br>
<br>
<blockquote type=cite class=cite cite="">CESG E-Poll Identifier:
CESG-P-2016-11-001 Approval to publish CCSDS 921.1-B-1, Cross Support
Transfer Service—Specification Framework (Blue Book, Issue 1)<br>
Results of CESG poll beginning 30 November 2016 and ending 14 December
2016:<br><br>
Abstain: 1 (16.67%) (Calzolari)<br>
Approve Unconditionally: 2 (33.33%) (Barkley, Shames)<br>
Approve with Conditions: 3 (50%) (Merri, Behal, Scott)<br>
Disapprove with Comment: 0 (0%) <br><br>
CONDITIONS/COMMENTS:<br><br>
Mario Merri (Approve with Conditions): MOIMS has over the last years
reported that the CCSDS has wrongly embarked in the development of a
multiplicity of frameworks to define services: the MAL, this one and
possibly the EDS are examples. Having said that, I do not put any
condition on this book in the light of the "London
Agreement".<br><br>
Bigette Behal (Approve with Conditions): cf. MOIMS AD conditions<br><br>
Keith Scott (Approve with Conditions):
=====================================<br><br>
General comments (NOT conditions on moving the book forward):<br>
=====================================<br>
The framework does not specify implementations, and therefore can't
ensure interoperability. I see its utility as the basis (framework) for
OTHER blue books that do specify protocol, but am surprised that the book
in itself is Blue.<br><br>
Requirements such as the following don't seem to have been tested in the
Yellow Book:<br>
3.2.1.1 "All invokers of confirmed operations shall implement a
timer for the acknowledgement in case of three-phase operations or the
return in case of two-phase operations. In case the timer expires, the
service user may issue a PEER-ABORT. and <br><br>
3.2.1.2 "On reception of the acknowledgement in case of three-phase
operations or the return in case of two-phase operations, the invoker of
the corresponding confirmed operations shall stop the timer." seem
to not be tested in the Yellow Book.<br><br>
4.5.3.2.7.1 At the time of insertion of a TRANSFER-DATA or NOTIFY
invocation into an<br>
empty return buffer, the service provider shall start a timer called the
release timer. <br><br>
Am I in fact mistaken about the above tests? Is there something that maps
the tests in the yellow book to individual requirement numbers in the
draft blue book?<br><br>
=====================================<br>
CONDITIONS that must be met (or where I need to be convinced I'm
wrong):<br>
=====================================<br>
Section 1.5.1<br>
From:<br>
section 0 presents the purpose, scope, applicability, ...<br>
To:<br>
section 1 presents the purpose, scope, applicability, ...<br><br>
<br>
==END==<br><br>
<br>
Total Respondents: 6<br>
No response was received from the following Area(s):<br><br>
SOIS<br><br>
SECRETARIAT INTERPRETATION OF RESULTS: Approved with
Conditions<br>
PROPOSED SECRETARIAT
ACTION:
Generate CMC poll after conditions have been addressed<br><br>
* * * * * * * * * * * * * * * * * * * * * * * *</blockquote><br><br>
<br>
<blockquote type=cite class=cite cite="">
From: "Scott, Keith
L." <<a href="mailto:kscott@mitre.org">kscott@mitre.org</a>>
<br>
To: "Barkley, Erik J
(3970)"
<<a href="mailto:erik.j.barkley@jpl.nasa.gov">
erik.j.barkley@jpl.nasa.gov</a>>,
"<a href="mailto:Margherita.di.Giulio@esa.int">
Margherita.di.Giulio@esa.int</a>"
<<a href="mailto:Margherita.di.Giulio@esa.int">
Margherita.di.Giulio@esa.int</a>> <br>
Cc:
"<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:tomg@aiaa.org">tomg@aiaa.org</a>"
<<a href="mailto:tomg@aiaa.org">tomg@aiaa.org</a>>,
"<a href="mailto:wo_._he@t-online.de">wo_._he@t-online.de</a>"
<<a href="mailto:wo_._he@t-online.de">wo_._he@t-online.de</a>>,
"<a href="mailto:Holger.Dreihahn@esa.int">Holger.Dreihahn@esa.int</a>
"
<<a href="mailto:Holger.Dreihahn@esa.int">Holger.Dreihahn@esa.int</a>
>,
"<a href="mailto:Nestor.Peccia@esa.int">Nestor.Peccia@esa.int</a>
"
<<a href="mailto:Nestor.Peccia@esa.int">Nestor.Peccia@esa.int</a>>
<br>
Date: 20/01/2017 20:33 <br>
Subject: Re: CESG-P-2016-11-001
Approval to publish CCSDS 921.1-B-1, Cross Support Transfer
Service-Specification Framework (Blue Book, Issue 1)- Replies to your
commenst <br>
<div align="center"><br>
</div>
<br><br>
<br>
If everyone else is OK with it, I am (and I really do NOT mean that as
passive-aggressively as it sounds). I included the comments as
‘non-binding’ because I don’t think it’s worth holding up the book at
this point. <br>
<br>
I’ll be very interested to see the CESG’s reaction when I put forth a bp
security book that doesn’t cover all of the shall statements, but covers
e.g. all the classes of error conditions (ok, that IS meant to be more
passive-aggressive, as I suspect someone will hold my feet to the fire).
<br>
<br>
And, as I said on the phone, I thing we the CESG (ok, maybe I’m not part
of that we any more, but regardess), maybe just ‘the CESG’ should know
what the deal is and what to do. It may be that the CESG wants to
allow testing of the major chunks / classes of protocols and not nit-pick
over every shall statement. I’d be all for that as a WG chair and
sometime-implementer. <br>
<br>
So in short, yes, I’m good with your and Margherita’s explanations for
both book color and testing. <br>
<br>
--keith <br>
<br>
<br>
<b>From: </b>Eric Barkley
<<a href="mailto:erik.j.barkley@jpl.nasa.gov">
erik.j.barkley@jpl.nasa.gov</a>><b><br>
Date: </b>Thursday, January 19, 2017 at 8:43 PM<b><br>
To:
</b>"<a href="mailto:Margherita.di.Giulio@esa.int">
Margherita.di.Giulio@esa.int</a>"
<<a href="mailto:Margherita.di.Giulio@esa.int">
Margherita.di.Giulio@esa.int</a>>, Keith Scott
<<a href="mailto:kscott@mitre.org">kscott@mitre.org</a>><b><br>
Cc: </b>Tom Gannett
<<a href="mailto:thomas.gannett@tgannett.net">
thomas.gannett@tgannett.net</a>>, Tom Gannett
<<a href="mailto:tomg@aiaa.org">tomg@aiaa.org</a>>,
"<a href="mailto:wo_._he@t-online.de">wo_._he@t-online.de</a>"
<<a href="mailto:wo_._he@t-online.de">wo_._he@t-online.de</a>>,
"<a href="mailto:Holger.Dreihahn@esa.int">Holger.Dreihahn@esa.int</a>
"
<<a href="mailto:Holger.Dreihahn@esa.int">Holger.Dreihahn@esa.int</a>
>, Nestor Peccia
<<a href="mailto:Nestor.Peccia@esa.int">Nestor.Peccia@esa.int</a>
><b><br>
Subject: </b>RE: CESG-P-2016-11-001 Approval to publish CCSDS 921.1-B-1,
Cross Support Transfer Service-Specification Framework (Blue Book, Issue
1)- Replies to your commenst <br>
<br>
Keith, <br>
<br>
My reading is that the prototype sufficiently covered the classes of
error conditions involved. Given Margherita’s inputs, do you
agree? <br>
<br>
-Erik <br>
<br>
<b>From:</b>
<a href="mailto:Margherita.di.Giulio@esa.int">
Margherita.di.Giulio@esa.int</a>
[<a href="mailto:Margherita.di.Giulio@esa.int" eudora="autourl">
mailto:Margherita.di.Giulio@esa.int</a>] <b><br>
Sent:</b> Friday, January 13, 2017 3:08 AM<b><br>
To:</b> Scott, Keith L.
<<a href="mailto:kscott@mitre.org">kscott@mitre.org</a>><b><br>
Cc:</b>
<a href="mailto:thomas.gannett@tgannett.net">
thomas.gannett@tgannett.net</a>;
<a href="mailto:tomg@aiaa.org">tomg@aiaa.org</a>; Barkley, Erik J (3970)
<<a href="mailto:erik.j.barkley@jpl.nasa.gov">
erik.j.barkley@jpl.nasa.gov</a>>;
<a href="mailto:wo_._he@t-online.de">wo_._he@t-online.de</a>;
<a href="mailto:Holger.Dreihahn@esa.int">Holger.Dreihahn@esa.int</a>;
<a href="mailto:Nestor.Peccia@esa.int">Nestor.Peccia@esa.int</a><b><br>
Subject:</b> CESG-P-2016-11-001 Approval to publish CCSDS 921.1-B-1,
Cross Support Transfer Service-Specification Framework (Blue Book, Issue
1)- Replies to your commenst <br>
<br>
Dear Keith, <br>
Thank you for taking the time to assess the CSTS Specification Framework,
and for your valuable comments. <br>
Herewith we would like to provide some answers . <br>
<u><br>
About the Blue Book issue :</u> <br><br>
The decision to make a blue book out of CSTS SFW a has been taken many
years ago on the basis of several considerations. Manly, the intent was
to enforce that whenever possible the procedures of the SFW with a
minimum of changes are used to construct CSTSes. In that regard the
specifications contained in the SFW are binding and go beyond a
"best practice", although the SFW as such does not guarantee
interoperability. <br>
Also, I would like to stress that most of CCSDS Blue Books cannot ensure,
per se, interoperability, but rather they cover one part (or one portion)
of a more comprehensive protocol or of a stack. <br>
Think, for instance, of ISP1, or the MAL, or any of the books
describing the individual layers of the Packet TC or Packet TM stack.
None of those recommendations can guarantee interoperability on their
own, still they are Blue Books. <br>
<u><br>
About missing tests in the Yellow Book</u> <br><br>
Your remarks are correct but, in general, error conditions (like time-out
of receptions), although implemented in the Prototype, are only partly
validated, as it would be very demanding for a Prototype to validate all
error conditions, and all their combinations. I think the Prototype is
supposed to proof the concept. <br><br>
However, for the DPP the following two error cases were, indeed,
tested as part of the Provider’s tests : <br><br>
Chapter 6.3.7 of Yellow Book : <br>
We ensured (by creating back-pressure) that the Provider stops reading on
the network and let the User send a STOP operation (confirmed). The
Provider, having stopped reading the network, does not read and process
the STOP operation. As a consequence the CSTS User invokes a PEER-ABORT
operation when the return timeout occurs. <br><br>
Chapter 6.3.5 of Yellow Book : <br>
Also in this case, we ensured (by creating back-pressure) that the
Provider stops reading on the network and let the User send a STOP
operation (confirmed). The Provider, having stopped reading the network,
does not read and process the STOP operation. In this test, the heartbeat
dead factor was set to a value lower than the “return” time
out. So, when the heartbeat dead factor expires, the Provider
aborts the session with diagnostic “heartbeat receive timeout” and
transitions to the Unbound state. <br><br>
As regards Requirement 4.5.3.2.7, the T04 test procedure verifies the
nominal case for that requirement, notably in step T04.008 transfer
data buffers are timely delivered (as soon as they get full, i.e. before
expiration of the release timer) . <br>
The delivery of buffer at timeout – the “latency limit” - is indeed
implemented in the Prototype, if required it can be checked
by code inspection. <br>
As said at the beginning, it is not possible to validate all possible
conditions with a Prototype, as this would be an overkill, considering
the budgets normally allocated for Prototypes development. <br>
<u><br>
Incorrectly resolved cross reference</u> <br>
As regards the incorrectly resolved cross reference ("0"), this
issue has been introduced by the Editor, and we think that this is due to
a "feature" of Word which resolves cross references to
"0" rather than to the correct string. Knowing that, we ( the
Working Group) normally handcraft the correct reference. <br><br>
Please let us know if the above replies are acceptable. <br>
If yes, I assume that once Tom has corrected the cross reference,
publication of the SFW as Blue Book can go ahead. <br><br>
Kind regards,<br>
Margherita <br><br>
<br>
--------------------------------------------------------------<b><br>
Margherita di Giulio</b> <br>
Ground Station Back-end Section (OPS-GIB)<br>
<b><br>
European Space Agency ESA/ESOC</b><br>
Robert-Bosch-Str. 5<br>
D-64293 Darmstadt - Germany<br>
Tel: +49-6151-902779<br>
e-mail:
<a href="mailto:Margherita.di.Giulio@esa.int">
Margherita.di.Giulio@esa.int</a> <br>
This message and any attachments are intended for the use of the
addressee or addressees only. <br>
The unauthorised disclosure, use, dissemination or copying (either in
whole or in part) of its <br>
content is not permitted. <br>
If you received this message in error, please notify the sender and
delete it from your system. <br>
Emails can be altered and their integrity cannot be guaranteed by the
sender. <br>
<br>
Please consider the environment before printing this email. <br>
<br><br>
<pre>This message and any attachments are intended for the use of the
addressee or addressees only.</pre><br><br>
<pre>The unauthorised disclosure, use, dissemination or copying (either
in whole or in part) of its</pre><br><br>
<pre>content is not permitted.</pre><br><br>
<pre>If you received this message in error, please notify the sender and
delete it from your system.</pre><br><br>
<pre>Emails can be altered and their integrity cannot be guaranteed by
the sender.</pre><br><br>
<pre> </pre><br><br>
<pre>Please consider the environment before printing this
email.</pre><br><br>
<pre> </pre></blockquote></body>
</html>