[Cesg-all] Results of CESG Polls closing 1 August 2017

Wed Aug 2 20:00:15 UTC 2017

CESG E-Poll Identifier: CESG-P-2017-07-001 
Approval to release CCSDS 431.1-R-1, Variable 
Coded Modulation Protocol (Red Book, Issue 1) for CCSDS Agency review
Results of CESG poll beginning 18 July 2017 and ending 1 August 2017:

                  Abstain:  0 (0%)
  Approve Unconditionally:  6 (85.71%) (Barkley, 
Merri, Burleigh, Cola, Calzolari, He)
  Approve with Conditions:  1 (14.29%) (Shames)
  Disapprove with Comment:  0 (0%)

CONDITIONS/COMMENTS:

Peter Shames (Approve with Conditions): See 
attached PID form and marked up document. There 
are a few items that should be cleaned up before 
this is sent out for agency review.

Here is a high level summary:

1) The SANA, Security, and Patent Annexes are missing.
2) The explicit definitions of pilots appears ambiguous (pg 3-1)
3) Some of the explanations of the relationships 
among this doc, and [2] and [4] could be clearer. 
See pos 1-1, 3-1, 3-2, and Annex B.
4) Sec 4 could reference, even if in passing, 
that these Managed Parameters, in a compliant 
CCSDS cross support deployment, would be handled by CCSDS Service Management.

Scott Burleigh (Approve Unconditionally): No 
conditions, but three comments. (1) On page 1-2, 
I think it would be good to define "ASM". (2) On 
page 2-1, I would have liked to have seen a note 
on why this protocol is not applicable to uplink. 
(3) On page 4-1: a personal preference, I think 
"static" would be better than "permanent".

Total Respondents: 7
No response was received from the following Area(s):

SOIS

SECRETARIAT INTERPRETATION OF RESULTS:  Approved with Conditions
PROPOSED SECRETARIAT ACTION:            Generate 
CMC poll after conditions have been addressed

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

CESG E-Poll Identifier: CESG-P-2017-07-002 
Approval to release CCSDS 141.0-R-1, Optical 
Communications Physical Layer (Red Book, Issue 1) for CCSDS Agency review
Results of CESG poll beginning 18 July 2017 and ending 1 August 2017:

                  Abstain:  0 (0%)
  Approve Unconditionally:  4 (57.14%) (Merri, Burleigh, Calzolari, He)
  Approve with Conditions:  3 (42.86%) (Barkley, Shames, Cola)
  Disapprove with Comment:  0 (0%)

CONDITIONS/COMMENTS:

Erik Barkley (Approve with Conditions): This may 
be more of a quesion than a condition, but filed 
as condition pending further input: it seems odd 
to have a book going to agency review when the 
patent considerations section is indicated as "To 
be supplied." I think the agencies would 
appreciate knowing if there are patent 
considerations as part of the agency review. The 
statement is ambigous and can be read as "yes, 
there are and they are forthcoming" -- if they 
are known why not state them for agencies to be aware of?

Similarly for SANA considerations -- it does not 
seem like there is anything in particular that 
needs to be registered, so perhaps indicate 
"none" or indicate what it is that gets 
registered so that the agencies are aware/have been informed?

Peter Shames (Approve with Conditions): See 
attached PID file and marked up document. There 
are a number of issues that need to be cleaned up 
before this goes out for agency review.

Here is a high level summary:

1) Definitions appear to be incomplete
2) Several abbreviations used without being defined
3) SANA and Patent sections are missing, they 
could at least be sketched in at this point. 
There are a few SANA Registries that will need to 
be updated to add optical comm coverage.
4) Rationale is weak, it essentially says CCSDS 
says there should be one, but we did not provide even a hint.

Scott Burleigh (Approve Unconditionally): No 
conditions, but two comments. (1) On page 2-1, 
the reader might wonder how it is possible to 
assess the correctness of this document in the 
absence of rationale, which will only be provided 
in a future informative document; some 
explanation would be appropriate. (2) On page 
B-1, security might be provided at the 
application and/or transport **and/or network** layer.

