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

[Gian.Paolo.Calzolari at esa.int]

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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/cesg/attachments/20160713/680a1388/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 7112 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/cesg/attachments/20160713/680a1388/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 6328 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/cesg/attachments/20160713/680a1388/attachment-0001.gif>