[Sis-ams] FW: [Secretariat] [CESG] Results of CESG poll closing 22 March 2010

[Burleigh, Scott C (313B)]

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.

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:

*         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.

*         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.

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.

Scott


>-----Original Message-----

>From: secretariat-bounces at mailman.ccsds.org [mailto:secretariat-

>bounces at mailman.ccsds.org] On Behalf Of CCSDS Secretariat

>Sent: Tuesday, March 23, 2010 9:50 AM

>To: cesg at mailman.ccsds.org

>Subject: [Secretariat] [CESG] Results of CESG poll closing 22 March 2010

>

>CESG E-Poll Identifier:  CESG-P-2010-03-002 CESG

>Approval of Asynchronous Message Service Blue Book

>Results of CESG poll beginning 6 March 2010 and ending 15 March 2010:

>

>                  Abstain:  1 (16.67%) (Barkley)

>  Approve Unconditionally:  1 (16.67%) (Durst)

>  Approve with Conditions:  2 (33.33%) (Shames, Taylor)

>  Disapprove with Comment:  2 (33.33%) (Peccia, Thompson)

>

>CONDITIONS/COMMENTS:

>

>      Peter Shames (Approve with

>Conditions):  Sec 1, the term "module" is

>extensively used, and seems to refer to an

>implemented piece of software in a data system,

>but it is not ever really defined and seems to be synonymous with "node".

>

>  The definitions in Sec 1.3.3.3 are somewhat

>complex and can be confusing because of all of

>the overlapping terminology.  One or more

>diagrams that discriminate: continuum, venture,

>unit, cell, domain, node, cell, and root cell would be really useful.

>

>Pg 1-5, The definition of the term "node", i.e.

>"A node (i.e., a mission data system module) is a

>communicating entity that implements some part of

>the functionality of some AMS venture" is

>inconsistent with the use of the term node in

>RASDS and in many other contexts.  Node here

>appears to be used to refer to a software

>module.  Node is RASDS (and elsewhere) is used to

>refer to a physical object.  Suggest the use of

>the term "component" or some more software

>relevant term instead.  If, instead, you really

>do mean a physical node, i.e. a computer or other

>physical object, then you need to clean up your

>definition and use.  The use of the term in 2.1

>only complicates the matter "Messages are

>exchanged directly between modules (nodes)".

>

>Sec 2.1.2:  A number of terms that appear in the

>text in italics, e.g. reply, context, query are

>not defined but are apparently just to be

>understood in context.  It would be better if these were unambiguously

>defined.

>

>Sec 2.2.1: The term "application" is used earlier

>in a software sense to define "a data system

>implementation, typically taking the form of a

>set of source code text files".  This sounds like

>a body of software, described separately from its

>deployment in a real system.  In this section, in

>figure 2-1, there is an element labeled

>"application Q, authority R", but this appears to

>represent a real deployment in a real

>system.  Isn't this actually a "venture"

>according to the definitions provided earlier,

>i.e. "a functioning projection of the application-

>for which some authority is responsible - onto a

>set of one or more running computers"?

>

>Sec 2.3.1: "AAMS occupies a position in the OSI

>protocol stack model somewhere between level 4

>(Transport) and level 7 (Application);".  I would

>state unequivocally that AMS is a LAYER 7

>application service.  As defined in the ISO-BRM:

>"7.1.3.1.2 As the only layer in the Reference

>Model that directly provides services to the

>application-processes, the Application Layer

>necessarily provides all OSI services directly usable by application-processes.

>7.1.3.1.3 There exists no Application Layer

>service in the sense of (N)-layer service in that there is neither a general

>service provided to an upper layer nor a relation to a service-access-point. "

>

>Sec 2.3.1 describes "The network location at

>which a node can receive messages" but the term

>"network location" is not defined.  Further, it

>sounds a lot like a reference to a port of a

>physical node in a real system, not to a logical

>interface for a software module as implemented in

>a real system.  Suggest that this language get

>cleaned up as it is potentially confusing.

>

>Sec 2.3.4 jumps into use of the terms N4, N3, N6

>without ever introducing them or what they might

>mean.  One is left to deduce this from context.

>

>Sec 2.3.8 makes references to the use of public

>keys, encryption, authentication without

>providing any references for these terms.  Some

>tie to these terms, as defined in CCSDS security

>standards or elsewhere should be provided.

>

>Sec 4:  While the text in this section is quite

>clear the use of either state machines or a state

>table would make the whole protocol operation

>much clearer.  Where this has been done in other

>protocol specifications it has been found to be

>of a great help and it is a recommended practice.

>

>Sec 4.2.5.5.5, the term "capsule" is used before

>it is defined.  When later defined, in sec 5.3.4,

>it is said to be "A capsule is a data structure

>that is identical in format and semantics to an

>AAMS message, including optional checksum, except

>that it is never passed to a transport service for

>transmission. "  The use of this separate term

>for an object that appears to be exactly

>identical to an AAMS message seems gratuitous and potentially confusing.

>

>Sec 6.2 on an AMQP based AMSP can be read to be a

>part of the normative specification, yet it is

>neither required nor authoritative, merely

>exemplary.  It should be marked as such.

>

>Sec 8, the MIB should presumably include

>definitions for N4 and N5, along with those for N1, 2, 3 and 6.

>

>Annex A, the list of recognized transport

>services is defined as normative, but is

>presumably an extensible set.  How is this

