[Css-csts] SANA CSS OID Registry is still wrong

Wed May 12 14:18:40 UTC 2021

CSTSWG colleagues ---
At yesterday's CSTSWG (11 May), I took the action to check if the errors in the SANA Registry CSS OID subtree and the Functional Resource registry are still present. Unfortunately, they still are. This shouldn't be a surprise since the registry was last updated on 14 January and I wrote my last email on the subject on 4 March (see below).

But what I find strange is that I was not able to get the same "view" of the OID tree that Holger shared during our meeting. For example, when I view the OID tree using Chrome on Windows, I see all of the parameters (Holger sees no parameters) and I see both 401 Transmission and Reception FR Sets, but the labels are all fouled up - e.g., "CCSDS 401 Physical Channel Reception" is labelled "stratum" and "Physical Channel" is labeled "resource_set". Also, the FR Sets and their OIDs are displayed all out of order.

As I said in my email of 4 March, I don't have the time or resources to try to discover and catalog all of the errors. It's a mess.

Best regards,
John

From: John Pietras
Sent: Thursday, March 4, 2021 11:59 AM
To: Holger.Dreihahn at esa.int
Cc: Erik.J.Barkley at jpl.nasa.gov
Subject: RE: SANA CSS OID Registry is still partially wrong

Hi, Holger. I think that point 1 is something that they just fixed in the past few weeks (i.e., since I sent my email below). However, even there, it has two minor "errors" - if we want the OID tree to be consistent with the SFW, the label for 1.3.112.4.4.2 should be "crossSupportResources", not "crossSupport Resources", and the label for 1.3.112.4.4.2.1 should be "crossSupportFunctionalities" not "Functional Resources". But yes, if these two label/classifier issues are cleaned up, point 1 has basically already been addressed.

However, I see from this latest change that they added information to the OID tree itself (which, as I recall, is what we asked them to do). Unfortunately, there are many glitches with that, regarding "stratum" vs "resource set". In most cases, they got the "stratum" and "resource set" labels wrong. E.g.,  "AOS Space Link Protocol Transmission" is listed as the "stratum" and under it "Space Link Protocol" is listed as the "resource set" (they are of course reversed). See also CCSDS 401 Physical Channel Reception, CCSDS 401 Physical Channel Reception, Cfdp File Data Production, Fixed Length Frame (FLF) Unified Space Link Protocol Transmission, Fixed Length Frame Synchronization, Channel Encoding, and OID Generation, Fixed-Length Frame (FLF) Synchronization and Channel Decoding, Frame Data Sink, Monitored Data CSTS, and Real-Time Radiometric Data Collection.

It's also not clear what the logic is for the ordering - the OIDs are all out of sequence. That may be to try to align the tree in alphabetical order of the OID labels (classifiers) but even that isn't followed.

Sorry to throw this new set of problems back to you.

Best regards,
John

From: Holger.Dreihahn at esa.int<mailto:Holger.Dreihahn at esa.int> [mailto:Holger.Dreihahn at esa.int]
Sent: Thursday, March 4, 2021 11:21 AM
To: John Pietras <john.pietras at gst.com<mailto:john.pietras at gst.com>>
Cc: Erik.J.Barkley at jpl.nasa.gov<mailto:Erik.J.Barkley at jpl.nasa.gov>
Subject: RE: SANA CSS OID Registry is still partially wrong

HiJohn,
I was just about to forward the email, but looking at the CSS OID Structure I see:
[cid:image001.jpg at 01D74716.7E2ED510]

So your point 1 is addressed, right?

For point 2 - 4, yes, it looks wrong.

Best regards,
Holger

Holger Dreihahn
European Spacecraft Operations Centre | European Space Agency | H-293
+49 6151 90 2233 | http://www.esa.int/esoc<https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.esa.int%2Fesoc&data=04%7C01%7Cjohn.pietras%40gst.com%7C2e53035c36dd4544cac008d8df298437%7C17917f83951e48839dd6b11685623b38%7C1%7C0%7C637504716720045186%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ioX4whDty%2BHGyZ8DAvnjzlQZwOmGcHo7kle8fZPWEE0%3D&reserved=0>

