[Css-csts] RE: Ambiguous issues regarding the MD-CSTS

[John Pietras]

Martin,

Thank you for your quick response. I was not expecting to hear from you for a few weeks yet.

 

Regarding the comments on the syntax, I have no problem with putting back the syntax definition:

 

- fully qualiifed name for a monitored parameter = <functional resource identifier>.<monitored parameter type name>

- fully qualiifed name for a notifiable type name = <functional resource identifier>.<notifiable event type name>

 

Regarding the question of whether we really want to mandate definition of a default set or not rather allow scenarios (service agreements) where a specific set must always be selected by the user, a revisit of the Cyclic Report and Notification procedure specficatiions in R-0.22 CSTS FW shows new 'default not defined' diagnostics that have been added to the START operations. Clearly this must have been driven by this conversation. Thanks, Yves!

 

Best regards,

John

 

 

-----Original Message-----
From: Martin Götzelmann [mailto:martin.goetzelmann at vega.de] 
Sent: Sunday, July 18, 2010 12:11 PM
To: John Pietras; css-csts at mailman.ccsds.org
Subject: RE: Ambiguous issues regarding the MD-CSTS

 

Dear John,

 

My comments were only hand-written and I no longer have that copy. Therefore the response below is a sort of "reconstruction" with no guarantee that it conforms to my original comments. I do not think that we returned to the two topics in Portsmouth.

 

Note 3 under section 2.2.2:

I believe that it would be beneficial if the format (syntax) of the fully qualified name would be defined in the MD CSTS because this would enable the development of SW that can parse the name and can look it up in some table. If this definition is left to the definition of the parameters and if the syntax differs for different parameter sets, then special SW may have to be written for each variant.

 

Section 4.6.3

I beleive my question was whether we really want to mandate definition of a default set or not rather allow scenarios (service agreements) where a specific set must always be selected by the user.

 

Regards, Martin

 

________________________________

 

From: John Pietras [mailto:john.pietras at gst.com]

Sent: Fri 16/07/2010 10:23 PM

To: Martin Götzelmann; css-csts at mailman.ccsds.org

Subject: Ambiguous issues regarding the MD-CSTS

 

 

 

Martin and CSTSWG colleagues ---

 

During the review of the draft MD-CSTS in Portsmouth, I made short notes about the review comments in my copy of the MD-CSTS. Upon reviewing those notes, I came across two comments thay are cryptic enough that I need some help in remembering what the issues are.

 

 

 

1. Note 3 under section 2.2.1 states: "The syntax of the fully qualified name is outside the scope of this Recommended Standard. The syntax is defined as part of the specification of each set of monitored parameters and notifiable events that are transferred by the MD-CSTS." I recorded the comment "to be discussed". 

 

 

 

As I (vaguely) recall, this was an issue that Martin raised, and I believe that it had to do with whether we should defer the syntax definition to the monitord data dictionary(ies) or pick one and specify it in the MD-CSTS. However, I don't recall that we ever returned to the topic. I guess that we'll have to coninue the discussion via email, Can the person who raised this issue (Martin?) please restate the concern?

 

 

 

(On a related topic, I have decided to delete the informative reference to the nonexistent Monitored Data for Space Communication Services standard. Instead, I have put in a statement in a Note that simply states that CCSDS may define a standard set.)

 

 

 

 

 

2. Section 4.6.3 (Default Monitored Parameter List) states: "Service Management shall establish a single default set of monitored parameters for each Service Agreement". I recoerded the comment "Revisit". I do not recall the concern here - can anyone enlighten me?

 

 

 

 

 

Thank you for any help you can provide in clarifying these matters.

 

 

 

Best regards,

 

John

 

 

 

 

 

 

 

 

 

 

______________________________________________________________________

This email has been scanned by the MessageLabs Email Security System.

For more information please visit http://www.messagelabs.com/email 

______________________________________________________________________

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/css-csts/attachments/20100719/98e67421/attachment.html