[Css-csts] combined default list for MD-CSTS Cyclic Report andInformation Query procedures

[Martin Götzelmann]

Dear John,
 
As I have raised the comment, I guess I should at least try to provide a justification. Actually, I had (and have) the feeling that the added complexity of having to deal with two lists is not worth the potential benefit. After all the reason for having the default list at all was to support the very simple case where everything is fixed and known to both parties, such that all the user needs to do is start monitoring. For me it is no longer simple if the data I get depend on the method I use to access them - I am afraid that might be confusing.
 
I concur that it is not an important point and we should not deal to long with it. Therefore, if you have a strong feeling that two default lists are really of value, that is OK for me.
 
Regards, Martin

________________________________

From: css-csts-bounces at mailman.ccsds.org [mailto:css-csts-bounces at mailman.ccsds.org] On Behalf Of John Pietras
Sent: 06 November 2009 22:39
To: css-csts at mailman.ccsds.org
Subject: [Css-csts] combined default list for MD-CSTS Cyclic Report andInformation Query procedures



CSTS-WG colleagues ---

In reviewing the draft MD-CSTS last week in Noordwijk, we decided to combine the default lists for the Cyclic Report (CR) and Information Query (IQ) procedures into a single default list (at least, that's what I have in my notes). 

 

I honestly don't remember spending much time discussing this, and in thinking about it further I wonder if it's a good idea. I think that the kinds of data that are to be cyclically reported are likely to be different enough from the kinds of data to be retrieved on special occasion that it's worthwhile to keep two separate default lists. Put another way, I don't see the burden of keeping a separate default list for each class of procedure to be high enough to outweigh the potential benefit of two different default lists. Of course, if we don't allow a separate list for IQ, it would be easy enough to create a named list that would essentially be the "standard" list for IQ (e.g., "defQuery"). But the user would have to enter that name in the GET every time, which defeats the purpose of not having to name the parameters. Basically, if there's not a separate default list for IQ, I think the default list will almost always be used for periodically-reported parameters and will rarely if ever be used for IQ.

 

I don't usually like to force a revisit of a decision made (at least, so quickly after it has been made), but I feel as though I was "asleep at the wheel" on this last week and that I should have defended it a bit more strongly when it came up in the review. I don't want to make this a long, drawn-out discussion, but for my benefit, can anyone state a strong case for not allowing a separate default list for IQ, other than it's just simpler?

 

 

Best regards,

John

 

John Pietras

GST, Inc. 

7855 Walker Drive, Suite 200

Greenbelt, MD 20770

240-542-1155

 


______________________________________________________________________
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/20091113/63315b4b/attachment.html