[CESG] Re: PICS resolution

Fri Apr 15 14:11:36 EDT 2011

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<mailto: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<mailto:peter.m.shames at jpl.nasa.gov>>
Cc: Adrian Hooke <Adrian.J.Hooke at jpl.nasa.gov<mailto:Adrian.J.Hooke at jpl.nasa.gov>>, CCSDS Engineering Steering Group - CESG Exec <cesg at mailman.ccsds.org<mailto:cesg at mailman.ccsds.org>>, "cesg-bounces at mailman.ccsds.org<mailto:cesg-bounces at mailman.ccsds.org>" <cesg-bounces at mailman.ccsds.org<mailto: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.

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