Tomaso de Cola (Approve with Conditions): 1) The 
book deals with optical communications: why not 
stating that is about free-space optical 
communications, since optical communications 
(e.g., LiFi) could be used onboard spacecraft or 
on planets to link rovers and landers (for example)?

2) Section 2.2 states that one of the objectives 
of the book is to define the center wavelength. 
As a matter of fact, the center frequency (from 
which wavelngth in vacuum can be derived) is the 
first objective (see section 3 and subsequent).

3) Section 1.1 states that the specification 
deals only with space-to ground and 
ground-to-space. Could it me explicitly stated 
that space-to-space is beyond the scope of this release of the book?

4) Section B.1.1 states that security is provided 
by upper layers, indicating transport and 
application layers as those eligilbe for it. In 
my view, SDLS is also to be considered. Without 
entering the jungle of all possible protocol 
providing secure communication, the brackets and 
the indication of transport/application layer could be simply removed.

5) No clear if there are patent implications to 
be provided in the next release or there are none.

Total Respondents: 7
No response was received from the following Area(s):

SOIS

SECRETARIAT INTERPRETATION OF RESULTS:  Approved with Conditions
PROPOSED SECRETARIAT ACTION:            Generate 
CMC poll after conditions have been addressed

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

CESG E-Poll Identifier: CESG-P-2017-07-003 
Approval to release CCSDS 922.2-R-1, Cross 
Support Transfer ServiceTracking Data Service 
(Red Book, Issue 1) for CCSDS Agency review
Results of CESG poll beginning 18 July 2017 and ending 1 August 2017:

                  Abstain:  0 (0%)
  Approve Unconditionally:  4 (66.67%) (Barkley, Burleigh, Cola, Calzolari)
  Approve with Conditions:  2 (33.33%) (Merri, Shames)
  Disapprove with Comment:  0 (0%)

CONDITIONS/COMMENTS:

Mario Merri (Approve with Conditions): General
I believe more work is required on this book and 
I have provided my comments below. In general 
terms I have the following major considerations:
1) I had the impression in a few places of the 
document that an architecture of the systems 
providing the data is prescribed instead of only 
specifying the service interface.

2) Considering that the service is meant to 
transfer the handful of tracking-related 
parameters using relatively simple transfer 
patterns (real-time/complete, 
streaming/playback), I cannot really match this 
with the complexity of the proposed standard (94 pages).

3) The initial sections are difficult to read and often unclear

Detailed comments.

1.2.1 SCOPE OF THE TD-CSTS
The section dedicates 2 out of 3 paragraphs to 
describe what is not covered in the scope. The 
one paragraph that states what is in scope is not 
very clear and requires knowledge of refernce 
[3]. I recommend that this section is made more 
clear as to clearly identifiy the scope of the document.

1.3 APPLICABILITY
I do not find this sectiuon clear. The typical 
use case where this service could help should be clearly identified.

1.5.2 CROSS SUPPORT TRANSFER SERVICES DOCUMENTATION
This section is not very clear, including the 
picture, which seems to provide an overview of 
the full CSS area: where are all the service 
management docs? Also, it is not clear where does the current document fit.

2.1 SERVICE SUMMARY
"The data delivery mode of an instance of the 
TD-CSTS is established by Service Management" 
where is this define the SM books?

I do not undertstand the relevance of the note. 
Why should the format be different?

2.2.1 GENERAL
I have difficulties in understanding the example 
in the last paragraph "A Service Package can contain multiple instances ..."

2.2.2 SERVICE PRODUCTION
The tracking-data-generating functions depicted 
in figure 2-1 seems to prescribe an architecture 
of the systems providing the data. Is this always 
the same regardless the antenna ownership? The 
standard should focus on the interface rather 
than on the way the exchanged data are produced. 
Clealry I understahnd that in this case metadate 
such as carrier power ... are important to 
qualify the date and must be included in the interface.

