[CESG] Additional presentation to CMC for extra items // SPP delays?

Mon Nov 27 17:05:55 UTC 2017

Gippo,

I do understand the one simple clean-up project, two books.  I was the one who pointed out that the GB also needed fixing.

What I was referring to was the second topic discussed in reference to 133.0-B, the topic of extensions to the packet secondary header that you explicitly asked to separate from the "clean up".

This was what I asked about.

Regards, Peter

From: Gian Paolo Calzolari <Gian.Paolo.Calzolari at esa.int>
Date: Monday, November 27, 2017 at 8:21 AM
To: Peter Shames <peter.m.shames at jpl.nasa.gov>
Cc: CCSDS Engineering Steering Group - CESG Exec <cesg at mailman.ccsds.org>
Subject: Re: [CESG] Additional presentation to CMC for extra items // SPP delays?

Peter,
        there are not two separate projects against one document. The two projects re on different books: 133.0-B and 130.0-G respectively.

If you refer to the fact that sometimes in the future 130.0-G Overview of Space Communications Protocols may need further modification this will be tackled as required (e.g project modification or new project if the old one is finished or something else...) when such need will materialise..
Note that starting the two project concurrently has been explicitly requested by SLP.

I hope this addresses your remarks

Regards

Gippo

From:        "Shames, Peter M (312B)" <peter.m.shames at jpl.nasa.gov>
To:        "Gian.Paolo.Calzolari at esa.int" <Gian.Paolo.Calzolari at esa.int>
Cc:        CCSDS CESG -- <cesg at mailman.ccsds.org>
Date:        27/11/2017 17:05
Subject:        Re: [CESG] Additional presentation to CMC for extra items // SPP delays?
________________________________

Hi Gippo,

Thanks for processing this request to make the limited set of changes to the SPP and OSCP docs.  They are really over-due and I am glad to see the plan to make these repairs being put into motion.

I do not think that the second project is in progress yet.  And I still question the logic of creating two separate projects against one document.  How do you think this is going to be handled?  Two separate versions of the same document?  Two separate agency reviews for the same document?   Is there going to be an enforced delay in publishing the second version with the second set of updates in order to maintain document stability?

Just what do you think the plan is to deal with these considerations?

Regards, Peter

From: Gian Paolo Calzolari <Gian.Paolo.Calzolari at esa.int>
Date: Wednesday, November 22, 2017 at 2:41 AM
To: Peter Shames <peter.m.shames at jpl.nasa.gov>
Cc: CCSDS Engineering Steering Group - CESG Exec <cesg at mailman.ccsds.org>
Subject: Re: [CESG] Additional presentation to CMC for extra items // SPP delays?

Peter,
       thanks to the excellent cooperation by Greg Kazz (but not only) the SLS-SLP request to start two projects (instead of one as originally planned in The Hague) is out for starting CMC Poll less than two weeks after the The Hague Meetings.

I think we all shall be happy for this timely achievement.

Regards

Gippo

From:        Gian.Paolo.Calzolari at esa.int
To:        "Shames, Peter M (312B)" <peter.m.shames at jpl.nasa.gov>
Cc:        "CESG -- CCSDS-Engineering SteeringGroup\(cesg at mailman.ccsds.org\)\(cesg at mailman.ccsds.org\)" <cesg at mailman.ccsds.org>
Date:        13/11/2017 12:07
Subject:        Re: [CESG] Additional presentation to CMC for extra items // SPP        delays?
Sent by:        "CESG" <cesg-bounces at mailman.ccsds.org>
________________________________

[attachment "ConceptPaper-uplink coding_green_V2(cleanFinal).pdf" deleted by Gian Paolo Calzolari/esoc/ESA]

Peter,
      it looks as you were not there when I clearly told Greg that "despite not strictly needed for updating of documents, you may want to prepare a concept paper to support the SLS resolution as it is much simpler editing in word that putting dates in CWE".

The Concept Paper we refer to is like the attached one (BTW, done by JPL guys) and contains the information to be relied anyhow to CMC to allow them to approve the new project.

If you think that providing this kind of  information (normally 1 page of text and 1 or 2 pages for project definition) is provoking big delays, I will have to live with this.

Regards

Gian Paolo

From:        "Shames, Peter M (312B)" <peter.m.shames at jpl.nasa.gov>
To:        "Gian.Paolo.Calzolari at esa.int" <Gian.Paolo.Calzolari at esa.int>
Cc:        "Nestor.Peccia at esa.int" <Nestor.Peccia at esa.int>, "CESG -- CCSDS-Engineering SteeringGroup(cesg at mailman.ccsds.org)(cesg at mailman.ccsds.org)" <cesg at mailman.ccsds.org>
Date:        13/11/2017 01:09
Subject:        Re: [CESG] Additional presentation to CMC for extra items
________________________________

Gippo,

I know that these issues were raised prior to the WG and that both of them were discussed within the meetings.  Ken Andrews gave a presentation on the coding issue and Greg Kazz gave a presentation on the SPP which you, I, Jonathan, and Scott were all present for.

Given this situation, and the very straightforward fact that text was left out of a revised document without any explanation, I do not think that what I have stated is in any way unilateral.  In fact, it seems to me that it is you who are unilaterally throwing roadblocks in the way of forward progress in both of these cases.

