[Cesg-all] Results of CESG poll closing 27 February 2012
CCSDS Secretariat
tomg at aiaa.org
Tue Feb 28 09:21:24 EST 2012
CESG E-Poll Identifier: CESG-P-2012-02-001
Approval to release CCSDS
211.2-P-1.1, Proximity-1 Space Link
Protocol—Coding and Synchronization Sublayer
(Pink Book, Issue 1.1) for CCSDS Agency review
Results of CESG poll beginning 13 February 2012 and ending 27 February 2012:
Abstain: 0 (0%)
Approve Unconditionally: 6 (100%) (Peccia,
Giulio, Taylor, Calzolari, Moury, Scott)
Approve with Conditions: 0 (0%)
Disapprove with Comment: 0 (0%)
Total Respondents: 6
No response was received from the following Area(s):
SEA
SECRETARIAT INTERPRETATION OF RESULTS: Approved Unconditionally
PROPOSED SECRETARIAT ACTION: Generate CMC poll
* * * * * * * * * * * * * * * * * * * * * * * *
CESG E-Poll Identifier: CESG-P-2012-02-002
Approval to release CCSDS
211.0-P-4.1, Proximity-1 Space Link
Protocol—Data Link Layer (Pink Book, Issue 4.1) for CCSDS Agency review
Results of CESG poll beginning 13 February 2012 and ending 27 February 2012:
Abstain: 0 (0%)
Approve Unconditionally: 6 (100%) (Peccia,
Giulio, Taylor, Calzolari, Moury, Scott)
Approve with Conditions: 0 (0%)
Disapprove with Comment: 0 (0%)
CONDITIONS/COMMENTS:
Keith Scott (Approve Unconditionally): Prox-1 Data Link Layer
2.2.3.2
How do we reconcile 2.2.3.2:
The Sequence Controlled service ensures that data
are reliably transferred across the space
link and delivered in order, without gaps,
errors, or duplications within a single
communication session without COP-P
resynchronization during the session (see 4.3.2).
with Note 2 in section 4.3.2.2:
2 The mechanisms provided in this specification
will not eliminate duplicate data
associated with the transition between the end of
one session and the beginning of the
next. Elimination of this problem is left to the controlling data system.
------
** Figure 2-1 at the top:
"INPUT of USER DATA + Routing Info" -- is it
really routing information? Maybe "USER DATA +
Control Info"? If this referrs specifically to
the Port ID then OK, I suppose the control of
data output from the receiver is a form of routing.
This meshes with 2.1.6 'Addressing' where one
could use 'The Port ID provides the means to *direct* user data internally...'
------
2.2.3.2
I think where it says: "...without gaps, errors,
or duplications wthin a single communication
session *without COP-P resynchronization during the session*..."?
might be better phrased as:
"... without gaps, errors, or duplications within
a single communication session *when COP-P
resynchronization is not required during the session (see 4.3.2).*"
AND it seems like there may be duplicates anyway
if there are other sessions (as above)?
----
"SDUs supplied by a sending user for transfer
with the Sequence Controlled quality of service
are inserted into transfer frames as required and
transmitted on a Physical Channel (PC) in the
order in which they are presented."
The frames may be initially transmitted in the
order in which they are presented, but
retransmissions will mess with this ordering, correct?
----
"4.2.6 The SENT_TIME_BUFFER shall store all of
the egress clock times, associated frame sequence
numbers, and QoS Indicator when time tag data is collected."
What does this mean? Does 'when time tag data is
collected' apply to all of the data mentioned (1.
egress times, 2. frame sequence number, 3. QoS
indicators) or are the first two always stored
and QoS indicators only included when time tag
data is collected? Does this mean '...and the
QoS indicator of when time tag...' (and if so, what exactly does that mean?)
4.2.6.1
Same issue as 4.2.6
-----
The section numbers around 4.2.5 -- 4.2.7 seem busted. Maybe they should be:
4.2.5 MAC BUFFERS
4.2.5.1 SENT_TIME_BUFFER
4.2.5.1.1 The SENT_TIME_BUFFER shall store all of
the egress clock times, associated frame sequence
numbers, and QoS Indicator when time tag data is collected.
4.2.5.2 RECEIVE_TIME_BUFFER
4.2.5.2.2 The RECEIVE_TIME_BUFFER shall store all
of the ingress clock times, associated frame
sequence numbers and QoS Indicator when time tag data is collected.
-----
4.3.2.2 (and Reliable Data Transfer in general)
Is the user informed of whether COP-P
resynchronization has taken place during the
course of a single communication session? If
not, how does the receiver know if there may be
duplicate data? Does detecting resynchronization
require setting the MIB parameter Resync_Local to
'false'? If the user is required to monitor the
RESYNC variable (7.1.2) to detect
resynchronization, is there any guarantee that
the user will detect the change (that is, if the
user reads 1/second, will they notice the resynch event?)
Note 1 in section 4.3.2.2 -- how is the delivery
of duplicate data due to factors outside the
scope of the Proximity-1 protocol? It seems that
duplicate data may be delivered because the
Proximity-1 protocol does not detect duplication
across resynchronization events, but I suspect a
more robust COP-like protocol *could*. The point
is, the duplicate data is a result of the Prox-1
reliability mechanisms not being robust across
resynchronzation, not some sort of external factor.
What are the 'bounds' on duplicate data reception
associated with Note 2 in section 4.3.2.2? Are
all data received with 256 frames of a
communication session boundary suspect of duplication, e.g.?
---------------
6.2.2.1.1
It is unclear from the below when or if the
receiver is powered on in half-duplex mode:
"...
b) connecting-T: In the Physical Layer, the
Connecting-Transmit state in full duplex
shall dictate that the ***receiver (sequentially
in half duplex)*** and transmitter are
powered on and enabled to process received frames, and that the transmitter is
enabled for asynchronous channel operations.
(***In half duplex, only the transmitter is
powered on.***) The Hail Activity shall be
conducted while MODE is connecting-T.
6.2.3.7 REMOTE_SCID_BUFFER
Are the tests mentioned done on reception or
transmission? It seems like this is trying to
ensure that all frames are sent to the same destination spacecraft ID?
6.2.3.9 RECEIVING_SCID_BUFFER
"...or it may be loaded with the spacecraft ID
contained in the first valid received frame." --
First of WHAT (I think 'first valid received
frame of a new connection where the sourceOrDest
parameter of the frame is DESTINATION' [since if
the first valid received frame has
sourceOrDestination set to source then the value
of the SCID will be the transmitter -- or is this not possible?])?
2/2
Total Respondents: 6
No response was received from the following Area(s):
SEA
SECRETARIAT INTERPRETATION OF RESULTS: Approved Unconditionally
PROPOSED SECRETARIAT ACTION: Generate CMC poll
* * * * * * * * * * * * * * * * * * * * * * * *
CESG E-Poll Identifier: CESG-P-2012-02-003
Approval to release CCSDS
211.1-P-3.1, Proximity-1 Space Link
Protocol—Physical Layer (Pink Book, Issue 3.1) for CCSDS Agency review
Results of CESG poll beginning 13 February 2012 and ending 27 February 2012:
Abstain: 0 (0%)
Approve Unconditionally: 6 (100%) (Peccia,
Giulio, Taylor, Calzolari, Moury, Scott)
Approve with Conditions: 0 (0%)
Disapprove with Comment: 0 (0%)
Total Respondents: 6
No response was received from the following Area(s):
SEA
SECRETARIAT INTERPRETATION OF RESULTS: Approved Unconditionally
PROPOSED SECRETARIAT ACTION: Generate CMC poll
* * * * * * * * * * * * * * * * * * * * * * * *
CESG E-Poll Identifier: CESG-P-2012-02-004
Approval to release CCSDS 508.0-R-1, Conjunction
Data Message (Red Book, Issue 1) for CCSDS Agency review
Results of CESG poll beginning 13 February 2012 and ending 27 February 2012:
Abstain: 0 (0%)
Approve Unconditionally: 5 (83.33%) (Peccia,
Giulio, Taylor, Calzolari, Moury)
Approve with Conditions: 1 (16.67%) (Scott)
Disapprove with Comment: 0 (0%)
CONDITIONS/COMMENTS:
Keith Scott (Approve with
Conditions): Below are two comments that the WG
can take under advisement and one condition that
I believe should be addressed by the time the
document goes for final review/publication. I do
not believe any of these should hold up putting the book out for agency review.
============
Comment
Section 2.2
Are the following statements (highlighted by **s) redundant?
The CDM contains information about a single
conjunction between Object1 and Object2. It
contains the time of the closest approach between
Object1 and Object2 and the **position,
velocity**, and covariance of Object1 and Object2
at the time of closest approach. It also contains
information about how the position, velocity, and
covariance were determined as well as the
**relative positions and velocities** of Object1
and Object2 at the time of closest approach. This
information is used by satellite owner/operators
to evaluate the risk of a conjunction and plan
maneuvers if deemed warranted by that agency/organization.
Does the second set refer to 'information about
how the positions and velocities are calculated'
or is it meant to highlight that the *relative*
positions and velocities are different from the
(absolute?) positions and velocities mentioned above?
==============
Comment
Section 3 (General question about KVN message structure)
A NOTE here that says something about 'one
keyword per line', possibly with a forward
reference to section 6, might be
helpful. Mentioning 6.2.1.14 (that the ORDER of
keywords in the KVN representation is fixed by
this recommendation) would also have been helpful when I hit section 3.
===============
Condition
Section 3.1.3
'The CDM shall be provided using file name syntax
and length that do not violate computer
constraints established in standard, widely-used computing environments.'
This isn't a requirement or constraint. Can't we
pick a character set and a maximum file name
length? If not then I suggest cutting the second
sentence, as the parties already had to agree on
the naming scheme from the previous sentence
(maybe cut the second sentence entirely, regardless?)
Total Respondents: 6
No response was received from the following Area(s):
SEA
SECRETARIAT INTERPRETATION OF RESULTS: Approved with Conditions
PROPOSED SECRETARIAT ACTION: Generate
CMC poll after conditions have been addressed
* * * * * * * * * * * * * * * * * * * * * * * *
More information about the CESG-all
mailing list