"TDM Recording Buffer": this also seems to 
prescribe an implementation to allow the delivery 
modes (complete or real-time). While I think the 
delivery modes are indeed part of the interface, 
the prescription on how to implement them are not.

2.2.3 SERVICE PROVISION
"TD-CSTS is equal to, and configured through, the 
data delivery mode of the Buffered Tracking Data 
Message Delivery procedure ...": didn't you say 
before that was configured via SM?

2nd paragraph "In the real-time data delivery 
mode ...": I cannot really understand the final part.

Also the remaining part of the section is 
difficult to understand and confusing.

2.3 SERVICE MANAGEMENT
Which SM books define what is presented in this section?

2.4 CROSS SUPPORT VIEW
"The merged and TDM-segmented tracking data ...": 
what does this mean? In addition this paragraph 
prescribes an implementation that is irrelevant to the interface.

2.5 OPERATIONAL SCENARIO
I do not see anything specific to tracking data 
in the proposed services. The services described 
are good to transmit any type of data that is 
available either in real time (streaming) or 
playback and is to be delivered in complete or 
real-time mode. It is just a "transfer any data" 
service or am I wrong? Why do we need a book specific to TDM?

3.1 DISCUSSION
The title of the section is arguable considering its content.

"The Tracking Data CSTS may be implemented ...": 
again it seems more a proposed implementation 
than the specification of a standard service interface.

4.4.1 OVERVIEW
The point raised on Section 2.5 above seems to be 
confiremed in Section 4.4.1 OVERVIEW where it is 
stated "The overall activities of the Buffered 
Tracking Data Message Delivery procedure are the 
same as those of the standard Buffered Data 
Delivery procedure as defined in 4.5 of reference 
[1]." If this is the case, why a 94 page document is needed?

5. SETTING OF SERVICE ...
Typo in the title FRAMEWWORK->FRAMEWORK

6 TRACKING DATA SERVICE-SPECIFIC ...
Can't we find an easier section title?

Annex B
Considering that the service is meant to transfer 
the handful of parameters defined in this annex 
using relatively simple transfer patterns 
(real-time/complete, streaming/playback), I 
cannot really match this with the complexity of the proposed standard.

Peter Shames (Approve with Conditions): This 
document is in very good shape and most of the 
comments are editorial in nature. See the attached mark-up document.

Here is a high level summary:

- The biggest issue is that the document is not 
entirely clear on just what the contents of the TDM data stream.
 Sec 2.2.3 says: Each TD-CSTS instance 
operating in the real-time mode transfers the 
atomic segments, each of which contains one 
measurement of one of the selected tracking data 
types, as they are made available by the TDM Segment Generation function.
 Sec 2.2.1 says: "each of the TD-CSTS instances 
has access to the two-way Doppler and angle tracking measurements.

- It is not ever made completely clear that the 
real time TDM data stream can contain a sequence 
of TDM atomic segments each of which can contain a different data type.

- Much of Sec 2.5 (six pages) seems to be about 
Service Management and the behavior of the 
TD-CSTS service as configured by this. This is 
useful, but is it your intention to include this 
sort of behavioral description in every CSTS 
service spec and thereby avoid needing to produce 
a GB as well? This is fundamentally a document consistency question.

- In Sec B3 on TDM Atomic Segments it might be 
good to be really explicit (if this is the case) 
that successive Atomic Segments may contain 
different data types, from the list on pg B-1, 
but all taken at the same time. For instance, an 
example showing Doppler, range, and antenna 
tracking angles might make this clear. This also 
relates to the first comment, above.

- In Sec 6 OIDs are referenced, but they are not 
defined nor are they in the acronym list.

- There are some issues in Annex G2 on SANA Considerations.

Scott Burleigh (Approve Unconditionally): No 
conditions, but a suggestion: page 2-1 refers to 
"network" and "backpressure" but there is nowhere 
any discussion of what this means. I think a 
section enumerating "Requirements on the 
underlying service" would be appropriate.

