<font size=2 face="sans-serif">Peter,</font>
<br><font size=2 face="sans-serif"> we
had to skip this topic because we got late.</font>
<br><font size=2 face="sans-serif">As well, I did propose te topic beacuse
I am pretty sure we had not ever had to deal with this kind of question
before,</font>
<br><font size=2 face="sans-serif">Actually in another point the Orange
Book states:</font>
<br><font size=2 color=blue face="sans-serif">.... it is necessary to:</font>
<br><font size=2 color=blue face="sans-serif">– define a new reserved
APID in case of a Space Packet, to signal the use of the EC shim layer.</font>
<br><font size=2 color=blue face="sans-serif">– define a new Protocol
Identifier or new protocol extensions, in case of an Encapsulation Packet,
to signal the use of the EC shim layer. </font>
<br>
<br><font size=2 face="sans-serif">The second bullet is aligned with your
(good) remark and supersed the text I attached to my first e-mail.</font>
<br>
<br><font size=2 face="sans-serif">I propose we oput this in agenda for
next CESG telecon also considering that</font>
<br><font size=2 face="sans-serif">1) for the time being the APID can be
left undefined and subject to agency choice and management.</font>
<br><font size=2 face="sans-serif">2) One value of the </font><font size=2 face="Calibri">Extended
Protocol Identifiers can be set to be "Agency Specific"</font>
<br><font size=2 face="Calibri">3) JPL and DLR are preparing a concept
paper for a Blue Book on Erasure Codes so in the future we may have stringer
need for those SANA values.</font>
<br>
<br><font size=2 face="Calibri"> and, last but not least, we do need
a CESG agreed approach.</font>
<br>
<br><font size=2 face="Calibri">Regards</font>
<br>
<br><font size=2 face="Calibri">Gippo</font>
<br>
<br>
<br>
<br><font size=1 color=#5f5f5f face="sans-serif">From:
</font><font size=1 face="sans-serif">"Shames, Peter
M (312G)" <peter.m.shames@jpl.nasa.gov></font>
<br><font size=1 color=#5f5f5f face="sans-serif">To:
</font><font size=1 face="sans-serif">"Gian.Paolo.Calzolari@esa.int"
<Gian.Paolo.Calzolari@esa.int>, "Nestor.Peccia@esa.int"
<Nestor.Peccia@esa.int>, </font>
<br><font size=1 color=#5f5f5f face="sans-serif">Cc:
</font><font size=1 face="sans-serif">Tom Gannett <tomg@aiaa.org>,
CCSDS CESG -- <cesg@mailman.ccsds.org></font>
<br><font size=1 color=#5f5f5f face="sans-serif">Date:
</font><font size=1 face="sans-serif">03/09/2014 02:16</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Subject:
</font><font size=1 face="sans-serif">Re: [CESG] Topic
for telecon: Defining SANA registries on Orange book request</font>
<br>
<hr noshade>
<br>
<br>
<br><font size=2 face="Calibri">Gippo,</font>
<br>
<br><font size=2 face="Calibri">I do not believe that we got to this topic
in today's CESG telecon. We have not, to my knowledge, ever had to
deal with this kind of question before, I.e. The creation of a registry
or changes to a registry by an Orange Book. We had to deal with something
similar back when SCPS was published as an Orange Book, but at that point
we did not have a SANA and the "registry" was just the published
documents.</font>
<br>
<br><font size=2 face="Calibri">I general I think we should consider this
sort of request, but I think we need to do an engineering analysis in the
general case to see if it is acceptable. My reasoning is that if
we have a lot of Orange Books (and we seem to be creating more of them
now) we could use up valuable "ID" real estate quickly, as in
Protocol ID and Reserved APIDs. The Extended Protocol Ids are not
so much of an issue.</font>
<br>
<br><font size=2 face="Calibri">In the normal SANA course of things each
registry has an associated policy and means of managing the registry entries.
Given the limited number space it does not seem reasonable to me
to allow an experimental spec to use up one of the limited number of protocol
identifiers defined in 135.0-B-4, table 7-7a,, but it does seem acceptable
to use one of the extended protocol identifiers defined in 133.1-b-2. </font>
<br>
<br><font size=2 face="Calibri">Furthermore, the policy on both of these
registries is "CCSDSBlue", which means that only a Blue Book
update is acceptable. Perhaps that policy should be re-stated for
the Extended Protocol Identifiers (</font><a href=http://sanaregistry.org/r/extended_protocol_id/extended_protocol_id.html><font size=2 color=blue face="Calibri"><u>http://sanaregistry.org/r/extended_protocol_id/extended_protocol_id.html</u></font></a><font size=2 face="Calibri">),
to allow such more liberal assignments, but surely not for the protocol
identifiers (</font><a href=http://sanaregistry.org/r/protocol_id/protocol_id.html><font size=2 color=blue face="Calibri"><u>http://sanaregistry.org/r/protocol_id/protocol_id.html</u></font></a><font size=2 face="Calibri">).</font>
<br>
<br><font size=2 face="Calibri">In any event, I think that this is something
that the SLS should take up and bring to the SSG (and/or CESG) for further
discussion after the technical options and implications have been deliberated.</font>
<br>
<br><font size=2 face="Calibri">Regards, Peter</font>
<br>
<br>
<br>
<br><font size=2 face="Calibri"><b>From: </b>Gian Paolo Calzolari <</font><a href=mailto:Gian.Paolo.Calzolari@esa.int><font size=2 color=blue face="Calibri"><u>Gian.Paolo.Calzolari@esa.int</u></font></a><font size=2 face="Calibri">><b><br>
Date: </b>Monday, September 1, 2014 12:07 AM<b><br>
To: </b>Nestor Peccia <</font><a href=mailto:Nestor.Peccia@esa.int><font size=2 color=blue face="Calibri"><u>Nestor.Peccia@esa.int</u></font></a><font size=2 face="Calibri">><b><br>
Cc: </b>Tom Gannett <</font><a href=mailto:tomg@aiaa.org><font size=2 color=blue face="Calibri"><u>tomg@aiaa.org</u></font></a><font size=2 face="Calibri">>,
CCSDS Engineering Steering Group - CESG Exec <</font><a href=mailto:cesg@mailman.ccsds.org><font size=2 color=blue face="Calibri"><u>cesg@mailman.ccsds.org</u></font></a><font size=2 face="Calibri">><b><br>
Subject: </b>[CESG] Topic for telecon: Defining SANA registries on Orange
book request</font>
<br>
<br><font size=2 face="sans-serif">Nestor, I would like to add a topic
for next telecon.<br>
As you know CESG is voting for the pblication of an Orange Book on Erasure
Codes.<br>
This draft book states:</font><font size=2 face="Calibri"> </font><font size=2 face="Arial"><br>
This document requests that SANA perform the following actions:<br>
1. define a new reserved APID...<br>
2. define a new Protocol Identifier...<br>
3, define a new Extended Protocol Identifier...</font><font size=2 face="Calibri">
</font>
<p><font size=2 face="sans-serif"><br>
In general I think a (published) book should not contain those requests
but simply reference the registries that should be created "as part
of the approval process.<br>
However in this case we are speaking about an Orange Book. <br>
Is it acceptable to create registries for Orange Books?</font><font size=2 face="Calibri"><br>
</font><font size=2 face="sans-serif"><br>
Regards</font><font size=2 face="Calibri"> <br>
</font><font size=2 face="sans-serif"><br>
Gian Paolo</font><font size=2 face="Calibri"> </font>
<p><font size=2 face="Calibri">This message and any attachments are intended
for the use of the addressee or addressees only.<br>
The unauthorised disclosure, use, dissemination or copying (either in whole
or in part) of its<br>
content is not permitted.<br>
If you received this message in error, please notify the sender and delete
it from your system.<br>
Emails can be altered and their integrity cannot be guaranteed by the sender.<br>
<br>
Please consider the environment before printing this email.<br>
</font>
<p><PRE>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.
</PRE>