[cssm] [EXTERNAL] CSSM: Service Agreement Parameters - Update of the presentation from Fall Meetings 2023

Fri Jan 19 05:39:45 UTC 2024

Dear Peter,

Okay, so we have been warned that your desk is “loaded” 😊.    More seriously, although the inputs are good, I think we (the CSSM WG) are still a good ways away from coming near the territory of service agreements for all of space exploration – e.g. I think there would have to be a lot of discussion first as to what DTN network management needs to have by way of peering arrangements, etc.  For now, we (CSSM WG) are just trying to gather a preliminary list of likely service agreement parameters for E2S link management.   I think we can be mindful and can agree in principle with, as you say to us, “to discuss this at more length when you are ready.”

On a side note we could also consider, perhaps somewhat more seriously, adoption for (additional) FRMs in SOIS, SIS, etc.   This could also have a bearing on capturing service agreement parameters in other domains that you note.

Best regards,
-Erik

From: SMWG <smwg-bounces at mailman.ccsds.org> On Behalf Of Shames, Peter M (US 312B) via SMWG
Sent: Thursday, January 18, 2024 9:45
To: Marcin.Gnat at dlr.de; smwg at mailman.ccsds.org
Subject: Re: [cssm] [EXTERNAL] CSSM: Service Agreement Parameters - Update of the presentation from Fall Meetings 2023

Hi Marcin, et al,

It’s great that you guys have started to develop this Service Agreement framework.  I think it should be of a lot of use and that what you have produced is a good start.

That said, I have a few comments and observations that will undoubtedly come up when this standard crosses my desk as part of a CESG review.  So I thought I’d toss them out now, for your consideration.

Comments

  1.  This draft makes mention of a variety of objects for which we have existing (if somewhat incompletely filled out) SANA registries, but there is no mention of SANA anywhere.  I believe that all of the following should be referenced, and that the standard should clarify how these are to be used, extended if needed, or substituted only where it is essential to do so.
     *   https://sanaregistry.org/r/organizations/<https://urldefense.us/v3/__https:/sanaregistry.org/r/organizations/__;!!PvBDto6Hs4WbVuu7!J54qJVQ6uOSMg6cM_6oPzeBd9gHFGlqv3g5u8EqaMKUW21CdwumYrMxJJlVatZVHoO1AW2gubjpTTuSQ54bCjLZRwQ$>
     *   https://sanaregistry.org/r/contacts/<https://urldefense.us/v3/__https:/sanaregistry.org/r/contacts/__;!!PvBDto6Hs4WbVuu7!J54qJVQ6uOSMg6cM_6oPzeBd9gHFGlqv3g5u8EqaMKUW21CdwumYrMxJJlVatZVHoO1AW2gubjpTTuSQ54aKUFABXA$>
     *   https://sanaregistry.org/r/service_management_entity_types/<https://urldefense.us/v3/__https:/sanaregistry.org/r/service_management_entity_types/__;!!PvBDto6Hs4WbVuu7!J54qJVQ6uOSMg6cM_6oPzeBd9gHFGlqv3g5u8EqaMKUW21CdwumYrMxJJlVatZVHoO1AW2gubjpTTuSQ54bePBw39g$>
     *   https://sanaregistry.org/r/service_sites_apertures/<https://urldefense.us/v3/__https:/sanaregistry.org/r/service_sites_apertures/__;!!PvBDto6Hs4WbVuu7!J54qJVQ6uOSMg6cM_6oPzeBd9gHFGlqv3g5u8EqaMKUW21CdwumYrMxJJlVatZVHoO1AW2gubjpTTuSQ54YyS0VoOA$>
     *   https://sanaregistry.org/r/spacecraft/<https://urldefense.us/v3/__https:/sanaregistry.org/r/spacecraft/__;!!PvBDto6Hs4WbVuu7!J54qJVQ6uOSMg6cM_6oPzeBd9gHFGlqv3g5u8EqaMKUW21CdwumYrMxJJlVatZVHoO1AW2gubjpTTuSQ54aEYDzClg$>
     *   https://sanaregistry.org/r/spacecraftid/<https://urldefense.us/v3/__https:/sanaregistry.org/r/spacecraftid/__;!!PvBDto6Hs4WbVuu7!J54qJVQ6uOSMg6cM_6oPzeBd9gHFGlqv3g5u8EqaMKUW21CdwumYrMxJJlVatZVHoO1AW2gubjpTTuSQ54au9Neskg$>

  1.  This seems to be exclusively focused on “standard” Earth to S/C services, but we are already in an era where there are existing “space based services”, like the Mars orbiting missions, and the Lunar mission set, with “standardized” relay operations, is already in development.  Is there a plan for addressing these other classes of missions?
  2.  Is there a plan to build in extensibility for new service types as these are developed?  This might include, for instance, Lunar PNT services, DTN services, and DTN to IP “protocol bridging”.

I’d be happy to discuss this at more length when you are ready.

Thanks, Peter

From: SMWG <smwg-bounces at mailman.ccsds.org<mailto:smwg-bounces at mailman.ccsds.org>> on behalf of SMWG <smwg at mailman.ccsds.org<mailto:smwg at mailman.ccsds.org>>
Reply-To: "Marcin.Gnat at dlr.de<mailto:Marcin.Gnat at dlr.de>" <Marcin.Gnat at dlr.de<mailto:Marcin.Gnat at dlr.de>>
Date: Thursday, January 18, 2024 at 12:49 AM
To: SMWG <smwg at mailman.ccsds.org<mailto:smwg at mailman.ccsds.org>>
Subject: [EXTERNAL] [cssm] CSSM: Service Agreement Parameters - Update of the presentation from Fall Meetings 2023

Dear all,

I had a small task to update the collection of the Service Agreement parameters, which I presented during Fall Meetings 2023. During this presentation we had a discussion and number of comments/changes, which now I implemented. As you can see I still have there two or so “TBCs”. Except that I think it looks good for the first schema version for SA File type. I will try to set it up until our next teleconference, but not promising it….;-)

Cheers
Marcin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20240119/4b096bc0/attachment-0001.htm>