Gian Paolo Calzolari (Approve Unconditionally): 
Comment: I just find a little odd that there is 
no mention (e.g. among informative references) of 
the radio metric standards the production is 
expected to support. The matter can be discussed during Agency Review.

Total Respondents: 6
No response was received from the following Area(s):

SOIS

SECRETARIAT INTERPRETATION OF RESULTS:  Approved with Conditions
PROPOSED SECRETARIAT ACTION:            Generate 
CMC poll after conditions have been addressed

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

CESG E-Poll Identifier: CESG-P-2017-07-004 
Approval to release CCSDS 921.2-R-1, Guidelines 
for Specifications of Cross Support Transfer 
Services (Red Book, Issue 1) for CCSDS Agency review
Results of CESG poll beginning 18 July 2017 and ending 1 August 2017:

                  Abstain:  1 (16.67%) (Calzolari)
  Approve Unconditionally:  3 (50%) (Barkley, Burleigh, Cola)
  Approve with Conditions:  2 (33.33%) (Merri, Shames)
  Disapprove with Comment:  0 (0%)

CONDITIONS/COMMENTS:

Mario Merri (Approve with Conditions): GENERAL
1) The document seems to provide an extra large 
set of guidelines internal to the CSTS WG on how 
to write future BBs specifying CSTSes. To this 
effect the book is clearly useful, but I am not 
sure about its usefulness as CCSDS recommended 
practice. Is there really the possibility that 
people external to CCSDS will come up with new 
CSTS Services? Shouldn't this document just be an 
internal unpublished guideline.

2) The number of guidelines is very large (111 
pages) and they are expressed mainly as textual 
requirements. This implies that checking 
compliance of future prospective CSTS services 
would be very difficult, expensive and error 
prone. Was any alternative approach considered 
that could improve this, e.g. XML schema?

1.1 PURPOSE OF THIS RECOMMENDED PRACTICE
Please add the following sentect after the second 
paprgraph: "In the context of CSTS a ground 
entity is either a ground station or a control centre."

Peter Shames (Approve with Conditions): This 
document is very mature and there are few 
editorial or technical issues that need to be 
addressed. These are reflected in the attached marked-up version.

That said, the Applicability Section, sec 1.3, 
makes it sound like this document is really a 
specification for how CCSDS should use the 
features of the CSTS Framework to create new 
concrete CSTS services. As such it seems to be 
more of a CCSDS internal procedure, i.e. Yellow 
Book, than a Magenta Book that any user might attempt to utilize.

Having read through the whole (long) document it 
is clear that this really is a document that is 
intended for CCSDS WGs that want to develop new 
CSTS Framework based standards. I am certain that 
it will be useful to that group of users. That 
said, those users are not the typical space 
data system users that our standards are designed for.

Based on this analysis I am suggesting that you 
publish this as a Yellow Book, a recommended 
practice for development of CSTS standards, and 
not as a MB. I am concerned that sending it out 
for agency review will only confuse our users, 
who would then be wondering what they should do 
with it. Or, if we send it our for draft MB 
review and later choose to publish as a Yellow 
Book, we leave them wondering why we didnt get 
the color right in the first place.

Tomaso de Cola (Approve Unconditionally): Some editorial comments:

1) The ToC does not include Annex X

2)The note after paragraph 4.6.4.2 refers to 
annex xx, which apparently does not exist

3) Annex C starts with C1, C2 and then 3. I guess it should be C3, C4. etc.

4) Annex X is without a title (there is 
immediately X.1). By the way, why annex X after 
annex C and before Annex D? Wouldn't it be better 
to have annexes A, B, C, D, E, etc.?

Total Respondents: 6
No response was received from the following Area(s):

SOIS

SECRETARIAT INTERPRETATION OF RESULTS:  Approved with Conditions
PROPOSED SECRETARIAT ACTION:            Generate 
CMC poll after conditions have been addressed

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