[CMC] The nature of Green Books

[Adrian J. Hooke]

At 01:14 AM 2/14/2007, Jean-Luc.Gerner at esa.int wrote:
>At CCSDS we are currently developing GBs with two completely different 
>perspectives:
>- Type 1 GB: support to a Blue Book. It is a user guide for the BB. It 
>does not introduce new techniques, procedures, ... that are not in the BB. 
>Its approval at ADs/DADs level is fully justified. It means it has been 
>verified that the technical content is correct, that the info needed by 
>the user is
>there, etc ...
>- Type 2 GB: description of novel systems architectures, techniques, ... 
>for future programmes. The Cislunar GB is a typical case.

Jean-Luc: you are basically correct. However, what is missing in your 
Type-2 definition is the unwritten idea that *every* Working Group should 
*start* by defining what it is setting out to do - and the vehicle for 
doing this is a Type-2 Green Book. We have often said that this should be 
our standard way of doing business. We should first define our requirements 
and architecture in a Type-2 Green Book, and get it agreed; then we should 
develop the solutions (Practices, Standards, Experimental); then we should 
document all of the supporting material via a Type-1 Green Book. This is 
exactly the process that the Cislunar WG has been following.

>What does it mean for an AD to approve such a book? Just that it is 
>technically consistent? That it is the best known solution to future 
>(still unknown) needs? That it is compatible with existing Blue Books? Else?

CCSDS A02.1-Y-2, Restructured Organization and Processes, addresses the 
jobs of an Area Director. The two that seem to matter most here are:
2.      Screening all proposals to form new WGs that are brought forward by 
BOFs to make sure that they are supported by required documentation and 
their technical focus is vectored towards the goals and objectives of CCSDS.
10.     Ensuring that all Area work follows the set of architectural 
principles agreed by the CESG and is properly synchronized with the smooth 
evolution of the large installed base of CCSDS-compatible mission support 
infrastructure.

A major job of an AD is to ensure stability by highlighting any potentially 
disruptive developments, so an Area Director is clearly expected to have a 
good working knowledge of how CCSDS products are actually implemented and 
used by real missions. An AD  should therefore be able to spot disruptive 
stuff and pounce on it like a hawk. That, by the way, is why everyone 
suddenly woke up to extreme significance of the the Cislunar Green Book and 
the draft IP-over-CCSDS Red Book in CO Springs.

>What it for sure does not mean is that the AD's agency endorses it. In 
>other words, the GB, despite the fundamental nature of the material it 
>contains, is just a CCSDS-internal technical note.

This is an excellent point, because a Type-2 Green Book is essentially a 
view of the future. As such, it postulates future needs for international 
space mission interoperability and it establishes the rationale and 
requirements for new standards. Those new standards will clearly impact 
future Agency infrastructure and yet, as you note, the Area Directors do 
not officially represent the interests of their Agency's missions and/or 
infrastructure. Neither, for that matter, do many of the CMC Members.

However, we *do* have a group that represents those interests, and that 
group is the IOAG (although they only contain 6 of the 10 CCSDS Agencies). 
So perhaps we should selectively involve the IOAG in the review and 
approval of some (not all) Type-2 Green Books? The Cislunar Green Book is a 
case in point - it presents a very broad and sweeping view of the future 
and surely the mission and infrastructure guys should have a say as to 
whether they will need it or not? In fact, I have a note from CO Springs 
that says that we should send it to the IOAG for comments. Should we do that?

I'm going to pause here for comments. I've also CC'd the CMC since this 
topic ranges beyond the CESG.

///adrian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/cmc/attachments/20070214/58592f6e/attachment.html