[CESG] Why renaming GSCID inf revised CCSDS SCID Code Assignment Control Procedures?

Gian.Paolo.Calzolari at esa.int Gian.Paolo.Calzolari at esa.int
Tue Jul 19 07:31:29 UTC 2016


Fine with me.
What about other CESGers?
Regards

Gian Paolo



From:   "Shames, Peter M (312B)" <peter.m.shames at jpl.nasa.gov>
To:     "Thomas Gannett" <thomas.gannett at tgannett.net>, 
"Gian.Paolo.Calzolari at esa.int" <Gian.Paolo.Calzolari at esa.int>
Cc:     "'CCSDS CESG --'" <cesg at mailman.ccsds.org>
Date:   18/07/2016 18:12
Subject:        Re: [CESG] Why renaming GSCID inf revised CCSDS SCID Code 
Assignment Control Procedures?



Guys,
 
I think we?ve gotten into the right neighborhood now.    And I like Tom?s 
suggestion for use of Q-SCID.  I?ll mark up the draft to reflect this 
agreement and re-submit. 
 
And we will, as requested, go thru the full CESG / CMC / Agency review 
cycle.
 
Agreed?
 
Peter
 
 
From: Tom Gannett <thomas.gannett at tgannett.net>
Date: Monday, July 18, 2016 at 6:09 AM
To: Gian Paolo Calzolari <Gian.Paolo.Calzolari at esa.int>, Peter Shames 
<peter.m.shames at jpl.nasa.gov>
Cc: CCSDS Engineering Steering Group - CESG Exec <cesg at mailman.ccsds.org>
Subject: RE: [CESG] Why renaming GSCID inf revised CCSDS SCID Code 
Assignment Control Procedures?
 
I?m not sure where ?global? came from, except I think it was a catchy term 
in the early days of personal computing. The book actually defines a 
qualified SCID, so why not ?QSCID? for SCID qualified by version number 
and frequency band? 
 
 
Thomas Gannett
thomas.gannett at tgannett.net
+1 443 472 0805
 
From: Gian.Paolo.Calzolari at esa.int [mailto:Gian.Paolo.Calzolari at esa.int] 
Sent: Monday, July 18, 2016 4:47 AM
To: Shames, Peter M (312B)
Cc: CCSDS CESG --; Tom Gannett
Subject: Re: [CESG] Why renaming GSCID inf revised CCSDS SCID Code 
Assignment Control Procedures?
 
Peter, 
        my cent. 
1) Priority is on 320.0-B/M ==> let's focus there 
2) Define  ?Extended GSCID? or E-GSCID (or any better name) 
3) Remark with NOTES that 
        a- GSCID is the term used before (kept for backward compatibility) 
and it defines a value that does go into the field(s) of the Transfer 
Frames (while  E-GSCID does not). 
        b- other documents refer to that value as MCID 
        c- (optionally) future use of the acronym GSCID is 
discouraged/deprecated. 
4) Replace VN with TFVN and add a NOTE to explain this painless 
replacement due to the fact that TFVN is used by SDLP's and SLE documents 
and that "Version Number" could be ambiguous as there are actually TFVN 
and PVN. 

That's all. 
For the rest let's see the version Tom will produce at CESG Poll. 

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>, 
"CCSDS CESG --" <cesg at mailman.ccsds.org> 
Cc:        "Tom Gannett" <thomas.gannett at tgannett.net> 
Date:        14/07/2016 18:01 
Subject:        Re: [CESG] Why renaming GSCID inf revised CCSDS SCID Code 
Assignment Control Procedures? 




Hi Gippo, 
  
That?s fine, but what do you propose we do with the existing 
inconsistency?   We have used two different terms to mean the exact same 
thing.  In one case (actually 4 cases) we call these two fields ?MCID?, in 
the other case we call the exact same two fields ?SCID?.  In your opinion 
should we drop the term GSCID and use MCID everywhere, or should we bring 
all of the protocols into line and adopt GSCID everywhere? 
  
Or, probably the worst case, should we document this mistake we have made 
so that it is clear that we have two terms for the same thing? 
  
I?m asking you, in particular, because all of those protocol docs are in 
your area.  I?m also guessing that you will be resistant to changing any 
of them, in which case the choice is likely to be ?Keep MCID.?  We can do 
that, but then we will need to put something in the ?GSCID doc?, which 
should really in that case be called the ?MCID doc?, that these are 
actually one and the same. 
  
And I think, as I said, that we can call this field, concatenated with the 
frequency bin, the ?Extended GSCID? or E-GSCID (or E-MCID). 
  
I?d like to get your opinion about this specific issue so I can include it 
in the revised 320x0 that I submit for review. 
  
Thanks, Peter 
  
  
From: CESG <cesg-bounces at mailman.ccsds.org> on behalf of Gian Paolo 
Calzolari <Gian.Paolo.Calzolari at esa.int>
Date: Thursday, July 14, 2016 at 2:01 AM
To: CCSDS Engineering Steering Group - CESG Exec <cesg at mailman.ccsds.org>
Cc: Tom Gannett <thomas.gannett at tgannett.net>
Subject: Re: [CESG] Why renaming GSCID inf revised CCSDS SCID Code 
Assignment Control Procedures? 
  
IMHO reusing terms giving them a different meaning is wrong by nature and 
prone to introduce backward compatibility issues. 



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>, "Tom Gannett" <
thomas.gannett at tgannett.net> 
Date:        13/07/2016 17:22 
Subject:        Re: [CESG] Why renaming GSCID inf revised CCSDS SCID Code 
Assignment Control Procedures? 





Dear Gippo, 
 
