<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:x="urn:schemas-microsoft-com:office:excel" xmlns:p="urn:schemas-microsoft-com:office:powerpoint" xmlns:a="urn:schemas-microsoft-com:office:access" xmlns:dt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s="uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs="urn:schemas-microsoft-com:rowset" xmlns:z="#RowsetSchema" xmlns:b="urn:schemas-microsoft-com:office:publisher" xmlns:ss="urn:schemas-microsoft-com:office:spreadsheet" xmlns:c="urn:schemas-microsoft-com:office:component:spreadsheet" xmlns:odc="urn:schemas-microsoft-com:office:odc" xmlns:oa="urn:schemas-microsoft-com:office:activation" xmlns:html="http://www.w3.org/TR/REC-html40" xmlns:q="http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc="http://microsoft.com/officenet/conferencing" xmlns:D="DAV:" xmlns:Repl="http://schemas.microsoft.com/repl/" xmlns:mt="http://schemas.microsoft.com/sharepoint/soap/meetings/" xmlns:x2="http://schemas.microsoft.com/office/excel/2003/xml" xmlns:ppda="http://www.passport.com/NameSpace.xsd" xmlns:ois="http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir="http://schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:dsp="http://schemas.microsoft.com/sharepoint/dsp" xmlns:udc="http://schemas.microsoft.com/data/udc" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:sub="http://schemas.microsoft.com/sharepoint/soap/2002/1/alerts/" xmlns:ec="http://www.w3.org/2001/04/xmlenc#" xmlns:sp="http://schemas.microsoft.com/sharepoint/" xmlns:sps="http://schemas.microsoft.com/sharepoint/soap/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:udcs="http://schemas.microsoft.com/data/udc/soap" xmlns:udcxf="http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udcp2p="http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf="http://schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss="http://schemas.microsoft.com/office/2006/digsig-setup" xmlns:dssi="http://schemas.microsoft.com/office/2006/digsig" xmlns:mdssi="http://schemas.openxmlformats.org/package/2006/digital-signature" xmlns:mver="http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns:mrels="http://schemas.openxmlformats.org/package/2006/relationships" xmlns:spwp="http://microsoft.com/sharepoint/webpartpages" xmlns:ex12t="http://schemas.microsoft.com/exchange/services/2006/types" xmlns:ex12m="http://schemas.microsoft.com/exchange/services/2006/messages" xmlns:pptsl="http://schemas.microsoft.com/sharepoint/soap/SlideLibrary/" xmlns:spsl="http://microsoft.com/webservices/SharePointPortalServer/PublishedLinksService" xmlns:Z="urn:schemas-microsoft-com:" xmlns:st="" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 12 (filtered medium)">
<style>
<!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
{mso-style-priority:99;
mso-style-link:"Plain Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Calibri","sans-serif";}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
span.PlainTextChar
{mso-style-name:"Plain Text Char";
mso-style-priority:99;
mso-style-link:"Plain Text";
font-family:"Calibri","sans-serif";}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page Section1
{size:8.5in 11.0in;
margin:1.0in 111.1pt 1.0in 111.1pt;}
div.Section1
{page:Section1;}
/* List Definitions */
@list l0
{mso-list-id:1303926720;
mso-list-type:hybrid;
mso-list-template-ids:1214252498 67698689 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l0:level1
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
-->
</style>
<!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=EN-US link=blue vlink=purple>
<div class=Section1>
<p class=MsoNormal><span style='color:#1F497D'>Hi, AMS fans. We have had
a setback: the result of the CESG Poll on the question of asking CMC to publish
the AMS spec as a Recommended Standard was disapproval. The remarks of
the Area Directors are given below.<o:p></o:p></span></p>
<p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='color:#1F497D'>I think it’s still
possible to standardize the Asynchronous Message Service within CCSDS, but
unfortunately it will take some more work. Several of the Area Directors
are demanding extensive editorial changes to the specification. More
seriously, it looks as if we have got to do some supplementary interoperability
testing – some of which will entail additional development of optional
features in one or more of our implementations. In particular:<o:p></o:p></span></p>
<p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><span
style='font-family:Symbol;color:#1F497D'><span style='mso-list:Ignore'>·<span
style='font:7.0pt "Times New Roman"'>
</span></span></span><![endif]><span style='color:#1F497D'>We need checksums working
in either Pat’s implementation or Tim’s so that we can test
interoperability with mine. This may not be too tough, and we might even
be able to do the testing over the Internet.<o:p></o:p></span></p>
<p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><span
style='font-family:Symbol;color:#1F497D'><span style='mso-list:Ignore'>·<span
style='font:7.0pt "Times New Roman"'>
</span></span></span><![endif]><span style='color:#1F497D'>We need to do
something about testing all the optional security mechanisms in the spec.
If we think NASA can live without them for now, we might modify the spec to just
provide hooks for future use and slip the detailed specifications into a future
supplementary document. But if we need the security procedures in the
Blue Book from day 1, then we need to scope the cost of implementing and
testing them; I expect that to be large.<o:p></o:p></span></p>
<p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='color:#1F497D'>I had scheduled only a single
morning of AMS discussion during the October CCSDS Technical Meetings in
Portsmouth, thinking we were all done and only needed a little time to wrap
up. I think a single morning is still enough time, but now I think we
need to use that morning to develop a plan for completing this additional work.
Please give it some thought between now and then so we can converge on a
strategy quickly.<o:p></o:p></span></p>
<p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='color:#1F497D'>Scott<o:p></o:p></span></p>
<p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p>
<div style='border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'>
<p class=MsoPlainText>>-----Original Message-----<o:p></o:p></p>
<p class=MsoPlainText>>From: secretariat-bounces@mailman.ccsds.org
[mailto:secretariat-<o:p></o:p></p>
<p class=MsoPlainText>>bounces@mailman.ccsds.org] On Behalf Of CCSDS
Secretariat<o:p></o:p></p>
<p class=MsoPlainText>>Sent: Tuesday, March 23, 2010 9:50 AM<o:p></o:p></p>
<p class=MsoPlainText>>To: cesg@mailman.ccsds.org<o:p></o:p></p>
<p class=MsoPlainText>>Subject: [Secretariat] [CESG] Results of CESG poll
closing 22 March 2010<o:p></o:p></p>
<p class=MsoPlainText>><o:p> </o:p></p>
<p class=MsoPlainText>>CESG E-Poll Identifier: CESG-P-2010-03-002 CESG<o:p></o:p></p>
<p class=MsoPlainText>>Approval of Asynchronous Message Service Blue Book<o:p></o:p></p>
<p class=MsoPlainText>>Results of CESG poll beginning 6 March 2010 and
ending 15 March 2010:<o:p></o:p></p>
<p class=MsoPlainText>><o:p> </o:p></p>
<p class=MsoPlainText>>
Abstain: 1 (16.67%) (Barkley)<o:p></o:p></p>
<p class=MsoPlainText>> Approve Unconditionally: 1 (16.67%)
(Durst)<o:p></o:p></p>
<p class=MsoPlainText>> Approve with Conditions: 2 (33.33%)
(Shames, Taylor)<o:p></o:p></p>
<p class=MsoPlainText>> Disapprove with Comment: 2 (33.33%)
(Peccia, Thompson)<o:p></o:p></p>
<p class=MsoPlainText>><o:p> </o:p></p>
<p class=MsoPlainText>>CONDITIONS/COMMENTS:<o:p></o:p></p>
<p class=MsoPlainText>><o:p> </o:p></p>
<p class=MsoPlainText>> Peter Shames (Approve
with<o:p></o:p></p>
<p class=MsoPlainText>>Conditions): Sec 1, the term "module"
is<o:p></o:p></p>
<p class=MsoPlainText>>extensively used, and seems to refer to an<o:p></o:p></p>
<p class=MsoPlainText>>implemented piece of software in a data system,<o:p></o:p></p>
<p class=MsoPlainText>>but it is not ever really defined and seems to be
synonymous with "node".<o:p></o:p></p>
<p class=MsoPlainText>><o:p> </o:p></p>
<p class=MsoPlainText>> The definitions in Sec 1.3.3.3 are somewhat<o:p></o:p></p>
<p class=MsoPlainText>>complex and can be confusing because of all of<o:p></o:p></p>
<p class=MsoPlainText>>the overlapping terminology. One or more<o:p></o:p></p>
<p class=MsoPlainText>>diagrams that discriminate: continuum, venture,<o:p></o:p></p>
<p class=MsoPlainText>>unit, cell, domain, node, cell, and root cell would
be really useful.<o:p></o:p></p>
<p class=MsoPlainText>><o:p> </o:p></p>
<p class=MsoPlainText>>Pg 1-5, The definition of the term "node",
i.e.<o:p></o:p></p>
<p class=MsoPlainText>>"A node (i.e., a mission data system module) is
a<o:p></o:p></p>
<p class=MsoPlainText>>communicating entity that implements some part of<o:p></o:p></p>
<p class=MsoPlainText>>the functionality of some AMS venture" is<o:p></o:p></p>
<p class=MsoPlainText>>inconsistent with the use of the term node in<o:p></o:p></p>
<p class=MsoPlainText>>RASDS and in many other contexts. Node here<o:p></o:p></p>
<p class=MsoPlainText>>appears to be used to refer to a software<o:p></o:p></p>
<p class=MsoPlainText>>module. Node is RASDS (and elsewhere) is used
to<o:p></o:p></p>
<p class=MsoPlainText>>refer to a physical object. Suggest the use of<o:p></o:p></p>
<p class=MsoPlainText>>the term "component" or some more software<o:p></o:p></p>
<p class=MsoPlainText>>relevant term instead. If, instead, you really<o:p></o:p></p>
<p class=MsoPlainText>>do mean a physical node, i.e. a computer or other<o:p></o:p></p>
<p class=MsoPlainText>>physical object, then you need to clean up your<o:p></o:p></p>
<p class=MsoPlainText>>definition and use. The use of the term in 2.1<o:p></o:p></p>
<p class=MsoPlainText>>only complicates the matter "Messages are<o:p></o:p></p>
<p class=MsoPlainText>>exchanged directly between modules (nodes)".<o:p></o:p></p>
<p class=MsoPlainText>><o:p> </o:p></p>
<p class=MsoPlainText>>Sec 2.1.2: A number of terms that appear in the<o:p></o:p></p>
<p class=MsoPlainText>>text in italics, e.g. reply, context, query are<o:p></o:p></p>
<p class=MsoPlainText>>not defined but are apparently just to be<o:p></o:p></p>
<p class=MsoPlainText>>understood in context. It would be better if
these were unambiguously<o:p></o:p></p>
<p class=MsoPlainText>>defined.<o:p></o:p></p>
<p class=MsoPlainText>><o:p> </o:p></p>
<p class=MsoPlainText>>Sec 2.2.1: The term "application" is used
earlier<o:p></o:p></p>
<p class=MsoPlainText>>in a software sense to define "a data system<o:p></o:p></p>
<p class=MsoPlainText>>implementation, typically taking the form of a<o:p></o:p></p>
<p class=MsoPlainText>>set of source code text files". This
sounds like<o:p></o:p></p>
<p class=MsoPlainText>>a body of software, described separately from its<o:p></o:p></p>
<p class=MsoPlainText>>deployment in a real system. In this section,
in<o:p></o:p></p>
<p class=MsoPlainText>>figure 2-1, there is an element labeled<o:p></o:p></p>
<p class=MsoPlainText>>"application Q, authority R", but this
appears to<o:p></o:p></p>
<p class=MsoPlainText>>represent a real deployment in a real<o:p></o:p></p>
<p class=MsoPlainText>>system. Isn't this actually a
"venture"<o:p></o:p></p>
<p class=MsoPlainText>>according to the definitions provided earlier,<o:p></o:p></p>
<p class=MsoPlainText>>i.e. "a functioning projection of the
application—<o:p></o:p></p>
<p class=MsoPlainText>>for which some authority is responsible — onto
a<o:p></o:p></p>
<p class=MsoPlainText>>set of one or more running computers"?<o:p></o:p></p>
<p class=MsoPlainText>><o:p> </o:p></p>
<p class=MsoPlainText>>Sec 2.3.1: "AAMS occupies a position in the OSI<o:p></o:p></p>
<p class=MsoPlainText>>protocol stack model somewhere between level 4<o:p></o:p></p>
<p class=MsoPlainText>>(Transport) and level 7 (Application);". I
would<o:p></o:p></p>
<p class=MsoPlainText>>state unequivocally that AMS is a LAYER 7<o:p></o:p></p>
<p class=MsoPlainText>>application service. As defined in the ISO-BRM:<o:p></o:p></p>
<p class=MsoPlainText>>"7.1.3.1.2 As the only layer in the Reference<o:p></o:p></p>
<p class=MsoPlainText>>Model that directly provides services to the<o:p></o:p></p>
<p class=MsoPlainText>>application-processes, the Application Layer<o:p></o:p></p>
<p class=MsoPlainText>>necessarily provides all OSI services directly usable
by application-processes.<o:p></o:p></p>
<p class=MsoPlainText>>7.1.3.1.3 There exists no Application Layer<o:p></o:p></p>
<p class=MsoPlainText>>service in the sense of (N)-layer service in that
there is neither a general<o:p></o:p></p>
<p class=MsoPlainText>>service provided to an upper layer nor a relation to
a service-access-point. "<o:p></o:p></p>
<p class=MsoPlainText>><o:p> </o:p></p>
<p class=MsoPlainText>>Sec 2.3.1 describes "The network location at<o:p></o:p></p>
<p class=MsoPlainText>>which a node can receive messages" but the term<o:p></o:p></p>
<p class=MsoPlainText>>"network location" is not defined.
Further, it<o:p></o:p></p>
<p class=MsoPlainText>>sounds a lot like a reference to a port of a<o:p></o:p></p>
<p class=MsoPlainText>>physical node in a real system, not to a logical<o:p></o:p></p>
<p class=MsoPlainText>>interface for a software module as implemented in<o:p></o:p></p>
<p class=MsoPlainText>>a real system. Suggest that this language get<o:p></o:p></p>
<p class=MsoPlainText>>cleaned up as it is potentially confusing.<o:p></o:p></p>
<p class=MsoPlainText>><o:p> </o:p></p>
<p class=MsoPlainText>>Sec 2.3.4 jumps into use of the terms N4, N3, N6<o:p></o:p></p>
<p class=MsoPlainText>>without ever introducing them or what they might<o:p></o:p></p>
<p class=MsoPlainText>>mean. One is left to deduce this from context.<o:p></o:p></p>
<p class=MsoPlainText>><o:p> </o:p></p>
<p class=MsoPlainText>>Sec 2.3.8 makes references to the use of public<o:p></o:p></p>
<p class=MsoPlainText>>keys, encryption, authentication without<o:p></o:p></p>
<p class=MsoPlainText>>providing any references for these terms. Some<o:p></o:p></p>
<p class=MsoPlainText>>tie to these terms, as defined in CCSDS security<o:p></o:p></p>
<p class=MsoPlainText>>standards or elsewhere should be provided.<o:p></o:p></p>
<p class=MsoPlainText>><o:p> </o:p></p>
<p class=MsoPlainText>>Sec 4: While the text in this section is quite<o:p></o:p></p>
<p class=MsoPlainText>>clear the use of either state machines or a state<o:p></o:p></p>
<p class=MsoPlainText>>table would make the whole protocol operation<o:p></o:p></p>
<p class=MsoPlainText>>much clearer. Where this has been done in other<o:p></o:p></p>
<p class=MsoPlainText>>protocol specifications it has been found to be<o:p></o:p></p>
<p class=MsoPlainText>>of a great help and it is a recommended practice.<o:p></o:p></p>
<p class=MsoPlainText>><o:p> </o:p></p>
<p class=MsoPlainText>>Sec 4.2.5.5.5, the term "capsule" is used
before<o:p></o:p></p>
<p class=MsoPlainText>>it is defined. When later defined, in sec
5.3.4,<o:p></o:p></p>
<p class=MsoPlainText>>it is said to be "A capsule is a data structure<o:p></o:p></p>
<p class=MsoPlainText>>that is identical in format and semantics to an<o:p></o:p></p>
<p class=MsoPlainText>>AAMS message, including optional checksum, except<o:p></o:p></p>
<p class=MsoPlainText>>that it is never passed to a transport service for<o:p></o:p></p>
<p class=MsoPlainText>>transmission. " The use of this separate
term<o:p></o:p></p>
<p class=MsoPlainText>>for an object that appears to be exactly<o:p></o:p></p>
<p class=MsoPlainText>>identical to an AAMS message seems gratuitous and
potentially confusing.<o:p></o:p></p>
<p class=MsoPlainText>><o:p> </o:p></p>
<p class=MsoPlainText>>Sec 6.2 on an AMQP based AMSP can be read to be a<o:p></o:p></p>
<p class=MsoPlainText>>part of the normative specification, yet it is<o:p></o:p></p>
<p class=MsoPlainText>>neither required nor authoritative, merely<o:p></o:p></p>
<p class=MsoPlainText>>exemplary. It should be marked as such.<o:p></o:p></p>
<p class=MsoPlainText>><o:p> </o:p></p>
<p class=MsoPlainText>>Sec 8, the MIB should presumably include<o:p></o:p></p>
<p class=MsoPlainText>>definitions for N4 and N5, along with those for N1,
2, 3 and 6.<o:p></o:p></p>
<p class=MsoPlainText>><o:p> </o:p></p>
<p class=MsoPlainText>>Annex A, the list of recognized transport<o:p></o:p></p>
<p class=MsoPlainText>>services is defined as normative, but is<o:p></o:p></p>
<p class=MsoPlainText>>presumably an extensible set. How is this<o:p></o:p></p>
<p class=MsoPlainText>>handled? It is registered somewhere?<o:p></o:p></p>
<p class=MsoPlainText>><o:p> </o:p></p>
<p class=MsoPlainText>>Sec E1, same comment as earlier, AMS is an application
LAYER service.<o:p></o:p></p>
<p class=MsoPlainText>><o:p> </o:p></p>
<p class=MsoPlainText>> Nestor Peccia
(Disapprove with<o:p></o:p></p>
<p class=MsoPlainText>>Comment): Criticisms as those raised on the
SM&C books apply:<o:p></o:p></p>
<p class=MsoPlainText>>- No clear statement of how AMS relates to
other<o:p></o:p></p>
<p class=MsoPlainText>>CCSDS standards, and what the recommended full
protocol stack should look<o:p></o:p></p>
<p class=MsoPlainText>>like.<o:p></o:p></p>
<p class=MsoPlainText>>- No clear how AMS is intended to relate to<o:p></o:p></p>
<p class=MsoPlainText>>deployment within the ground segment. What is a<o:p></o:p></p>
<p class=MsoPlainText>>module of a ground data system ? Where is defined<o:p></o:p></p>
<p class=MsoPlainText>>? Which agreed reference architecture is used
as baseline for the RB ?<o:p></o:p></p>
<p class=MsoPlainText>>- No definition of what a service is, what a<o:p></o:p></p>
<p class=MsoPlainText>>service layer is, no mention of interfaces,<o:p></o:p></p>
<p class=MsoPlainText>>protocols, bindings, relations between service<o:p></o:p></p>
<p class=MsoPlainText>>provider and consumer, how it relates to other kinf
of standards ?<o:p></o:p></p>
<p class=MsoPlainText>><o:p> </o:p></p>
<p class=MsoPlainText>>On the Test Report, comments are as follows:<o:p></o:p></p>
<p class=MsoPlainText>>General:<o:p></o:p></p>
<p class=MsoPlainText>>The AMS test report does not conform to the Yellow
book document structure.<o:p></o:p></p>
<p class=MsoPlainText>>No explanation of the notation used for the tables is
provided.<o:p></o:p></p>
<p class=MsoPlainText>>No reference or explanation of the actual test
procedures is provided.<o:p></o:p></p>
<p class=MsoPlainText>><o:p> </o:p></p>
<p class=MsoPlainText>>Specific:<o:p></o:p></p>
<p class=MsoPlainText>>Section 1)<o:p></o:p></p>
<p class=MsoPlainText>>It is assumed that Security and Checksum shall be<o:p></o:p></p>
<p class=MsoPlainText>>removed from the specification as per the process<o:p></o:p></p>
<p class=MsoPlainText>>for CCSDS "In cases in which one or more options<o:p></o:p></p>
<p class=MsoPlainText>>or features have not been demonstrated in at<o:p></o:p></p>
<p class=MsoPlainText>>least two interoperable prototypes or<o:p></o:p></p>
<p class=MsoPlainText>>implementations, the specification may advance to<o:p></o:p></p>
<p class=MsoPlainText>>the CCSDS Recommended Standard level only if<o:p></o:p></p>
<p class=MsoPlainText>>those options or features are removed. "<o:p></o:p></p>
<p class=MsoPlainText>><o:p> </o:p></p>
<p class=MsoPlainText>>Section 2.3)<o:p></o:p></p>
<p class=MsoPlainText>>It is assumed that the relevant sections of the<o:p></o:p></p>
<p class=MsoPlainText>>specification shall be removed seeing as "The<o:p></o:p></p>
<p class=MsoPlainText>>indicated steps in chapter 2.3b were not<o:p></o:p></p>
<p class=MsoPlainText>>performed due to the unavailability of underlying<o:p></o:p></p>
<p class=MsoPlainText>>capabilities at the time of testing".<o:p></o:p></p>
<p class=MsoPlainText>><o:p> </o:p></p>
<p class=MsoPlainText>>Section 3.2)<o:p></o:p></p>
<p class=MsoPlainText>>As the second configuration was not completed<o:p></o:p></p>
<p class=MsoPlainText>>this cannot be considered a complete test and<o:p></o:p></p>
<p class=MsoPlainText>>therefore the specification has not been<o:p></o:p></p>
<p class=MsoPlainText>>completely verified by two implementations, I<o:p></o:p></p>
<p class=MsoPlainText>>cannot see how this can be considered proper
validation of the red book.<o:p></o:p></p>
<p class=MsoPlainText>><o:p> </o:p></p>
<p class=MsoPlainText>>Section 4.1)<o:p></o:p></p>
<p class=MsoPlainText>>Many tests were not performed in this section due<o:p></o:p></p>
<p class=MsoPlainText>>to implementation bugs. The statement "Deferred<o:p></o:p></p>
<p class=MsoPlainText>>steps in this series indicate implementation<o:p></o:p></p>
<p class=MsoPlainText>>bugs, and not specification issues.". Until all<o:p></o:p></p>
<p class=MsoPlainText>>tests are passed how can it be proven that other
hidden issues do not exist?<o:p></o:p></p>
<p class=MsoPlainText>><o:p> </o:p></p>
<p class=MsoPlainText>> Rodger Thompson
(Disapprove with<o:p></o:p></p>
<p class=MsoPlainText>>Comment): I would first like to note that I
have<o:p></o:p></p>
<p class=MsoPlainText>>no issue with the AMS standard itself, and<o:p></o:p></p>
<p class=MsoPlainText>>understand that work done within my own<o:p></o:p></p>
<p class=MsoPlainText>>organisation has shown it to have a pretty solid
basis.<o:p></o:p></p>
<p class=MsoPlainText>><o:p> </o:p></p>
<p class=MsoPlainText>>My concerns are with the Red Book and perhaps<o:p></o:p></p>
<p class=MsoPlainText>>most significantly, the associated Test Report.<o:p></o:p></p>
<p class=MsoPlainText>><o:p> </o:p></p>
<p class=MsoPlainText>>On the Red Book, based on a relatively brief<o:p></o:p></p>
<p class=MsoPlainText>>review, I would like to voice similar criticisms<o:p></o:p></p>
<p class=MsoPlainText>>to those raised in recent reviews of the SM&C
books:<o:p></o:p></p>
<p class=MsoPlainText>>- I could not find a clear statement of how AMS<o:p></o:p></p>
<p class=MsoPlainText>>relates to other CCSDS standards, and what the<o:p></o:p></p>
<p class=MsoPlainText>>recommended full protocol stack should look like.<o:p></o:p></p>
<p class=MsoPlainText>>- It is not clear how AMS is intended to relate<o:p></o:p></p>
<p class=MsoPlainText>>to deployment within the ground segment.<o:p></o:p></p>
<p class=MsoPlainText>>- The language of the document seems to be<o:p></o:p></p>
<p class=MsoPlainText>>unnecessarily convoluted, which does not result in
clarity.<o:p></o:p></p>
<p class=MsoPlainText>><o:p> </o:p></p>
<p class=MsoPlainText>>On the Test Report, there are a number of serious
shortcomings:<o:p></o:p></p>
<p class=MsoPlainText>>- It does not conform to the Yellow book
document structure<o:p></o:p></p>
<p class=MsoPlainText>>- No explanation is given of the notation used<o:p></o:p></p>
<p class=MsoPlainText>>- No description is given of the actual test
procedures used<o:p></o:p></p>
<p class=MsoPlainText>>- The test report itself indicates that some<o:p></o:p></p>
<p class=MsoPlainText>>tests were not completed, and that others failed<o:p></o:p></p>
<p class=MsoPlainText>>because of implementation errors. Given this,
it<o:p></o:p></p>
<p class=MsoPlainText>>is difficult to see why the conclusion is that the
standard has been verified.<o:p></o:p></p>
<p class=MsoPlainText>><o:p> </o:p></p>
<p class=MsoPlainText>><o:p> </o:p></p>
<p class=MsoPlainText>><o:p> </o:p></p>
<p class=MsoPlainText>> Erik Barkley
(Abstain): although I am<o:p></o:p></p>
<p class=MsoPlainText>>abstaining as this does not directly affect the<o:p></o:p></p>
<p class=MsoPlainText>>CSS Area I would like to note the following:<o:p></o:p></p>
<p class=MsoPlainText>><o:p> </o:p></p>
<p class=MsoPlainText>>1) the recommendation would benefit from some<o:p></o:p></p>
<p class=MsoPlainText>>formal diagramming techniques. In particular,<o:p></o:p></p>
<p class=MsoPlainText>>there are a number of definitions that have<o:p></o:p></p>
<p class=MsoPlainText>>interrelationships from a continuum, venture,<o:p></o:p></p>
<p class=MsoPlainText>>cell, unit, node, etc. It would help the
reader<o:p></o:p></p>
<p class=MsoPlainText>>to gain familiarity via a UML class diagram<o:p></o:p></p>
<p class=MsoPlainText>>indicating the relationships of the various<o:p></o:p></p>
<p class=MsoPlainText>>terms, especially as they are fundamental to
recommendation.<o:p></o:p></p>
<p class=MsoPlainText>><o:p> </o:p></p>
<p class=MsoPlainText>>2) There are state definitions implied by<o:p></o:p></p>
<p class=MsoPlainText>>successful registration, missing heartbeats,<o:p></o:p></p>
<p class=MsoPlainText>>etc. I would strongly recommend that these<o:p></o:p></p>
<p class=MsoPlainText>>states be formally modeled and shown in something<o:p></o:p></p>
<p class=MsoPlainText>>like a UML State diagram -- this will help with<o:p></o:p></p>
<p class=MsoPlainText>>verification of recommendation correctness and<o:p></o:p></p>
<p class=MsoPlainText>>help implementation developments.<o:p></o:p></p>
<p class=MsoPlainText>><o:p> </o:p></p>
<p class=MsoPlainText>>3) The test report does not include any<o:p></o:p></p>
<p class=MsoPlainText>>information on the test cases/plans/design; it is<o:p></o:p></p>
<p class=MsoPlainText>>difficult to assess the adequacy of the testing<o:p></o:p></p>
<p class=MsoPlainText>>without this information; suggest including the<o:p></o:p></p>
<p class=MsoPlainText>>test cases/plans/design information in the test<o:p></o:p></p>
<p class=MsoPlainText>>report (or at least include it in the polling<o:p></o:p></p>
<p class=MsoPlainText>>materials?) Also, the test report has many<o:p></o:p></p>
<p class=MsoPlainText>>"Error! Reference source not found"
statements in it.<o:p></o:p></p>
<p class=MsoPlainText>><o:p> </o:p></p>
<p class=MsoPlainText>>4) It is a bit dismaying to see that the vast<o:p></o:p></p>
<p class=MsoPlainText>>majority of the RIDS were generated by one<o:p></o:p></p>
<p class=MsoPlainText>>individual at one member agency. In and of itself<o:p></o:p></p>
<p class=MsoPlainText>>this is not a critique of the recommendation but<o:p></o:p></p>
<p class=MsoPlainText>>rather a plea to be more effective in engaging<o:p></o:p></p>
<p class=MsoPlainText>>agency reviews. (This is aimed more at CCSDS in<o:p></o:p></p>
<p class=MsoPlainText>>general, not the AMS working group per se.)<o:p></o:p></p>
<p class=MsoPlainText>><o:p> </o:p></p>
<p class=MsoPlainText>>Summary: The recommendation does seem to be<o:p></o:p></p>
<p class=MsoPlainText>>generally quite good in terms of being a service<o:p></o:p></p>
<p class=MsoPlainText>>specification but would benefit from some formal<o:p></o:p></p>
<p class=MsoPlainText>>modeling information/diagram inclusion.<o:p></o:p></p>
<p class=MsoPlainText>><o:p> </o:p></p>
<p class=MsoPlainText>> Chris Taylor (Approve
with<o:p></o:p></p>
<p class=MsoPlainText>>Conditions): Just a comment not a condition for<o:p></o:p></p>
<p class=MsoPlainText>>publication. The SOIS is using a subset of the<o:p></o:p></p>
<p class=MsoPlainText>>AMS purely within the onboard segment and not<o:p></o:p></p>
<p class=MsoPlainText>>over the spacelink. This subset will be proven this
year by prototyping.<o:p></o:p></p>
<p class=MsoPlainText>><o:p> </o:p></p>
<p class=MsoPlainText>><o:p> </o:p></p>
<p class=MsoPlainText>>Total Respondents: 6<o:p></o:p></p>
<p class=MsoPlainText>><o:p> </o:p></p>
<p class=MsoPlainText>>No response was received from the following Area(s):<o:p></o:p></p>
<p class=MsoPlainText>><o:p> </o:p></p>
<p class=MsoPlainText>> SLS<o:p></o:p></p>
<p class=MsoPlainText>><o:p> </o:p></p>
<p class=MsoPlainText>>SECRETARIAT INTERPRETATION OF RESULTS:
Disapproved<o:p></o:p></p>
<p class=MsoPlainText>>PROPOSED SECRETARIAT
ACTION: To be
determined<o:p></o:p></p>
<p class=MsoPlainText>><o:p> </o:p></p>
<p class=MsoPlainText>>* * * * * * * * * * * * * * * * * * * * * * * *<o:p></o:p></p>
<p class=MsoPlainText>><o:p> </o:p></p>
<p class=MsoPlainText>><o:p> </o:p></p>
<p class=MsoPlainText>>_______________________________________________<o:p></o:p></p>
<p class=MsoPlainText>>CESG mailing list<o:p></o:p></p>
<p class=MsoPlainText>>CESG@mailman.ccsds.org<o:p></o:p></p>
<p class=MsoPlainText>>http://mailman.ccsds.org/mailman/listinfo/cesg<o:p></o:p></p>
<p class=MsoPlainText>><o:p> </o:p></p>
<p class=MsoPlainText>>_______________________________________________<o:p></o:p></p>
<p class=MsoPlainText>>Secretariat mailing list<o:p></o:p></p>
<p class=MsoPlainText>>Secretariat@mailman.ccsds.org<o:p></o:p></p>
<p class=MsoPlainText>>http://mailman.ccsds.org/mailman/listinfo/secretariat<o:p></o:p></p>
</div>
</div>
</body>
</html>