From:        "John Pietras" <john.pietras at gst.com<mailto:john.pietras at gst.com>>
To:        "Holger.Dreihahn at esa.int<mailto:Holger.Dreihahn at esa.int>" <Holger.Dreihahn at esa.int<mailto:Holger.Dreihahn at esa.int>>
Cc:        "Erik.J.Barkley at jpl.nasa.gov<mailto:Erik.J.Barkley at jpl.nasa.gov>" <Erik.J.Barkley at jpl.nasa.gov<mailto:Erik.J.Barkley at jpl.nasa.gov>>
Date:        04/03/2021 17:12
Subject:        RE: SANA CSS OID Registry is still partially wrong
________________________________

Thanks, Holger. I had mentioned to Peter that we were having some difficulty getting SANA to get the OID registry right, and he of course was interested. I told him that we were still trying to work the issue "through the proper channels", but if we can't get out of this "I fixed it/no you really didn't" loop we may have to escalate the concern.

Best regards,
John

From: Holger.Dreihahn at esa.int<mailto:Holger.Dreihahn at esa.int> [mailto:Holger.Dreihahn at esa.int]
Sent: Thursday, March 4, 2021 11:02 AM
To: John Pietras <john.pietras at gst.com<mailto:john.pietras at gst.com>>
Cc: Erik.J.Barkley at jpl.nasa.gov<mailto:Erik.J.Barkley at jpl.nasa.gov>
Subject: RE: SANA CSS OID Registry is still partially wrong

Hi John,
I will forward it to SANA, but they are not really responsive. For our FRM request they just replied that this is 'new' and will be addressed at some point. The question when is not answered.

Best regards,
Holger

Holger Dreihahn
European Spacecraft Operations Centre | European Space Agency | H-293
+49 6151 90 2233 | http://www.esa.int/esoc<https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.esa.int%2Fesoc&data=04%7C01%7Cjohn.pietras%40gst.com%7C2e53035c36dd4544cac008d8df298437%7C17917f83951e48839dd6b11685623b38%7C1%7C0%7C637504716720045186%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ioX4whDty%2BHGyZ8DAvnjzlQZwOmGcHo7kle8fZPWEE0%3D&reserved=0>

From:        "John Pietras" <john.pietras at gst.com<mailto:john.pietras at gst.com>>
To:        "Holger.Dreihahn at esa.int<mailto:Holger.Dreihahn at esa.int>" <Holger.Dreihahn at esa.int<mailto:Holger.Dreihahn at esa.int>>
Cc:        "Erik.J.Barkley at jpl.nasa.gov<mailto:Erik.J.Barkley at jpl.nasa.gov>" <Erik.J.Barkley at jpl.nasa.gov<mailto:Erik.J.Barkley at jpl.nasa.gov>>
Date:        04/03/2021 16:57
Subject:        RE: SANA CSS OID Registry is still partially wrong
________________________________

Hi, Holger.
I just remembered that I sent this to you a few weeks ago. Have you had the chance to forward the comments to the SANA guys, and if so have they responded in any way?

Thanks.

Best regards,
John

From: John Pietras
Sent: Friday, February 19, 2021 12:08 PM
To: Holger.Dreihahn at esa.int<mailto:Holger.Dreihahn at esa.int>
Cc: Erik.J.Barkley at jpl.nasa.gov<mailto:Erik.J.Barkley at jpl.nasa.gov>
Subject: SANA CSS OID Registry is still partially wrong

