[CESG] Revised EFCTLU draft Orange Book

Gian.Paolo.Calzolari at esa.int Gian.Paolo.Calzolari at esa.int
Mon Jun 4 09:57:45 EDT 2012


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.
-----------------------------------------------------------------
Two typos on parameter    block-encode  --->  Channle / motiviated
-------------------------------
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)
------------------------------------------------
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?
--------------------------------------------
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).
-------------------------------------------------







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



Gian Paolo,
 
I believe the attached updated experimental recommendation was sent to you 
for consideration with regards to your conditions for release as a CCSDS 
orange book approximately 6 weeks ago. It was revised in response to your 
concerns stated as a condition for release as a CCSDS orange book.  May I 
respectfully ask that you please review the updated document and provide 
an indication as to the conditions having been satisfied?  In doing so I 
would like to note that this is on the experimental track for CCSDS so I 
believe proper consideration needs to be applied in that regard.  I would 
like to remove this from the list of pending CSS area affairs.  Please do 
not hesitate to let me know if you have any questions or comments.
 
Best regards,
 
-Erik
[attachment "912x11o0_CESG_Approval-response-120406.docx" deleted by Gian 
Paolo Calzolari/esoc/ESA]
_______________________________________________
CESG mailing list
CESG at mailman.ccsds.org
http://mailman.ccsds.org/mailman/listinfo/cesg



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/20120604/f513a12d/attachment.htm


More information about the CESG mailing list