>handled?  It is registered somewhere?

>

>Sec E1, same comment as earlier, AMS is an application LAYER service.

>

>      Nestor Peccia (Disapprove with

>Comment):  Criticisms as those raised on the SM&C books apply:

>-  No clear statement of how AMS relates to other

>CCSDS standards, and what the recommended full protocol stack should look

>like.

>-  No clear how AMS is intended to relate to

>deployment within the ground segment. What is a

>module of a ground data system ? Where is defined

>? Which agreed reference architecture  is used as baseline for the RB ?

>- No definition of what a service is, what a

>service layer is, no mention of interfaces,

>protocols, bindings, relations between service

>provider and consumer, how it relates to other kinf of standards ?

>

>On the Test Report, comments are as follows:

>General:

>The AMS test report does not conform to the Yellow book document structure.

>No explanation of the notation used for the tables is provided.

>No reference or explanation of the actual test procedures is provided.

>

>Specific:

>Section 1)

>It is assumed that Security and Checksum shall be

>removed from the specification as per the process

>for CCSDS "In cases in which one or more options

>or features have not been demonstrated in at

>least two interoperable prototypes or

>implementations, the specification may advance to

>the CCSDS Recommended Standard level only if

>those options or features are removed. "

>

>Section 2.3)

>It is assumed that the relevant sections of the

>specification shall be removed seeing as "The

>indicated steps in chapter 2.3b were not

>performed due to the unavailability of underlying

>capabilities at the time of testing".

>

>Section 3.2)

>As the second configuration was not completed

>this cannot be considered a complete test and

>therefore the specification has not been

>completely verified by two implementations, I

>cannot see how this can be considered proper validation of the red book.

>

>Section 4.1)

>Many tests were not performed in this section due

>to implementation bugs. The statement "Deferred

>steps in this series indicate implementation

>bugs, and not specification issues.". Until all

>tests are passed how can it be proven that other hidden issues do not exist?

>

>      Rodger Thompson (Disapprove with

>Comment):  I would first like to note that I have

>no issue with the AMS standard itself, and

>understand that work done within my own

>organisation has shown it to have a pretty solid basis.

>

>My concerns are with the Red Book and perhaps

>most significantly, the associated Test Report.

>

>On the Red Book, based on a relatively brief

>review, I would like to voice similar criticisms

>to those raised in recent reviews of the SM&C books:

>-  I could not find a clear statement of how AMS

>relates to other CCSDS standards, and what the

>recommended full protocol stack should look like.

>-  It is not clear how AMS is intended to relate

>to deployment within the ground segment.

>-  The language of the document seems to be

>unnecessarily convoluted, which does not result in clarity.

>

>On the Test Report, there are a number of serious shortcomings:

>-  It does not conform to the Yellow book document structure

>-  No explanation is given of the notation used

>-  No description is given of the actual test procedures used

>-  The test report itself indicates that some

>tests were not completed, and that others failed

>because of implementation errors.  Given this, it

>is difficult to see why the conclusion is that the standard has been verified.

>

>

>

>      Erik Barkley (Abstain):  although I am

>abstaining as this does not directly affect the

>CSS Area I would like to note the following:

>

>1) the recommendation would benefit from some

>formal diagramming techniques. In particular,

>there are a number of definitions that have

>interrelationships from a continuum, venture,

>cell, unit, node,  etc.  It would help the reader

>to gain familiarity via a UML class diagram

>indicating the relationships of the various

>terms, especially as they are fundamental to recommendation.

>

>2) There are state definitions implied by

>successful registration, missing heartbeats,

>etc.  I would strongly recommend that these

>states be formally modeled and shown in something

>like a UML State diagram -- this will help with

>verification of recommendation correctness and

>help implementation developments.

>

>3) The test report does not include any

>information on the test cases/plans/design; it is

>difficult to assess the adequacy of the testing

>without this information; suggest including the

>test cases/plans/design information in the test

>report (or at least include it in the polling

>materials?)  Also, the test report has many

>"Error! Reference source not found" statements in it.

>

>4) It is a bit dismaying to see that the vast

>majority of the RIDS were generated by one

>individual at one member agency. In and of itself

>this is not a critique of the recommendation but

>rather a plea to be more effective in engaging

>agency reviews. (This is aimed more at CCSDS in

>general, not the AMS working group per se.)

>

>Summary: The recommendation does seem to be

>generally quite good in terms of being a service

>specification but would benefit from some formal

>modeling information/diagram inclusion.

>

>      Chris Taylor (Approve with

>Conditions):  Just a comment not a condition for

>publication. The SOIS is using a subset of the

>AMS purely within the onboard segment and not

>over the spacelink. This subset will be proven this year by prototyping.

>

>

>Total Respondents:  6

>

>No response was received from the following Area(s):

>

>      SLS

>

>SECRETARIAT INTERPRETATION OF RESULTS:  Disapproved

>PROPOSED SECRETARIAT ACTION:            To be determined

>

>* * * * * * * * * * * * * * * * * * * * * * * *

>

>

>_______________________________________________

>CESG mailing list

>CESG at mailman.ccsds.org

>http://mailman.ccsds.org/mailman/listinfo/cesg

>

>_______________________________________________

>Secretariat mailing list

>Secretariat at mailman.ccsds.org

>http://mailman.ccsds.org/mailman/listinfo/secretariat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/sis-ams/attachments/20100401/a9d092da/attachment-0001.htm