Hi, Holger.
I just checked the SANA registry to see (among other things) if they've fixed the problems with what used to be called the CSTS OID registry. The registry was indeed updated on 2021-01-13 an renamed "CSS OID Subtree", but there are still multiple problems with it:
1.     Although it purports to be the "CSS OID", it still starts with the subnodes of the csts node (i.e., the framework subnode, 1.3.112.4.4.1.1), not the css node itself (1.3.112.4.4) or even the subnodes of the css node (csts, 1.3.112.4.4.1). The problem with that is that the crossSupportResources (1.3.112.4.4.2) subnode  under css is not registered anywhere as far as I can tell. Furthermore, we need to register the crossSupportFunctionalities (1.3.112.4.4.2.1) and agenciesFunctionalities (1.3.112.4.4.2.2) subnodes under crossSupportResources. Futhermore, because SANA ha not registered either the css OID or the csts OID itself as being under the authority of CSSA, it appears that SANA could unilaterally assign the 1.3.112.4.4.2 subnode to some other (non-CSS) use. Finally, the Authority for this registry is listed as CCSDS.CSS.CSTS - technically, since it's supposed to be the CSS OID subtree, I think that the Authority should be CCSDS.CSS. Other OIDs that the Area needs to register should be done so under the css node, and those might not have anything to do with the CSTS WG (an in any case, since WGs are supposed to be "temporary", authority over the css node should be with the CSS Area anyway). Proposed resolution: (a) Get SANA to include the css and csts OIDs in this registry so that CSSA is given control over everything that appears under the css node; and (b) have the crossSupportResources (1.3.112.4.4.2), crossSupportFunctionalities (1.3.112.4.4.2.1), and agenciesFunctionalities (1.3.112.4.4.2.2) subnodes added to the OIDs that are registered under the css node.
2.     Under the modules subnode, 1.3.112.4.4.1.1.1, the CSS OID registry values start to go wrong with 1.3.112.4.4.1.1.1.3, which should be common-types but the SANA registry has as service-type. There are multiple other errors under the modules subnode dealing with missing, misnamed, and/or wrong OID values that I'm not going to identify individually. Proposed resolution: Get SANA to fix it.
3.     Under the framework subnode, 1.3.112.4.4.1.1, the CSS OID registry values start to go wrong with 1.3.112.4.4.1.1.2, which should be operations but the SANA registry has as a totally bizarre attributes node, with scname, antenna, and tsprofile subnodes. Proposed resolution: Get rid of the attributes subtree and assign 1.3.112.4.4.1.1.2 to the operations subtree.
4.     Even once the operations node is correctly given the correct 1.3.112.4.4.1.1.2 OID , what's under it is screwed up from the very beginning. 1.3.112.4.4.1.1.2.1  should be bindInvocation, but the first label under the operations node in the CSS OID registry is given as execDirectiveInvocation. There are numerous other mistakes. Proposed resolution: Get SANA to fix it.
At this point, I've given up trying to unearth all of the problems with the CSS OID registry as currently published. I don't know where the problem lies here - does SANA not have the latest OID assignments as made in the SFW, or do they have the information and are just ignoring it?
Finally, although this is not strictly an issue for the OIDs under the css node, this is a concern for CSSA and CSTSWG anyway. One used to be able to see the complete CCSDS OID tree (i.e., the ccsds node (1.3.112.4)  and everything underneath it. I can no longer find that larger OID tree on the SANA website. Why this is a concern for CSSA/CSTSWG is that as far as SANA is concerned the space-link-extension node (1.3.112.4.3) is no longer reserved for SLE services. [The allocation of the space-link-extension node as 1.3.112.4.3 - that is, directly under the ccsds node - predates the existence of the current "Area" structure of CCSDS, and to my understanding SLE was the first set of CCSDS standards to use ISO OIDs, so they got put directly under ccsds.] We need to ensure that SANA can't "give away" 1.3.112.4.3 to some other group. Proposed resolution: Either (a) get SANA to make the full CCSDS OID tree visible on the SANA site, and make sure that 1.3.112.4.3 is already allocated as space-link-extension, or (b) create a Space Link Extension OID registry with CSSA as the controlling authority.
Best regards,
John

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<mailto:dpo at esa.int>).

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<mailto:dpo at esa.int>).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/css-csts/attachments/20210512/eb47e60b/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 25359 bytes
Desc: image001.jpg
URL: <http://mailman.ccsds.org/pipermail/css-csts/attachments/20210512/eb47e60b/attachment-0001.jpg>