[Css-csts] RE: Effects of using individual Labels with MD-CSTS

Tue Aug 13 09:44:43 EDT 2013

Dear John,

I worked on your updates and a I am going to upload the July version to CWE
site.
Please note that the access to the configuration was not sufficiently
specified (See your comment 11). The associated changes are quite important
and that's why it took me more time than I originally assumed for this
update.

Here are my responses to your comments:

1. I added a new subsection with the following text:
Configuration parameters subsection
This subsection lists the parameters that need to be configured in the
context of this procedure.
This subsection also identifies those parameters that are accessible by the
Service User for monitoring. The parameters can be accessed by means of the
GET or the NOTIFY operation.

2. I do not get your point.
The requirement 3.11.1.3 was phrased "b) contains one or more parameter
names, then return the values of all of the listed parameters;"
The new text reads "b) contains one or more parameter names, then return the
qualified parameters for of the listed parameters;".
There is no mention of label in that requirements.
The requirements "c) contains one or more parameter labels, then for each
label return the qualified parameter for that label that is associated with
the service instance that executes the procedure that contains the GET
operation" you added covers the label case.
I did not change the text and accepted your changes.

3. From a later email, we agreed to keep the Functional Resource Name and as
you proposed to introduce the Functional Resource type.

4. See answer to your comment 11. The parameter is 'accessible' and is part
of the rework on how to access the configuration.

5. As stated in section 4.5.2.2.1, “Whether an event is classified as
discardable or non-discardable shall be specified by the derived procedure or
services”, the definition is done by the derived procedure or service".
This list is not accessible by the Service User and is specified in the
derived procedure or service.

6. Ok

7. Ok

8. Ok

9. Ok

10. Ok

11. I acknowledge that the ASN.1 list-name definition referenced in Table
4-31 is not suitable for the required definition. I reviewed in details the
approach and noted that the access to the configuration is more complicated
than originally expected (I clearly overlooked how to access the
information).
As a consequence this is an important change in the Framework
The scenario is as follows:
   The Service User requests the configuration parameters. The book as
   defined foresees the configuration but does not explain how to request
   them. The new definition clarify this aspect.
   The Service User has two possibilities: (a) use the Information Query
   procedure, (b) use the Notification procedure. The capability is given to
   the two procedures as their definition is very similar.
   The Service Provider returns the complete configuration of that procedure.
   In the case the Service User requests the procedure type (Information
   Query only), the Service Provider shall return the configuration of all
   procedure instances for that procedure type.
   To cope with the Notification capability, a new Framework event is added.
   So far the FW limited the generic event to service production changes. The
   new event ('configurationChange') allows the Service Provider to report on
   configuration changes of procedure instances.
The changes are quite substantial for the access to the configuration:
- Clarification of the GET
- Extension of the NOTIFY with a new Framework event

12. The only left parameter is "list of parameters (Functional Resource Types
and Instances)".

13. Ok

14. Ok

15. Ok.
Please note that I also harmonised the text with the GET operation (the
selection is similar and makes use of the same ASN.1 definition)

16. Ok

17. Ok

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/
__________________________________________________

  From:       John Pietras <john.pietras at gst.com>                                                                                  

  To:         "Yves.Doat at esa.int" <Yves.Doat at esa.int>                                                                              

  Date:       24/07/2013 16:58                                                                                                     

  Subject:    RE: Effects of using individual Labels with MD-CSTS                                                                  

