[cssm] Review comments on the SMURF

Tue Feb 22 10:56:44 UTC 2022

Hello

I have implemented SMURF w0.19 generation on our system (EMSP) limited to 
booking request, replace and delete, and validated them against the xsd.

Here are my findings

Syntax:

1) srvPkgRef is attribute for replaceSrvPkg, and element for deleteSrvPkg. 
Any reason why ?
It has also different upper/lower case for the first S  : srvPkgRef is 
attribute for replace, and  (S upercase SrvPkgRef), element for delete. 

2) I can see
newOnlineSrvPkgReq
replaceOnlineSrvPkgReq

But no deleteOnlineSrvPkgReq. Shall we use deleteSrvPkg instead ?

3) What about replaceOnlineSrvPkgReq vs replaceSrvPkg ?
May be an answer to point 2). I was not able to implement 
replaceOnlineSrvPkgReq. I din't find how to incorporate new times 
parameters in a way which validates against the xsd.
I have use replaceSrvPkg instead.

XSD

SANA xsd import via hmtl link doesn't work for me. I had to download the 
file onto my system and edit the xsd to remove the html link.
e.g.  
<xsd:include schemaLocation="
https://sanaregistry.org/r/ndmxml_qualified/ndmxml-2.0.0-master-2.0.xsd"/> 
can not be found

Looking at the example provided

Contains absolute times. It needs to be updated for each support, and in 
case the support track times are modified, it becomes invalid.
Time should be offset relative to the of start/end of the service package.

Anyway, Absolute Time format shall be Time format B instead of 

<startTime>
     <year value="2020"/>
     <dayOfYear value="184"/>
     <hourOfDay value="11"/>
     <minuteOfHour value="20"/>
     <secondOfMinute value="30"/>

</startTime>

Philosophical:
Unnecessary verbose and complex.But I suppose this is CCSDS trademark.

So many options will never be implemented by any single network.

The approach of keeping items to accomodate very specific needs will 
result in a non-standard usage of the standard. 
Each network will implement its own concept in the background. 

I have a strong preference to standardise only concept currently supported 
by ALL network (or at least a majority). Everything else shall be covered 
by "extended parameters".
But as time is running short, I will not object to go for agency review 
with the current version.

I now it has been agreed that preferredDuration is now an unsignedInt 
instead of a ISO duration, but I still have a bad feeling of going away 
from existing standard.

Regards
________________________________________
Martin UNAL
Ground Operation Manager
Ground Facilities Ops HSO - ONO
H-376
ESOC
Robert-Bosch Strasse 5
64 293 Darmstadt
Germany
Tel +49 6151 90 2959 
________________________________________

From:   "Barkley, Erik J\(US 3970\) via SMWG" <smwg at mailman.ccsds.org>
To:     "Colin.Haddow at esa.int" <Colin.Haddow at esa.int>
Cc:     "CCSDS Service Mgmt WG" <smwg at mailman.ccsds.org>
Date:   10/02/2022 23:40
Subject:        [cssm] Review comments on the SMURF
Sent by:        "SMWG" <smwg-bounces at mailman.ccsds.org>

Dear Colin,

Attached please find my comments on the SMURF draft recommended standard. 
Overall this is quite an impressive document and I think it is very close 
to being ready for agency review. Here is a summary of the more 
significant comments:

1.      I think there is still some cleanup needed with regard to removal 
of the request for accounting report. Here and there it is still 
referenced but the main UML diagram and the report request UML specific 
diagrams have the accounting report removed which I think is just fine 
given that we are quite unlikely to produce any kind of definition for a 
standardized accountability report anytime soon.
2.      There is still some leftover stuff with regard to the scenario 
sets which I think we all agreed we are not putting in the book so a bit 
of cleanup is needed there.
3.      For a few of the parameter descriptions there are essentially 
usage consideration notes rather than a direct description of the 
parameter itself. It strikes me that we could either collect these notes 
in a usage considerations Annex or move the note like material in the 
description into specific notes about usage consideration where this 
occurs (i.e. essentially in line with the parameter table entry). In 
either case, I think this then would make the description entries more in 
line with CCSDS "terse style" pedantic as it may be.
4.      Optional use of start and end times for requests seems odd to me ? 
for example, a request for communication geometry (Communications Planning 
Information Format) seems like it would have to be bounded in time.  This 
might need further explanation if these values are optional and/or perhaps 
they should be mandatory?
5.      Location of the XML Instance examples:  the CPIF calls out the 
github repository directly; I am okay with the a SANA GitHub repository 
registry as indicated by the SMURF, but if we are to do that I think we 
need to add a description of the registry (simple though it may be) and 
start working with the SANA guys to get it into place. 

Well, that?s it.  What do you think? 

Best regards,
-Erik[attachment "902x9w0_19 - 
ServiceManagementUtilizationRequestFormats-eb.doc" deleted by Martin 
Unal/esoc/ESA] _______________________________________________
SMWG mailing list
SMWG at mailman.ccsds.org
https://mailman.ccsds.org/cgi-bin/mailman/listinfo/smwg

This message is intended only for the recipient(s) named above. It may contain proprietary information and/or
protected content. Any unauthorised disclosure, use, retention or dissemination is prohibited. If you have received
this e-mail in error, please notify the sender immediately. ESA applies appropriate organisational measures to protect
personal data, in case of data privacy queries, please contact the ESA Data Protection Officer (dpo at esa.int).

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20220222/d762645b/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Example-902x05w0_06_DDOR-ConfigurationProfile.xml
Type: application/octet-stream
Size: 13352 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20220222/d762645b/attachment-0005.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 902x09w0_19-Smurf.xsd
Type: application/octet-stream
Size: 14991 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20220222/d762645b/attachment-0006.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 902x09w0_19-Smurf-BasicCons.xsd
Type: application/octet-stream
Size: 3751 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20220222/d762645b/attachment-0007.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 902x09w0_19-Smurf-EnhancedCons.xsd
Type: application/octet-stream
Size: 8778 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20220222/d762645b/attachment-0008.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 902x12w1_04-SmCmnEnt-DataWrp.xsd
Type: application/octet-stream
Size: 10635 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20220222/d762645b/attachment-0009.obj>