From thomas.gannett at tgannett.net Mon Apr 4 18:12:57 2011
From: thomas.gannett at tgannett.net (Thomas Gannett)
Date: Mon Apr 4 17:55:54 2011
Subject: [CESG] New CESG Poll
Message-ID: <4d9a4270.9182e50a.746c.ffff9ecd@mx.google.com>
Skipped content of type multipart/alternative-------------- next part --------------
BEGIN:VCALENDAR
PRODID:-//Microsoft Corporation//Outlook 12.0 MIMEDIR//EN
VERSION:2.0
METHOD:PUBLISH
X-MS-OLK-FORCEINSPECTOROPEN:TRUE
BEGIN:VEVENT
CATEGORIES:Orange Category
CLASS:PUBLIC
CREATED:20110404T221111Z
DESCRIPTION:CESG-P-2011-04-001 Approval to publish CCSDS 910.14-G-1\, Spac
e Communication Cross Support???Service Management???Operations Concept (G
reen Book\, Issue 1)\n
DTEND;VALUE=DATE:20110419
DTSTAMP:20110404T221111Z
DTSTART;VALUE=DATE:20110418
LAST-MODIFIED:20110404T221111Z
PRIORITY:5
SEQUENCE:0
SUMMARY;LANGUAGE=en-us:CESG Poll Closure
TRANSP:TRANSPARENT
UID:040000008200E00074C5B7101A82E0080000000060114CA2F3F2CB01000000000000000
010000000EB24FDC95DC2044BB49C1D98AE4E0D01
X-ALT-DESC;FMTTYPE=text/html:\n\n\n\n\n\n\n\n\nCESG-P-2011-04-001 Approval to publish CCSDS 910.14-G-1\, \; Space
Communication Cross Support???Service Management???Operations Concept (Gr
een Book\, Issue 1)
\n\n\n
X-MICROSOFT-CDO-BUSYSTATUS:FREE
X-MICROSOFT-CDO-IMPORTANCE:1
X-MICROSOFT-DISALLOW-COUNTER:FALSE
X-MS-OLK-ALLOWEXTERNCHECK:TRUE
X-MS-OLK-CONFTYPE:0
BEGIN:VALARM
TRIGGER:-PT1080M
ACTION:DISPLAY
DESCRIPTION:Reminder
END:VALARM
END:VEVENT
END:VCALENDAR
From adrian.j.hooke at jpl.nasa.gov Tue Apr 5 08:16:02 2011
From: adrian.j.hooke at jpl.nasa.gov (Hooke, Adrian J (9000))
Date: Tue Apr 5 07:58:42 2011
Subject: [CESG] FW: IOAG: Priorities concerning the SM&C Services
Message-ID: <6D12692A7874434DAC51C93B019D4349F30AB6FF01@ALTPHYEMBEVSP20.RES.AD.JPL>
From: Michael.Schmidt@esa.int [Michael.Schmidt@esa.int]
Sent: Tuesday, April 05, 2011 3:02 AM
To: Soula Jean-Marc; Adde, Barbara (HQ-CG000)
Cc: Hooke, Adrian J. (HQ-CG000)[JPL]; inoue.hiroshi; 'Salotti Luca'; 'Martin Pilgram'; Kearney, Mike W. (MSFC-EO01); Paolo.Ferri@esa.int; 'peter.allan@stfc.ac.uk'; Liebrecht, Philip E (HQ-CG000); 'razoryonov@rambler.ru'; '???'; 'sks@isac.gov.in'; Kearney, Mike W. (MSFC-EO01); Warhaut Manfred
Subject: IOAG: Priorities concerning the SM&C Services
Dear All,
my impression from the last telecon was that the MOSCG might not continue since it is not possible to identify a new chair. However, since the SM&C services have some importance and since the corresponding SM&C WG in CCSDS has asked for some guidance I believe that it is useful to identify the priorities from an operations points of view.
Therefore please find attached the ESA proposal concerning the priorities of the various SM&C services.
Priority 1a: Completion of services that are almost done
The SM&C should complete the work on services, which are almost done. This concerns:
* M&C Service: This service is almost completed and is required by agencies that are already implementing corresponding solutions. The effort should be limited.
* Common Service: Since this provides capabilities that are needed in conjunction with all other services and since the work is almost the service should be completed. The effort should be limited.
Note: The above services are not important for operations of unmanned missions at this stage. It is possible that manned missions have a certain interest in these services.
Priority 1b: Services that are highly important to operations at ESA
* Planning Services: The planning interfaces (on ground) and the corresponding data products should be dealt with first. These are the areas in which even within a single Agency very little standardisation exists. At the same time, these are also areas in which a lot of cross-agencies interfaces are already established, so the benefits of standardisation would be immediate. Since this service covers also the data products it is recommended to also look at the required Data Product Delivery Services in this context.
Priority 2: Services that are of medium importance to operations at ESA
* Navigation Service: The data structures are already well defined in the context of the CCSDS NAV working group, so the service layer on top of this should be relatively straightforward.
Priority 3: Services that are of less importance to operations at ESA
* Scheduling: There is a lack of standardisation of the interfaces or "services" offered by Planning systems and also in the distribution of schedules to be executed. Increasing use of on-board scheduling and on-board procedures also mean scheduling and automation services are exposed to the space-ground interface. The services need to be considered as a set to ensure a consistent and coherent approach to managing the control aspect of M&C, both in live operations and history, by ensuring referential integrity and a clear audit trail from planning request to scheduled task to automated activity to discrete action.
Note: Only the automation services that are relevant in the context of scheduling are to be taken into account here.
Priority 4: Services that are not relevant to operations at ESA at this stage
This category concerns services that are not relevant to cross-support at this stage.
* On-Board S/W Maintenance, Time Services: It is recommended that these services are not dealt with in detail at this stage. The work should be resumed when the corresponding concepts have been widely established across Agencies.
* Automation Service: It is recommended that the automation services that are not relevant in the context of scheduling are not dealt with at this stage.
Kind Regards
Michael Schmidt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/cesg/attachments/20110405/17c436c4/attachment.htm
From Gian.Paolo.Calzolari at esa.int Wed Apr 6 12:42:15 2011
From: Gian.Paolo.Calzolari at esa.int (Gian.Paolo.Calzolari@esa.int)
Date: Wed Apr 6 12:25:10 2011
Subject: [CESG] CCSDS 355.0-R-1, Space Data Link Security Protocol (Red Book,
Issue 1) vs Proximity-1
Message-ID:
Dear All,
as you know is these days CESG Poll CESG-P-2011-03-005 is ongoing
for the Approval to release CCSDS 355.0-R-1, Space Data Link Security
Protocol (Red Book, Issue 1) for CCSDS Agency review.
Peter has approved the poll (thanks!) with some remarks.
I think it is worth to address his first remark (i.e. Why is Porx-1 not
addressed along with TM, TC & AOS? Is there the assumption that if data
is securely delivered to space that relaying it is then not a problem? )
for sake of clarity.
The shortest answer to the question is that Proximity-1 is not addressed
on purpose as SDLS WG decision; i.e. SDLS protocol is meant to protect TC
Direct From Earth (DFE) and TM Direct To Earth (DTE) space links.
Here are some points providing the rationale:
- The prime threats we are aiming to protect from with this SDLS protocol
are on earth, not in space and surely not in deep space. This is why SDLS
WG did not consider compatibility with Proximity-1 a necessary feature of
the SDLS protocol. The User Requirements Document (URD) which was the
basis for SDLS development did not list Proximity-1 as target data link
protocol for the above mentioned reason.
- The WG had originally gone into the SDLS protocol development with the
intent of creating a ?shim? to allow it to work with TM, TC, AOS, *and*
Prox-1. But the more they looked at Prox-1, the more they realized that
it would require changes to Proximity-1 to allow SDLS to work (they
consulted with Greg Kazz on this). So, WG idea was to define the SDLS
protocol for those CCSDS link layer protocols that would not require any
changes and then influence the next rewrite of Proximity to allow SDLS to
be seamlessly incorporated.
- I think also that there would be a big number of issues (for key
management etc.) to be tackled and recommending CCSDS 355.0-R-1 for
Proximity-1 would just be misleading.without a thorough analysis of multi
hop (even if limited to one hop right now) encrypted environment.
- In conclusion, adding Proximity-1 to SDLS would require serious rework
(unless one is looking for mere formatting inclusion) and when its
revised, the WG will include it in SDLS.
I hope this is clarifying the issue.
Best regards
Gian Paolo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/cesg/attachments/20110406/bde4ffeb/attachment.html
From adrian.j.hooke at jpl.nasa.gov Wed Apr 6 16:03:42 2011
From: adrian.j.hooke at jpl.nasa.gov (Hooke, Adrian J (9000))
Date: Wed Apr 6 15:46:29 2011
Subject: [CESG] Planetary Communications SIG?
Message-ID: <6D12692A7874434DAC51C93B019D4349F30AB70244@ALTPHYEMBEVSP20.RES.AD.JPL>
Gian Paolo: the CWE map http://cwe.ccsds.org/default.aspx still shows the PlaCom SIG, headed by J-L Gerner. As far as we know, there has been no activity since he left. Do you plan to keep this SIG alive with a new chair, or disband it?
///adrian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/cesg/attachments/20110406/b78534d5/attachment.html
From peter.m.shames at jpl.nasa.gov Wed Apr 6 16:48:36 2011
From: peter.m.shames at jpl.nasa.gov (Shames, Peter M (313B))
Date: Wed Apr 6 16:31:31 2011
Subject: [CESG] CCSDS 355.0-R-1, Space Data Link Security Protocol (Red
Book, Issue 1) vs Proximity-1
In-Reply-To:
Message-ID:
Gippo,
On checking with interested parties here it appears that there is no pressing need to address Prox 1 at this time. Further, I do understand that it was considered and tackling it was set aside in the interests of dealing with the more pressing (and more tractable) issues first, TC, AOS, and TM.
At this point it would suffice for me to have a note in the spec to describe the rationale of why it was left out.
I presume that the rest of the issues will be addressed by the WG.
Regards, Peter
From: Gian Paolo Calzolari >
Date: Wed, 6 Apr 2011 09:42:15 -0700
To: CCSDS Engineering Steering Group - CESG Exec >
Subject: [CESG] CCSDS 355.0-R-1, Space Data Link Security Protocol (Red Book, Issue 1) vs Proximity-1
Dear All,
as you know is these days CESG Poll CESG-P-2011-03-005 is ongoing for the Approval to release CCSDS 355.0-R-1, Space Data Link Security Protocol (Red Book, Issue 1) for CCSDS Agency review.
Peter has approved the poll (thanks!) with some remarks.
I think it is worth to address his first remark (i.e. Why is Porx-1 not addressed along with TM, TC & AOS? Is there the assumption that if data is securely delivered to space that relaying it is then not a problem? ) for sake of clarity.
The shortest answer to the question is that Proximity-1 is not addressed on purpose as SDLS WG decision; i.e. SDLS protocol is meant to protect TC Direct From Earth (DFE) and TM Direct To Earth (DTE) space links.
Here are some points providing the rationale:
- The prime threats we are aiming to protect from with this SDLS protocol are on earth, not in space and surely not in deep space. This is why SDLS WG did not consider compatibility with Proximity-1 a necessary feature of the SDLS protocol. The User RequirementsDocument (URD) which was the basis for SDLS development did not list Proximity-1 as target data link protocol for the above mentioned reason.
- The WG had originally gone into the SDLS protocol development with the intent of creating a ?shim? to allow it to work with TM, TC, AOS, *and* Prox-1. But the more they looked at Prox-1, the more they realized that it would require changes to Proximity-1 to allow SDLS to work (they consulted with Greg Kazz on this). So, WG idea was to define the SDLS protocol for those CCSDS link layer protocols that would not require any changes and then influence the next rewrite of Proximity to allow SDLS to be seamlessly incorporated.
- I think also that there would be a big number of issues (for key management etc.) to be tackled and recommending CCSDS 355.0-R-1 for Proximity-1 would just be misleading.without a thorough analysis of multi hop (even if limited to one hop right now) encrypted environment.
- In conclusion, adding Proximity-1 to SDLS would require serious rework (unless one is looking for mere formatting inclusion) and when its revised, the WG will include it in SDLS.
I hope this is clarifying the issue.
Best regards
Gian Paolo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/cesg/attachments/20110406/037dea26/attachment.html
From Gian.Paolo.Calzolari at esa.int Mon Apr 11 08:41:26 2011
From: Gian.Paolo.Calzolari at esa.int (Gian.Paolo.Calzolari@esa.int)
Date: Mon Apr 11 08:24:30 2011
Subject: [CESG] Planetary Communications SIG?
In-Reply-To: <6D12692A7874434DAC51C93B019D4349F30AB70244@ALTPHYEMBEVSP20.RES.AD.JPL>
References: <6D12692A7874434DAC51C93B019D4349F30AB70244@ALTPHYEMBEVSP20.RES.AD.JPL>
Message-ID:
Adrian,
CNES reported some interest in continuing the PlaCom SIG activity
and this will be checked in Berlin.
Regards
Gian Paolo
From:
"Hooke, Adrian J (9000)"
To:
"Gian.Paolo.Calzolari@esa.int"
Cc:
CCSDS Engineering Steering Group - CESG Exec
Date:
06-04-2011 22:03
Subject:
[CESG] Planetary Communications SIG?
Sent by:
cesg-bounces@mailman.ccsds.org
Gian Paolo: the CWE map http://cwe.ccsds.org/default.aspx still shows the
PlaCom SIG, headed by J-L Gerner. As far as we know, there has been no
activity since he left. Do you plan to keep this SIG alive with a new
chair, or disband it?
///adrian
_______________________________________________
CESG mailing list
CESG@mailman.ccsds.org
http://mailman.ccsds.org/mailman/listinfo/cesg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/cesg/attachments/20110411/e31098e5/attachment.htm
From tomg at aiaa.org Mon Apr 11 06:00:00 2011
From: tomg at aiaa.org (CCSDS Secretariat)
Date: Mon Apr 11 10:24:16 2011
Subject: [CESG] CESG Poll Closure Reminder
Message-ID:
Dear CESG Members,
The closure date for the following polls is 13 April 2011:
- CESG-P-2011-03-003 Approval to dissolve Information Packaging and
Registries Working Group
- CESG-P-2011-03-004 Approval to dissolve Information Architecture
Working Group
- CESG-P-2011-03-005 Approval to release CCSDS 355.0-R-1, Space Data
Link Security Protocol (Red Book, Issue 1) for CCSDS Agency review
These polls can be accessed via the following link:
http://public.ccsds.org/sites/cwe/cesg/Polls/default.aspx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/cesg/attachments/20110411/0b64219a/attachment.html
From peter.m.shames at jpl.nasa.gov Tue Apr 12 21:50:28 2011
From: peter.m.shames at jpl.nasa.gov (Shames, Peter M (313B))
Date: Tue Apr 12 21:33:38 2011
Subject: [CESG] Re: PICS resolution
In-Reply-To: <6D12692A7874434DAC51C93B019D4349EF9F229629@ALTPHYEMBEVSP20.RES.AD.JPL>
Message-ID:
Skipped content of type multipart/alternative-------------- next part --------------
A non-text attachment was scrubbed...
Name: pics_wp.pdf
Type: application/pdf
Size: 48416 bytes
Desc: pics_wp.pdf
Url : http://mailman.ccsds.org/pipermail/cesg/attachments/20110412/f3d7cafd/pics_wp-0001.pdf
From tomg at aiaa.org Thu Apr 14 06:00:00 2011
From: tomg at aiaa.org (CCSDS Secretariat)
Date: Thu Apr 14 11:35:41 2011
Subject: [CESG] CESG Poll Closure Reminder
Message-ID: <4bbd3b6f-f8cb-4a94-9c1c-62cc659e76ff@AIAASWMLEXCH002.hq.ad.aiaa.org>
Dear CESG Members,
The closure date for the following poll is 18 April 2011:
- CESG-P-2011-04-001 Approval to publish CCSDS
910.14-G-1, Space Communication Cross
Support?Service Management?Operations Concept (Green Book, Issue 1)
This poll can be accessed via the following link:
http://public.ccsds.org/sites/cwe/cesg/Polls/default.aspx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/cesg/attachments/20110414/1f711ea2/attachment.htm
From tomg at aiaa.org Thu Apr 14 12:44:59 2011
From: tomg at aiaa.org (CCSDS Secretariat)
Date: Thu Apr 14 12:28:05 2011
Subject: [CESG] CESG Poll Extension
Message-ID: <496d954d-dddc-4906-9b4f-36e4553e77a9@AIAASWMLEXCH002.hq.ad.aiaa.org>
Dear CESG Members,
At the request of an AD, the closure date for the following polls has
been changed to 15 April 2011:
- CESG-P-2011-03-003 Approval to dissolve Information Packaging and
Registries Working Group
- CESG-P-2011-03-004 Approval to dissolve Information Architecture
Working Group
- CESG-P-2011-03-005 Approval to release CCSDS 355.0-R-1, Space Data
Link Security Protocol (Red Book, Issue 1) for CCSDS Agency review
These polls can be accessed via the following link:
http://public.ccsds.org/sites/cwe/cesg/Polls/default.aspx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/cesg/attachments/20110414/5c202c15/attachment.htm
From adrian.j.hooke at jpl.nasa.gov Thu Apr 14 13:42:58 2011
From: adrian.j.hooke at jpl.nasa.gov (Hooke, Adrian J (9000))
Date: Thu Apr 14 13:25:45 2011
Subject: [CESG] Magenta, Blue and Profiles
Message-ID: <6D12692A7874434DAC51C93B019D4349F30AB70C38@ALTPHYEMBEVSP20.RES.AD.JPL>
I'd like to try to wrap up a discussion that we had in February, where I believe that we had reached consensus on the following:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1. The litmus test between a Blue Book and a Magenta Book is as follows.
a. If a document has interoperability properties, and;
b. If it is directly implementable (i.e., two people could independently read the specification, each produce an independent implementations and it could be realistically expected that those two implementations would interoperate), and;
c. If it clearly needs to be tested.
Then it is a Blue Book. If not, it is a Magenta Book.
2. Within the Blue Book category there are three types of standard:
a. CCSDS Recommended Standard (something that internally contains a native specification developed by CCSDS)
b. CCSDS Recommended Standard: Adaptation Profile (something that adopts/adapts a native specification developed somewhere else, such as by another standards organization)
c. CCSDS Recommended Standard: Utilization Profile (something that specifies how to use one or more existing CCSDS Blue Books to perform a particular function)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Any disagreements? If not, we should adopt these guidelines as our working terms of reference and incorporate into the ongoing update to the Procedures Manual. The term "application profile" should then deprecated and removed from the description of Recommended Practices in our terminology.
Best regards,
Adrian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/cesg/attachments/20110414/5a0bb022/attachment.htm
From adrian.j.hooke at jpl.nasa.gov Thu Apr 14 14:37:49 2011
From: adrian.j.hooke at jpl.nasa.gov (Hooke, Adrian J (9000))
Date: Thu Apr 14 14:20:36 2011
Subject: [CESG] RE: Proposed Technical Corrigendum to Encap Service 133.1-B-2
In-Reply-To:
References:
Message-ID: <6D12692A7874434DAC51C93B019D4349F30AB70C69@ALTPHYEMBEVSP20.RES.AD.JPL>
The London agreement was that we only have to test IP-over-Encap.
Encap has to be (separately and independently) interoperability tested over TM, TC, AOS and Prox-1 and we know that there are deficiencies there; but we have an agreed way-forward to document the testing issues in the Encap spec. and then progressively work them off as resources become available.
In this case, IP is directly implementable and Encap is directly implementable. With the deprecation of the term "Application Profile", IP-over-CCSDS should be CCSDS Recommended Standard: Adaptation Profile (something that adopts/adapts a native specification developed somewhere else, such as by another standards organization).
///a
From: Shames, Peter M (313B)
Sent: Thursday, April 14, 2011 12:29 PM
To: Gian.Paolo.Calzolari@esa.int; Hooke, Adrian J (9000)
Cc: Chris Taylor; Kazz, Greg J (313B); Keith Scott; Tom Gannett; Gilles Moury
Subject: Re: Proposed Technical Corrigendum to Encap Service 133.1-B-2
Gippo,
I do not know what "agreement" you are referencing, but the requirements on how we operate are documented in the CCSDS Procedures. In the current CCSDS Procedures document all Blue Books need to be interoperability tested and one class of Magenta Books, Application Profiles, also need to be interoperability tested. IP Over CSDS is an instance of an Application profile, thus it needs to be interoperability tested. ENCAP is a Blue Book, thus it too needs to have all of its options interoperability tested, even if the implementation is just a few lines of code.
If and when we decide to change the CCSDS policy to make Application Profiles Blue Books, which we have discussed but not decided upon, then these will still need to have interoperability testing done, as Blue Books. In effect nothing will have changed except the "color" of the books. This class of documents will effectively need to have the same content in either case.
The issues that was raised, as I understand it, was how to handle the fact that the ENCAP did not have complete interoperability testing done prior to publication. In this regard we all, collectively, screwed up. The "fix" that was proposed was to waive the requirement for now, and document this in the spec, thus preventing the complete removal of the spec from the current standards track, but to require that interop testing be done as soon as possible.
The other issue was just how far down the stack testing needed to be done. I believe that in all cases the agreement is that testing needs to only be done down to the top of the underlying "protocol service providing layer" that sits underneath the protocol or stack of protocols that are being specified. In practice that would mean that ENCAP would need to be tested over any protocol that it is to be used with: TC, TM, AOS, and Prox-1. There is no requirement to test all layers below this underlying "protocol service providing layer". The same practice would apply at any layer, particularly where a stack of protocols, I.e. Application Profile, is being specified.
Where things get a little interesting is between layers like the Coding and Sync sub-layer of the link layer, and the Modulation sub-layer of the physical layer. The interfaces between link layer protocols and coding protocols become complicated since there is the possibility of having block coding synchronous with link layer blocks, or asynchronous with regard link layer blocks. How this is to work must be specified. Similarly the interface between the coding sub-layer and the modulation sub-layer must be carefully defined. It is not clear that there is a need to test a new coding spec with each and every modulation spec (a large task indeed), but if we choose not to do that we will need to analyze it and carefully document why that is not required.
Regards, Peter
From: Gian Paolo Calzolari >
Date: Thu, 14 Apr 2011 08:44:30 -0700
To: Adrian Hooke >
Cc: Chris Taylor >, Greg Kazz >, Keith Scott >, Peter Shames >, Tom Gannett >, Gilles Moury >
Subject: RE: Proposed Technical Corrigendum to Encap Service 133.1-B-2
Adrian,
one statement in the slides you sent me (i.e. interoperability testing for Magenta Book) is in conflict with the latest agreement (Blue needs prototype, Magenta needs no prototype).
This is confirming an opinion I have expressed several times; i.e. IP over CCSDS should be a blue book since it is defining a new service.
As such, IP over CCSDS would need prototyping while the Encapsulation service would stay as is considering also that the packet extraction only based on recognizing a packet version and a legth can be with few lines of software.
Ciao
Gian Paolo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/cesg/attachments/20110414/eb9fb216/attachment-0001.htm
From adrian.j.hooke at jpl.nasa.gov Fri Apr 15 08:45:14 2011
From: adrian.j.hooke at jpl.nasa.gov (Hooke, Adrian J (9000))
Date: Fri Apr 15 08:27:59 2011
Subject: [CESG] RE: Magenta, Blue and Profiles
In-Reply-To: <6D12692A7874434DAC51C93B019D4349F30AB70C38@ALTPHYEMBEVSP20.RES.AD.JPL>
References: <6D12692A7874434DAC51C93B019D4349F30AB70C38@ALTPHYEMBEVSP20.RES.AD.JPL>
Message-ID: <6D12692A7874434DAC51C93B019D4349F30ADBF191@ALTPHYEMBEVSP20.RES.AD.JPL>
Bob Durst suggested an important modification to 1c, which I paraphrase below for your consideration:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1. The litmus test between a Blue Book and a Magenta Book is as follows.
a. If a document has interoperability properties, and;
b. If it is directly implementable (i.e., two people could independently read the specification, each produce an independent implementations and it could be realistically expected that those two implementations would interoperate), and;
c. If it clearly needs to be tested, because failure to conduct interoperability testing prior to release of the standard may place an adopting mission at operational or financial risk.
Then it is a Blue Book. If not, it is a Magenta Book.
2. Within the Blue Book category there are three types of standard:
a. CCSDS Recommended Standard (something that internally contains a native specification developed by CCSDS)
b. CCSDS Recommended Standard: Adaptation Profile (something that adopts/adapts a native specification developed somewhere else, such as by another standards organization)
c. CCSDS Recommended Standard: Utilization Profile (something that specifies how to use one or more existing CCSDS Blue Books to perform a particular function)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
A good test case came up yesterday: IP-over-CCSDS Links. Clearly, IP is a 2b standard and IP itself has been interoperability tested at least enough to pass CCSDS muster ;-) . However, interoperability of two implementations of IP running over Encap needs to be verified. Separate interoperability testing of Encap-over-CCSDS Links takes care of the rest.
///a
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/cesg/attachments/20110415/38475909/attachment.html
From Gian.Paolo.Calzolari at esa.int Fri Apr 15 12:04:16 2011
From: Gian.Paolo.Calzolari at esa.int (Gian.Paolo.Calzolari@esa.int)
Date: Fri Apr 15 11:47:25 2011
Subject: [CESG] Re: PICS resolution
In-Reply-To:
References: <6D12692A7874434DAC51C93B019D4349EF9F229629@ALTPHYEMBEVSP20.RES.AD.JPL>
Message-ID:
Dear CESG colleagues,
here are a few comments to Peter's input.
Peter states: Prior to the first Red Book review, each draft standard
shall have a Protocol Implementation Conformance Specification (PICS)
Pro-Forma section provided.
Of course it would be very good practice to provide PICS for the first
Agency review.
However we know that sometimes there is the need or the wish from some
working groups to go for the first Agency Review already knowing that this
will not be the final one.
Without disputing on the reasons for this approach, I think that the only
real requirement should be to have PICS being part of the last Agency
Review before publication.
Peter states: The PICS Pro Forma is to provide a statement of what
conformance to the specification means and to embody this as an Annex in
the standard.
It should state ?normative annex?.
Peter states: The PICS Pro Forma is required for all CCSDS standards
track documents, whether a protocol, pre se, or some other normative
specification, such as a profile, abstract syntax, encoding rule or
information object specification.
The statement above is clearly in conflict with CMC Resolution
CMC-R-2010-06-010 (see at the bottom of this mail) limiting the obligation
for PICS only to Blue Books including a protocol. IMO, the CMC resolution
shall be fully endorsed by CESG with
1. Hints to decide when it shall be considered that a Blue Book is
including a protocol.
2. Invitation (not command) to include PICS whenever possible also in
Blue Books not including a protocol.
Peter states: The primary purpose of the PICS Pro Forma is to clearly
define what elements within the standard are required and which are
optional.
I cannot share this statement. The mandatory and optional elements of a
standard are clearly defined using the CCSDS editorial rules; e.g.
a) the words ?shall? and ?must? imply a binding and verifiable
specification;
b) the word ?should? implies an optional, but desirable,
specification;
c) the word ?may? implies an optional specification;
d) the words ?is?, ?are?, and ?will? imply statements of fact.
The annex we want to add to CCSDS documents is a template to be filled by
implementers to clearly document which options are provided within a
specific product.
Just as final remarks, I share Chris' concern about resources.
That's all for the time being.
I wish you all a nice week and and an happy Easter break
Gian Paolo
---------------------------------------
As per Tom Gannett?s mail there is a CMC resolution pending on PICS:
FWI: The Fall 2008 resolution was not implemented because it was
problematic: the "P" in PICS stands for Protocol, and trying to force
conformance statements for non-protocols into the PICS mold ranges from
difficult to impossible. At the June 2010 Brazil meeting the requirement
was narrowed to apply only to Blue Books defining protocols, and the
Brazil resolution effectively supersedes the earlier resolution:
CMC-R-2010-06-010: CMC resolves that if a Blue Book includes a protocol it
shall include PICS Proforma as a normative annex.
The need for some sort of conformance statements for non-protocols was
acknowledged, but they may need to be handled on a case-by-case basis.
Currently a formal requirement for non-protocol conformance statements
does not really exist.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/cesg/attachments/20110415/b8bf4f07/attachment.htm
From adrian.j.hooke at jpl.nasa.gov Fri Apr 15 13:01:15 2011
From: adrian.j.hooke at jpl.nasa.gov (Hooke, Adrian J (9000))
Date: Fri Apr 15 12:44:03 2011
Subject: [CESG] PICS resolution
In-Reply-To:
References: <6D12692A7874434DAC51C93B019D4349EF9F229629@ALTPHYEMBEVSP20.RES.AD.JPL>
Message-ID: <6D12692A7874434DAC51C93B019D4349F30ADBF200@ALTPHYEMBEVSP20.RES.AD.JPL>
1. Clearly we need CCSDS guidance about how to prepare a PICS.
2. Referring to a 68-page ISO document isn't the way to provide that guidance
3. As Gippo noted, "The annex we want to add to CCSDS documents is a template to be filled by implementers to clearly document which options are provided within a specific product"
4. Resources are in short supply, so how are we going to create that annex?
This doesn't sound like rocket science. Doesn't anyone have access to a contractor or summer student who could be tasked to crank this template out in a few weeks?
///a
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/cesg/attachments/20110415/d53847e3/attachment.htm
From adrian.j.hooke at jpl.nasa.gov Fri Apr 15 13:32:07 2011
From: adrian.j.hooke at jpl.nasa.gov (Hooke, Adrian J (9000))
Date: Fri Apr 15 13:14:53 2011
Subject: [CESG] PICS resolution
In-Reply-To: <6D12692A7874434DAC51C93B019D4349F30ADBF200@ALTPHYEMBEVSP20.RES.AD.JPL>
References: <6D12692A7874434DAC51C93B019D4349EF9F229629@ALTPHYEMBEVSP20.RES.AD.JPL>
<6D12692A7874434DAC51C93B019D4349F30ADBF200@ALTPHYEMBEVSP20.RES.AD.JPL>
Message-ID: <6D12692A7874434DAC51C93B019D4349F30ADBF22B@ALTPHYEMBEVSP20.RES.AD.JPL>
As Chris pointed out, we've done this before. Refer to the following for an example:
CCSDS 714.0-B-2
Space Communications Protocol Specification (SCPS)-Transport Protocol. Blue Book. Issue 2. October 2006.
ANNEX C: PROTOCOL IMPLEMENTATION CONFORMANCE STATEMENT PROFORMA
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/cesg/attachments/20110415/d3e530a6/attachment.htm
From peter.m.shames at jpl.nasa.gov Fri Apr 15 14:11:36 2011
From: peter.m.shames at jpl.nasa.gov (Shames, Peter M (313B))
Date: Fri Apr 15 13:54:47 2011
Subject: [CESG] Re: PICS resolution
In-Reply-To:
Message-ID:
Gippo,
Thanks for the feedback on this. The CESG had ben so quiet on this topic that I feared there were no longer frogs in the pond I been told to toss this "rock" into. ;-}
I have some comments in-line.
Regards, Peter
From: Gian Paolo Calzolari >
Date: Fri, 15 Apr 2011 09:04:16 -0700
To: Peter Shames >
Cc: Adrian Hooke >, CCSDS Engineering Steering Group - CESG Exec >, "cesg-bounces@mailman.ccsds.org" >
Subject: Re: [CESG] Re: PICS resolution
Dear CESG colleagues,
here are a few comments to Peter's input.
Peter states: Prior to the first Red Book review, each draft standard shall have a Protocol Implementation Conformance Specification (PICS) Pro-Forma section provided.
Of course it would be very good practice to provide PICS for the first Agency review.
However we know that sometimes there is the need or the wish from some working groups to go for the first Agency Review already knowing that this will not be the final one.
Without disputing on the reasons for this approach, I think that the only real requirement should be to have PICS being part of the last Agency Review before publication.
In the ISO spec they make a strong recommendation that the PICS Pro Forma be used to document all implementations of the standard, including any prototyping used to validate the standard. In thinking about just what we need to do in the policy to cover both this CMC requirement and how it might impact the existing requirements for prototyping "most [standards track] documents".
CCSDS Proc (Nov 10 CMC draft), B2.2.b CCSDS Draft Standard (Red Book)
At some point in the evolution of a Draft Standard that is intended to result in a change to mission-support infrastructure, at least one hardware or software prototype (or other implementation) must exist that demonstrates and exercises all of the options and features of the specification in an operationally relevant environment, either real or simulated. This point may be issue-1, or it may be a later issue depending on circumstances, but for most documents the implementation must exist prior to issuing a final Draft Standard
And, later in this same paragraph:
The documentation of the qualifying implementation must include clear statements about its ability to support each of the individual options and features.
But in the next section the requirement changes.
CCSDS Proc (Nov 10 CMC draft), B2.2.c CCSDS Recommended Standard (Blue Book)
With a few exceptions (for which waivers must be sought), conversion of a Draft Standard to a Recommended Standard also requires that at least two independent and interoperable prototypes or implementations must have been developed and demonstrated in an operationally relevant environment, either real or simulated. In cases in which one or more options or features have not been demonstrated in at least two independently developed interoperable prototypes or implementations, the specification may advance to the CCSDS Recommended Standard level only if those options or features are removed.
So the policy is, and has been for many years, that all CCSDS Draft Standards are expected to have at least one prototype (of some form) early in the process and that the documentation of the prototype in expected to include clear statements about its ability to support each of the options and features. One clear and concise way to document what is required and what is optional is to create a PICS Pro Forma for the spec which can then be filled out by the implementors of each prototype.
Some working groups may indeed plan on two or even more Red Book reviews, but since agency reviews are costly doing too many of these is to be avoided. Paragraph B2.2.b addresses this too. It would appear that the best course for us to choose might be to state that the WG should produce a PICS Pro Forma no later than the point at which it decides to do its first prototype. This would be at the point where the WG believes that the draft spec is mature enough to do even one prototype, and not at the end of the process. By the time that the WG believes that the spec is mature enough to go Blue it is required to have done at least two complete interoperable prototypes and clearly these should be documented using this PICS Pro Forma, which itself should be by that time a mature, succinct, statement of just what the spec mandates or leaves optional.
Peter states: The PICS Pro Forma is to provide a statement of what conformance to the specification means and to embody this as an Annex in the standard.
It should state ?normative annex?.
Agree completely.
Peter states: The PICS Pro Forma is required for all CCSDS standards track documents, whether a protocol, pre se, or some other normative specification, such as a profile, abstract syntax, encoding rule or information object specification.
The statement above is clearly in conflict with CMC Resolution CMC-R-2010-06-010 (see at the bottom of this mail) limiting the obligation for PICS only to Blue Books including a protocol. IMO, the CMC resolution shall be fully endorsed by CESG with
1. Hints to decide when it shall be considered that a Blue Book is including a protocol.
2. Invitation (not command) to include PICS whenever possible also in Blue Books not including a protocol.
Throughout the CCSDS Procs document we various use the term 'protocols", as in "1.1 SPACE TELEMATICS DOMAIN: the communications protocols by which these applications exchange information." But we also use the more complete phrase "B2.1.a Recommended Standards: CCSDS Recommended Standards (Blue Books) define specific interfaces, technical capabilities, or protocols, or provide prescriptive and/or normative definitions of interfaces, protocols, or other controlling standards such as encoding approaches." We do not ever define what we mean by "protocol" but we are quite clear that Blue Books may be of several different forms and that all must adhere to the prototyping, interoperability testing, and documentation rules.
It is quite clear that all CCSDS recommended standards (Blue Books), of whatever form, are intended to be complete, unambiguous, and at a sufficient level of detail that they can be directly implemented, and B2.1.a says "Blue Books should also include a Protocol Implementation Conformance Statement (PICS) as a normative annex.". It does not appear to be sensible to draw a distinction between "protocols", per se, nor to separate these from "data exchange standards", or "coding and modulation standards", or "cross support standards", or any of the other possible forms of normative and implementable CCSDS standards. All need to be prototyped, all need to be interoperable, and all need clear documentation of just what has been prototyped and validated. A narrow reading of the meaning of the word "protocol" just is not reasonable and really does not serve us.
Peter states: The primary purpose of the PICS Pro Forma is to clearly define what elements within the standard are required and which are optional.
I cannot share this statement. The mandatory and optional elements of a standard are clearly defined usingthe CCSDS editorial rules; e.g.
a) the words ?shall? and ?must? imply a binding and verifiable specification;
b) the word ?should? implies an optional, but desirable, specification;
c) the word ?may? implies an optional specification;
d) the words ?is?, ?are?, and ?will? imply statements of fact.
The annex we want to add to CCSDS documents is a template to be filled by implementers to clearly document which options are provided within a specific product.
I agree completely with this requirement on CCSDS standards to clearly document, and in a "terse style" just what is required and what is optional. I also agree that we need the PICS Pro Forma to be a Normative Annex that is effectively a template that shall be filled in by all CCSDS prototype implementers to document which of the features of the standard that they have implemented and what the status of their implementation is. I think we can, and should, require the use of this as a part of the CCSDS standardization and implementation process, with a waiver process that can be used judiciously where doing such prototyping just does not make sense. By including the PICS Pro Forma as a normative annex we are providing a template that other implementers may use.
What we do not yet have a a succinct statement of what the PICS Pro Forma specification must include. The specification itself, must define, clearly and unambiguously, just what the specification is, using text, diagrams, tables, state machines, etc. A typical PICS Pro Forma is a succinct statement of just which sections of the specification are required and which are optional. In a normal PICS Pro Forma (according to ISO) this would be documented using a table containing columns for Item number (standard paragraph reference), Item Description (one or two words), Status (of Item Number, mandatory, Optional, Conditional, Prohibited, or N/A), and Support (when filled in, the terms yes, no, or N/A). Other columns such as Predicate, Sender, Receiver, Initiator, Responder, may also be adopted if they are necessary. There may be more than one table used for different sections of the document, using different columns where required.
Each of these tables for a protocol specification will then have a row for each relevant clause in the specification and also rows for PDUs, PDU parameters, Timers, Negotiation Capabilities, Error Handling, Dependencies, and any other required or optional features of the standard. Information object standards (I.e. Data exchange specs like TDM or XFDU) would use the same column form, but include a different set of specification clauses, like object classes, packages, attributes, and operations. Similarly service specifications, coding specifications, modulation specifications, and compression specifications.
In effect this provides a single paragraph capturing the salient features of the ISO PICS document for at least protocols and data exchange standards.
Just as final remarks, I share Chris' concern about resources.
That's all for the time being.
I wish you all a nice week and and an happy Easter break
Gian Paolo
---------------------------------------
I too share Chris concern about resources, but this is something that we have been told we must wrestle to the ground. In a more normal year I would likely volunteer to get this done, but since my standards budget has just been whacked by more than 30% I do not have the resources here at JPL to get this done. Hopefully someone else can step in to provide the resources to do as Adrian has suggested to elaborate on my one paragraph version above and produce the 3-5 page version of the ISO spec.
Happy Easter and a sweet Passover to one and all.
Regards, Peter
As per Tom Gannett?s mail there is a CMC resolution pending on PICS:
FWI: The Fall 2008 resolution was not implemented because it was problematic: the "P" in PICS stands for Protocol, and trying to force conformance statements for non-protocols into the PICS mold ranges from difficult to impossible. At the June 2010 Brazil meeting the requirement was narrowed to apply only to Blue Books defining protocols, and the Brazil resolution effectively supersedes the earlier resolution:
CMC-R-2010-06-010: CMC resolves that if a Blue Book includes a protocol it shall include PICS Proforma as a normative annex.
The need for some sort of conformance statements for non-protocols was acknowledged, but they may need to be handled on a case-by-case basis. Currently a formal requirement for non-protocol conformance statements does not really exist.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/cesg/attachments/20110415/ea5f4997/attachment-0001.htm
From peter.m.shames at jpl.nasa.gov Fri Apr 15 14:16:45 2011
From: peter.m.shames at jpl.nasa.gov (Shames, Peter M (313B))
Date: Fri Apr 15 13:59:56 2011
Subject: [CESG] Re: PICS resolution
In-Reply-To:
Message-ID:
My apologies. This note was sent prematurely due to some sort of glitch in the MS Outlook software that I have been forced to use. I did a "cut" of some text, but the "paste" was treated as a "send". The corrected version is attached.
Cheers, Peter
From: Peter Shames >
Date: Fri, 15 Apr 2011 11:11:36 -0700
To: Gian Paolo Calzolari >
Cc: Adrian Hooke >, CCSDS Engineering Steering Group - CESG Exec >, "cesg-bounces@mailman.ccsds.org" >
Subject: Re: [CESG] Re: PICS resolution
Gippo,
Thanks for the feedback on this. The CESG had ben so quiet on this topic that I feared there were no longer frogs in the pond I been told to toss this "rock" into. ;-}
I have some comments in-line.
Regards, Peter
From: Gian Paolo Calzolari >
Date: Fri, 15 Apr 2011 09:04:16 -0700
To: Peter Shames >
Cc: Adrian Hooke >, CCSDS Engineering Steering Group - CESG Exec >, "cesg-bounces@mailman.ccsds.org" >
Subject: Re: [CESG] Re: PICS resolution
Dear CESG colleagues,
here are a few comments to Peter's input.
Peter states: Prior to the first Red Book review, each draft standard shall have a Protocol Implementation Conformance Specification (PICS) Pro-Forma section provided.
Of course it would be very good practice to provide PICS for the first Agency review.
However we know that sometimes there is the need or the wish from some working groups to go for the first Agency Review already knowing that this will not be the final one.
Without disputing on the reasons for this approach, I think that the only real requirement should be to have PICS being part of the last Agency Review before publication.
In the ISO spec they make a strong recommendation that the PICS Pro Forma be used to document all implementations of the standard, including any prototyping used to validate the standard. In thinking about just what we need to do in the policy to cover both this CMC requirement and how it might impact the existing requirements for prototyping "most [standards track] documents".
CCSDS Proc (Nov 10 CMC draft), B2.2.b CCSDS Draft Standard (Red Book)
At some point in the evolution of a Draft Standard that is intended to result in a change to mission-support infrastructure, at least one hardware or software prototype (or other implementation) must exist that demonstrates and exercises all of the options and features of the specification in an operationally relevant environment, either real or simulated. This point may be issue-1, or it may be a later issue depending on circumstances, but for most documents the implementation must exist prior to issuing a final Draft Standard
And, later in this same paragraph:
The documentation of the qualifying implementation must include clear statements about its ability to support each of the individual options and features.
But in the next section the requirement changes.
CCSDS Proc (Nov 10 CMC draft), B2.2.c CCSDS Recommended Standard (Blue Book)
With a few exceptions (for which waivers must be sought), conversion of a Draft Standard to a Recommended Standard also requires that at least two independent and interoperable prototypes or implementations must have been developed and demonstrated in an operationally relevant environment, either real or simulated. In cases in which one or more options or features have not been demonstrated in at least two independently developed interoperable prototypes or implementations, the specification may advance to the CCSDS Recommended Standard level only if those options or features are removed.
So the policy is, and has been for many years, that all CCSDS Draft Standards are expected to have at least one prototype (of some form) early in the process and that the documentation of the prototype in expected to include clear statements about its ability to support each of the options and features. One clear and concise way to document what is required and what is optional is to create a PICS Pro Forma for the spec which can then be filled out by the implementors of each prototype.
Some working groups may indeed plan on two or even more Red Book reviews, but since agency reviews are costly doing too many of these is to be avoided. Paragraph B2.2.b addresses this too. It would appear that the best course for us to choose might be to state that the WG should produce a PICS Pro Forma no later than the point at which it decides to do its first prototype. This would be at the point where the WG believes that the draft spec is mature enough to do even one prototype, and not at the end of the process. By the time that the WG believes that the spec is mature enough to go Blue it is required to have done at least two complete interoperable prototypes and clearly these should be documented using this PICS Pro Forma, which itself should be by that time a mature, succinct, statement of just what the spec mandates or leaves optional.
Peter states: The PICS Pro Forma is to provide a statement of what conformance to the specification means and to embody this as an Annex in the standard.
It should state ?normative annex?.
Agree completely.
Peter states: The PICS Pro Forma is required for all CCSDS standards track documents, whether a protocol, pre se, or some other normative specification, such as a profile, abstract syntax, encoding rule or information object specification.
The statement above is clearly in conflict with CMC Resolution CMC-R-2010-06-010 (see at the bottom of this mail) limiting the obligation for PICS only to Blue Books including a protocol. IMO, the CMC resolution shall be fully endorsed by CESG with
1. Hints to decide when it shall be considered that a Blue Book is including a protocol.
2. Invitation (not command) to include PICS whenever possible also in Blue Books not including a protocol.
Throughout the CCSDS Procs document we various use the term 'protocols", as in "1.1 SPACE TELEMATICS DOMAIN: the communications protocols by which these applications exchange information." But we also use the more complete phrase "B2.1.a Recommended Standards: CCSDS Recommended Standards (Blue Books) define specific interfaces, technical capabilities, or protocols, or provide prescriptive and/or normative definitions of interfaces, protocols, or other controlling standards such as encoding approaches." We do not ever define what we mean by "protocol" but we are quite clear that Blue Books may be of several different forms and that all must adhere to the prototyping, interoperability testing, and documentation rules.
It is quite clear that all CCSDS recommended standards (Blue Books), of whatever form, are intended to be complete, unambiguous, and at a sufficient level of detail that they can be directly implemented, and B2.1.a says "Blue Books should also include a Protocol Implementation Conformance Statement (PICS) as a normative annex.". It does not appear to be sensible to draw a distinction between "protocols", per se, nor to separate these from "data exchange standards", or "coding and modulation standards", or "cross support standards", or any of the other possible forms of normative and implementable CCSDS standards. All need to be prototyped, all need to be interoperable, and all need clear documentation of just what has been prototyped and validated. A narrow reading of the meaning of the word "protocol" just is not reasonable and really does not serve us.
Peter states: The primary purpose of the PICS Pro Forma is to clearly define what elements within the standard are required and which are optional.
I cannot share this statement. The mandatory and optional elements of a standard are clearly defined usingthe CCSDS editorial rules; e.g.
a) the words ?shall? and ?must? imply a binding and verifiable specification;
b) the word ?should? implies an optional, but desirable, specification;
c) the word ?may? implies an optional specification;
d) the words ?is?, ?are?, and ?will? imply statements of fact.
The annex we want to add to CCSDS documents is a template to be filled by implementers to clearly document which options are provided within a specific product.
I agree completely with this requirement on CCSDS standards to clearly document, and in a "terse style" just what is required and what is optional. I also agree that we need the PICS Pro Forma to be a Normative Annex that is effectively a template that shall be filled in by all CCSDS prototype implementers to document which of the features of the standard that they have implemented and what the status of their implementation is. I think we can, and should, require the use of this as a part of the CCSDS standardization and implementation process, with a waiver process that can be used judiciously where doing such prototyping just does not make sense. By including the PICS Pro Forma as a normative annex we are providing a template that other implementers may use.
What we do not yet have a a succinct statement of what the PICS Pro Forma specification must include. The specification itself, must define, clearly and unambiguously, just what the specification is, using text, diagrams, tables, state machines, etc. A typical PICS Pro Forma is a succinct statement of just which sections of the specification are required and which are optional. In a normal PICS Pro Forma (according to ISO) this would be documented using a table containing columns for Item number (standard paragraph reference), Item Description (one or two words), Status (of Item Number, mandatory, Optional, Conditional, Prohibited, or N/A), and Support (when filled in, the terms yes, no, or N/A). Other columns such as Predicate, Sender, Receiver, Initiator, Responder, may also be adopted if they are necessary. There may be more than one table used for different sections of the document, using different columns where required.
Each of these tables for a protocol specification will then have a row for each relevant clause in the specification and also rows for PDUs, PDU parameters, Timers, Negotiation Capabilities, Error Handling, Dependencies, and any other required or optional features of the standard. Information object standards (I.e. Data exchange specs like TDM or XFDU) would use the same column form, but include a different set of specification clauses, like object classes, packages, attributes, and operations. Similarly service specifications, coding specifications, modulation specifications, and compression specifications.
The PICS Pro Forma for a coding spec would be similar to a protocol one, except it would contain rows relating to algorithms, rates, constraint lengths, randomization, interleaving, symbol inversion, and use within the rest of the protocol stack. Modulation would use the same columns, but include rows for algorithm, encoding rules, power and spectral efficiency, applicable bands, filtering, pre-coding, constraints on use, bandwidth limitations.
In effect these three paragraphs capture the salient features of the ISO PICS document for at least protocols, data exchange standards, coding and modulation. Each of the required types of rows for any given standard can be directly determined from the Blue Book itself and the WG members are in the best position, given some simple guidance, to state just what must be included for any given type of Blue Book.
Just as final remarks, I share Chris' concern about resources.
That's all for the time being.
I wish you all a nice week and and an happy Easter break
Gian Paolo
---------------------------------------
I too share Chris concern about resources, but this is something that we have been told we must wrestle to the ground. In a more normal year I would likely volunteer to get this done, but since my standards budget has just been whacked by more than 30% I do not have the resources here at JPL to get this done. Hopefully someone else can step in to provide the resources to do as Adrian has suggested to elaborate on my one paragraph version above and produce the 3-5 page version of the ISO spec.
Happy Easter and a sweet Passover to one and all.
Regards, Peter
As per Tom Gannett?s mail there is a CMC resolution pending on PICS:
FWI: The Fall 2008 resolution was not implemented because it was problematic: the "P" in PICS stands for Protocol, and trying to force conformance statements for non-protocols into the PICS mold ranges from difficult to impossible. At the June 2010 Brazil meeting the requirement was narrowed to apply only to Blue Books defining protocols, and the Brazil resolution effectively supersedes the earlier resolution:
CMC-R-2010-06-010: CMC resolves that if a Blue Book includes a protocol it shall include PICS Proforma as a normative annex.
The need for some sort of conformance statements for non-protocols was acknowledged, but they may need to be handled on a case-by-case basis. Currently a formal requirement for non-protocol conformance statements does not really exist.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/cesg/attachments/20110415/8bc9b73a/attachment.htm
From peter.m.shames at jpl.nasa.gov Fri Apr 15 14:33:09 2011
From: peter.m.shames at jpl.nasa.gov (Shames, Peter M (313B))
Date: Fri Apr 15 14:16:33 2011
Subject: [CESG] PICS resolution
In-Reply-To: <6D12692A7874434DAC51C93B019D4349F30ADBF22B@ALTPHYEMBEVSP20.RES.AD.JPL>
Message-ID:
Good example to look at. Follows the ISO spec, uses their terminology, contains the kinds of columns and indicators required, and also provides an example of the kinds of header / identifying information that is required.
It's also quite concise, but still a non-trivial amount of work, since it compresses the references to a complex 75 page spec into 14 pages of tables with references to a number of standards, clear indication of what is mandatory, and check boxes for implementation conformance.
Thanks, Peter
From: Adrian Hooke >
Date: Fri, 15 Apr 2011 10:32:07 -0700
To: CCSDS Engineering Steering Group - CESG Exec >
Subject: RE: [CESG] PICS resolution
As Chris pointed out, we?ve done this before. Refer to the following for an example:
CCSDS 714.0-B-2
Space Communications Protocol Specification (SCPS)?Transport Protocol. Blue Book. Issue 2. October 2006.
ANNEX C: PROTOCOL IMPLEMENTATION CONFORMANCE STATEMENT PROFORMA
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/cesg/attachments/20110415/e46db714/attachment.htm
From peter.m.shames at jpl.nasa.gov Fri Apr 15 17:11:40 2011
From: peter.m.shames at jpl.nasa.gov (Shames, Peter M (313B))
Date: Fri Apr 15 16:54:48 2011
Subject: [CESG] Magenta, Blue and Profiles
In-Reply-To: <6D12692A7874434DAC51C93B019D4349F30AB70C38@ALTPHYEMBEVSP20.RES.AD.JPL>
Message-ID:
Adrian, et al,
In general I agree completely with this approach. I do have three comments, however:
1. Application profile is a perfectly good term of art that is also reflected in the ISO PICS document I referenced earlier. Relabeling it "utilization profile" does not in any way change the nature of the specification.
2. For a Utilization Profile we will need a set of guidelines that reflect just what the expected structure and content are to be, and what testing must be done.
3. Similarly, for an Adaptation Profile we will need a set of guidelines that reflect just what the expected structure and content are to be, and what testing must be done.
I also note that this change will clear up an issue in the current draft CCSDS Procedures Yellow Book that addressed the need to do implementation testing of Application Profile Magenta Books. With Application Profiles changed to Blue Books there should be no need to mandate interoperability testing for any Magenta Books, but I believe that the general requirement on "implementation experience", should remain for Magenta Books:
Sec B2.3.c, CCSDS Recommended Practice (Magenta Book)
Converting a CCSDS Draft Practice to a CCSDS Recommended Practice is always preceded by a successful formal agency review. Generally, only a specification for which significant implementation experience has been obtained may be elevated to the CCSDS Recommended Practice level. The WG chair is responsible for documenting the specific implementations that qualify the specification for advancement.
Regards, Peter
From: Adrian Hooke >
Date: Thu, 14 Apr 2011 10:42:58 -0700
To: CCSDS Engineering Steering Group - CESG Exec >
Subject: [CESG] Magenta, Blue and Profiles
I?d like to try to wrap up a discussion that we had in February, where I believe that we had reached consensus on the following:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1. The litmus test between a Blue Book and a Magenta Book is as follows.
a. If a document has interoperability properties, and;
b. If it is directly implementable (i.e., two people could independently read the specification, each produce an independent implementations and it could be realistically expected that those two implementations would interoperate), and;
c. If it clearly needs to be tested.
Then it is a Blue Book. If not, it is a Magenta Book.
2. Within the Blue Book category there are three types of standard:
a. CCSDS Recommended Standard (something that internally contains a native specification developed by CCSDS)
b. CCSDS Recommended Standard: Adaptation Profile (something that adopts/adapts a native specification developed somewhere else, such as by another standards organization)
c. CCSDS Recommended Standard: Utilization Profile (something that specifies how to use one or more existing CCSDS Blue Books to perform a particular function)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Any disagreements? If not, we should adopt these guidelines as our working terms of reference and incorporate into the ongoing update to the Procedures Manual. The term "application profile" should then deprecated and removed from the description of Recommended Practices in our terminology.
Best regards,
Adrian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/cesg/attachments/20110415/6a4d9e9d/attachment.html
From adrian.j.hooke at jpl.nasa.gov Sat Apr 16 10:01:08 2011
From: adrian.j.hooke at jpl.nasa.gov (Hooke, Adrian J (9000))
Date: Sat Apr 16 09:44:15 2011
Subject: [CESG] Magenta, Blue and Profiles
In-Reply-To:
References: <6D12692A7874434DAC51C93B019D4349F30AB70C38@ALTPHYEMBEVSP20.RES.AD.JPL>,
Message-ID: <6D12692A7874434DAC51C93B019D4349F30AD3061A@ALTPHYEMBEVSP20.RES.AD.JPL>
> Application profile is a perfectly good term of art that is also reflected in the ISO PICS
> document I referenced earlier. Relabeling it "utilization profile" does not in any
> way change the nature of the specification.
Correct. However, I continue to advocate the deprecation of the term "Application Profile" because of the ambiguity in the word "application". On one hand it describes what the user wants to do (how to apply some protocols to a particular problem) and on the other it has the connotation of a particular protocol in the Application layer.
Take IP over CCSDS: the user wants to run IP across CCSDS links. But calling it an Application Profile suggests that IP is an Application layer protocol, which it isn't. Can't we just purge the term and move on with the terminology that I thought we had agreed-upon in February? --
a. CCSDS Recommended Standard (something that internally contains a native specification developed by CCSDS)
b. CCSDS Recommended Standard: Adaptation Profile (something that adopts/adapts a native specification developed somewhere else, such as by another standards organization)
c. CCSDS Recommended Standard: Utilization Profile (something that specifies how to use one or more existing CCSDS Blue Books to perform a particular function)
Why retain a third kind of Profile?
Best regards
Adrian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/cesg/attachments/20110416/0694b2c5/attachment.htm
From Nestor.Peccia at esa.int Sun Apr 17 16:14:05 2011
From: Nestor.Peccia at esa.int (Nestor.Peccia@esa.int)
Date: Sun Apr 17 15:57:17 2011
Subject: [CESG] Re: PICS resolution
In-Reply-To:
References:
Message-ID:
Peter
I fully share Gippo's comments, and Adrian's / Chris' concerns
ciao
nestor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/cesg/attachments/20110417/9b22531b/attachment.html
From peter.m.shames at jpl.nasa.gov Sun Apr 17 23:04:29 2011
From: peter.m.shames at jpl.nasa.gov (Shames, Peter M (313B))
Date: Sun Apr 17 22:47:47 2011
Subject: [CESG] Re: PICS resolution
In-Reply-To:
References:
Message-ID: <3ED1B7BC-B2BF-41E9-937C-C8971122C3D5@jpl.nasa.gov>
Great. I have no idea what that means in practical terms that we can tell all of CCSDS to use as guidance. Since it was ESA that pushed for it, and you guys seem to think you know what approach will work, I suggest that you offer up a real solution.
I already provided one, if you do not like it provide one you do like.
Peter
Sent from Peter's iPhone
On Apr 17, 2011, at 1:14 PM, "Nestor.Peccia@esa.int" > wrote:
Peter
I fully share Gippo's comments, and Adrian's / Chris' concerns
ciao
nestor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/cesg/attachments/20110417/7e8bd6f3/attachment.html
From peter.m.shames at jpl.nasa.gov Sun Apr 17 23:21:35 2011
From: peter.m.shames at jpl.nasa.gov (Shames, Peter M (313B))
Date: Sun Apr 17 23:04:49 2011
Subject: [CESG] Magenta, Blue and Profiles
In-Reply-To: <6D12692A7874434DAC51C93B019D4349F30AD3061A@ALTPHYEMBEVSP20.RES.AD.JPL>
References: <6D12692A7874434DAC51C93B019D4349F30AB70C38@ALTPHYEMBEVSP20.RES.AD.JPL>
<6D12692A7874434DAC51C93B019D4349F30AD3061A@ALTPHYEMBEVSP20.RES.AD.JPL>
Message-ID:
We can purge the term and adopt these two new ones. But we still need to do the hard part and that is to provide guidance as to just what these types of specs are, how the docs are to be structured, and how they are to be tested to demonstrate interoperability.
The ISO spec has some guidance on this. Someone should take up the task of crafting this.
However, since my suggested approaches seem to just get tossed out these days I suggest you identify someone else to play "bring me a rock" with.
Peter
Sent from Peter's iPhone
On Apr 16, 2011, at 7:01 AM, "Hooke, Adrian J (9000)" > wrote:
> Application profile is a perfectly good term of art that is also reflected in the ISO PICS
> document I referenced earlier. Relabeling it "utilization profile" does not in any
> way change the nature of the specification.
Correct. However, I continue to advocate the deprecation of the term "Application Profile" because of the ambiguity in the word "application". On one hand it describes what the user wants to do (how to apply some protocols to a particular problem) and on the other it has the connotation of a particular protocol in the Application layer.
Take IP over CCSDS: the user wants to run IP across CCSDS links. But calling it an Application Profile suggests that IP is an Application layer protocol, which it isn't. Can't we just purge the term and move on with the terminology that I thought we had agreed-upon in February? --
a. CCSDS Recommended Standard (something that internally contains a native specification developed by CCSDS)
b. CCSDS Recommended Standard: Adaptation Profile (something that adopts/adapts a native specification developed somewhere else, such as by another standards organization)
c. CCSDS Recommended Standard: Utilization Profile (something that specifies how to use one or more existing CCSDS Blue Books to perform a particular function)
Why retain a third kind of Profile?
Best regards
Adrian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/cesg/attachments/20110417/a24a7d76/attachment.html
From adrian.j.hooke at jpl.nasa.gov Mon Apr 18 08:11:19 2011
From: adrian.j.hooke at jpl.nasa.gov (Hooke, Adrian J (9000))
Date: Mon Apr 18 07:53:57 2011
Subject: [CESG] RE: SOIS Plug-and-Play
In-Reply-To: <384CFE6B78365146B96A248C6DD390A116744E@mx-bri-exch1.scisys.co.uk>
References: <384CFE6B78365146B96A248C6DD390A116744E@mx-bri-exch1.scisys.co.uk>
Message-ID: <6D12692A7874434DAC51C93B019D4349F30ADBF318@ALTPHYEMBEVSP20.RES.AD.JPL>
Stuart: you are going to update the SOIS-APP charter to reflect the proposed new work, right?
///adrian
From: sois-app-bounces@mailman.ccsds.org [mailto:sois-app-bounces@mailman.ccsds.org] On Behalf Of Stuart Fowell
Sent: Monday, April 18, 2011 5:40 AM
To: sois@mailman.ccsds.org; sois-app@mailman.ccsds.org; sois-opp@mailman.ccsds.org
Cc: sois-exec@mailman.ccsds.org
Subject: [Sois-app] Future Mailing List Usage on SOIS Plug-and-Play
Dear SOISers,
It has rightly been pointed out that the Plug-and-Play discussion threads are being sent to too many of the SOIS mailing lists, so that everyone is receiving multiple postings and threads are being tangled.
To rectify this, I propose to only use the SOIS-APP mailing lists in future as the plug-and-play work is being performed under the auspices of the Application Support Services WG. (FYI the SOIS-OPP mailing list refers to the now defunct Onboard Plug-and-Play BoF - the BoF was successful in defining the charter updates to the APP WG and therefore is defunct).
For all those who are not subscribed to the SOIS-APP mailing list but wish to participate in the plug-and-play discussions please could you subscribe (here is a link to the appropriate CCSDS webpage http://mailman.ccsds.org/cgi-bin/mailman/listinfo/sois-app).
Regards,
Stuart
___________________________________________________________
Stuart D. Fowell B.Eng MBCS
Senior Consultant - Space Division
SciSys UK Limited
T: +44 (0)117 916 5138 | M: +44 (0)7715 750255 | F: +44 (0)117 916 5299
E: stuart.fowell@scisys.co.uk | http://www.scisys.co.uk
SciSys UK Limited. Registered in England and Wales No. 4373530.
Registered Office: Methuen Park, Chippenham, Wiltshire SN14 0GB, UK.
Before printing, please think about the environment.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/cesg/attachments/20110418/3e4f396f/attachment.htm
From Stuart.Fowell at scisys.co.uk Mon Apr 18 08:20:58 2011
From: Stuart.Fowell at scisys.co.uk (Stuart Fowell)
Date: Mon Apr 18 08:04:09 2011
Subject: [CESG] RE: SOIS Plug-and-Play
References: <384CFE6B78365146B96A248C6DD390A116744E@mx-bri-exch1.scisys.co.uk>
<6D12692A7874434DAC51C93B019D4349F30ADBF318@ALTPHYEMBEVSP20.RES.AD.JPL>
Message-ID: <384CFE6B78365146B96A248C6DD390A116746B@mx-bri-exch1.scisys.co.uk>
>From the SOIS PnP Telecon on 05/04/2011:
Action 1.3 CT/SF to check charter is up-to-date, due date 19/04/2011.
At this stage, it is not yet clear exactly how the Electronic Data
Sheets will pan out in Magenta/Blue/etc books, given the need for common
data dictionaries, device class-specific standard EDS, etc.
So, whilst we will ensure the charter reflects this work, an exhaustive
and unchanging list of books is not possible (yet).
________________________________
From: Hooke, Adrian J (9000) [mailto:adrian.j.hooke@jpl.nasa.gov]
Sent: 18 April 2011 13:11
To: Stuart Fowell
Cc: CCSDS Engineering Steering Group - CESG Exec
Subject: RE: SOIS Plug-and-Play
Stuart: you are going to update the SOIS-APP charter to reflect the
proposed new work, right?
///adrian
From: sois-app-bounces@mailman.ccsds.org
[mailto:sois-app-bounces@mailman.ccsds.org] On Behalf Of Stuart Fowell
Sent: Monday, April 18, 2011 5:40 AM
To: sois@mailman.ccsds.org; sois-app@mailman.ccsds.org;
sois-opp@mailman.ccsds.org
Cc: sois-exec@mailman.ccsds.org
Subject: [Sois-app] Future Mailing List Usage on SOIS Plug-and-Play
Dear SOISers,
It has rightly been pointed out that the Plug-and-Play discussion
threads are being sent to too many of the SOIS mailing lists, so that
everyone is receiving multiple postings and threads are being tangled.
To rectify this, I propose to only use the SOIS-APP mailing lists in
future as the plug-and-play work is being performed under the auspices
of the Application Support Services WG. (FYI the SOIS-OPP mailing list
refers to the now defunct Onboard Plug-and-Play BoF - the BoF was
successful in defining the charter updates to the APP WG and therefore
is defunct).
For all those who are not subscribed to the SOIS-APP mailing list but
wish to participate in the plug-and-play discussions please could you
subscribe (here is a link to the appropriate CCSDS webpage
http://mailman.ccsds.org/cgi-bin/mailman/listinfo/sois-app).
Regards,
Stuart
___________________________________________________________
Stuart D. Fowell B.Eng MBCS
Senior Consultant - Space Division
SciSys UK Limited
T: +44 (0)117 916 5138 | M: +44 (0)7715 750255 | F: +44 (0)117 916
5299
E: stuart.fowell@scisys.co.uk | http://www.scisys.co.uk
SciSys UK Limited. Registered in England and Wales No. 4373530.
Registered Office: Methuen Park, Chippenham, Wiltshire SN14 0GB, UK.
Before printing, please think about the environment.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/cesg/attachments/20110418/912bf3a2/attachment.htm
From Chris.Taylor at esa.int Mon Apr 18 08:54:54 2011
From: Chris.Taylor at esa.int (Chris.Taylor@esa.int)
Date: Mon Apr 18 08:38:02 2011
Subject: [CESG] RE: SOIS Plug-and-Play
In-Reply-To: <6D12692A7874434DAC51C93B019D4349F30ADBF318@ALTPHYEMBEVSP20.RES.AD.JPL>
References: <384CFE6B78365146B96A248C6DD390A116744E@mx-bri-exch1.scisys.co.uk>
<6D12692A7874434DAC51C93B019D4349F30ADBF318@ALTPHYEMBEVSP20.RES.AD.JPL>
Message-ID:
Adrian, this was actually agreed some time ago at the CESG where I raised
this issue of a new working group on P&P versus incorporating P&P into the
existing charter. The decision taken was to update the charter but alas it
was never actioned. So yes the existing APs WG charter will be updated.
Regards,
//ct
From: "Hooke, Adrian J (9000)"
To: Stuart Fowell
Cc: CCSDS Engineering Steering Group - CESG Exec
Date: 18/04/2011 14:11
Subject: [CESG] RE: SOIS Plug-and-Play
Sent by: cesg-bounces@mailman.ccsds.org
Stuart: you are going to update the SOIS-APP charter to reflect the proposed
new work, right?
///adrian
From: sois-app-bounces@mailman.ccsds.org [
mailto:sois-app-bounces@mailman.ccsds.org] On Behalf Of Stuart Fowell
Sent: Monday, April 18, 2011 5:40 AM
To: sois@mailman.ccsds.org; sois-app@mailman.ccsds.org;
sois-opp@mailman.ccsds.org
Cc: sois-exec@mailman.ccsds.org
Subject: [Sois-app] Future Mailing List Usage on SOIS Plug-and-Play
Dear SOISers,
It has rightly been pointed out that the Plug-and-Play discussion threads are
being sent to too many of the SOIS mailing lists, so that everyone is
receiving multiple postings and threads are being tangled.
To rectify this, I propose to only use the SOIS-APP mailing lists in future
as the plug-and-play work is being performed under the auspices of the
Application Support Services WG. (FYI the SOIS-OPP mailing list refers to the
now defunct Onboard Plug-and-Play BoF ? the BoF was successful in defining
the charter updates to the APP WG and therefore is defunct).
For all those who are not subscribed to the SOIS-APP mailing list but wish to
participate in the plug-and-play discussions please could you subscribe (here
is a link to the appropriate CCSDS webpage
http://mailman.ccsds.org/cgi-bin/mailman/listinfo/sois-app).
Regards,
Stuart
___________________________________________________________
Stuart D. Fowell B.Eng MBCS
Senior Consultant ? Space Division
SciSys UK Limited
T: +44 (0)117 916 5138 | M: +44 (0)7715 750255 | F: +44 (0)117 916 5299
E: stuart.fowell@scisys.co.uk | http://www.scisys.co.uk
SciSys UK Limited. Registered in England and Wales No. 4373530.
Registered Office: Methuen Park, Chippenham, Wiltshire SN14 0GB, UK.
Before printing, please think about the environment.
_______________________________________________
CESG mailing list
CESG@mailman.ccsds.org
http://mailman.ccsds.org/mailman/listinfo/cesg
From adrian.j.hooke at jpl.nasa.gov Tue Apr 19 16:21:36 2011
From: adrian.j.hooke at jpl.nasa.gov (Hooke, Adrian J (9000))
Date: Tue Apr 19 16:04:21 2011
Subject: [CESG] US Patent 6, 023,
783 for Flexible Advanced Coding and Modulation
Scheme for High Rate Telemetry Applications
Message-ID: <6D12692A7874434DAC51C93B019D4349F30ADBF642@ALTPHYEMBEVSP20.RES.AD.JPL>
Skipped content of type multipart/related-------------- next part --------------
A non-text attachment was scrubbed...
Name: ISO-Patent-Statement-and-Licensing-Declaration-Form(US6023783)v0.1.doc
Type: application/octet-stream
Size: 108032 bytes
Desc: ISO-Patent-Statement-and-Licensing-Declaration-Form(US6023783)v0.1.doc
Url : http://mailman.ccsds.org/pipermail/cesg/attachments/20110419/018a914f/ISO-Patent-Statement-and-Licensing-Declaration-FormUS6023783v0.1-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: US_Patent_006023783.info.pdf
Type: application/octet-stream
Size: 13276 bytes
Desc: US_Patent_006023783.info.pdf
Url : http://mailman.ccsds.org/pipermail/cesg/attachments/20110419/018a914f/US_Patent_006023783.info-0001.obj
From mike.kearney at nasa.gov Tue Apr 19 16:29:50 2011
From: mike.kearney at nasa.gov (Kearney, Mike W. (MSFC-EO01))
Date: Tue Apr 19 16:13:11 2011
Subject: [CESG] RE: US Patent 6,023,783 for Flexible Advanced Coding and
Modulation Scheme for High Rate Telemetry Applications
In-Reply-To: <6D12692A7874434DAC51C93B019D4349F30ADBF642@ALTPHYEMBEVSP20.RES.AD.JPL>
References: <6D12692A7874434DAC51C93B019D4349F30ADBF642@ALTPHYEMBEVSP20.RES.AD.JPL>
Message-ID: <2AC93642F8D00342B8FE3F273143E1242B1B61ECCA@NDMSSCC08.ndc.nasa.gov>
Skipped content of type multipart/alternative-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 2472 bytes
Desc: image001.jpg
Url : http://mailman.ccsds.org/pipermail/cesg/attachments/20110419/10abb9d6/image001.jpg
From Jean-Marc.Soula at cnes.fr Wed Apr 20 04:16:02 2011
From: Jean-Marc.Soula at cnes.fr (Soula Jean-Marc)
Date: Wed Apr 20 03:59:19 2011
Subject: [CESG] RE: [CMC] RE: US Patent 6, 023,
783 for Flexible Advanced Coding and Modulation Scheme for
High Rate Telemetry Applications
In-Reply-To: <2AC93642F8D00342B8FE3F273143E1242B1B61ECCA@NDMSSCC08.ndc.nasa.gov>
References: <6D12692A7874434DAC51C93B019D4349F30ADBF642@ALTPHYEMBEVSP20.RES.AD.JPL>
<2AC93642F8D00342B8FE3F273143E1242B1B61ECCA@NDMSSCC08.ndc.nasa.gov>
Message-ID:
Skipped content of type multipart/alternative-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 2472 bytes
Desc: image001.jpg
Url : http://mailman.ccsds.org/pipermail/cesg/attachments/20110420/f053799d/attachment-0001.jpe
From peter.allan at stfc.ac.uk Wed Apr 20 04:28:46 2011
From: peter.allan at stfc.ac.uk (peter.allan@stfc.ac.uk)
Date: Wed Apr 20 04:13:59 2011
Subject: [CESG] RE: [CMC] RE: US Patent 6, 023,
783 for Flexible Advanced Coding
and Modulation Scheme for High Rate Telemetry Applications
In-Reply-To:
References: <6D12692A7874434DAC51C93B019D4349F30ADBF642@ALTPHYEMBEVSP20.RES.AD.JPL>
<2AC93642F8D00342B8FE3F273143E1242B1B61ECCA@NDMSSCC08.ndc.nasa.gov>
Message-ID: <09759CD7A2B6EE4698AFF764012B70E20F3DD0@EXCHMBX03.fed.cclrc.ac.uk>
Skipped content of type multipart/alternative-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 2472 bytes
Desc: image001.jpg
Url : http://mailman.ccsds.org/pipermail/cesg/attachments/20110420/c33f04ab/image001-0001.jpg
From adrian.j.hooke at jpl.nasa.gov Wed Apr 20 08:14:55 2011
From: adrian.j.hooke at jpl.nasa.gov (Hooke, Adrian J (9000))
Date: Wed Apr 20 07:57:34 2011
Subject: [CESG] Mars attacks
Message-ID: <6D12692A7874434DAC51C93B019D4349F30ADBF726@ALTPHYEMBEVSP20.RES.AD.JPL>
http://www.4m.net/showthread.php?213413-CCSDS-amp-MARS-Go-To-War-in-Doubleheader-This-Weekend&s=1b6e9bd215e5ad54afdd569d7e958145
CCSDS & MARS Go To War in Doubleheader This Weekend
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/cesg/attachments/20110420/0334c1c2/attachment.html
From Juan.Miro at esa.int Thu Apr 21 05:27:10 2011
From: Juan.Miro at esa.int (Juan.Miro@esa.int)
Date: Thu Apr 21 07:27:57 2011
Subject: [CESG] Re: [CMC] RE: US Patent 6, 023,
783 for Flexible Advanced Coding and
Modulation Scheme for High Rate Telemetry Applications
In-Reply-To: <2AC93642F8D00342B8FE3F273143E1242B1B61ECCA@NDMSSCC08.ndc.nasa.gov>
References: <6D12692A7874434DAC51C93B019D4349F30ADBF642@ALTPHYEMBEVSP20.RES.AD.JPL>
<2AC93642F8D00342B8FE3F273143E1242B1B61ECCA@NDMSSCC08.ndc.nasa.gov>
Message-ID:
Thank you Mike, I appreciate your efficient approach.
I wish you Happy Easter
Regards
Juan
|------------>
| From: |
|------------>
>------------------------------------------------------------------------------------------------------------------------------------------------------|
|"Kearney, Mike W. (MSFC-EO01)" |
>------------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| To: |
|------------>
>------------------------------------------------------------------------------------------------------------------------------------------------------|
|"Hooke, Adrian J (9000)" |
>------------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Cc: |
|------------>
>------------------------------------------------------------------------------------------------------------------------------------------------------|
|Steering Group - CESG Exec , CCSDS Management Council , CCSDS@esa-sf1.esa.gmessaging.net |
>------------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Date: |
|------------>
>------------------------------------------------------------------------------------------------------------------------------------------------------|
|19/04/2011 22:30 |
>------------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Subject: |
|------------>
>------------------------------------------------------------------------------------------------------------------------------------------------------|
|[CMC] RE: US Patent 6,023,783 for Flexible Advanced Coding and Modulation Scheme for High Rate Telemetry Applications |
>------------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Sent by: |
|------------>
>------------------------------------------------------------------------------------------------------------------------------------------------------|
|cmc-bounces@mailman.ccsds.org |
>------------------------------------------------------------------------------------------------------------------------------------------------------|
I understand, and I believe we can take action rapidly since this is a
familiar topic for the CMC.
I will compose a letter to CalTech first, and if that fails to get the needed
results, I will compose a letter to IV directly. I will proceed with this
unless I hear some objections from the CMC members. If anyone believes that
we need a CMC resolution before I take action, please ?reply all? to this
message within the next few days.
I commend the efforts of the SLS team to date, in their struggle to follow
policy and get a response from the patent-holder.
-=- Mike
Mike Kearney
NASA MSFC EO-01
256-544-2029
From: Hooke, Adrian J (9000) [mailto:adrian.j.hooke@jpl.nasa.gov]
Sent: Tuesday, April 19, 2011 3:22 PM
To: Kearney, Mike W. (MSFC-EO01)
Cc: CCSDS Management Council; CCSDS Engineering Steering Group - CESG Exec
Subject: US Patent 6,023,783 for Flexible Advanced Coding and Modulation
Scheme for High Rate Telemetry Applications
Mike: please see the attached request from Gian Paolo for CCSDS to intervene
in the matter of getting an ISO Patent Declaration and Licensing Form signed
by the licensee for US Patent 6,023,783.
There seems to have been no meaningful response from the licensee since ESA
first submitted a licensing request 17-months ago.
Best regards
Adrian
Adrian J. Hooke
(Embedded image moved to file: pic02124.jpg)
cid:image001.jpg@01CBDF24.92902CD0
Chairman, CCSDS Engineering Steering Group (CESG)
Space Communications and Navigation Office (SCaN)
Suite 7L70
Space Operations Mission Directorate
NASA Headquarters
Washington DC 20024-3210
202-358-0097 office
818-653-9553 mobile
From: Gian.Paolo.Calzolari@esa.int [mailto:Gian.Paolo.Calzolari@esa.int]
Sent: Wednesday, April 06, 2011 11:35 AM
To: Hooke, Adrian J (9000); Nestor.Peccia@esa.int
Subject: US Patent 6,023,783 for Flexible Advanced Coding and Modulation
Scheme for High Rate Telemetry Applications
Dear Adrian and Nestor,
as you know, the US Patent 6,023,783 is affecting the Red Book on
Flexible Advanced Coding and Modulation Scheme for High Rate Telemetry
Applications.
Despite it is ESA opinion that US Patent 6,023,783 is not applicable to the
coding described in the book, we have tried to contact Intellectual Ventures
since long time with very poor results.
The situation did not change after the change of the CCSDS policy with
respect to patented technologies.
After I informed Mr. Ryan Clark of the policy change towards a simplified
approach and provided him with the " ISO patent statement and licensing
declaration form", there was no reaction at all.
Reminders and telephone calls gave no result.
Considering the current status, I ask CESG to escalate the issue and possibly
get Intellectual Ventures contacted directly by CCSDS since - as it stands
now - it looks as this company has no interest in providing whatsoever
statement or license.
Thank you for your support.
Gian Paolo
PS I attach here the ISO form that was sent to Mr. Clark together with some
basic information about the patent.
The contact details we have used are:
W. Ryan Clark
Intellectual Ventures
3150 139th Ave SE
Building 4
Bellevue, WA 98005
http://www.intellectualventures.com/
"Ryan Clark"
_______________________________________________
CMC mailing list
CMC@mailman.ccsds.org
http://mailman.ccsds.org/mailman/listinfo/cmc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pic02124.jpg
Type: image/jpeg
Size: 2472 bytes
Desc: not available
Url : http://mailman.ccsds.org/pipermail/cesg/attachments/20110421/4322e2d6/pic02124.jpg
From thomas.gannett at tgannett.net Fri Apr 22 19:33:20 2011
From: thomas.gannett at tgannett.net (Thomas Gannett)
Date: Fri Apr 22 19:16:50 2011
Subject: [CESG] New CESG Poll
Message-ID: <4db2104b.97abe60a.6791.3713@mx.google.com>
Skipped content of type multipart/alternative-------------- next part --------------
BEGIN:VCALENDAR
PRODID:-//Microsoft Corporation//Outlook 12.0 MIMEDIR//EN
VERSION:2.0
METHOD:PUBLISH
X-MS-OLK-FORCEINSPECTOROPEN:TRUE
BEGIN:VEVENT
CATEGORIES:Orange Category
CLASS:PUBLIC
CREATED:20110422T233053Z
DESCRIPTION:CESG-P-2011-04-002 Approval to release CCSDS 123.0-R-1\, Lossl
ess Multispectral & Hyperspectral Image Compression (Red Book\, Issue 1) f
or CCSDS Agency review\n
DTEND;VALUE=DATE:20110506
DTSTAMP:20110422T233053Z
DTSTART;VALUE=DATE:20110505
LAST-MODIFIED:20110422T233053Z
PRIORITY:5
SEQUENCE:0
SUMMARY;LANGUAGE=en-us:CESG Poll Closure
TRANSP:TRANSPARENT
UID:040000008200E00074C5B7101A82E00800000000B05881BF2301CC01000000000000000
01000000057027F828668AD47A0749F05D678729C
X-ALT-DESC;FMTTYPE=text/html:\n\n\n\n\n\n\n\n\nCESG-P-2011-04-002 Approval to release CCSDS 123.0-R-1\, \; Lossle
ss Multispectral &\; Hyperspectral Image Compression (Red Book\, Issue
1) for CCSDS Agency review
\n\n\n
X-MICROSOFT-CDO-BUSYSTATUS:FREE
X-MICROSOFT-CDO-IMPORTANCE:1
X-MICROSOFT-DISALLOW-COUNTER:FALSE
X-MS-OLK-ALLOWEXTERNCHECK:TRUE
X-MS-OLK-CONFTYPE:0
BEGIN:VALARM
TRIGGER:-PT1080M
ACTION:DISPLAY
DESCRIPTION:Reminder
END:VALARM
END:VEVENT
END:VCALENDAR
From Gilles.Moury at cnes.fr Wed Apr 27 08:45:10 2011
From: Gilles.Moury at cnes.fr (Moury Gilles)
Date: Wed Apr 27 08:28:37 2011
Subject: [CESG] Re: PICS resolution
In-Reply-To:
References:
Message-ID: <7D9B0824DDE55A4987E9C8A65F95DC833203C4@cst-xch-006.cnesnet.ad.cnes.fr>
Dear CESG colleagues,
We should definitely limit PICS to blue books where PICS is really
adding something (and not just pages to the recommendation!) , i.e.
protocols with a significant number of options.
For example for RF&Modulation, the blue book is a collection of
individual recommendations, each one having no or very limited set of
options. Therefore I do not see the added value of a PICS.
For TM channel coding book, we are again dealing with a blue book
listing a collection of coding schemes, each one having no or limited
set of options. Conformity statement of a product/project is fairly
straightforward by referencing the coding scheme used and the few
associated parameters.
For data link protocols and SDLS protocol, it makes sense to add a PICS
since the number of options and managed parameters is usually large.
Having a standard form to record unambiguously the capability / test
coverage of a product or the configuration of a project is a plus.
Filling this form to record the options implemented in prototypes and
exercised during interoperability testing, and appending it to the test
report, is clearly desirable.
I would favour a non systematic approach to PICS addition, leaving to
the area director the freedom to judge when it has added-value.
Best regards,
Gilles
Gilles MOURY
CNES Toulouse
From: Peter Shames
Date: Fri, 15 Apr 2011 11:11:36 -0700
To: Gian Paolo Calzolari
Cc: Adrian Hooke , CCSDS Engineering
Steering Group - CESG Exec ,
"cesg-bounces@mailman.ccsds.org"
Subject: Re: [CESG] Re: PICS resolution
Gippo,
Thanks for the feedback on this. The CESG had ben so quiet on
this topic that I feared there were no longer frogs in the pond I been
told to toss this "rock" into. ;-}
I have some comments in-line.
Regards, Peter
From: Gian Paolo Calzolari
Date: Fri, 15 Apr 2011 09:04:16 -0700
To: Peter Shames
Cc: Adrian Hooke , CCSDS
Engineering Steering Group - CESG Exec ,
"cesg-bounces@mailman.ccsds.org"
Subject: Re: [CESG] Re: PICS resolution
Dear CESG colleagues,
here are a few comments to Peter's input.
Peter states: Prior to the first Red Book
review, each draft standard shall have a Protocol Implementation
Conformance Specification (PICS) Pro-Forma section provided.
Of course it would be very good practice to provide PICS
for the first Agency review.
However we know that sometimes there is the need or the
wish from some working groups to go for the first Agency Review already
knowing that this will not be the final one.
Without disputing on the reasons for this approach, I
think that the only real requirement should be to have PICS being part
of the last Agency Review before publication.
In the ISO spec they make a strong recommendation that the PICS
Pro Forma be used to document all implementations of the standard,
including any prototyping used to validate the standard. In thinking
about just what we need to do in the policy to cover both this CMC
requirement and how it might impact the existing requirements for
prototyping "most [standards track] documents".
CCSDS Proc (Nov 10 CMC draft), B2.2.b CCSDS Draft
Standard (Red Book)
At some point in the evolution of a Draft Standard that
is intended to result in a change to mission-support infrastructure, at
least one hardware or software prototype (or other implementation) must
exist that demonstrates and exercises all of the options and features of
the specification in an operationally relevant environment, either real
or simulated. This point may be issue-1, or it may be a later issue
depending on circumstances, but for most documents the implementation
must exist prior to issuing a final Draft Standard
And, later in this same paragraph:
The documentation of the qualifying implementation must
include clear statements about its ability to support each of the
individual options and features.
But in the next section the requirement changes.
CCSDS Proc (Nov 10 CMC draft), B2.2.c CCSDS Recommended
Standard (Blue Book)
With a few exceptions (for which waivers must be
sought), conversion of a Draft Standard to a Recommended Standard also
requires that at least two independent and interoperable prototypes or
implementations must have been developed and demonstrated in an
operationally relevant environment, either real or simulated. In cases
in which one or more options or features have not been demonstrated in
at least two independently developed interoperable prototypes or
implementations, the specification may advance to the CCSDS Recommended
Standard level only if those options or features are removed.
So the policy is, and has been for many years, that all CCSDS
Draft Standards are expected to have at least one prototype (of some
form) early in the process and that the documentation of the prototype
in expected to include clear statements about its ability to support
each of the options and features. One clear and concise way to document
what is required and what is optional is to create a PICS Pro Forma for
the spec which can then be filled out by the implementors of each
prototype.
Some working groups may indeed plan on two or even more Red Book
reviews, but since agency reviews are costly doing too many of these is
to be avoided. Paragraph B2.2.b addresses this too. It would appear
that the best course for us to choose might be to state that the WG
should produce a PICS Pro Forma no later than the point at which it
decides to do its first prototype. This would be at the point where the
WG believes that the draft spec is mature enough to do even one
prototype, and not at the end of the process. By the time that the WG
believes that the spec is mature enough to go Blue it is required to
have done at least two complete interoperable prototypes and clearly
these should be documented using this PICS Pro Forma, which itself
should be by that time a mature, succinct, statement of just what the
spec mandates or leaves optional.
Peter states: The PICS Pro Forma is to provide a
statement of what conformance to the specification means and to embody
this as an Annex in the standard.
It should state "normative annex".
Agree completely.
Peter states: The PICS Pro Forma is required for
all CCSDS standards track documents, whether a protocol, pre se, or some
other normative specification, such as a profile, abstract syntax,
encoding rule or information object specification.
The statement above is clearly in conflict with CMC
Resolution CMC-R-2010-06-010 (see at the bottom of this mail) limiting
the obligation for PICS only to Blue Books including a protocol. IMO,
the CMC resolution shall be fully endorsed by CESG with
1. Hints to decide when it shall be considered
that a Blue Book is including a protocol.
2. Invitation (not command) to include PICS
whenever possible also in Blue Books not including a protocol.
Throughout the CCSDS Procs document we various use the term
'protocols", as in "1.1 SPACE TELEMATICS DOMAIN: the communications
protocols by which these applications exchange information." But we
also use the more complete phrase "B2.1.a Recommended Standards: CCSDS
Recommended Standards (Blue Books) define specific interfaces, technical
capabilities, or protocols, or provide prescriptive and/or normative
definitions of interfaces, protocols, or other controlling standards
such as encoding approaches." We do not ever define what we mean by
"protocol" but we are quite clear that Blue Books may be of several
different forms and that all must adhere to the prototyping,
interoperability testing, and documentation rules.
It is quite clear that all CCSDS recommended standards (Blue
Books), of whatever form, are intended to be complete, unambiguous, and
at a sufficient level of detail that they can be directly implemented,
and B2.1.a says "Blue Books should also include a Protocol
Implementation Conformance Statement (PICS) as a normative annex.". It
does not appear to be sensible to draw a distinction between
"protocols", per se, nor to separate these from "data exchange
standards", or "coding and modulation standards", or "cross support
standards", or any of the other possible forms of normative and
implementable CCSDS standards. All need to be prototyped, all need to
be interoperable, and all need clear documentation of just what has been
prototyped and validated. A narrow reading of the meaning of the word
"protocol" just is not reasonable and really does not serve us.
Peter states: The primary purpose of the PICS
Pro Forma is to clearly define what elements within the standard are
required and which are optional.
I cannot share this statement. The mandatory and
optional elements of a standard are clearly defined usingthe CCSDS
editorial rules; e.g.
a) the words 'shall' and 'must' imply a binding
and verifiable specification;
b) the word 'should' implies an optional, but
desirable, specification;
c) the word 'may' implies an optional
specification;
d) the words 'is', 'are', and 'will' imply
statements of fact.
The annex we want to add to CCSDS documents is a
template to be filled by implementers to clearly document which options
are provided within a specific product.
I agree completely with this requirement on CCSDS standards to
clearly document, and in a "terse style" just what is required and what
is optional. I also agree that we need the PICS Pro Forma to be a
Normative Annex that is effectively a template that shall be filled in
by all CCSDS prototype implementers to document which of the features of
the standard that they have implemented and what the status of their
implementation is. I think we can, and should, require the use of this
as a part of the CCSDS standardization and implementation process, with
a waiver process that can be used judiciously where doing such
prototyping just does not make sense. By including the PICS Pro Forma
as a normative annex we are providing a template that other implementers
may use.
What we do not yet have a a succinct statement of what the PICS
Pro Forma specification must include. The specification itself, must
define, clearly and unambiguously, just what the specification is, using
text, diagrams, tables, state machines, etc. A typical PICS Pro Forma
is a succinct statement of just which sections of the specification are
required and which are optional. In a normal PICS Pro Forma (according
to ISO) this would be documented using a table containing columns for
Item number (standard paragraph reference), Item Description (one or two
words), Status (of Item Number, mandatory, Optional, Conditional,
Prohibited, or N/A), and Support (when filled in, the terms yes, no, or
N/A). Other columns such as Predicate, Sender, Receiver, Initiator,
Responder, may also be adopted if they are necessary. There may be more
than one table used for different sections of the document, using
different columns where required.
Each of these tables for a protocol specification will then have
a row for each relevant clause in the specification and also rows for
PDUs, PDU parameters, Timers, Negotiation Capabilities, Error Handling,
Dependencies, and any other required or optional features of the
standard. Information object standards (I.e. Data exchange specs like
TDM or XFDU) would use the same column form, but include a different set
of specification clauses, like object classes, packages, attributes, and
operations. Similarly service specifications, coding specifications,
modulation specifications, and compression specifications.
The PICS Pro Forma for a coding spec would be similar to a protocol one,
except it would contain rows relating to algorithms, rates, constraint
lengths, randomization, interleaving, symbol inversion, and use within
the rest of the protocol stack. Modulation would use the same columns,
but include rows for algorithm, encoding rules, power and spectral
efficiency, applicable bands, filtering, pre-coding, constraints on use,
bandwidth limitations.
In effect these three paragraphs capture the salient features of the ISO
PICS document for at least protocols, data exchange standards, coding
and modulation. Each of the required types of rows for any given
standard can be directly determined from the Blue Book itself and the WG
members are in the best position, given some simple guidance, to state
just what must be included for any given type of Blue Book.
Just as final remarks, I share Chris' concern about resources.
That's all for the time being.
I wish you all a nice week and and an happy Easter break
Gian Paolo
---------------------------------------
I too share Chris concern about resources, but this is something that we
have been told we must wrestle to the ground. In a more normal year I
would likely volunteer to get this done, but since my standards budget
has just been whacked by more than 30% I do not have the resources here
at JPL to get this done. Hopefully someone else can step in to provide
the resources to do as Adrian has suggested to elaborate on my one
paragraph version above and produce the 3-5 page version of the ISO
spec.
Happy Easter and a sweet Passover to one and all.
Regards, Peter
As per Tom Gannett's mail there is a CMC resolution pending on
PICS:
FWI: The Fall 2008 resolution was not implemented because it
was problematic: the "P" in PICS stands for Protocol, and trying to
force conformance statements for non-protocols into the PICS mold ranges
from difficult to impossible. At the June 2010 Brazil meeting the
requirement was narrowed to apply only to Blue Books defining protocols,
and the Brazil resolution effectively supersedes the earlier resolution:
CMC-R-2010-06-010: CMC resolves that if a Blue Book includes a
protocol it shall include PICS Proforma as a normative annex.
The need for some sort of conformance statements for
non-protocols was acknowledged, but they may need to be handled on a
case-by-case basis. Currently a formal requirement for non-protocol
conformance statements does not really exist.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/cesg/attachments/20110427/b8458563/attachment.htm
From thomas.gannett at tgannett.net Thu Apr 28 06:00:00 2011
From: thomas.gannett at tgannett.net (Thomas Gannett)
Date: Thu Apr 28 08:38:25 2011
Subject: [CESG] CESG Poll Closure Reminder
Message-ID: <4db963a3.0b5d340a.0f60.13f1@mx.google.com>
Dear CESG Members,
The closure date for the following poll is 5 May 2011:
- CESG-P-2011-04-002 Approval to release CCSDS 123.0-R-1, Lossless
Multispectral & Hyperspectral Image Compression (Red Book, Issue 1)
for CCSDS Agency review
This poll can be accessed via the following link:
http://public.ccsds.org/sites/cwe/cesg/Polls/default.aspx
From thomas.gannett at tgannett.net Thu Apr 28 06:00:00 2011
From: thomas.gannett at tgannett.net (Thomas Gannett)
Date: Thu Apr 28 10:31:42 2011
Subject: [CESG] CESG Poll Closure Reminder
Message-ID: <4db97e33.4807dc0a.4414.157b@mx.google.com>
Dear CESG Members,
The closure date for the following poll is 5 May 2011:
- CESG-P-2011-04-002 Approval to release CCSDS 123.0-R-1, Lossless
Multispectral & Hyperspectral Image Compression (Red Book, Issue 1)
for CCSDS Agency review
This poll can be accessed via the following link:
http://public.ccsds.org/sites/cwe/cesg/Polls/default.aspx