[Css-csts] Re: Effects of using individual Labels with MD-CSTS
Yves.Doat at esa.int
Yves.Doat at esa.int
Mon Jul 15 02:33:37 EDT 2013
Dear John,
The problem I understand is that leaving in the Framework all the
possibilities implies that the service as to refine the behaviour to
ensure the service provider returns with a predictable behaviour names or
labels.
I see in your proposed refinement that the intention is to enforce the
provider to return names. As you correctly points out, this requires a new
refined procedure.
Reading your new service, the questions I have are:
1. what do we gain in leaving the flexibility? In my view not much.
2. What do we loose if the Framework imposes tor return names whatever
the user requests (names or labels)? Considering that the overall approach
is based on names, I do not think we do loose much.
In view of the service specifications difficulties you are facing and
considering that we do not loose much (It's my feeling), I would propose
that whatever is requested (names or labels), the service provider always
return names.
That approach will in addition ensure a unique identification when
troubleshooting will be required.
If everybody agrees and in view of the difficulties I am prepared to
update the Framework for imposing the service provider to always return
names.
Please let me know if you (the working group) would see an issue with that
change and if you would agree.
Best regards
Yves
From:
John Pietras <john.pietras at gst.com>
To:
"Yves.Doat at esa.int" <Yves.Doat at esa.int>
Cc:
"CCSDS_CSTSWG (css-csts at mailman.ccsds.org)" <css-csts at mailman.ccsds.org>,
"css-csts-bounces at mailman.ccsds.org" <css-csts-bounces at mailman.ccsds.org>
Date:
09/07/2013 22:48
Subject:
Effects of using individual Labels with MD-CSTS
Yves and CSTSWG colleagues ---
Yesterday I responded to Yves? message (see below). With regard to his
question about whether the CSTS SFW should specify the behavior of an
operation of a procedure when a Label is used in the subscription (e.g.,
can the return contain either a Label or a Name?), Yves expressed a
preference for not locking it down in the CSTS SFW. I agreed with that
preference, and suggested that the CSTS SFW could formally defer the
specification of the behavior to the individual services. When I wrote my
response yesterday, I thought that it would be sufficient to address the
behavior as a refinement of some operation parameter values.
Yesterday and today I modified the MD-CSTS specification to address the
the behavior with respect to what gets reported/notified when a Label is
used in the subscription or query. Unfortunately, it looks like the effect
on the MD-CSTS (and other services using the Cyclic Report and
Notification procedures and the GET operation) may be more extensive than
I had originally anticipated.
I?ve uploaded the modified MD-CSTS specification to the CWE at URL
http://cwe.ccsds.org/css/docs/CSS-CSTS/CWE%20Private/Future%20Services%20using%20Toolkit/MonitoredDataCSTS/MonitoredDataCSTS_W-0.15-13-07-09.doc
The complications arise because according to the CSTS Guidelines (most
recent version posted on the CWE ? October 2012), a change in or addition
to procedure behavior is defined as an extension, which in turn requires
that a new Procedure Type Identifier be defined (along with a new name for
the procedure) and a new procedure specification section to be added to
the service specification.
I tried to figure out how to add the specification of such behavior in the
service specifications without needing to create extended procedures, but
so far I have not had success. The best thing that I have been able to
think of so far is that we might define a standard set of behaviors in the
CSTS SFW and require that a service specification select among them (sort
of like how we have defined standard state machines from which each
service specification selects the one to which it conforms). If we have a
standard set of behaviors, a service that selects which of those behaviors
that applies to it could be considered to be refining (instead of
extending) the behavior, and that would not involve creating a new
Procedure Type Identifier. The Guidelines would also have to change to
allow refinement of behavior.
How should we proceed? Do we just accept that any service that uses the
Cyclic Report or Notification procedure or any procedure that uses the GET
operation will have to be extended (that is, it will be impossible to
simply adopt the Framework version of the procedure), or should we try to
figure out how to ?standardize? this behavior in the Framework? I look
forward to your (and other CSTSWG colleagues?) responses.
Best regards,
John
From: John Pietras
Sent: Monday, July 08, 2013 11:57 AM
To: 'Yves.Doat at esa.int'
Cc: CCSDS_CSTSWG (css-csts at mailman.ccsds.org);
css-csts-bounces at mailman.ccsds.org
Subject: RE: [Css-csts] RE: Updated CSTS SFW on CWE - labels
Yves,
My comments are interleaved below.
Best regards,
John
From: Yves.Doat at esa.int [mailto:Yves.Doat at esa.int]
Sent: Monday, July 08, 2013 2:37 AM
To: John Pietras
Cc: CCSDS_CSTSWG (css-csts at mailman.ccsds.org);
css-csts-bounces at mailman.ccsds.org
Subject: Re: [Css-csts] RE: Updated CSTS SFW on CWE - labels
Dear John,
Thanks for your reply.
1. No mixing of Names and Labels
As you did not really object I kept the definition as is not allowing the
mixture of names and labels in a request.
The defined ASN.1 has not been changed and read as follows:
ListOfParametersEvents ::= CHOICE
{ defaultList [0] NULL
, paramEventNames [1] SEQUENCE OF Name
, paramEventLabels [2] SEQUENCE OF Label
, listName [3] VisibleString
, functionalResourceName [4] FunctionalResourceName
}
My main argument to keep the definition as is, is simplicity. Allowing
mixing would be possible but would introduce a complexity in the
definition. The consequence of this approach is that a service user that
will need to retrieve names and labels will have to issue two requests.
In case someone would have a concern with that approach please let me
know.
As I stated in my earlier message, I have no objection to not allowing the
mixture of Names and Labels. However, there two places in my proposed
revised text (?921x1r2[Draft 201306] - Return Services-JVP?) that imply
that they could be mixed. Below are proposed rewordings:
a) Section 3.11.2.3.1 (b), second sentence: change ?The list of
unknown Parameter Names and Parameter Labels shall be returned with the
diagnostic.?
to
?The list of unknown Parameter Names or Parameter Labels shall be returned
with the diagnostic.?
b) Section 4.7.4.1.3.1 (b), second sentence: change ?The list of
unknown Parameter Names and Parameter Labels shall be returned with the
diagnostic.?
to
?The list of unknown Parameter Names or Parameter Labels shall be returned
with the diagnostic.?
2. Return of Names when Labels are requested:
Another aspect which you are addressing is what a service provider shall
return in case a label is required. At the moment he can return a name or
a label.
In your proposed scenario, in case the service provider only "knows" one
name whether he returns a name or a label does not make any difference and
can be accepted.
However in the case a service provider would "know" more than one name and
return a label, the service user may be misled as he cannot be sure if the
returned information is the requested on.
A solution would be to force the service provider only to return names. In
case a service user would request a label and the service would "know"
more than a name, he would return all "known" names. The service user
would have to filter/search himself for the desired one. This would
resolve the uncertainty but I am not sure is the service user would "know"
how to filter.
The question is: Do we want the service provider to return only names and
do not allow the return of labels? On one hand I adhere to this
limitation, on the other hand this implementation would remove flexibility
for the service definition and may be counter-productive.
Currently the definition allows the service provider to return names and
labels.
This solution impacts the current definition and I would appreciate to get
the position of the group members.
(In case my explanation is not clear we should discuss the topic in a next
teleconference.)
It was my understanding from our discussion at the last telecon that we
decided that if the user subscribed to a parameter or event using its
Name, then the report/notification/etc. would have to use the full Name
also. I don?t believe that we had any decision on what has to be returned
when a Label is used in the subscription. In ?921x1r2[Draft 201306] -
Return Services-JVP?, I tried to address this by proposing explicit
requirements that (a) state that a Name returns a Name, and (b) defers the
decision about what gets returned in response to a Label to the service
specifications that use that procedure.
Specifically, for the Notification procedure, the relevant requirements
are:
4.8.3.2.3 If an event is subscribed in terms of an individual event name,
the corresponding notification-type parameter (see 3.10.2.2.3.1) shall
contain that event name.
4.8.3.2.4 The service specification or derived procedure shall specify
the conditions under which it is permissible or required to use the event
label or event name in a notification-type parameter that corresponds to
an event that is subscribed in terms of an event label.
For the qualified parameters (which are returned for all procedures that
deal with parameters) the relevant requirements are:
B2.3 If a parameter in the list-of-parameters parameter is identified by
an individual parameter name, the corresponding qualified parameter shall
include that parameter name.
B2.4 The service specification or derived procedure shall specify the
conditions under which it is permissible or required to use the parameter
label or parameter name in a qualified parameter that corresponds to a
parameter in the list-of-parameters parameter that is identified by an
individual parameter label.
If the CSTSWG agrees with this approach (Names result in Names, but the
result of Labels is determined by the service) then I think the above
requirements largely resolve the problem. The only resulting issue that I
can think of is how such definition should be documented in the service
specifications. I believe that since it would be a ?down selection? of
existing possibilities (Names, Labels, or Names and Labels) it should be
treated as a refinement. Does this seem correct to the rest of the CSTSWG?
The procedures in some services may be perfectly unambiguous with
returning labels ? e.g., the production status of an SLE-like CSTS can be
assumed to always apply to the production associated with that CSTS
instance, and so the instance number is not necessary.
However, for something like the MD-CSTS, it will always be necessary to
return full Names. I will revisit the MD-CSTS specification to ensure (a)
that it handles individual Labels as well as Names in the
list-of-parameters and list-of-events parameters and (b) that it is clear
that Names are always returned regardless of whether Names or Labels are
used in the subscriptions. If we agree that this should be treated as a
refinement, then I?ll make the appropriate changes to the MD-CSTS
specification.
Best regards
Yves
__________________________________________________
Head of the Ground Facilities Infrastructure Section (HSO-ONI)
in the Ground Facilities Operations Division
ESA/ESOC Robert-Bosch Strasse 5
D-64293 Darmstadt, Germany
Tel.: +49 (6151) 90.2288 Fax:+49 (6151) 90.3046
Internet: http://www.esa.int/
__________________________________________________
This message and any attachments are intended for the use of the addressee or addressees only. The unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its content is not permitted. If you received this message in error, please notify the sender and delete it from your system. Emails can be altered and their integrity cannot be guaranteed by the sender.
Please consider the environment before printing this email.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/css-csts/attachments/20130715/5463f340/attachment.html
More information about the Css-csts
mailing list