[Css-csts] A#01-0510S : review of the parameter list provided byESA

[John Pietras]

Wolfgang,
I have a few comments about the monitored parameter list as documented
in (Monitored parameters list- CNES comments WH reply.doc). 

1. Many parameters have an asterix (*) aftere their names. What does the
asterix signify?

2. The PLOP and "coherent with data clock" parameters are grouped under
the Uplink Subcarrier Status category. However, it is my understading
that data (and therefore the PLOP) can be modulated onto the carrier as
well as the subcarrier. Should not the PLOP (and I assume the "coherent
with data clock" parameter) also be allowed to be assiociated with the
uplink carrier? (NOTE - It is for situations such as this that the
strawman breakout of functional resources has a Symbol Stream functional
resource. All parameters of the Symbol Stream resource are then
associated with whatever carrier or subcarrier is being data-modulated.)

3. Under the Uplink Subcarrier Status, the PLOP parameter has values
"always on" and "always off". What are these, since they are not
CCSDS-defined PLOPs?

4. I'm showing my ignoreance here - what is hybrid ranging?

5. The various SLE transfer services report the status of a number of
production parameters associated with those transfer services. As
written in the draft monitored parameters list, these production
parameters are grouped with the SLE transfer services. This raises a
question in my mind - is it better to (a) associate these production
parameters with the individual transfer service instances (in which case
there may be redundant reports of the same values), or (b) report the
production parameters once (e.g., associated with the symbol stream or
physical channel) and somehow relate the transfer service isntances with
their respective symbol streams/physical channels?

6. Is this list of parameters supposed to be ones that can be cyclically
reported, notified on change, queriable, or all classes? For parameters
associated with SLE transfer services, the list of monitored parameters
includes parameters that are notified via the ASYNC-NOTIFY operation,
periodically reported via the STATUS-REPORT operation, and one-time
retrieved via the GET-PARAMETER operation. The FOP State, for example,
is retrievable via the GET-PARAMETER operation but not via the
STATUS-REPORT operation.  Would it make sense to annotate in the
parameter list to list the expected "access method" (e.g.,
cyclically-reported, notification on change of value (e.g., for states
or other enumerated types), of via information query)? 

Best regards,
John