<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:TimesNewRomanPSMT;
panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
{font-family:TimesNewRomanPS;
panose-1:2 11 6 4 2 2 2 2 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle20
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:545413572;
mso-list-template-ids:-673007686;}
@list l0:level1
{mso-level-start-at:6;
mso-level-text:%1;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:24.0pt;
text-indent:-24.0pt;
mso-ansi-font-size:12.0pt;
font-family:TimesNewRomanPSMT;}
@list l0:level2
{mso-level-text:"%1\.%2";
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:33.0pt;
text-indent:-24.0pt;
mso-ansi-font-size:12.0pt;
font-family:TimesNewRomanPSMT;}
@list l0:level3
{mso-level-text:"%1\.%2\.%3";
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:54.0pt;
text-indent:-36.0pt;
mso-ansi-font-size:12.0pt;
font-family:TimesNewRomanPSMT;}
@list l0:level4
{mso-level-text:"%1\.%2\.%3\.%4";
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:63.0pt;
text-indent:-36.0pt;
mso-ansi-font-size:12.0pt;
font-family:TimesNewRomanPSMT;}
@list l0:level5
{mso-level-number-format:alpha-lower;
mso-level-text:"%1\.%2\.%3\.%4\.%5";
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:90.0pt;
text-indent:-54.0pt;
mso-ansi-font-size:12.0pt;
font-family:TimesNewRomanPSMT;}
@list l0:level6
{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6";
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:99.0pt;
text-indent:-54.0pt;
mso-ansi-font-size:12.0pt;
font-family:TimesNewRomanPSMT;}
@list l0:level7
{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7";
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:126.0pt;
text-indent:-72.0pt;
mso-ansi-font-size:12.0pt;
font-family:TimesNewRomanPSMT;}
@list l0:level8
{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\.%8";
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:135.0pt;
text-indent:-72.0pt;
mso-ansi-font-size:12.0pt;
font-family:TimesNewRomanPSMT;}
@list l0:level9
{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\.%8\.%9";
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:144.0pt;
text-indent:-72.0pt;
mso-ansi-font-size:12.0pt;
font-family:TimesNewRomanPSMT;}
@list l1
{mso-list-id:1505709712;
mso-list-template-ids:1023841200;}
@list l1:level1
{mso-level-tab-stop:36.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1:level2
{mso-level-tab-stop:72.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1:level3
{mso-level-tab-stop:108.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1:level4
{mso-level-tab-stop:144.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1:level5
{mso-level-tab-stop:180.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1:level6
{mso-level-tab-stop:216.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1:level7
{mso-level-tab-stop:252.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1:level8
{mso-level-tab-stop:288.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1:level9
{mso-level-tab-stop:324.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l2
{mso-list-id:1509246040;
mso-list-template-ids:1657339678;}
ol
{margin-bottom:0cm;}
ul
{margin-bottom:0cm;}
--></style>
</head>
<body lang="en-IT" link="#0563C1" vlink="#954F72" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal"><span lang="EN-US">Dear WG members,<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">FYI and to be discussed.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">Regards<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">Mehran<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US" style="font-size:12.0pt;color:black">From:
</span></b><span lang="EN-US" style="font-size:12.0pt;color:black">"Shames, Peter M (US 312B)" <peter.m.shames@jpl.nasa.gov><br>
<b>Date: </b>Wednesday, 6 July 2022 at 00:49<br>
<b>To: </b>Mehran Sarkarati <Mehran.Sarkarati@esa.int><br>
<b>Cc: </b>Mario Merri <Mario.Merri@esa.int>, Duhaze Marc <Marc.Duhaze@cnes.fr>, "Reeves, Scott (MSFC-HP27)[HOSC SERVICES CONTRACT]" <scott.reeves@nasa.gov>, Peter van der Plas <Peter.van.der.Plas@esa.int>, CESG <cesg@mailman.ccsds.org><br>
<b>Subject: </b>Re: [EXTERNAL] Comments on the MAL BB<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
</div>
<p class="MsoNormal"><span lang="EN-US" style="color:black">Dear Mehran, et al,<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:black"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:black">You and your WG seem to have a very different approach to this process than I do. Your email makes the statement “Our WG sees this as very unfortunate that you consider the points you have raised
as severe enough to stop the Agency review </span><span lang="EN-US">“. I can easily imagine that being so, but your disappointment is not sufficient reason to let a flawed document go out for agency review as having the backing of CCSDS. Your email also
<span style="color:black">speaks of “surprised to see new comments on parts that were not changed”, along with your belief that my comments should have been confined only to specific changes and that they were largely editorial and therefore could be easily
ignored. These statements are both wrong and dismissive. <o:p></o:p></span></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:black"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:black">You should all know by now that I do not approach these document reviews lightly. I, and other members of the CESG, have certain responsibilities as defined in the CCSDS Org & Proc, A02.1-Y-4. You
may not be familiar with the rules that govern CCSDS so I have quoted key sections from the Org & Proc in
</span><span lang="EN-US" style="color:#0070C0">Blue </span><span lang="EN-US" style="color:black">(<b><i>emphasis added</i></b>):<o:p></o:p></span></p>
<p style="text-indent:18.0pt"><b><span lang="EN-US" style="color:#0070C0">2.3.2.2.g
</span></b><b><span lang="EN-US" style="font-size:12.0pt;font-family:TimesNewRomanPSMT;color:#0070C0">d) </span></b><i><span lang="EN-US" style="font-size:12.0pt;font-family:TimesNewRomanPS;color:#0070C0">Consistency</span></i><span lang="EN-US" style="font-size:12.0pt;font-family:TimesNewRomanPSMT;color:#0070C0">.
An important job of the CESG is to watch over the output of all of the WGs to help prevent CCSDS specifications that are at odds with each other. This is why ADs and DADs are required to review the drafts coming out of Areas other than their own as part of
the consensus process leading up to their adoption into the program of work. <b>
<i>The quality of the CCSDS Recommended Standards comes both from the review that they get in the WGs and the review that the WG products get from the CESG</i></b>.
<o:p></o:p></span></p>
<p><b><span lang="EN-US" style="font-size:12.0pt;font-family:TimesNewRomanPSMT;color:#0070C0">2.3.2.3 CESG Responsibilities<o:p></o:p></span></b></p>
<p style="margin-left:36.0pt"><span lang="EN-US" style="font-size:12.0pt;font-family:TimesNewRomanPSMT;color:#0070C0">j) identifying “red flag” items where
<b><i>technical work in a proposed CCSDS document is not of the required quality or nature</i></b>, where technical work is not progressing satisfactorily, where resources are inadequate, or where significant issues exist, and raising these to the attention
of the CMC for corrective action; </span><span lang="EN-US" style="color:#0070C0"><o:p></o:p></span></p>
<p style="margin-left:54.0pt;text-indent:-36.0pt;mso-list:l0 level3 lfo2"><![if !supportLists]><b><i><span lang="EN-US" style="font-size:12.0pt;font-family:TimesNewRomanPSMT;color:#0070C0"><span style="mso-list:Ignore">6.1.1<span style="font:7.0pt "Times New Roman"">
</span></span></span></i></b><![endif]><span lang="EN-US" style="font-size:12.0pt;font-family:TimesNewRomanPSMT;color:#0070C0">In this context, norms are specific and precise rules that elaborate the detailed behavioral and structural requirements of a standard.
<b><i>To say that a section of a standard is “normative” is to say that it is both well specified, i.e., a norm, and that it must be adhered to in order for an implementation to be compliant.
</i></b></span><b><i><span lang="EN-US" style="color:#0070C0"><o:p></o:p></span></i></b></p>
<p style="margin-left:18.0pt"><b><span lang="EN-US" style="font-size:12.0pt;font-family:TimesNewRomanPS;color:#0070C0">6.1.4.2
</span></b><span lang="EN-US" style="font-size:12.0pt;font-family:TimesNewRomanPSMT;color:#0070C0">The principal difference between these two branches is that Recommended Standards are
<b><i>precise, prescriptive and/or normative specifications that define interfaces, protocols, or other controlling standards at a sufficient level of technical detail that they can be directly implemented and used for space-mission interoperability and cross
support.</i></b> Recommended Standards may be defined at a single layer in the OSI reference model,</span><span lang="EN-US" style="font-size:8.0pt;font-family:TimesNewRomanPSMT;color:#0070C0;position:relative;top:-6.0pt;mso-text-raise:6.0pt">9
</span><span lang="EN-US" style="font-size:12.0pt;font-family:TimesNewRomanPSMT;color:#0070C0">or they may specify how to utilize a set of related standards from several layers in the OSI reference model or how to adapt other standards for use in space.
</span><span lang="EN-US" style="color:#0070C0"><o:p></o:p></span></p>
<p class="MsoNormal"><b><span lang="EN-US" style="color:#0070C0">B1.2 Recommended Standard Branch<o:p></o:p></span></b></p>
<p><span lang="EN-US" style="font-size:12.0pt;font-family:TimesNewRomanPSMT;color:#0070C0">d)
<b><i>Pink Books are issued when changes to an existing Blue Book are extensive enough to warrant review of the entire document</i></b>; Pink Sheets (changed pages only) are issued otherwise. In the case of Pink Sheets, only changes to the current issue of
the Blue Book are subject to review. </span><span lang="EN-US" style="color:#0070C0"><o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:black">Here is what I believe is true:<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:black"> <o:p></o:p></span></p>
<ol style="margin-top:0cm" start="1" type="1">
<li class="MsoNormal" style="color:black;mso-list:l1 level1 lfo5"><span lang="EN-US">You made changes to the entire document, not just to “Pink Sheets”, therefore the entire document is under review. This is our standard practice.<o:p></o:p></span></li><li class="MsoNormal" style="color:black;mso-list:l1 level1 lfo5"><span lang="EN-US">The MAL has always been “abstract”, this is even stated in its name, and this version makes it even more abstract (and vague). Your WG seems to think that this is a good thing.
I think that it is the antithesis of what a Blue Book is because it is not “</span><b><i><span lang="EN-US" style="font-size:12.0pt;font-family:TimesNewRomanPSMT;color:windowtext">at a sufficient level of technical detail that they can be directly implemented
and used for space-mission interoperability and cross support</span></i></b><span lang="EN-US">”.
<o:p></o:p></span></li><li class="MsoNormal" style="color:black;mso-list:l1 level1 lfo5"><span lang="EN-US">Because the MAL fails this fundamental test this document is not really a Blue Book. It is, at best, a Magenta Book that needs to be bound, after the fact, to a specific set
of implementation choices to produce something that is in any way interoperable. This approach says, in essence, “Take this concept, and these two other docs, together, to make a BB MAL sandwich.” This is unprecedented anywhere else in CCSDS (or in other
interoperable standards for that matter). <o:p></o:p></span></li><li class="MsoNormal" style="color:black;mso-list:l1 level1 lfo5"><span lang="EN-US">Other Areas and WG have separate abstract architecture documents (MB) and properly formalized and implementable Blue Books (BB). An excellent and parallel example is the CSS
abstract “Guidelines for the Specification of Cross Support Transfer Services”, CCSDS 921.2-M-1, and the completely formal and directly implementable standards that are built upon it, such as “Cross Support Transfer Service, Monitored Data Service”, CCSDS
922.1-B-1. The first provides the architecture and the framework for a variety of different services, the second provides the specific, directly implementable, and interoperable service. This should sound familiar to you as a concept, but you have missed
the mark.<o:p></o:p></span></li><li class="MsoNormal" style="color:black;mso-list:l1 level1 lfo5"><span lang="EN-US">A last comment is that the only way that any set of interoperable applications can be built using the MAL is to bind them to a specific data representation and a specific transport
technology. This is really the “Blue” part. You have stated in the past that these different choices (a specific MAL sandwich) can all interoperate using a sort of “generic bridge”, but I have seen evidence in some of these bindings that there is no mapping
for some fields. The design of the binding is such that some data must be passed “by management” and therefore outside of the specified interface. Because of this I have to conclude that anything like full interoperability and idempotence is not generally
achievable at the protocol level.<o:p></o:p></span></li></ol>
<p class="MsoNormal"><span lang="EN-US" style="color:black"> <o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:black">I am aware that there are at least a few agencies who support this whole MAL construct. I am also aware that there are other agencies who do not believe, after 20 years of development, that is has
sufficient value for them to invest in it. Agencies are entitled to make choices as to what to invest in. Our job in CCSDS is to try and ensure that when a standard says that it is “</span><b><i><span lang="EN-US" style="font-size:12.0pt;font-family:TimesNewRomanPSMT">at
a sufficient level of technical detail that they can be directly implemented and used for space-mission interoperability and cross support</span></i></b><span lang="EN-US" style="color:black">” that that is a testable and verifiable truth.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:black"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:black">As I have clearly stated, I do not believe that this document has either sufficient detail, nor is it directly implementable, so as to meet this exacting CCSDS Blue Book test. Instead of taking this
re-writing opportunity to improve the MAL and bring it into closer alignment with CCSDS norms you have chosen to make it even more abstract and vague. I think this is a missed opportunity on your part, but that’s your call. <o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:black"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:black">For some reason you seem to think that all of the feedback provided to the effect that this vagueness is not acceptable is “just editorial”, and therefore can be ignored. I think you are missing the
point and also trying to rewrite the rules that the rest of CCSDS operates by. But from my point of view if we allow this for the MAL then I fear we shall be pressured to allow such lapses in our level of standards compliance for other documents, and at that
point CCSDS will cease to have value to agencies and missions that require interoperability.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:black"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:black">So, as a matter of principle, I am going to request that you either fix these lapses in alignment with stated CCSDS Architectural Principles (especially A3, A8, and A10) and document content norms,
or that you “re-brand” and rewrite this as the Recommended Practice Magenta Book that it actually is given its current lack of specificity. The other approach you could take, of course, is to make this document more prescriptive so that it actually meets
the criteria for a Blue Book. This choice is yours.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:black"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:black">I do not expect this to make you happy, and I want to assure you that I do not make this request lightly. I have, in fact, given it a lot of thought and verified, by talking to other CCSDS experts,
that I am not mistaken in my analysis nor my judgements.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:black"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:black">This is why it took a week to get you a reply.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:black"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:black">Best regards, Peter Shames<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:black"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:black"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US" style="font-size:12.0pt;color:black">From:
</span></b><span lang="EN-US" style="font-size:12.0pt;color:black">Mehran Sarkarati <Mehran.Sarkarati@esa.int><br>
<b>Date: </b>Wednesday, June 29, 2022 at 3:17 AM<br>
<b>To: </b>Peter Shames <peter.m.shames@jpl.nasa.gov><br>
<b>Cc: </b>Mario Merri <Mario.Merri@esa.int>, Duhaze Marc <Marc.Duhaze@cnes.fr>, "Reeves, Scott (MSFC-HP27)[HOSC SERVICES CONTRACT]" <scott.reeves@nasa.gov>, Peter van der Plas <Peter.van.der.Plas@esa.int><br>
<b>Subject: </b>[EXTERNAL] Comments on the MAL BB<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
</div>
<p class="MsoNormal"><span lang="DE">Dear Peter, <o:p></o:p></span></p>
<p class="MsoNormal"><span lang="DE"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">We have reviewed carefully in the WG the comments, which you had raised as part of the CESG review on the updated MAL Book.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">Please find attached the responses.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">Most of the comments seemed to us editorial and not critical, as they seemed to ask for better wording or clarification, which we accept.
<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">Some comments seemed to be a misunderstanding by you, due to the MS Word track change function (comments made on deleted image and deleted text, etc.).<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">As you will see in the responses, at least our perception is that there is no big issue and we accept to update the wording and do the editorial updates.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">From a procedure perspective, we were expecting comments on the red-lined changed parts of the already published blue book. Since the MAL BB is already a published standard, which has gone through many review cycles,
we were a bit surprise to see new comments on unchanged parts of the book. Regardless we have also processed these comments and agreed to most of them.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">Our WG sees this as very unfortunate that you consider the points you have raised as severe enough to stop the Agency review and we would like to resolve your points as swift as possible and start the Agency review. Also
in order to avoid delays on the agency review of the Mission Planning BB.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">We suggest to have a meeting to discuss if there are any major points that we did not understand from your comments and if the provided answers clarify the questions, you have raised.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">Please let me know, when would be a good time for you.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">Regards<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">Mehran<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">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@esa.int).
<o:p></o:p></span></p>
</div>
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@esa.int).
</body>
</html>