[Cesg-all] Results of CESG polls closing 15 January 2014

[CCSDS Secretariat]

CESG E-Poll Identifier:  CESG-P-2013-12-001 
Approval to publish CCSDS 521.1-B-1,  Mission 
Operations Common Object Model (Blue Book, Issue 1)
Results of CESG poll beginning 31 December 2013 and ending 15 January 2014:

                  Abstain:  1 (25%) (Calzolari)
  Approve Unconditionally:  2 (50%) (Peccia, Scott)
  Approve with Conditions:  1 (25%) (Barkley)
  Disapprove with Comment:  0 (0%)

CONDITIONS/COMMENTS:

      Erik Barkley (Approve with 
Conditions):  Condition:  1) Please state the 
update/maintenance policy for the Schema in the 
SANA registry. [Condition satisfied via e-mail 1/16/2014]

Comments only, not conditions:

1) A more general CCSDS question, but its not 
clear how the archive service interacts/utilizes 
the CCSDS PAIS recommendation; there seems to be an overlap here.

2) It would be an interesting exercise to stack 
up the underlying transport recommendations to 
see how determination of where a message is 
expected to move next and when is performed over, 
say, DTN -- by definition, this is delay tolerant 
and the exact delay is not necessarily known; 
further there are DTN local QOS 
considerations.  How much link communications 
geometry, incl one-way-light time delay vs. on 
board s/c data storage vs QOS priorities will activity tracking be aware of?


Total Respondents:  4

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

      SEA
      SOIS

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

* * * * * * * * * * * * * * * * * * * * * * * *
CESG E-Poll Identifier:  CESG-P-2013-12-002 
Approval to publish CCSDS 
414.1-B-2,  Pseudo-Noise (PN) Ranging Systems (Blue Book, Issue 2)
Results of CESG poll beginning 31 December 2013 and ending 15 January 2014:

                  Abstain:  1 (25%) (Scott)
  Approve Unconditionally:  3 (75%) (Peccia, Barkley, Calzolari)
  Approve with Conditions:  0 (0%)
  Disapprove with Comment:  0 (0%)

Total Respondents:  4

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

      SEA
      SOIS

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

* * * * * * * * * * * * * * * * * * * * * * * *
CESG E-Poll Identifier:  CESG-P-2013-12-003 
Approval to publish CCSDS 414.0-G-2, Pseudo-Noise 
(PN) Ranging Systems (Green Book, Issue 2)
Results of CESG poll beginning 31 December 2013 and ending 15 January 2014:

                  Abstain:  1 (25%) (Scott)
  Approve Unconditionally:  3 (75%) (Peccia, Barkley, Calzolari)
  Approve with Conditions:  0 (0%)
  Disapprove with Comment:  0 (0%)

Total Respondents:  4

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

      SEA
      SOIS

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

* * * * * * * * * * * * * * * * * * * * * * * *
CESG E-Poll Identifier:  CESG-P-2013-12-004 
Approval to publish CCSDS 
651.1-B-1,  Producer-Archive Interface 
Specification (PAIS) (Blue Book, Issue 1)
Results of CESG poll beginning 31 December 2013 and ending 15 January 2014:

                  Abstain:  2 (50%) (Calzolari, Scott)
  Approve Unconditionally:  1 (25%) (Peccia)
  Approve with Conditions:  1 (25%) (Barkley)
  Disapprove with Comment:  0 (0%)

CONDITIONS/COMMENTS:

      Erik Barkley (Approve with Conditions):  It 
seems odd that this recommendation, which defines 
normative XML Schema, does not discuss 
registering and subsequent maintenance of this 
Schema in SANA. Request that the schema be 
registered and that a policy be stated in the blue book for doing so.

      Keith Scott (Abstain):  I'd like some 
clarification on the rules for interoperability 
testing, interoperability testing waivers, and test reports.

The test report lists multiple capabilities with 
interoperability level 0.5 [0.5 (orange) if an 
element of “medium” criticality is not implemented in the Test Cases or
any of the software prototype;] and a few 
capabilities are reported with interoperability 
level 0 [– 0 (red) if an element of “high” 
criticality is not implemented in the Test Cases or any of
the software prototype;].

