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

Tue Jun 5 11:35:50 EDT 2012

Erik:

A new resolution is not required, but a Word file representing the 
agreed-upon version of the document is.

Best regards,
Tom

At 11:30 AM 6/5/2012, Barkley, Erik J (3170) wrote:
>Tom,
>
>Very well.   It appears then that we have the vehicle to formally 
>solicit approval from those who concurred with Gian Paolo's comments 
>from the earlier poll.  I believe the original resolution is 
>sufficient? Or is a new resolution from the Area required?  If not 
>(and assuming all are okay with the ASCP name) then I request we 
>initiate the poll at your earliest convenience.
>
>Best regards,
>
>-Erik
>
>From: Thomas Gannett [mailto:thomas.gannett at tgannett.net]
>Sent: Tuesday, June 05, 2012 8:24 AM
>To: Shames, Peter M (313B); John Pietras; Gian.Paolo.Calzolari at esa.int
>Cc: Barkley, Erik J (3170); Moury Gilles; 
>css-csts at mailman.ccsds.org; cesg at mailman.ccsds.org
>Subject: Re: [Css-csts] RE: [CESG] Revised EFCTLU draft Orange Book
>
>Peter:
>
>The original CESG poll failed (result was disapproval rather than 
>conditional approval) so a new poll needs to be conducted.
>
>Tom
>
>At 11:15 AM 6/5/2012, Shames, Peter M (313B) wrote:
>
>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 <<mailto:john.pietras at gst.com>john.pietras at gst.com>
>Date: Tuesday, 5 June 2012 6:46 AM
>To: Gian Paolo Calzolari <<mailto:Gian.Paolo.Calzolari at esa.int> 
>Gian.Paolo.Calzolari at esa.int>
>Cc: Erik Barkley <<mailto:Erik.J.Barkley at jpl.nasa.gov> 
>Erik.J.Barkley at jpl.nasa.gov>, Gilles Moury 
><<mailto:Gilles.Moury at cnes.fr>Gilles.Moury at cnes.fr>, CSTS-WG 
><<mailto:css-csts at mailman.ccsds.org> css-csts at mailman.ccsds.org>, 
>CCSDS Engineering Steering Group - CESG Exec 
><<mailto:cesg at mailman.ccsds.org>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: 
><mailto:Gian.Paolo.Calzolari at esa.int>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: <mailto:cesg at mailman.ccsds.org>cesg at mailman.ccsds.org; 
><mailto:css-csts 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" <<mailto:john.pietras at gst.com>john.pietras at gst.com>
>To:
><<mailto:Gian.Paolo.Calzolari at esa.int> 
>Gian.Paolo.Calzolari at esa.int>, "Barkley, Erik J (3170)" 
><<mailto:erik.j.barkley at jpl.nasa.gov> erik.j.barkley at jpl.nasa.gov>
>Cc:
><<mailto:cesg at mailman.ccsds.org>cesg at mailman.ccsds.org >, 
><<mailto:css-csts 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 greenbelow.
>
>Best regards,
>John
>
>From:<mailto:Gian.Paolo.Calzolari at esa.int> 
>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: <mailto:cesg at mailman.ccsds.org>cesg at mailman.ccsds.org; 
><mailto:cesg-bounces 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/cesg/attachments/20120605/69c4d064/attachment.htm