Regards, Peter

From: Gian Paolo Calzolari <Gian.Paolo.Calzolari at esa.int>
Date: Sunday, November 12, 2017 at 1:15 PM
To: Peter Shames <peter.m.shames at jpl.nasa.gov>
Cc: Nestor Peccia <Nestor.Peccia at esa.int>, CCSDS Engineering Steering Group - CESG Exec <cesg at mailman.ccsds.org>
Subject: Re: [CESG] Additional presentation to CMC for extra items

Peter.
  Your points look as something that should have been discussed in WGs (were you there?)

I do not share your view and I reserve to complain if unilaterally presented to CMC.

Ciao

Gian Paolo
Sent from my iPhone

On 12. Nov 2017, at 22:08, Shames, Peter M (312B) <peter.m.shames at jpl.nasa.gov<mailto:peter.m.shames at jpl.nasa.gov>> wrote:
Hi Nestor,

There is no NWI page for the SecWG inputs because they do not yet have a plan for the work with work level estimates.  What they have is a "plan for a plan".  When they get done planning I'll submit the requests.

And on the subject of "things causing delays to projects", I would point out that the CESG approval cycle for draft and "proposed for publication" document is not the only place where delays are introduced.  It's just the one where there are currently issues being voiced.  I have also given voice to the sorts of delays that have recently been introduced in the SPP and the AOS coding topics where work is being started, or errors are being fixed.  These were not included in the materials you prepared, but they are very real sources of delays and thus should also be addressed.

SPP
In  the case of SPP, even though there was a meeting that arrived at consensus on the need and the topics to be covered, involving people from three SLS working groups, and the SIS, SOIS and SEA areas, there was an added request to create a white paper prior to starting the project in the WG.  This is certainly covered by the procedures, but it is usually invoked when there is a totally new, and not well understood, topic being introduced.  In this case the work is quite well understood and the delay somewhat uncalled for.  Just as you have "streamlined" some of the CESG voting procedures to avoid delays the same thing could have been done in this case.

AOS coding
In the case of the AOS coding for uplink there is a clear and documented situation where the topic of using TM coding for AOS, for uplink and downlink, were documented in an earlier CCSDS spec, "TM Channel Coding", CCSDS 101.0-B-6, but got dropped from the current "TM Synch and Channel Coding" spec, CCSDS
In the original 101.0 document, under Sec 1.3 Applicability, it stated, very clearly (emphasis added):

In addition to being applicable to conventional Packet Telemetry systems [1], the codes in this recommendation are applicable to the forward and return links of Advanced Orbiting Systems (AOS) [2]. For coding purposes, the terms ìTransfer Frameî and ìReed-Solomon Codeblockî as used in this recommendation are understood to be equivalent to the AOS terms ìVirtual Channel Data Unitî (VCDU), and ìCoded Virtual Channel Data Unitî (CVCDU), respectively.

For reasons that are totally unexplained in any form that anyone can unearth, this was modified in the current 131.0, under Sec 1.0 Purpose, to read:

The purpose of this Recommended Standard is to specify synchronization and channel coding schemes used with the TM Space Data Link Protocol (reference [1]) or the AOS Space Data Link Protocol (reference [2]). These schemes are to be used over space-to- ground or space-to-space communications links by space missions.

The consequence of this change, which appears to be both editorial and wrongly placed, iy should be in Applicability, as before, is to arbitrarily remove the explicit coverage for AOS uplink from the TM Synch and Channel Coding book.  The only explanation given was "this spec if for telemetry", therefore it should not be used for forward links.  But in the original 101.0 spec this case was covered, with no apparent issue being identified.

The "remedy" proposed for this editorial error is, instead of just fixing the error, to require that a new "Magenta Book" be produced.  I'll leave out of the discussion that this would actually need to be a Blue Book, of type "utilization profile".  Requiring that this error be remedied by creation of a new Blue Book appears to be punitive and will cause expense of resources that could well be invested otherwise.  It also is calling for creation of a new type of document within SLS, for which there is no precedent.  If one were to treat this request as a new policy on SLS document there would be a whole slew of new documents required, specifying how to use TC over specific codes, TM over other codes, etc.  This is a waste of time and resources which could be very easily avoided by simply using a corriegendum to repair the missing text.

So my request is that you either treat all of these sources of delays in an even handed fashion or that you treat none of them.   Furthermore, if you do decide to include the materials that we discussed I would request that you explicitly include the points I made during the meeting on the proximal source of the issue being inadequate quality control at the originating WG and Area level.  All of these issues could have been avoided at CESG review if the documents had been closer to error free and complete when submitted.

Best regards, Peter

From: CESG <cesg-bounces at mailman.ccsds.org<mailto:cesg-bounces at mailman.ccsds.org>> on behalf of Nestor Peccia <Nestor.Peccia at esa.int<mailto:Nestor.Peccia at esa.int>>
Date: Sunday, November 12, 2017 at 6:33 AM
To: CCSDS Engineering Steering Group - CESG Exec <cesg at mailman.ccsds.org<mailto:cesg at mailman.ccsds.org>>
Subject: [CESG] Additional presentation to CMC for extra items

Dear all.

Please find attached the additional presentation to CMC.

It still miss some inputs from SEA SEC WG for the NWIs.

Comments welcome

ciao
nestor
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.