[Css-csts] RE: [CESG] Revised EFCTLU draft Orange Book
Thomas Gannett
thomas.gannett at tgannett.net
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/css-csts/attachments/20120605/69c4d064/attachment-0001.html
More information about the Css-csts
mailing list