[Cesg-all] Result of CESG poll closing 31 January 2011

[CCSDS Secretariat]

CESG E-Poll Identifier:  CESG-P-2011-01-002 
Approval to release CCSDS 875.0-R-1, Spacecraft 
Onboard Interface Services--Message Transfer 
Service (Red Book, Issue 1) for CCSDS Agency review
Results of CESG poll beginning 15 January 2011 and ending 31 January 2011:

                  Abstain:  0 (0%)
  Approve Unconditionally:  5 (83.33%) (Peccia, Barkley, Taylor, Moury, Durst)
  Approve with Conditions:  1 (16.67%) (Shames)
  Disapprove with Comment:  0 (0%)

CONDITIONS/COMMENTS:

      Peter Shames (Approve with 
Conditions):  The vote is "Approve with 
conditions", but "Disapprove" could have been 
equally well applied. The document is ambiguous 
and miscast, thus needs extensive revisions, as 
noted below and in that attached markup 
text.  However, because much of the required 
content is present, the document can be rendered 
useful with major editing, but without the need for a total restructuring.

This document states that it's Purpose & Scope is to:

"The purpose of this document is to define 
services and service interfaces provided by the 
SOIS Message Transfer Service (MTS). Its scope is 
to specify the service only and not to specify 
methods of providing the service, although use of 
the SOIS subnetwork services is assumed."

The document, in its current form, does not 
define services, nor service interfaces, nor an 
API.  Instead it defines how to use AMS to 
provide the required protocol functionality, and 
uses many different AMS elements in explaining 
what it is about, all the while remaining coy 
about whether AMS is really adopted, or not.  The 
only very abstract service interface is drawn, by reference, from AMS itself.

The document is properly cast as a Magenta Book, 
recommended practice.  However, if is is to 
remain in its present form it should properly be 
relabeled as an Application Profile for how to 
use AMS to implement the MTS service. In that 
case it needs to change a lot of its text to 
reflect that intent and to remove the present 
ambiguities.  In this form it would also benefit 
from a protocol diagram showing how these layers 
stack up, MTS / AMS / SOIS Subnetwork Packet Service.

Some improved form of abstract service interface 
would also be appropriate in that situation.  Sec 
3.4 makes reference to adoption of AMS, so if the 
document were recast as an Application profile 
this binding could be clearly stated as the exposed MTS service interface.

Given the ambiguities in the present document 
this assumption cannot be safely made.  See statements in Sec 2-1:

"The Message Transfer Service is defined using a 
subset of the services provided by the CCSDS 
Asynchronous Message Service (AMS) (reference 
[1]), as defined in 3.3. Although the services 
are defined to be independent of the underlying 
protocol, it is recommended that the protocol 
used by the Message Transfer Service be the 
subset of the protocol provided by the AMS"

And in Sec 3.3.1:

"The Message Transfer Service shall use the 
following parameters (being the full set of 
parameters of AMS (reference [1]) but with a 
restricted definition as indicated)"

But in Sec 4.1 it says:

"NOTE – While multiple protocols may be used to 
support the Message Transfer Service, only one 
protocol, a subset of AMS, is currently defined by this standard.

The subset of AMS protocols defined in 4.2 should 
be supported by the SOIS Subnetwork Packet Service (reference [2])."

and in Sec 6.1:

"If the subset of AMS and Meta-AMS protocol is 
selected as the Protocol Specification, then the 
subset of the MIB of AMS (reference [1]), as 
defined in the following subsections, shall apply 
(taking into account the subset of AMS and 
Meta-AMS protocols defined in this Recommended Practice)."

Further, Annex B, which is only informative, adds 
to the confusion.  It is the only "Underlying 
Transport Service" in the document, making it 
confusing as to its relationship to AMS and MTS, and it says this:

"The Message Transfer Service Underlying 
Transport Service is dependent upon the selected 
Message Transfer Service Protocol Definition. The 
following subsections define the recommended use 
of the SOIS Subnetwork Packet Service (reference 
[2]) for each of the identified Message Transfer Service protocols."

This reference to "each of the identified MTS 
protocols" is confusing, largely because there is 
only one ever referenced in the document, namely 
AMS.  In fact, if all of the AMS content were to 
be removed the document would be totally gutted, 
hence this coy approach of "we're using AMS 
extensively, but not adopting it" is really inexplicable.

The document would be much clearer in its intent 
if it were simply cast as an Application Profile 
for "MTS Implementation using AMS".  As it stands 
it is neither fish nor fowl. It equivocates as to 
whether it is just that, while all the while adopting AMS constructs.

