[CESG] Re: PICS resolution

Wed Apr 27 08:45:10 EDT 2011

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 <peter.m.shames at jpl.nasa.gov>
Date: Fri, 15 Apr 2011 11:11:36 -0700
To: Gian Paolo Calzolari <Gian.Paolo.Calzolari at esa.int>
Cc: Adrian Hooke <Adrian.J.Hooke at jpl.nasa.gov>, CCSDS Engineering
Steering Group - CESG Exec <cesg at mailman.ccsds.org>,
"cesg-bounces at mailman.ccsds.org" <cesg-bounces at 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 <Gian.Paolo.Calzolari at esa.int>
	Date: Fri, 15 Apr 2011 09:04:16 -0700
	To: Peter Shames <peter.m.shames at jpl.nasa.gov>
	Cc: Adrian Hooke <Adrian.J.Hooke at jpl.nasa.gov>, CCSDS
Engineering Steering Group - CESG Exec <cesg at mailman.ccsds.org>,
"cesg-bounces at mailman.ccsds.org" <cesg-bounces at 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