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

Tue Jun 5 09:46:21 EDT 2012

Gian Paolo,

Thanks for the quick reply. I'll wait (as you suggest) to see if there
are any other comments, but if I hear nothing to the contrary I will go
with "ASCP" and make the changes that you propose regarding Idle CADUs.

Best regards,

John

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

Sent: Tuesday, June 05, 2012 9:39 AM
To: John Pietras
Cc: cesg at mailman.ccsds.org; css-csts at mailman.ccsds.org; Barkley, Erik J
(3170); Moury Gilles
Subject: RE: [CESG] Revised EFCTLU draft Orange Book

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
<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/ad2c6ef6/attachment.html