Sec 1.5.3.2, many terms used in unique ways in 
this document are not defined.  See notes 
throughput the document where these have been identified.

      Erik Barkley (Approve Unconditionally):  Comments:

The document may proceed to agency review.

I do have a few findings that I would like to 
request that working group address as part of the 
formal agency review if they are not addressed prior to the agency review:

  1) Page 2-2, interactions with regard to AMS 
monitoring of registrar health and configuration 
failover are indicated as being deprecated to 
optional.   I would suggest for ease of 
understanding by the reader stating this just 
simply as that it is not required. As it is 
currently phrased it tends to give the impression 
(at least to this reader) that the deprecation 
was from required to optional when in fact AMS 
already allows for this to be optional.

  2) Page 2-4 -- security considerations. In 
general it is hard to argue with the assumptions 
of operating in an isolated environment, but the 
treatment of confidentiality with regard to 
science data only seems to be dismissing 
application of MTS in a manned mission context. I 
suspect that the isolated environment is perhaps 
not quite so isolated in a large multi agency 
mission such as ISS – my understanding is that 
new data generating equipment is rolled in and 
out on a somewhat regular basis, and of course 
there is a fair amount of human communications 
involved. It may be worthwhile to re-examine the 
statement that there are no identified security 
concerns.  It may also be worth noting that as 
AMS is used, that in fact encryption keys etc. 
are already part of the security landscape for MTS.

3) Page 3-2 -- suggest formally defining 
Quality-of-Service parameters -- these are listed 
as an example as being "service class, priority 
and timeout".  If the flow label parameter is to 
be mapped onto this it seems then that there 
should be a formal definition so that the mapping can in fact be defined.

4) Pages 3-2, 3-3 -- the usage of AMS "term" and 
"flow label"  may perhaps be somewhat overlapping 
with regard to their semantics.  "flow label" 
(which AMS defines as an integer 0 to 65535 ) is 
indicated as mapping into QoS, while the  AMS 
"term" parameter indicates that it's definition 
is explicitly with regard to timeout 
considerations.  It is not clear from the 
document how timeouts are to be indicated in MTS 
(via flow label? or term? or some combination?)

5) Page 4-1 suggest relabeling section 4 header 
to be "AMS PROTOCOL PROFILE" as this section is 
very much about indicating constraints/restrictions on AMS protocol.

6) Page 5-1 suggest relabeling section 5 header 
to be "AMS PROTOCOL DATA UNITS" as this section 
is very much about indicating constraints/restrictions on AMS PDUs.


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

* * * * * * * * * * * * * * * * * * * * * * * *
CESG E-Poll Identifier:  CESG-P-2011-01-003 
Approval to release CCSDS 401.0-P-20.1, Radio 
Frequency and Modulation Systems-Part 1: Earth 
Stations and Spacecraft (Pink Sheet, Issue 20.1) for CCSDS Agency review
Results of CESG poll beginning 19 January 2011 and ending 31 January 2011:

                  Abstain:  0 (0%)
  Approve Unconditionally:  5 (83.33%) (Peccia, Barkley, Taylor, Moury, Durst)
  Approve with Conditions:  1 (16.67%) (Shames)
  Disapprove with Comment:  0 (0%)

CONDITIONS/COMMENTS:

      Peter Shames (Approve with 
Conditions):  This Pink Sheet has appropriate 
technical content. However, it makes a change in 
terminology from "Mbps" to "Mb/s" in Sec 
2.2.8.  Sec 2.2.7, which is not touched by these 
Pink Sheets continues to use the term 
"Mbps".  The minimum recommend change that the WG 
change all uses of the term in the doc to be consistent.

Note that "Kb/s" is used in several other places 
in the document, so the use of "b/s" for "bits 
per second" seems to be nearly consistent 
throughput.  However, the International 
Electromechanical Commission (IEC) published 
Amendment 2 to "IEC 60027-2: Letter symbols to be 
used in electrical technology – Part 2: 
Telecommunications and electronics."  In that 
document the terms "Mbits/s" and "Kbits/s" are 
preferred usage, because they eliminate 
ambiguity.  Recommend that the WG consider 
adopting this consistent terminology throughout 
at the next revision opportunity.

[DOCUMENT EDITOR NOTE: The change from Mbps to 
Mb/s is an editorial change made for compliance 
with the CCSDS Publications Manual, which 
requires SI units, and as such it is not subject 
to review.  The same change will be made 
throughout the document in the next published version.]


Total Respondents:  6

All Areas responded to this question.



SECRETARIAT INTERPRETATION OF RESULTS:  Approved
PROPOSED SECRETARIAT ACTION:            Generate CMC poll

* * * * * * * * * * * * * * * * * * * * * * * *