[CESG] [EXTERNAL] Keep the term “function” / was: Re: CESG-P-2020-12-006 Approval to publish CCSDS 922.3-B-1, Cross Support Transfer Service—Forward Frame Service ( Blue Book, Issue 1)

Wed Mar 17 15:51:32 UTC 2021

Erik,
        I am not asking to "introduce" the term layer if the FF-CSTS book.
To summarise
1) I simply oppose to the straight replacement (like Find & Replace in 
WinWord) of stratus/strata with layer/layers.
2) I recommend - whenever needed -  to stick to the existing layering 
definitions from the CCSDS books and then talk about functions.  

About #1, note that this straight replacement has been carried out after 
Peter's comments. Moreover I think that focusing the discussion on 
functions (as it is mostly done already) would not need adding the new 
concept of stratus/strata.

About #2 this should  be done when referring to the layers as defined in 
those SLS books (Protocol sublayer, Coding sublayer, and Physical layer, 
just to use a concise recall).Such references are already present in the 
FF-CSTS book and they should stay as they are (examples are 2.5.2.2g, 
2.5.2.5c, 2.5.3.1, 5.1.1, I1, etc.). It is also because of those existing 
references that replacing stratus with layer only introduces more 
ambiguity.

I hope this clarifies (once more) my position.

BTW, from your words,  it is also clear to me that you do not endorse 
publishing the document in the version (*) updated after CESG Poll.
(*) Being this one the version sent from John to Tom for closing SEA 
conditions.

Best regards

Gippo

From:   "Barkley, Erik J (US 3970)" <erik.j.barkley at jpl.nasa.gov>
To:     "Gian.Paolo.Calzolari at esa.int" <Gian.Paolo.Calzolari at esa.int>, 
"Shames, Peter M (US 312B)" <peter.m.shames at jpl.nasa.gov>
Cc:     "Thomas Gannett" <thomas.gannett at tgannett.net>, 
"cesg at mailman.ccsds.org" <cesg at mailman.ccsds.org>
Date:   17-03-21 16:18
Subject:        RE: [CESG]  [EXTERNAL] Keep the term “function” / was: Re: 
  CESG-P-2020-12-006 Approval to publish CCSDS 922.3-B-1, Cross Support 
Transfer Service—Forward Frame Service (  Blue Book, Issue 1)

Peter, Gippo,

I find the introducing the term “layer” to be confusing.  I believe we 
should not try to stretch the ISO OSI definition of layer too far and keep 
it bound, so to speak, to a strict communications aspects.  I believe that 
with a simple clarification in the FF-CSTS document as to what the term 
“strata” means, that we can keep that term.  But there are other 
considerations…

1.      The aperture stratum does not necessarily need to be “exposed” in 
the FF-CSTS book -- I think this is more of an artifact of having brought 
in the functional resource model and not having done careful editing with 
respect to the diagram/extent of the functional resource model necessary 
to be included to understand FF CSTS.  It does not “hurt” anything in the 
current book, but it can be excised.
2.      the FRM in and of itself is not strictly about communications 
protocols but rather the functions needed to achieve the services (stated 
in the abstract) that a ground station provides. Those services of course 
do have communication protocols but the FRM is not a communications stack 
-- in particular, you run into difficulties including such functions as 
off-line data storage management, Doppler extraction, weather data 
reporting, etc. trying to shoehorn this all into an ISO OSI model.  And 
just wear does DDOR fit in the ISO OSI model – again, I am very skeptical 
about using the well understood ISO OSI layer term to include things that 
clearly are not part of that model.  As such I think a term such as 
“strata” is in fact better -- granted, it probably needs a domain specific 
definition/qualification. I'm also open to another term.
3.      I am reminded of what Adrian Hooke used to tell me: "perfect is 
the enemy of good".  I do hope we are not engaging in "polishing the 
cannonball" exercises here.

Best regards,
-Erik 

From: CESG <cesg-bounces at mailman.ccsds.org> On Behalf Of 
Gian.Paolo.Calzolari at esa.int
Sent: Wednesday, March 17, 2021 1:14
To: Shames, Peter M (US 312B) <peter.m.shames at jpl.nasa.gov>
Cc: Thomas Gannett <thomas.gannett at tgannett.net>; cesg at mailman.ccsds.org
Subject: Re: [CESG] [EXTERNAL] Keep the term “function” / was: Re: 
CESG-P-2020-12-006 Approval to publish CCSDS 922.3-B-1, Cross Support 
Transfer Service—Forward Frame Service ( Blue Book, Issue 1)