In this case we seem to have a term, GSCID, defined in 320x0 that is used 
only in that document and nowhere else.  And we have the fields that 
compose that term, the VN and SCID, defined in every other relevant 
document as the MCID.  The only exception to this, I have been informed, 
is the new USLP which proposes to use the term GSCID instead of MCID. 
 
In order to get this cleared up efficiently I propose that we use the term 
MCID in the 320x0 document, thus fixing that obvious error, and that we 
also bring the USLP in-line, before it sees the light of day. 
 
At that point we can use the term GSCID as I proposed, without any risk of 
confusing anyone, since no other document uses that term. 
 
Or, if you wish, we can create a new term, Extended SCID (ESCID) and 
define it to mean the concatenation of the Frequency Band with the MCID 
(or GSCID, if you wish to persist that into the future).   
 
Or perhaps you want to change all of the other protocol docs to use the 
term GSCID instead of MCID so that they are all consistent? 
 
Which of these are acceptable, to you and the other CESG members? 
 
Regards, Peter 
 
 
From: Gian Paolo Calzolari <Gian.Paolo.Calzolari at esa.int>
Date: Wednesday, July 13, 2016 at 5:30 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: [CESG] Why renaming GSCID inf revised CCSDS SCID Code 
Assignment Control Procedures? 
 
Dear Peter, 
      I never said that the current situation is perfect. 
However i do find inappropriate having a term that means alfa till today 
and it will mean beta as of tomorrow. 
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>, 
"CCSDS CESG --" <cesg at mailman.ccsds.org> 
Cc:        "Tom Gannett" <thomas.gannett at tgannett.net> 
Date:        12/07/2016 18:58 
Subject:        Re: [CESG] Why renaming GSCID inf revised CCSDS SCID Code 
Assignment Control Procedures? 






Dear Gippo, 

I appreciate your attention to detail and looking at this early on, but I 
have to differ re some conclusions.   I note the following: 

-          The term GSCID was defined as ?GSCID = VN . SCID? where the ?.? 
means concatenation. 
-          The terms SCID and GSCID are used more or less interchangeably 
in the CCSDS 320x0b document, but they mean different things.  This is a 
flaw in the current document that I have tried to remedy. 
-          The term SCID is defined specifically in the various protocol 
documents, 320x0 just references it. 
-          The term GSCID does not appear in any of our protocol 
documents, TC, TM, or AOS.  They tend to call the combination of the VN 
(actually the TFVN) and the SCID an MCID, not a GSCID. 
-          If you search the CCSDS files you will find that the only 
reference to GSCID is in this 320x0 document, and not in any others. 
All of that said, I think that there is really no impediment in the way of 
extending the definition of GSCID to include the frequency band, because 
globally, in fact, the frequency band has from the beginning been a part 
of the actual physical and logical link layer signal.  We just did not 
acknowledge this until now. 
But if you are worried about some confusion for others we could introduce 
a new term for the FB . VN . SCID combination.  I?m reluctant to call it a 
?Super? SCID, that sounds like a kid?s toy.   ;-}  And in truth, I think 
that this is more of a Global SCID than the current definition, and which 
the protocol docs call an MCID.  In effect we have given the same thing 
two different names, surely that is not a good approach?  Maybe we should 
align this book with all of the existing protocol docs and call the VN . 
SCID combo an MCID and the FB . VN . SCID combo the GSCID? 
I am open to other suggestions. 
Regards, Peter 


From: CESG <cesg-bounces at mailman.ccsds.org> on behalf of Gian Paolo 
Calzolari <Gian.Paolo.Calzolari at esa.int>
Date: Tuesday, July 12, 2016 at 6:18 AM
To: CCSDS Engineering Steering Group - CESG Exec <cesg at mailman.ccsds.org>
Cc: Tom Gannett <thomas.gannett at tgannett.net>
Subject: [CESG] Why renaming GSCID inf revised CCSDS SCID Code Assignment 
Control Procedures? 

Dear CESGers, 
     in order to gain time and not to delay eventual Poll and start of 
Agency Review, I would like to anticipate that as SLS AD I wonder about 
the need of renaming GSCID in revised CCSDS SCID Code Assignment Control 
Procedures. 

In fact the revised book includes a new definition of GSCID (see snapshot) 
that is conflicting with the definition in the Blue Book in force (see 
second snapshot) as the new one also refers to Frequency Band. 

First of all I think that it is not appropriate modifying a term used for 
so many years (and for sure spread in "billions" of documents from many 
agencies) also considering that the the prefix "Global" is widely used for 
e.g. the Global VCID and Global MAP ID (for sure in SLE and SLS books) 
without considering the Frequency Band. 
Therefore there would be a discrepancy of meaning about the term Global 
between the GSCID and the GVCID 

Last, but not list the book title "CCSDS Global Spacecraft Identification 
Field" points to a field i.e. a portion of data that is normally contained 
in transfer frames. In other words while the actual GSCID matches 
completely the contents of some bits of a Frame Header, the proposed 
future GSCID will not. 

As a conclusion I would retain the current definition of  GSCID while 
adding a new definition for the  concatenation of the frequency band (FB), 
2-bit Version Number (VN) and the SCID. 
This could be called Universal SCID, Super SCID, Supreme SCID, Frequenced 
SCID or whatever you prefer.    [Please consider some humour in some 
proposed definitions.] 

Regards 

Gian Paolo 

PS Of course I did not perform a complete review of the document....... 



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


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/20160719/f00cf970/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 7115 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/cesg/attachments/20160719/f00cf970/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 6331 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/cesg/attachments/20160719/f00cf970/attachment-0001.gif>


More information about the CESG mailing list