[Css-csts] CSTS Toolkit White Book version 0.3

[Yasunori Iwana]

Dear Mr. Doat,

Thank yoy for your comments.

> 1. PROCEDURES:
> I note that the document does not address at all the procedures discussed in
> the working-group. The action A#06-0905 requires to draft the table of
> content for review by the working group. How does the document fit with that
> action? Will you have time before our meeting in Rome to answer that action?
> The section 4.2 of the minutes of meeting contains some information on the "4
> boxes book" that should be considered.

I have tried to reflect the issues discussed in the working group
into the white book as far as I can, but of course,
I do not think at all it is perfect.
Without contents, I  did not able to imagine the table of contents.

> The buffering of data is addressed in section 2.2.5 of the document. I note
> that this section covers part of our behaviour agreement but as the approach
> is not in line with our discussions (in particular the relation between the
> data and transfer buffers, the required operations, ...). I have the same
> comment vis-a-vis other procedures.
> I wonder why you updated the document with this text as the working-group
> agreed to distribute the work among the members, having individuals taking
> care of procedures.

Concerning the text of procedures documents, the depth of expression
is various; some document is like just idea notes and another is like
detailed specification.
I tried to catch the ideas or concepts from these procedures documents.
I admit the reflection is not enough.

> A new service will make use of defined procedures. That approach ensures that
> a service can select the required behaviour and ignore non-required
> behaviour. In this document we cannot achieve the agreed approach as the
> building blocks (the procedures) are not identified. The document shall be
> reworked to the approach agreed by the working-group. To that goal, we should
> first agree on the Table of Content of the document.

I do not understand what you mean.
In the interim meeting, didn't you agree on the Harmonized set of operations?
(I am sorry I was not able to participate in the interim meeting.)
I just tried to reflect the Harmonized set of operations into the white book.

> 2. MORE DETAILED COMMENTS
>
> 2.1.  SECTION  2.2.3 Blocking and Non-blocking
> The description is not in line with the working-group discussion, see CCR-34
> and minutes of meeting (section 2.10.3).

Sorry I admit I do not understand the Blocking. I will refine.

> 2.2 SECTION 2.2.4 Multiple START/STOP
> While the document describes the possibility to achieve multiple invocation
> of procedures by a service it does not describe any mechanism to achieve the
> required behaviour.

I introduced some mecahnisms;
  *start-mode (multiple starts, single start);
  *the data channel identification by the invoke-id-at-start;
  *multiple parameter sets concerning data transfers
    in GET-PARAMETER operations;
  *function of setting multiple parameter sets concerning data transfers
    in CONTROL-DIRECTIVE operations.

> EXTENSION PARAMETER
> The document redefines the extension parameter into a more-extension
> parameter (OCTET STRING with a maximum size 256). I do not think this is
> necessary. The type EXTERNAL should be used.

Woul you show me a usage example of type EXTERNAL?

> 2.3 SECTION 3.3.2 - START
> The START operation proposed in your document is not in-line with the
> discussion of the working-group.

I have noticed that these parameters in the table of START operation
parameters are needed for the provider to recognize the request from the user
on data transfer/data process /notification.

> 2.4. SECTION 3.8 - GET
> The definition seems to give an exhaustive list of possible parameters that
> can be retrieve. This is not my understanding of what the GET has to achieve.
> The GET shall give the possibility for a new service to retrieve whatever it
> needs.

I agree the parameter set can be extended (e.g. service specific parameter set).
I will add some extension mechanism.

> 2.4 SECTION 3.9 CONTROL-DIRECTIVE
> Charles is in charge of the corresponding procedure. Have you considered his
> inputs?
> What about the behaviour? Where is the THROW-EVENT procedure?
> Why are there set-parameters (Section 3.9.2.8 and 3.9.2.9)?

I just thought the THROW-EVENT, SET-PARAMETER are integrated into
the generic CONTROL-DIRECTIVE operation.
In the Charles document, set-parameter is handled in
the CONTROL-DIRECTIVE opearion as a kind of directive,
therefore I put it.

> 2.4 ASN.1 Definition
> The book defines 4 types of standard headers (2 invocations and 2 returns).
> The difference is the invoke-id.

Well, truely, three headers (2 invocations and 1 returns).

> The working group agreed to have all
> operations (confirmed and unconfirmed) carrying the invoke-id. We should only
> have two standard headers.

The invoke-id is outside of header, and only two headers type.
 I understand.

> The notifications cannot be expanded for external definition.
> The diagnostics cannot be expanded for external definition.

I can introduce the service specific notification, it is not a problem.
(in fact, in version 2 white book, there was an application-specific-status).
The service specific diagnostics, it is a good idea, I put it on a book.

> The common module is far too complex as it contains nearly all the type
> definition.

I will split it, and make it smaller.

> We should not need a service specific ASN.1 definition.

We need an opaque type module anyway; octet string, bit string.
I will change the name of the ASN.1 module ( to 'opaque type' or
someting).

> Service Instance Identifier should be in a dedicated module.
> ServiceIdentifier needs to be formalised. I propose an Object Identifier
> definition.

I understand.

I will participate in the meeting in Rome, but I regret to say
it will be my last CSTS meeting that I can participate in.
Originally my object of participation is to establish the realtime protocol
standard for tracking data, but the need of such a standard is not
recognized or prioritized in the IOAG or CCSDS.
Before leaving CSTS, I will do my best for the white book.

Yasunori Iwana