I am presuming that the fact that the test report 
indicates some untested capabilities that the 
report itself constitutes a request for a waiver 
of interoperability testing of those 
capabilities.  I'm fine with that, and with 
interpreting approving CESG votes as granting 
such a waiver, so long as I understand the 
procedure.  If the above interpretation is 
correct, then I assume that a CESG vote to 
disapprove because all the protocol capabilities 
were not tested would result in an updated test 
report covering the additional capabilities.


Total Respondents:  4

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

      SEA
      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-2013-12-005 
Approval to publish CCSDS 722.1-M-1,  Operation 
of CFDP over Encapsulation Service (Magenta Book, Issue 1)
Results of CESG poll beginning 31 December 2013 and ending 15 January 2014:

                  Abstain:  0 (0%)
  Approve Unconditionally:  2 (50%) (Peccia, Scott)
  Approve with Conditions:  2 (50%) (Barkley, Calzolari)
  Disapprove with Comment:  0 (0%)

CONDITIONS/COMMENTS:

      Erik Barkley (Approve with 
Conditions):  Please update the RID information to record the dispositions.

      Gian Paolo Calzolari (Approve with 
Conditions):  I have some problems with the two (brand new?) RIDs.

#1 It is Editorial but till a certain extent. It says:
In The Name column of table B-1, change “Uplink” 
to Forward Link” and “Downlink” to “Return Link”.
The uplink/downlink terminology was superseded by 
the more-general and encompassing forward/return 
with the advent of geosynchronous relay satellite 
networks such as TDRSS. The forward and return 
link terminology has been in use in CCSDS since 
AOS. Finally, table B-2 uses Forward and Return, 
and this change would make the two table consistent.
---------------------------------------------------
However the rest of the annex uses the terms 
uplink/downlink several times so the 
Forward/Return terminology in table B-1 comes out 
of the blue with respect to the surrounding text.
Different Matter for Proximity-1 where indeed the 
term forward/return is more consolidated (but not 
reflected in surrounding text).
It could be good to import/embed the following 
definitions from Proximity-1 book(s):
forward link: that portion of a Proximity space 
link in which the caller transmits and the 
responder receives (typically a command link).
return link: that portion of a Proximity space 
link in which the responder transmits and the 
caller receives (typically a telemetry link).
This would be good for both Table B-1 and B-2 
though Annex B is just INFORMATIVE.

#2 This RID is not editorial in my opinion. It says:
Change 3.4.3 from: “The CFDP UT Address shall 
contain the SDLP_Channel, PVN, EPI and (if Space 
Packets are used by the Encapsulation service) Data Loss Flag.”
To: “The CFDP UT Address shall contain the SDLP_Channel, PVN, and EPI.”
Add another requirement under 3.4: “If Space 
Packets are used by the Encapsulation service, 
the optional Data Loss Flag shall not be enabled in the Encapsulation Service.”
Section 3.4.1 states “CFDP UT Address = Encapsulation SDLP_Channel+PVN+EPI”.
The last paragraph of section 3.3 states “The 
Data Unit Loss Flag 
may be used only if the 
Space Packet is used for encapsulation. This 
parameter, if present, is ignored by implementations of this specification
Even if the Data Unit Loss were to be generated 
by the Encapsulation service, it would be ignored 
by CFDP. So to define the CFDP UT Address as 
having a component that CFDP can’t even see is 
illogical. In any case, the definitions of CFDP 
UT Address in 3.4.1 and 3.4.3 are different and need to be reconciled.
------------------------------------------------------------------
I think the original formulation (i.e. IGNORE) is 
the good one at least for the following reasons
1) the new requirement imposes to set up an 
external service and I am not sure this is fully correct
2) it is likely the external service has several 
users to which it delivers data and your CFDP is 
(possibly) just one of them. Then it would be 
really "dishonest" to oblige all users to use your settings.	

Total Respondents:  4

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

      SEA
      SOIS

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

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