[Css-csts] RE: [CESG] Revised EFCTLU draft Orange Book

Tue Jun 5 09:26:51 EDT 2012

Gian Paolo,

Thank you for the review (re-review?) of the revised Orange Book. I'm
very pleased that I have been able to satisfy almost all of your
concerns. In response to your major concern (the name PLOP-3),  I am
certainly open to a name that is not "PLOP-X" if it can still be listed
as a PLOP-in-Effect. Since the majority of the functions associated with
"PLOP-3" are the TM sync and channel coding functions as applied to AOS
on the forward link, I propose AOS Synchronization [and] Coding
Procedure (ASCP) or Forward ASCP (FASCP). Please let me know if you find
either of these acceptable and your preference (if you have one). 

As soon as I get some level of concurrence on the new name (where lack
of objection counts as concurrence) I will replace the terms throughout
the document and resubmit it through Erik, the cognizant AD. 

Please see my responses to your individual comments in bold green below.

Best regards, 

John

From: Gian.Paolo.Calzolari at esa.int [mailto:Gian.Paolo.Calzolari at esa.int]

Sent: Monday, June 04, 2012 9:58 AM
To: Barkley, Erik J (3170)
Cc: cesg at mailman.ccsds.org; cesg-bounces at mailman.ccsds.org; John Pietras
Subject: Re: [CESG] Revised EFCTLU draft Orange Book

Dear Erik, 
        you are right I received the new version in Darmstadt but
unfortunately workload and calendar did not really left much time to me
for a fast check in the post Spring Meeting time frame. 

Finally I have been able to do  such a review (for the most essential
and important topics) over this week end and - fist of all - I shall
congratulate John Pietras for the excellent work he has done in
satisfying the comments I submitted for SLS Area. 
I must say there is only one item that is still disturbing me; i.e. the
PLOP-3 acronym! 
John reply to my request to use another term stated: "The name PLOP-3
was selected to cause minimal changes to the FCLTU design and ASN.1
specifications upon which this experimental specification is based. It
should not be carried over to the eventual Recommended Standard that use
the functions that are being prototyped using this specification." 
Despite of this (reasonable) opinion, I am still convinced that this
acronym should not be used. When you start using a name, eventually it
will be hard to remove/change it. 
Moreover, using a different acronym will not prevent it from being used
within the plop-in-effect variable; e.g. 
        plop-in-effect        The PLOP being used: 'PLOP-1', 'PLOP-2',or
'AFOP'. 
where AFOP = AOS Frames Operation Procedure (or whatever else you like
better; e.g. AFIP = AOS Frame Insertion Procedure, etc. etc.) 
I do kindly ask you to replace PLOP-3 with whatever acronym you like
better. A "Replace All" should suffice. 

Some other (minor) comments are reported below, but I see no reason for
not restarting the CESG Poll. 

Please note that this is just my personal check and therefore does not
include the opinion of those CESG Members that shared my complaints. 

Best regards 

Gian Paolo 

---------------------------------------------------------------- 

Idle CADUs/Frames: in Darmstadt, chatting with John Pietras it looked
that John considered my comments aiming at forbidding generating Idle
Frames/CADUs by EFCLTU while I actually only asked to make clear that -
despite of layers - the global behavior would be "standard compliant". I
do not know whether John looked into a possible editorial change for
this. 

JVP response - The statement now reads:

"The transferring AOS CADUs implies an ability to multiplex CADUs that
is not currently prescribed by CCSDS Space Link Recommended Standards
(see references [9] and [10]). However, the net effect on the signal
being transmitted is compliant with the standards and therefore
interoperability in unaffected. In the future, if CADU multiplexing is
to be included in a real CCSDS Recommended Standard, CCSDS may wish to
formally modify the Space Link Recommended Standards to explicitly
support this capability."

----------------------------------------------------------------- 
Two typos on parameter    block-encode  --->  Channle / motiviated 

JVP response: fixed.

------------------------------- 
typo in Physical Layer Operations Procedure 3 (PLOP-3):  ===> PLOP -3
has a blank to be removed. (BUT I do prefer you replace PLOP-3 with a
better acronym :o) 

JVP response: Will be replaced with  new name (see above).

------------------------------------------------ 
b)        consumes one OCF data channel and extracts the CLCWs; based on
the values in the CLCWs, the Enhanced Forward CLTU service determines
whether the physical channel is available; 

JP response: This statement applies to the combined functionality of the
SLE-FG, so it still applies at least to the TC case. In any case, just
because using the CLCW to determine the status of an AOS forward link
was not envisioned by SLS, does that necessarily rule it out? Need to
check with potential users. 
Was this checked? 

JVP response: Some interest was expressed within the NASA community in
being able to have the RF availability and bit lock status of AOS
forward links reported in return link frames, but (a) the current
definition of the CLCW is mostly dedicated to COP parameters (which are
undefined with respect to AOS forward links), and (b) the
block/STOP/START behavior of the F-CLTU service with respect to reported
CLCW flag values is not ideal for forward AOS links. Therefore, I will
reword the Orange Book to limit the use of the CLCW flags by EF-CLTU to
be applicable only when it is operating in Telecommand mode. 

-------------------------------------------- 
AOS SL-PDU: A fixed-length space link protocol data unit that is carried
by the SLE-FTDU for an EFCLTU service instance that supplies a
synchronous space link. The synchronous SL-PDUs are: AOS transfer frame
(1.6.6e) and Channel Access Data Unit (1.6.6b)) (see figure D-1). 

This should be reworded to e.g.: 
AOS SL-PDU: A fixed-length space link protocol data unit that is carried
by the SLE-FTDU for an EFCLTU service instance that supplies a AOS
Forward space link. The AOS SL-PDUs are: AOS transfer frame (1.6.6e) and
Channel Access Data Unit (1.6.6b)) (see figure D-1). 

JVP response: fixed.

------------------------------------------------- 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/css-csts/attachments/20120605/a44d83ff/attachment.htm