[Css-csts] Re: [CSS] FunctionalResourcesForMD-CSTS-V2.doc on CWE

[Yves.Doat at esa.int]

Dear John

I had a look at your Technical Note and I really appreciate thta you 
initiated the work to compile and organise the various parameters.

You will find my comments below:
General comments:
I have some problems to map the SI-id (service package, service agreement 
and functional group) and the corresponding Service Package and Agreement 
listed in this document. The mapping should be clarified.
The TN addresses the SLE services but does not cover the CSTS services. 
E.g. the monitoring of the CSTS services (MDS, Unframe TM, ?) are not 
addressed (state of the service, ?)
The parameters should be (at a later stage) complemented with a 
definition, the unit and the range
Section 1.3., 3rd paragraph - Ditinguished Name. The way this term is used 
looks to be a Relative Distinguished Name.
Section 1.3., 3rd paragraph - Domain - Are you referring to the Ground 
Domain Services defined in the reference Model? If yes it should be 
stated, if not, what domain are to be considered?
Section 1.4, 2nd paragraph after the NOTE 1- "The monitoring of services 
is most easily associated with the functions performed as part of space 
link session (SLS) Service Packages". What if we want to use the 
MD-Service for non SLS service packages (e.g. Meteo Data)?
Section 1.5, last paragrah - What about the ESA parameters?
Section 1.6 - 1st paragraph - According to your definition, any monitored 
parameter can be gettable and be treated as events? Is that really what we 
want? My understanding was not to mix them. The proposed approach would of 
course cover monitoring on-change. We should discuss the matter.
Section 1.6 - NOTE - The configuration parameters could be gettable. In 
that cas I would support handling them by notification which would ensure 
the Service User to be notified when SM changes a configuration. If they 
are gettable, I am not sure when would the Service Used have to get them?
Section 1.6, last paragraph, last sentence. The more-detailed information 
that is of interest to the individual users of those transfer services is 
available to the users through the transfer service instances themselves. 
I understand that the detailed monitoring parameter has to be implemented 
by the service itself and not by the MD-CSTS. Is that correct? Whys do you 
propose this limitation to the MD?
Section 2, las 3 bullets - We have RAF, RCF and R-OCF services 
implementing each 3 modes on-line, on-line complete and off-line. Why do 
you only consider one mode in this list? The functional resource should 
focus on the service and a differentiation of transfer modes. Note: In 
section 2.9.2 you cover the three modes and this seems in contradiction 
with those bullets.
CSTS services will only consider real-time and off-line. How is that 
covered in the proposed approach?
Section 2.1.2 - The antennaId looks to be the Service Agreement. Accoring 
to the Reference Model, the Service Agreement identifies the SM and the 
transfer service. Why is the antennaId not mapped to the functional-group 
of the SI-id? (The same comment applies to other functional resources in 
the TN).
Section 2.1.3.1 reffers to the CLTU production status. In my view the 
definition should refer to the CSTS annex B as this is what we are working 
on (and is the same).
Section 2.1.3.4 and 2.1.3.5 refer to commanded antenna angles. I am 
missing the monitored antenna angles.
Section 2.2.2, Clrification for my ignorance - It is not clear to me  why 
is the functional resource named F401? (Does that refer to RF& Modulation 
Systems CCSDS 401)? I looked into SM book but could not clarify the origin 
of this name. Can you explain it to me? Could you give an example fo 
identifier?


Best regards


Yves 
__________________________________________________
Head of the Stations and M&C Integration Section (OPS-GSI)
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/
__________________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/css-csts/attachments/20090308/2887498e/attachment.htm