[Css-csts] RE: Action Item #03-0511S

[Martin Karch]

Dear John,

Thank you  very much for your quick and detailed response!

Here are my answers (below your comments).
"My first comment is that I think there is a conflict between the sentences "For example, the specification of a queriable CSTS could define a standard set of queriable parameters and parameter identifiers" and "In addition, the specification of a querible CSTS could define parameter list identifiers ...", and the notion that all identifiers will be registered by SANA. I think that if SANA is allocating and registering the identifiers, then they won't be defined (documented) in the CSTS specification itself. The CSTS specification may define the parameters and lists themselves and their "names", but the definition of the actual parameter identifiers for those names will be deferred to the SANA registry (unless I am misunderstanding the concept)."
I  agree with your comment, the CSTS will not define any identifiers. It needs to be clear  that a queriable CSTS could define queriable parameters (and parameter lists), but allocation/definition of their identifiers will be done by SANA.

"My second comment I had intended to give examples of different criteria by which the queriable parameters and lists could be defined. One example is the one that you kept: that the specification itself defines the parameter names and list names. Another example (appropriate to the Monitored Data CSTS) is where the names of the queriable parameters and lists, their definition, and of course their published identifiers are all deferred to the SANA registry.That second example has been cut out of the rewrite that you did."
I personally had the problem with the original 3rd  paragraph that according to my understanding no parameter will be specified  by SANA (the sentence started with "it could defer specification of the parameters ..."), only identifiers of parameters and parameter list identifiers are defined by SANA. As this area is perhaps not yet quite clear, we suggested to add this topic on the agenda of the next telecon.


"My third comment is that whereas the second paragraph states "The default list has no identifier ...", the (new) sixth paragraph states " ... default list identifier are allocated by [SANA] ...". There is obviously a conflict here. My inclination is that we don't need a default list object identifier, but I could be wrong. In any case, we need to decide and make the text consistent."

It is true that we do not need a default list identifier in the registry. We should remove "...default list identifier are allocated by SANA" in the sixth paragraph.


"For example, the specification of a queriable CSTS could define a standard set of queriable parameters, parameter lists, the member parameters of those lists, and the member parameters of the default list. As a different example, the specification of a queriable CSTS could simply refer to a SANA-maintained registry that defines the set of queriable parameters, parameter lists, the member parameters of those lists, and the member parameters of the default list."
This paragraph is now more precise and clearer than before. I assume the second sentence is an example that is appropriate for the Monitored Data CSTS.


"Regardless of whether the queriable parameters and/or parameter lists are defined and named in the CSTS specification itself or in a SANA registry that is referred to by that CSTS specification, the parameter identifiers, parameter list identifiers, and default list identifier [? - see above] are allocated by SANA and reside in a registry that is also maintained by SANA."

I feel that we can remove 'and the default list identifier'.


I see that you didn't yet make similar changes for the Cyclic Report and Notification procedures. Let's come to agreement on the wording for one (Information Query) and change the others after we have done so.
The intention was indeed to come to an agreement on the paragraphs with the common text before changing the others.


Best regards,
Martin




From: John Pietras [mailto:johnvpietras at gmail.com]
Sent: 29 August 2011 17:15
To: Martin Karch
Cc: css-csts at mailman.ccsds.org
Subject: RE: Action Item #03-0511S

Martin,
GST lost power over the weekend in the hurricane and I'm working from home until power can be restored at work. Please provide any responses to this message, and send any new messages, to this gmail account until further notice.

My first comment is that I think there is a conflict between the sentences "For example, the specification of a queriable CSTS could define a standard set of queriable parameters and parameter identifiers" and "In addition, the specification of a querible CSTS could define parameter list identifiers ...", and the notion that all identifiers will be registered by SANA. I think that if SANA is allocating and registering the identifiers, then they won't be defined (documented) in the CSTS specification itself. The CSTS specification may define the parameters and lists themselves and their "names", but the definition of the actual parameter identifiers for those names will be deferred to the SANA registry (unless I am misunderstanding the concept).

