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

[Gian.Paolo.Calzolari at esa.int]

John,
        I have a clear preference for ASCP (or even ASCoP if you like a 
more readable form).
Let's listen to other guys too.

For Idle AOS Frames/CADUs I would have a couple of changes (in red)  to 
propose
?Transferring AOS CADUs implies an ability - within the layers implemented 
by EFCLTU - to multiplex CADUs that is not currently prescribed by CCSDS 
Space Link Recommended Standards (see references [9] and [10]). However, 
the net behavior of the protocol stack implemented by user and provider 
and the 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 edit the Space Link Recommended Standards to explicitly 
support this capability.?
You can of course improve it, but I hope the target is clear.
about the last change (edit vs. formally modify), I prefer to say edit as 
it may be no change to the spec is needed as long as this is an 
implementation detail (and it may be included in a NOTE).

It looks all.

Thank you, John, for your patience and precious collaboration.

Gian Paolo



From:
"John Pietras" <john.pietras at gst.com>
To:
<Gian.Paolo.Calzolari at esa.int>, "Barkley, Erik J (3170)" 
<erik.j.barkley at jpl.nasa.gov>
Cc:
<cesg at mailman.ccsds.org>, <css-csts at mailman.ccsds.org>
Date:
05/06/2012 15:26
Subject:
RE: [CESG] Revised EFCTLU draft Orange Book



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.

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




This message and any attachments are intended for the use of the addressee or addressees only. The unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its content is not permitted. If you received this message in error, please notify the sender and delete it from your system. Emails can be altered and their integrity cannot be guaranteed by the sender.

Please consider the environment before printing this email.

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