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

[Shames, Peter M (313B)]

Guys,

I am glad that we have this resolved.  Thanks for being diligent in getting it done.

Since this was the last of the CESG items that needed resolution I think we are now ready to publish.  I do not believe that another poll is called for since these are not technical changes, just editorial ones, but I leave it to Tom Gannett to sort that out.

Thanks, Peter



From: John Pietras <john.pietras at gst.com<mailto:john.pietras at gst.com>>
Date: Tuesday, 5 June 2012 6:46 AM
To: Gian Paolo Calzolari <Gian.Paolo.Calzolari at esa.int<mailto:Gian.Paolo.Calzolari at esa.int>>
Cc: Erik Barkley <Erik.J.Barkley at jpl.nasa.gov<mailto:Erik.J.Barkley at jpl.nasa.gov>>, Gilles Moury <Gilles.Moury at cnes.fr<mailto:Gilles.Moury at cnes.fr>>, CSTS-WG <css-csts at mailman.ccsds.org<mailto:css-csts at mailman.ccsds.org>>, CCSDS Engineering Steering Group - CESG Exec <cesg at mailman.ccsds.org<mailto:cesg at mailman.ccsds.org>>
Subject: [Css-csts] RE: [CESG] Revised EFCTLU draft Orange Book

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> [mailto:Gian.Paolo.Calzolari at esa.int]
Sent: Tuesday, June 05, 2012 9:39 AM
To: John Pietras
Cc: cesg at mailman.ccsds.org<mailto:cesg at mailman.ccsds.org>; css-csts at mailman.ccsds.org<mailto: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<mailto:john.pietras at gst.com>>

To:

<Gian.Paolo.Calzolari at esa.int<mailto:Gian.Paolo.Calzolari at esa.int>>, "Barkley, Erik J (3170)" <erik.j.barkley at jpl.nasa.gov<mailto:erik.j.barkley at jpl.nasa.gov>>

Cc:

<cesg at mailman.ccsds.org<mailto:cesg at mailman.ccsds.org>>, <css-csts at mailman.ccsds.org<mailto: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 greenbelow.

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<mailto:cesg at mailman.ccsds.org>; cesg-bounces at mailman.ccsds.org<mailto: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/cesg/attachments/20120605/1f943a96/attachment-0001.htm