[CMC] Re: [CESG] The nature of Green Books

Thu Feb 15 03:47:32 EST 2007

Adrian wrote:

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?

Type 2 GBs, and Cislunar is a typical case, are the foundation for future
strategies and development. I believe that they deserve a higher status than
the Type 1 GBs. They should be singled-out on the WEB site rather than buried
into the Type-1 GBs.
Also, to acquire a higher status, they require a different approval process
than the simple procedure in place for Type-1.

Jean-Luc Gerner
TEC-ETN
Tel: +31 71 565 4473

             "Adrian J. Hooke"                                               
             <adrian.j.hooke at jp                                              
             l.nasa.gov>                                                  To 
             Sent by:                   Jean-Luc.Gerner at esa.int              
             cesg-bounces at mailm                                           cc 
             an.ccsds.org               CCSDS Management Council             
                                        <cmc at mailman.ccsds.org>, CCSDS       
                                        Engineering Steering Group - ADs     
             14/02/2007 21:05           <cesg at mailman.ccsds.org>             
                                                                     Subject 
                                        [CESG] The nature of Green Books     

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
_______________________________________________
CESG mailing list
CESG at mailman.ccsds.org
http://mailman.ccsds.org/mailman/listinfo/cesg