Peter, 
        indeed a layer (or a sub layer can "contain" several functions. 
This is why I recommend to stick to the existing layering definitions 
(Protocol sublayer, Coding sublayer, and Physical layer, just to use a 
concise recall) from the CCSDS books and then talk about functions. 
Talking about functions is something FF-CSTS book already did. I really 
concur that what is not required is this intermediate definition of 
stratus/strata and you see that - even starting from possibly different 
motivations - we reached the same conclusion about removing stratus/strata 
(while keeping layers and functions where they are used appropriately). 

Of course, I agree that the idea of working with SLS, and RFM WG in 
particular, on the clear definition of “aperture” would seem to be an 
entirely sensible thing to do.  The same for SLS-OPT as you mentioned. 
However I would not put in hold FF-CSTS publication waiting for this and I 
recommend you inform CSTS WG about your agreement on this approach such 
that they can prepare a (hopefully) final draft for publication. 

Regards 

Gian Paolo 

From:        "Shames, Peter M (US 312B)" <peter.m.shames at jpl.nasa.gov> 
To:        "Gian.Paolo.Calzolari at esa.int" <Gian.Paolo.Calzolari at esa.int> 
Cc:        "cesg at mailman.ccsds.org" <cesg at mailman.ccsds.org>, "Thomas 
Gannett" <thomas.gannett at tgannett.net> 
Date:        16-03-21 19:46 
Subject:        Re: [EXTERNAL] Keep the term “function” / was: Re: [CESG] 
CESG-P-2020-12-006 Approval to publish CCSDS 922.3-B-1, Cross Support 
Transfer Service—Forward Frame Service (  Blue Book, Issue 1) 

Hi Gippo,

Yes.  Thanks for that added clarity.

I do think that it is functions associated with a layer.  Some “layers” in 
the ISO BRM context, actually contain multiple functions and I think it is 
important to distinguish both functions and layers.

That said, I really want to remove that term “strata” because I think that 
is just confusing.  That said, there are still layers, in the ISO BRM 
context, and I think it valuable to identify which layer, or layers, we 
are talking about because that is a really valuable “touch stone” for 
people.

Thanks, Peter

From: Gian Paolo Calzolari <Gian.Paolo.Calzolari at esa.int>
Date: Tuesday, March 16, 2021 at 11:23 AM
To: Peter Shames <peter.m.shames at jpl.nasa.gov>
Cc: CCSDS Engineering Steering Group - CESG Exec <cesg at mailman.ccsds.org>, 
Tom Gannett <thomas.gannett at tgannett.net>
Subject: [EXTERNAL] Keep the term “function” / was: Re: [CESG] 
CESG-P-2020-12-006 Approval to publish CCSDS 922.3-B-1, Cross Support 
Transfer Service—Forward Frame Service ( Blue Book, Issue 1)

Peter, 
       only one remark about your statement. 
>> In the context of the FF-CSTS I would caution against removing the term 
“function”. 

I think there is a misunderstanding to be solved as sooner as better. 

I never proposed to remove the term “function” (or at least I never 
intended to do so). 
I meant that all the part using stratus/strata actually talk about 
functions (*). 
Therefore it is better to remove the term stratus/strata and just talk 
about functions. 
As far as I could see, in FF-CSTS this is feasible with easy adaptation of 
the  affected text. 

For the rest I will comment later, but I considered important to remove 
this misunderstanding (and sorry if my words originated it). 

Best regards 

Gippo 

(*) I find often more appropriate talking about functions in a layer 
instead of dividing a layer in more sublayers. 

From:        "Shames, Peter M (US 312B)" <peter.m.shames at jpl.nasa.gov> 
To:        "Gian.Paolo.Calzolari at esa.int" <Gian.Paolo.Calzolari at esa.int> 
Cc:        "cesg at mailman.ccsds.org" <cesg at mailman.ccsds.org>, "Thomas 
Gannett" <thomas.gannett at tgannett.net> 
Date:        16-03-21 18:55 
Subject:        Re: [EXTERNAL] Re: [CESG]  CESG-P-2020-12-006 Approval to 
publish CCSDS 922.3-B-1, Cross Support Transfer Service—Forward Frame 
Service (  Blue Book, Issue 1) 

Hi Gippo,

It seems we may be converging, which is all to the good.  The idea of 
working with SLS, and RFM WG in particular, on the clear definition of 
“aperture” would seem to be an entirely sensible thing to do.  This is 
especially the case since we will now have both “RF Apertures” and 
“Optical Apertures”, but have not (yet) formally defined the term 
“aperture” even though we use it in a few documents.  Aperture is not the 
only such term that we more or less take for granted that everyone knows, 
and so have not bothered to define it.  The terms “asset” and “space 
packet” are also on that list.  We all have some clean-up to do.

I still like the concept of treating either RF Apertures or Optical 
Apertures as being the lowest sub-layer of the Physical layer.  I’d 
suggest that we review the use of those terms in the up-coming meeting and 
try to reach closure on them.  As I noted earlier, the association of 
apertures with the bottom-most sub-layer of the Physical Layer seems 
entirely appropriate and consistent with existing RF&M (and other) usage, 
as well as being completely aligned with the ISO BRM description of Layer 
1, the Physical Layer.

In the context of the FF-CSTS I would caution against removing the term 
“function”.  The CSS Area has adopted a set of formalisms called the 
Functional Resource Model (FRM) to represent the functions that exist in 
our systems.  This term is also in wide use in systems architecture 
descriptions and is formalized in the RASDS and the docs that derive from 
that, the SCCS-ARD and ASL.   Other standards regularly use it as well.  I 
cannot see any good reason for abandoning that term, even if it does occur 
frequently in this doc. 

function 
The set of actions or activities performed by some object to achieve a 
goal; the transformation of inputs to outputs that may include the 
creation, modification, monitoring, or destruction of elements. 
[ccsds-311.0-M-1]

What would you propose to replace it with?  Or did you have in mind 
leaving the word out entirely?

Cheers, Peter

From: Gian Paolo Calzolari <Gian.Paolo.Calzolari at esa.int>
Date: Tuesday, March 16, 2021 at 1:07 AM
To: Peter Shames <peter.m.shames at jpl.nasa.gov>
Cc: CCSDS Engineering Steering Group - CESG Exec <cesg at mailman.ccsds.org>, 
Tom Gannett <thomas.gannett at tgannett.net>
Subject: Re: [EXTERNAL] Re: [CESG] CESG-P-2020-12-006 Approval to publish 
CCSDS 922.3-B-1, Cross Support Transfer Service—Forward Frame Service ( 
Blue Book, Issue 1)

Peter, 
      just to be clear I never asked to revert from layer to stratus. 
I simply remark that the straight replacement (e.g. a la WinWord) stratus 
--> layer does create new issues as e.g. the identification on an Aperture 
Layer. 
Actually I found that the document could live taking away strata and just 
deleting those parts that indeed refer mostly to functions (that is most 
likely the best seller term in that document) are likely to solve the 
issue. This is what I proposed in my comments to John. 

Defining sub layers can be an artifact that may look as a solution but as 
well can create new confusion if "invented" in a document without a real 
relationship with other documents. 
If the envisaged solution is to define an Aperture sub layer and a 
Modulation sub layer within the Physical Layer, I do recommend consulting 
the RFM WG on this. 

That's all for my European evening 

Best regards & stay healthy 

Gippo 

From:        "Shames, Peter M (US 312B)" <peter.m.shames at jpl.nasa.gov> 
To:        "Gian.Paolo.Calzolari at esa.int" <Gian.Paolo.Calzolari at esa.int> 
Cc:        "cesg at mailman.ccsds.org" <cesg at mailman.ccsds.org>, "Thomas 
Gannett" <thomas.gannett at tgannett.net> 
Date:        15-03-21 19:31 
Subject:        Re: [EXTERNAL] Re: [CESG]  CESG-P-2020-12-006 Approval to 
publish CCSDS 922.3-B-1, Cross Support Transfer Service—Forward Frame 
Service (  Blue Book, Issue 1) 

Hi Gippo,

I just got the details of this issue you raised forwarded from John.  I 
can forward the rather lengthy analysis that I sent back to him, which 
mostly extracted definitions from the Basic Reference Model (known as the 
ISO BRM) ISO/IEC 7498-1, the edition republished in 1996.

Here is a short summary of that analysis:

1.        The BRM concerns itself with “terrestrial systems of terminals, 
computers, and associated  devices for transferring information among them
”.
2.        The BRM defines and extensively uses the term “Layer”.
3.        The BRM makes no mention of “strata” nor “stratum”.
4.        Using that term stratum to rename what is already defined as a 
layer in the ISO BRM is just plain confusing.
5.        The BRM makes no mention of aperture or ground station but the 
Physical Layer is defined as “The Physical Layer provides the mechanical, 
electrical, functional and procedural means to activate, maintain, and 
de-activate physical-connections for bit transmission between 
data-link-entities. “
6.        This is a perfectly serviceable definition of the functions that 
an “aperture” provides for either RF or optical communications at the 
Physical Layer.
7.        We (CCSDS) do describe the roles of ground stations and 
terminals and apertures, but we do not tend to explicitly define them. 
They are used, but not formally defined, in the RF&M 401 document, and in 
the SCCS-ARD and Nav standards.
8.        The way that we use those terms, Earth Station or Aperture, for 
either RF or optical comms, is entirely consistent with the ISO BRM 
definition of “Physical Layer”.
9.        Just as “modulation”, which is not defined in the ISO BRM, is 
treated as a “sub-layer” of the Physical Layer, I think it entirely 
appropriate to treat the “aperture” as a sub-layer of the Physical Layer.

So I agree with you. Calling the aperture an “aperture layer” is a 
mis-statement.  On the other hand, calling it a “sub-layer of the Physical 
Layer” is entirely appropriate, and this fits both within the ISO BRM and 
is consistent with the nearly identical definition we have adopted for the 
modulation sub-layer of the Physical Layer.

Regards, Peter

From: Gian Paolo Calzolari <Gian.Paolo.Calzolari at esa.int>
Date: Friday, March 12, 2021 at 2:35 AM
To: Peter Shames <peter.m.shames at jpl.nasa.gov>
Cc: CCSDS Engineering Steering Group - CESG Exec <cesg at mailman.ccsds.org>, 
Tom Gannett <thomas.gannett at tgannett.net>
Subject: Re: [EXTERNAL] Re: [CESG] CESG-P-2020-12-006 Approval to publish 
CCSDS 922.3-B-1, Cross Support Transfer Service—Forward Frame Service ( 
Blue Book, Issue 1)

Peter, 
     actually I received the "publication package" from Tom. 
Actually your file is named differently from the one in that package, but 
I am not going to investigate the difference also because I provided some 
comment to Johh Pietras based on the file I got from Tom. 

I provided the comments on a friendly basis making clear to John that 
(according to rules) there is "no obligation to accept any of them." 

My major issue is the straight replacement of strata with layers. 
First this introduce an "Aperture Layer" I never heard before and then it 
also introduces many consistency concerns with other document statements 
that talk about functions. 

The other findings are minor or even just additional information for the 
book editor. 

IMO, resubmitting this big document to CESG would not be according to 
rules but it would be according to the spirit to  “produce the most 
useful, clear, and unambiguous standards” 

I wish you all a nice week end. 

Gian Paolo 

From:        "Shames, Peter M (US 312B)" <peter.m.shames at jpl.nasa.gov> 
To:        "Gian.Paolo.Calzolari at esa.int" <Gian.Paolo.Calzolari at esa.int> 
Cc:        "cesg at mailman.ccsds.org" <cesg at mailman.ccsds.org>, "Thomas 
Gannett" <thomas.gannett at tgannett.net> 
Date:        11-03-21 22:04 
Subject:        Re: [EXTERNAL] Re: [CESG]  CESG-P-2020-12-006 Approval to 
publish CCSDS 922.3-B-1, Cross Support Transfer Service—Forward Frame 
Service (  Blue Book, Issue 1) 

Dear Gippo,

Somehow it appears that you are more concerned with “follow the process to 
the letter” than you are on “produce the most useful, clear, and 
unambiguous standards”.

I did, by the way, say that I was guilty of missing this issue the first 
time around:

“the CESG failed to catch it earlier.  I point the finger at myself here, 
since I had the opportunity to catch the issue earlier”

I also admit to being late with my inputs.  The WG could have taken the 
“stand on ceremony” and “follow the process to the letter” approach, or 
just told me “too late”.  Instead they looked at this request, apparently 
realized that I was correct, and fixed it.

I’m attaching there updates here just so you all get to see what was, in 
fact, changed.  It’s not intended to be a secret.  Some of the other 
communications were sent to the CESG and the key one that initiated this 
is copied below for easy reference.

For my part I am glad that this was resolved in a way that produced a 
clear, unambiguous, standard that documents just what it is that the IOAG 
SISG requested. 

Best regards, Peter

From: Shames, Peter M (US 312B) [mailto:peter.m.shames at jpl.nasa.gov] 
Sent: Friday, January 15, 2021 7:49 PM
To: Barkley, Erik J (US 3970); Holger.Dreihahn at esa.int; Tom Gannett
Cc: CCSDS Engineering Steering Group - CESG Exec
Subject: Late input from SEA on the CESG-P-2020-02-006 CSTS FF poll

Dear Erik, Holger, Tom, et al,

Please accept this late input from SEA on this poll.  I took the time to 
actually review the spec in some detail and it took rather longer than  I 
expected.  I was hoping that this FF-CSTS spec would meet all of the 
planned requirements for this forward frame service.  Unless I somehow 
overlooked some important features that are documented deep in the bowels 
of this 218 page specification I am afraid that I have to conclude that it 
has missed the mark. 

The “mark” in my understanding, is that this spec was supposed to define 
the list of features that follows below.  These are drawn from the 
original SISG Space Internetworking Strategy report that first defined the 
features of this forward frame service intended to accommodate DTN (and 
IP) traffic, from the SCCS-ARD/ADD where these features were documented in 
the context of the rest of the CCSDS protocol stacks and Earth Space Link 
Terminal (ESLT, otherwise known as a ground station plus its associated 
control center elements), and the features that already existed in the 
EF-CLTU Orange Book that was created because there was no other documented 
service for handling the synchronous AOS frame protocol for forward links.

1.        Ability to provide an “SLE-like” forward link service for 
synchronous link protocols, initially AOS, but now to include USLP
2.        Provide encoding in the ESLT for this forward link frame stream
3.        Ability to accept input frame streams from more than one user 
source
4.        Ability to multiplex frame streams from all of the input 
sources, including some that are not directly from FF-CSTS itself
5.        Ability to keep a synchronous forward link filled, if necessary 
by inserting fill frames in the ESLT
6.        Ability to integrate the protocol PDUs from DTN, IP, CFDP, or 
other data sources, from “agents” instantiated in the ESLT, to create 
frames that encapsulate these PDUs, and to integrate these in the 
multiplexed frame stream (see items 3 & 4)

As best I can tell this spec fails to accomplish items 5 and 6 at all, and 
it appears to give only passing acknowledgement to items 2 or 4.  These 
are mentioned as being features that are needed somewhere in the ESLT, but 
there is not a section of the document, nor even an informative annex, let 
alone a normative one, that would suggest what was really intended nor how 
to accomplish it.  In my judgement this is a significant oversight and 
renders this document inadequate to the task at hand which was to document 
how these services were to be provisioned and integrated.

Unfortunately, from my point of view, instead of addressing these 
absolutely required services the document as presented spends a lot of 
“real estate” documenting how this new service can be made to handle TC 
forward asynchronous frames.  Since there is already a perfectly 
serviceable SLE F-CLTU that provides this service this seems like an 
unnecessary effort.  The only conceivable rationale that occurs to me is 
that this TC forward service is very much like that needed for USLP 
variable length frame forward service.  That said, I really have to 
question whether it would have been better to just modify SLE F-CLTU to 
accommodate USLP variable length frames instead of weighing this document 
down with this added baggage.

It appears that in this document we got far fewer of the essential 
features than were required and, at the same time, more features than were 
really useful.

While I recognize that a large amount of work has been expended to get 
this document to this point, in my estimation it falls far short of what 
is really required.  It does not provide all of the features called for in 
the IOAG SISG, nor that were documented in the SCCS-ARD Magenta Book, nor 
does it appear to provide all of the features in the F-CLTU Orange Book 
which has for years been supporting major operational missions.  It was 
intended to provide services that could meet all of these requirements, 
and it seems to have failed to do so.

Accordingly, I cannot support publishing this document in its current 
form.

With respect, Peter Shames

From: Peter Shames <peter.m.shames at jpl.nasa.gov>
Date: Thursday, March 4, 2021 at 1:34 PM
To: John Pietras <john.pietras at gst.com>
Cc: Erik Barkley <erik.j.barkley at jpl.nasa.gov>, "Holger.Dreihahn at esa.int" 
<Holger.Dreihahn at esa.int>, Wolfgang Hell <wo_._he at t-online.de>, Tim Pham <
timothy.t.pham at jpl.nasa.gov>, "Neutze, Robert L. (MSFC-EO60)[CSC - HOSC]" 
<robert.l.neutze at nasa.gov>, "Clement.Leclerc at cnes.fr" <
Clement.Leclerc at cnes.fr>, "Liao, Jason C (US 333F)" <
jason.c.liao at jpl.nasa.gov>, Tom Gannett <thomas.gannett at tgannett.net>
Subject: Re: [EXTERNAL] Response to CSEG Review comments on the FF-CSTS 
candidate Blue Book

Dear John,

Always a wonderful opening to a letter, right?  After looking over, in 
some detail, the proposed resolutions for the issues that I raised I am 
pleased to be able to state that you have addressed my concerns.  I 
believe that the changes have made the various distinctions among the 
different flavors of service provision clearer, and, more importantly from 
my PoV, have made the visible the assumptions that were  “baked in”, but 
not expressed, in service production.  This now provided visibility to the 
multiplexing functions that are so essential to the proper functioning of 
this service as a key part of the future CCSDS ESLT “plumbing”.

I consider my PID to poll CESG-P-2020-12-006 to be resolved and agree to 
having the revised document published in its modified form.

I will note that some last minute massaging by Tom Gannett will likely be 
required, there were at least a couple of spelling errors noted in 
passing.

Thanks, Peter

From: John Pietras <john.pietras at gst.com>
Date: Sunday, February 14, 2021 at 1:31 PM
To: Peter Shames <peter.m.shames at jpl.nasa.gov>
Cc: Erik Barkley <erik.j.barkley at jpl.nasa.gov>, "Holger.Dreihahn at esa.int" 
<Holger.Dreihahn at esa.int>, Wolfgang Hell <wo_._he at t-online.de>, Tim Pham <
timothy.t.pham at jpl.nasa.gov>, "Neutze, Robert L. (MSFC-EO60)[CSC - HOSC]" 
<robert.l.neutze at nasa.gov>, "Clement.Leclerc at cnes.fr" <
Clement.Leclerc at cnes.fr>, "Liao, Jason C (US 333F)" <
jason.c.liao at jpl.nasa.gov>, Tom Gannett <thomas.gannett at tgannett.net>
Subject: [EXTERNAL] Response to CSEG Review comments on the FF-CSTS 
candidate Blue Book

Peter, it’s taken a few weeks, but the CSTSWG has completed our response 
to your conditions and comments on the CSEG Review copy of the FF-CSTS 
candidate Blue Book. Erik has also reviewed and concurs with the response.

Attached are (a) an updated draft FF-CSTS book, containing the changes to 
the book that have resulted in response to your conditions/comments, and 
(b) a document that contains point-by-point responses to the comments that 
you made in your email of 16 January to Erik, Holger, and Tom and in your 
marked-up copy of the CESG Approval version of the book.

Hopefully, between the changes that have been made and the explanations 
provided for questions that you had, your conditions for approval have 
been satisfied. Please contact me if you have any further questions or 
comments. 

Tom G. – I’m copying you on this to keep you in the loop on where this 
book sits. Once the CSTSWG and Peter have come to agreement regarding 
removal of his conditions, I’ll send to you the final updated copy (if 
there any more changes), the final response/resolution document, and the 
original artwork for the updated figures so that you can prepare the CMC 
approval version.

Best regards,
John

From: Gian Paolo Calzolari <Gian.Paolo.Calzolari at esa.int>
Date: Thursday, March 11, 2021 at 3:26 AM
To: Peter Shames <peter.m.shames at jpl.nasa.gov>
Cc: CCSDS Engineering Steering Group - CESG Exec <cesg at mailman.ccsds.org>, 
Tom Gannett <thomas.gannett at tgannett.net>
Subject: Re: [EXTERNAL] Re: [CESG] CESG-P-2020-12-006 Approval to publish 
CCSDS 922.3-B-1, Cross Support Transfer Service—Forward Frame Service ( 
Blue Book, Issue 1)

Peter, 
    the updates have been visible to me only when -  following the 
announcement of conditions met - I asked them to Tom. 
I do not know whether anybody else in CESG (apart from CSS AD and DAD, I 
would guess) could see them. 

As I read your mail I perceive that everybody else (i.e. WG, CSS, other 
CESGers) is guilty but you. 
However, never mind. 

Clearly the rules only require to close condition and go ahead with next 
poll without more review from CESG. 
On the other hand the rules also require to vote during poll (and not 
after polls) and - as CESG agreed - to provide formal PIDs (this was 
discussed in order to give real visibility on conditions). 

I am reporting what I see as an issue with "heavy" changes after "heavy" 
Conditions. 
I would be curios about knowing who in CESG has been able to fully 
understand the requested changes and eventually to track the implemented 
changes. 
IMO, the mechanism of CESG conditions was thought to address changes with 
"reasonable/limited scope". 
IMO, when changes exceed a "reasonable/limited scope" the document should 
return to CESG Poll (or even to Agency Review in some cases). 

If nobody else can see this issue except me, then... peace and love. 

Best regards 

Gian Paolo 

From:        "Shames, Peter M (US 312B)" <peter.m.shames at jpl.nasa.gov> 
To:        "Gian.Paolo.Calzolari at esa.int" <Gian.Paolo.Calzolari at esa.int>, 
"cesg at mailman.ccsds.org" <cesg at mailman.ccsds.org> 
Cc:        "Thomas Gannett" <thomas.gannett at tgannett.net> 
Date:        11-03-21 00:10 
Subject:        Re: [EXTERNAL] Re: [CESG]  CESG-P-2020-12-006 Approval to 
publish CCSDS 922.3-B-1, Cross Support Transfer Service—Forward Frame 
Service (  Blue Book, Issue 1) 

Hi Gippo,

I’m guessing that these necessary updates were “visible” to you, and the 
rest of the CESG, because you were able to state the magnitude of the 
required changes.  Perhaps you are asking that the CESG be given an 
opportunity to re-review the changes in response to the PID.  I cannot 
tell because you did not address that issue.  But the CESG did get to see 
the changes.

In point of fact, the revisions do not make the document “heavily, nor 
completely different”  from the document that was reviewed.  What the 
changes do accomplish is to align the description of the service with the 
functionality requested in the IOAG SISG report from years ago, which you, 
yourself, were a co-author of.   What was required were not changes to the 
FF-CSTS service provisioning itself, but were clarifications to the 
service production that were not otherwise documented anywhere aside from 
the IOAG SISG report and the SCCS-ARD.  In the absence of these 
clarifications the functionality of the service, both provision (which is 
the core focus of the service exposed to users) and production (which are 
the functions that must be executed to deliver full functionality of frame 
merging and DTN bundle agent and CFDP file agent integration) would be 
inadequately documented.  It would have been left to the users to guess 
what production functionality was required or supported.  A massive source 
of ambiguity for a service that is to be the heart of DTN integration and 
support in the future ESLTs.

What is wrong with this approach is that the WG failed to incorporate the 
description of these critical production functions in the first place, and 
that the CESG failed to catch it earlier.  I point the finger at myself 
here, since I had the opportunity to catch the issue earlier and did, in 
fact, point this concern out a couple of years ago.  But then, I am only 
one of the six Area Directors.  It appears that no one else, including 
you, who were one of the authors of the IOAG SISG report that defined this 
new service, managed to catch this issue until now.

So, just what exactly is the problem here?

Peter

From: CESG <cesg-bounces at mailman.ccsds.org> on behalf of Gian Paolo 
Calzolari <Gian.Paolo.Calzolari at esa.int>
Date: Wednesday, March 10, 2021 at 7:35 AM
To: CCSDS Engineering Steering Group - CESG Exec <cesg at mailman.ccsds.org>
Cc: Tom Gannett <thomas.gannett at tgannett.net>
Subject: [EXTERNAL] Re: [CESG] CESG-P-2020-12-006 Approval to publish 
CCSDS 922.3-B-1, Cross Support Transfer Service—Forward Frame Service ( 
Blue Book, Issue 1)

Dear All, 
   I see that there is a 24 pages document only to explain which changes 
have been applied (to a 242 pages document) because of the (late) 
conditions. 

The document that will go to CMC - in a way invisible to CESGers -  is now 
heavily (if not completely) different from the one that was evaluated by 
CESG. 
Frankly speaking I think there is something very wrong in this approach. 

Best regards 

Gian Paolo 

From:        "Thomas Gannett" <thomas.gannett at tgannett.net> 
To:        cesg at mailman.ccsds.org 
Date:        07-03-21 16:48 
Subject:        Re: [CESG]  CESG-P-2020-12-006 Approval to publish CCSDS 
922.3-B-1, Cross Support Transfer Service—Forward Frame Service (  Blue 
Book, Issue 1) 
Sent by:        "CESG" <cesg-bounces at mailman.ccsds.org> 

Dear CESG Members,

Conditions for approval of CCSDS 922.3-B-1, Cross 
Support Transfer Service—Forward Frame Service 
(Blue Book, Issue 1) have been disposed to the 
satisfaction of the AD(s) who voted to approve 
with conditions. The Secretariat will now proceed 
with CMC polling to authorize publication.

Thomas Gannett
thomas.gannett at tgannett.net
+1 443 472 0805 [attachment "Re EXTERNAL Response to CSEG Review comments 
on the FF-CSTS candidate Blue Book.txt" deleted by Gian Paolo 
Calzolari/esoc/ESA] _______________________________________________
CESG mailing list
CESG at mailman.ccsds.org
https://mailman.ccsds.org/cgi-bin/mailman/listinfo/cesg 
This message is intended only for the recipient(s) named above. It may 
contain proprietary information and/or
protected content. Any unauthorised disclosure, use, retention or 
dissemination is prohibited. If you have received
this e-mail in error, please notify the sender immediately. ESA applies 
appropriate organisational measures to protect
personal data, in case of data privacy queries, please contact the ESA 
Data Protection Officer (dpo at esa.int).
This message is intended only for the recipient(s) named above. It may 
contain proprietary information and/or
protected content. Any unauthorised disclosure, use, retention or 
dissemination is prohibited. If you have received
this e-mail in error, please notify the sender immediately. ESA applies 
appropriate organisational measures to protect
personal data, in case of data privacy queries, please contact the ESA 
Data Protection Officer (dpo at esa.int).[attachment 
"922x3b0_CESG_Approval-PID_response_update-210207[1].doc" deleted by Gian 
Paolo Calzolari/esoc/ESA] 
This message is intended only for the recipient(s) named above. It may 
contain proprietary information and/or
protected content. Any unauthorised disclosure, use, retention or 
dissemination is prohibited. If you have received
this e-mail in error, please notify the sender immediately. ESA applies 
appropriate organisational measures to protect
personal data, in case of data privacy queries, please contact the ESA 
Data Protection Officer (dpo at esa.int).
This message is intended only for the recipient(s) named above. It may 
contain proprietary information and/or
protected content. Any unauthorised disclosure, use, retention or 
dissemination is prohibited. If you have received
this e-mail in error, please notify the sender immediately. ESA applies 
appropriate organisational measures to protect
personal data, in case of data privacy queries, please contact the ESA 
Data Protection Officer (dpo at esa.int).
This message is intended only for the recipient(s) named above. It may 
contain proprietary information and/or
protected content. Any unauthorised disclosure, use, retention or 
dissemination is prohibited. If you have received
this e-mail in error, please notify the sender immediately. ESA applies 
appropriate organisational measures to protect
personal data, in case of data privacy queries, please contact the ESA 
Data Protection Officer (dpo at esa.int).
This message is intended only for the recipient(s) named above. It may 
contain proprietary information and/or
protected content. Any unauthorised disclosure, use, retention or 
dissemination is prohibited. If you have received
this e-mail in error, please notify the sender immediately. ESA applies 
appropriate organisational measures to protect
personal data, in case of data privacy queries, please contact the ESA 
Data Protection Officer (dpo at esa.int).

This message is intended only for the recipient(s) named above. It may contain proprietary information and/or
protected content. Any unauthorised disclosure, use, retention or dissemination is prohibited. If you have received
this e-mail in error, please notify the sender immediately. ESA applies appropriate organisational measures to protect
personal data, in case of data privacy queries, please contact the ESA Data Protection Officer (dpo at esa.int).

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/cesg/attachments/20210317/a1df0970/attachment-0001.htm>