What this point out is the difference between the name of a parameter or list and the formal parameter identifier that is associated with that name. The CSTS specification may (but not always - see the next paragraph) define a queriable parameter and give it a name, but the parameter identifier for that parameter/list will be specified in the appropriate SANA registry.

My second comment I had intended to give examples of different criteria by which the queriable parameters and lists could be defined. One example is the one that you kept: that the specification itself defines the parameter names and list names. Another example (appropriate to the Monitored Data CSTS) is where the names of the queriable parameters and lists, their definition, and of course their published identifiers are all deferred to the SANA registry.That second example has been cut out of the rewrite that you did.

My third comment is that whereas the second paragraph states "The default list has no identifier ...", the (new) sixth paragraph states " ... default list identifier are allocated by [SANA] ...". There is obviously a conflict here. My inclination is that we don't need a default list object identifier, but I could be wrong. In any case, we need to decide and make the text consistent.

The following paragraphs express what I had intended to state while also reflecting the concepts of your new fifth and sixth paragraphs ("For example, the specification ... maintained by SANA"):

For example, the specification of a queriable CSTS could define a standard set of queriable parameters, parameter lists, the member parameters of those lists, and the member parameters of the default list. As a different example, the specification of a queriable CSTS could simply refer to a SANA-maintained registry that defines the set of queriable parameters, parameter lists, the member parameters of those lists, and the member parameters of the default list.

Regardless of whether the queriable parameters and/or parameter lists are defined and named in the CSTS specification itself or in a SANA registry that is referred to by that CSTS specification, the parameter identifiers, parameter list identifiers, and default list identifier [? - see above] are allocated by SANA and reside in a registry that is also maintained by SANA.

I see that you didn't yet make similar changes for the Cyclic Report and Notification procedures. Let's come to agreement on the wording for one (Information Query) and change the others after we have done so.

I agree with your correction on page 4 ("notification-enabled CSTS).

I agree that for consistency the use of the operations to set-up and deliver the notifications should be included in the Concept section for Notification.

Best regards,
John



From: Martin Karch [mailto:martin.karch at vega.de<mailto:martin.karch at vega.de>]
Sent: Friday, August 26, 2011 1:35 PM
To: John Pietras
Cc: css-csts at mailman.ccsds.org<mailto:css-csts at mailman.ccsds.org>
Subject: RE: Action Item #03-0511S

Dear John,

Thank you very much for the updated description.

In the meantime we (Margherita, Yves and myself) had a conversation on the subject, and we feel that we (on WG level) need to discuss open questions around  the published identifiers with respect to e.g:


-          What precisely should go into the repository maintained by SANA (list identifiers, parameter identifiers)

-          What are the default parameters/how to specify

-          The default list (defined by procedure level?)

-          Etc.

There will be a chance for the discussion on the next  telecon (or webex) .


On the first  page of the attachment I have proposed a little change to your description:  I made the attempt to split up the paragraphs a little bit (I personally feel that it is better to read). Then I removed the sentences starting with 'it could defer specification of parameters ... ". Instead I added a paragraph, which clearly says that it is the responsibility of SANA to allocate the published identifiers and to maintain the corresponding repository.

On page 4: 'For a given reporting CSTS' should read 'For a given notification-enabled CSTS' as this definition was made in the first paragraph of 'Concepts' on the same page.

Minor comment on Page 4 on the description of the concept of the Notification procedure:  In the description of the Information Query and Cyclic Report Procedure, the related operations like START, TRANSFER-DATA, STOP and GET are mentioned. In order to keep the descriptions in-line, the related operations should also be mentioned in the text for the Notification procedure concept description (page 4 and 5)


Best regards,
Martin

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/css-csts/attachments/20110829/dcb43c1d/attachment-0001.html