Yves,
Attached is my markup of the CSTS SFW. Most of my changes/comments are
directly related to the labels vs. names topic, but I found some other things
that I noted in comments and/or made proposed changes in the text. Below is
the list of the places where I made changes or inserted comments:
1.		 Section 1.6.3.2 (Specification of Procedures) should have a new
subsection 1.6.3.2.6 added to describe the Configuration Parameters sections
that have been added. Concerning those tables, each Configuration Parameters
table (e.g., Table 4-2) has the column header "Gettable". This implies that
only the GET operation can access these values, but as we discussed (in
Bordeaux, I think) anything that is available to the GET operation is also
available to the Cyclic Report. At a minimum, this new section 1.6.3.2.6
should explain that "gettable" means that it is accessible by both the GET
operation and the Cyclic Report procedure. Alternatively, perhaps a different
term (e.g., Accessible) could be used as the column title. But in any case it
should be made clear that the designation applies to both GET and Cyclic
Report.
2.		 In section 3.11.1.3 (b), you had deleted "and labels". However,
the CSTSWG had decided that it is okay to put individual labels in the
list-of-parameters:  whether names or labels are used in the invocation, only
names would be returned. What we decided at the last telecon is that the
standard behavior in response to a label is to return only the single
parameter value associated with the service instance that executes the
procedure. I've reworked section 3.11.1.3 to reflect this. Also, the phrasing
"names and values" was used throughout this section. But more than just names
and values are returned - qualified parameters are returned (Note that the
Cyclic Report procedure uses "qualified parameter" in its Behavior
definition). I reworded the paragraphs to use "qualified parameter".
3.		 Regarding my email yesterday, I've put a comment on the
"Functional Resource Name " option in 3.11.1.3 asking whether it's still
relevant in the standard case. I also put a similar comment on the
corresponding diagnostic in 3.11.2.3.1. I've flagged all instances of
Functional resource Name as an option for subscription. If the WG decides not
to change anything, these comment balloons can be deleted throughout.
4.		 In table 4-9, the 'named list of gettable parameters' is
designated as a gettable parameter. I don't understand this. Its type is
"sequence of Visible Strings TypeAndValue". TypeAndValue doesn't seem
appropriate. What is returned? If it's the set of list names, that's not the
same as a named list - if a named list is queried then it should be the
sequence of parameter labels.
5.		 In table 4-16, non-discardable notifications is listed as a
configuration parameter. Perhaps I missed something in Bordeaux, but I don't
understand how this can be a configuration item.
6.		 In section 4.7.2.2, second from last paragraph: The text has
been corrected to remove the possibility that a qualified parameter could
contain a label.
7.		 In 4.7.3.2.4 the text has been corrected to remove the
possibility that a qualified parameter could contain a label.
8.		 In 4.7.3.2.4, the requirement has been expanded identify the
standard behavior with respect to labels, names, lists, etc.
9.		 In 4.7.4.2.2.1 NOTE, the text has been corrected to remove the
possibility that a qualified parameter could contain a label.
10.		 In 4.7.4.2.2.3 NOTE, the text has been corrected to remove the
possibility that a qualified parameter could contain a label.
11. 		 In table 4-31, "list-names and the parameters that they
represent" is listed as Gettable. Its Type is given as "Sequence of Visible
Strings" but this would be a complex data structure (a string for the name,
and a sequence of the Labels represented by that list name). I don't think
that we have such a structure (type) defined.  I noticed that for the
Notification procedure "list-of-events and their names (Functional Resource
Types and Instances)" is listed as *not* being Gettable - is this an
inconsistency between Cyclic Report and Notification? Finally, I added
"labels" to clarify that the list name represents parameter labels.
12.		  In table 4-31, there is a "list of parameters (Functional
Resource Types and Instances)" row and a "list of parameters to be reported"
row. What's the difference between these rows?
13.		 In table 4-31, I changed "default list and the parameters that
it represents" to " default list and the parameter labels that it
represents".
14.		 In 4.8.2.2, second paragraph, I removed the sentence that states
that a one label can trigger multiple different notifications.
15.		 In 4.8.3.2.2, I added bullets to expand on what gets returned as
a function of what is subscribed to in the list-of-events of the START
invocation.
16.		 In B2.1, bullet, reverted to the previous definition where only
parameter names (not labels) can appear in qualified parameters.
17.		 I deleted the previously-suggested new B2.3 and B2.4, which
dealt with how to decide whether the qualified parameter should contain a
name or a label. We don't need these now that Q-Ps can contain only names.

Best regards,
John

-----Original Message-----
From: Yves.Doat at esa.int [mailto:Yves.Doat at esa.int]
Sent: Wednesday, July 17, 2013 11:22 AM
To: John Pietras
Subject: RE: Effects of using individual Labels with MD-CSTS

Dear John,
As discussed please find attached the working version of the Framework.
I will not work on it until you return it to me.

I started to identify the changes:
- Marked with comments (to be removed / to be checked)
- I changed the ASN.1 types: NotificationTypes and QualifiedParameter.

Best regards
Yves
(See attached file: 921x1r2[Draft 201307] - Return Services - for John.docx)

[attachment "921x1r2[Draft 201307] - Return Services - for
John-response.docx" deleted by Yves Doat/esoc/ESA]

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.