[Css-csts] Monitored Data Service : some points to verify

[John Pietras]

Cyril,

Thank you for your thoughtful review of the version 0.8 draft of the
MD-CSTS. I have just posted an update (v0.9) that addresses most of your
questions and the comments made at the CSTSWG telecon where we discussed
the version 0.8 draft. Please see my responses (in red) to your comments
interleaved below.

 

Best regards,

John

 

-----Original Message-----
From: css-csts-bounces at mailman.ccsds.org
[mailto:css-csts-bounces at mailman.ccsds.org] On Behalf Of Cyril THOMAS
Sent: Friday, October 16, 2009 11:19 AM
To: css-csts at mailman.ccsds.org
Subject: [Css-csts] Monitored Data Service : some points to verify

 

Dear John,

 

Reading once again the Monitored Data CSTS document (v0.8) raised for me

some points to check :

1) In your operational scenario on page 2-13 the parameters are named

"functionalGroup:parameterName" whereas at the end of page 5-1 a "." is
used

to separate the functional group and parameter name (according to
revision

bars it seems that the previous approach was to used the semi-colon,
maybe

you did not update your scenario accordingly ?)

 

Actually, I had intended that the notation use the semicolon (:)
separator, so that the components of the functional resource identifier
would be separated by periods ("dots"). I chose the separation by dots
to be consistent with the syntax of SLE service instance identifiers.

 

2) On page 2-14 in the operational scenario you mention that the stop on

secondary procedure is done before the stop on prime procedure. When
reading

this, a question came up in my mind : what happen if we do the other way
? A

note in the Framework (in ?2.6.1) states : "This Recommended Standard
does

not specify any interdependencies between the procedures that constitute
a

service.  However, the service specification may specify dependencies
that

must be observed e.g. with respect to the sequence in which procedures
are

started". I could not find in the Monitored Data CSTS document a place
where

this is explained. Maybe something could be added in the normative part
of

the document ?

 

This is a good question. It is my understanding that if an instance of
any stateful CSTS is in the 'bound.ready' state (which is where it would
be following the STOP of the prime procedure) would treat any other
incoming invocations (such as the STOP invocation of a secondary
procedure) as a protocol error. However, in looking again at the
Framework, I see that there is no support for this. We should discuss
this at the meeting next week.

 

3) In the table 3-1 we state that the Monitored Data CSTS can have any

number of cyclic report procedure instances and notication procedure

instances. I was wondering if we shouldn't state that an upper bound may
be

specified via the service management ?

 

Appropriate parameters have been added to the Managed Information
section (section 4) of version 0.9

 

4) On page 2-13, second paragraph : "...which places the prime procedure
in

the 'Active' substate and the service instance in the 'Ready' substate"
if

I'm not mistaken it should be in 'Active' substate. Also I'm wondering
if it

would not be better to state 'Bound.ready' and 'Bound.active' to keep
the

terminology used in the framework. Using 'ready' and 'active' for SI

substate is quite confusing with the 'inactive' and 'active' states of

procedures.

 

Agree. The changes have been made in v0.9.

 

5) I could not find in the document the format for parameter list names.
Is

everything allowed ? Shouldn't we specify something?

 

Section 4.6.2 states "Service management shall establish the set of
published monitored parameter list names, and for each list name the
subset of the monitored parameters that are represented by that list
name. The content and syntax of the monitored parameter list names is to
be mutually agreed between the MDOS and Complex.", and there is a
similar statement for notifiable event list names.

 

I can't think of any strong reasons for establishing a format for list
names, but if someone can provide a good justification I'm interested in
hearing about it.

 

6) I guess there is a typo in the title of section 4.6.4 : "4.6.34.6.4

DEFAULT MONITORED PARAMETER LISTS" if my understanding is correct there
is

only one default list, so we should remove the final "s".

 

Thank you. It has been fixed.

 

Best regards,

Cyril.

 

 

_______________________________________________

Css-csts mailing list

Css-csts at mailman.ccsds.org

http://mailman.ccsds.org/cgi-bin/mailman/listinfo/css-csts

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/css-csts/attachments/20091020/2661e2a0/attachment.htm