[Smwg] terminology "respecified" versus "dynamically assigned"

Wed Sep 26 19:40:12 UTC 2018

Hi, everyone.
Just to throw in my $.02: I did indeed use "respecified parameter" because it was the SN terminology for the equivalent concept (i.e., what to call the modification of a config profile parameter value in the context of a Service Request, as opposed to a "reconfiguration", which is the SN term for a parameter value modification during the execution of the "Event" (SN-ese for Service Package)). I deliberately picked it in an attempt to narrow the understanding gap with SN personnel when it looked like SGSS was going to adopt CCSDS SM. However, I have no problem with "ModifiedParameter".

Regarding "nickname": at the risk of being pedantic, the frNickname is a user-supplied string name for the Functional Resource instance, and can substitute for the {FR Name (an OID) : FR Instance Number (an integer)} pair that names that FR instance. E.g.,  a Mission with two instances of Forward Space Link Carrier Transmission FR (OID = .1 .3 .112 .4 .4 .2 .1 .2) with FRINs 1 & 2 has the FR Names
{ .1 .3 .112 .4 .4 .2 .1 .2 : 1} and { .1 .3 .112 .4 .4 .2 .1 .2 : 2} for these instances, but can supply the frNicknames "X-Band transmitter" for FR instance { .1 .3 .112 .4 .4 .2 .1 .2 : 1} and " S-Band transmitter" for FR instance { .1 .3 .112 .4 .4 .2 .1 .2 : 2}, and these nicknames can be used in place of the {OID:FRIN} "names" in SM information entities (Note that they are only used in SM info entities - CSTSes must use the {OID:FRIN} form).

Individual parameters don't get nicknames, but they do have classifiers. Classifiers are the text string labels/tags that are associated with OBJECT IDENTIFIERS in the SANA Registry (and in the ASN.1 modules that declare those OIDs). E.g., the SANA Registry has a fwd401CarrierTransmissionProductionStatus parameter that is assigned the OID .1.3.112.4.4.2.1.2.1.1.1. - fwd401CarrierTransmissionProductionStatus is the classifier for the parameter that is formally  identified by the OID .1.3.112.4.4.2.1.2.1.1.1.

Unlike frNicknames, classifiers are specified in and controlled through the SANA Registry - Missions have no ability to modify classifiers. But for user-friendliness, SM info entities substitute the classifiers for the OIDs that they represent (again this is only true for SM info entities; CSTS PDUs must use the OIDs).

So whereas in an SM info entity the fwd401CarrierTransmissionProductionStatus parameter of the X-Band transmitter can be referred to by the pair of text strings "X-Band transmitter", "fwd401CarrierTransmissionProductionStatus",
that same parameter must be addressed in CSTS PDUs as
{{ .1 .3 .112 .4 .4 .2 .1 .2 : 1 } : .1.3.112.4.4.2.1.2.1.1.1}.
   \_____________  ________/  \  /   \______  ______________/
                 \/            \/           \/
            FR Type OID      FRIN       Parameter OID

Hope this helps more than confuses.

John

From: SMWG [mailto:smwg-bounces at mailman.ccsds.org] On Behalf Of Barkley, Erik J (3970)
Sent: Friday, September 21, 2018 4:02 PM
To: Eddy, Wesley M. (GRC-LCN0)[MTI SYSTEMS, INC.] <wesley.m.eddy at nasa.gov>; CCSDS Service Mgmt WG <smwg at mailman.ccsds.org>
Subject: Re: [Smwg] terminology "respecified" versus "dynamically assigned"

Hi Wes,  that works for me.

-Erik

From: SMWG <smwg-bounces at mailman.ccsds.org<mailto:smwg-bounces at mailman.ccsds.org>> On Behalf Of Eddy, Wesley M. (GRC-LCN0)[MTI SYSTEMS, INC.]
Sent: Friday, September 21, 2018 12:52
To: Barkley, Erik J (3970) <Erik.J.Barkley at jpl.nasa.gov<mailto:Erik.J.Barkley at jpl.nasa.gov>>; CCSDS Service Mgmt WG <smwg at mailman.ccsds.org<mailto:smwg at mailman.ccsds.org>>
Subject: Re: [Smwg] terminology "respecified" versus "dynamically assigned"

Thanks Erik, that makes sense to me.  Would "ModifiedParameter" be an agreeable thing to call these in the UML and schema?

From: Barkley, Erik J (3970) <Erik.J.Barkley at jpl.nasa.gov<mailto:Erik.J.Barkley at jpl.nasa.gov>>
Sent: Friday, September 21, 2018 3:05 PM
To: Eddy, Wesley M. (GRC-LCN0)[MTI SYSTEMS, INC.] <wesley.m.eddy at nasa.gov<mailto:wesley.m.eddy at nasa.gov>>; CCSDS Service Mgmt WG <smwg at mailman.ccsds.org<mailto:smwg at mailman.ccsds.org>>
Subject: RE: terminology "respecified" versus "dynamically assigned"

Hi Wes,

Related to terminology - I just want to note that the OIDs are still in the picture - rather that we are looking at using the "common" name (I believe John has labeled this the "nickname" in the FRM).  I agree that it's not the 1.2.3.4.5.7.etc numbering being used, but technically, the object is being identified.

Okay, onto the main event :-) I think both dynamically assigned and re-specification etc. smack a little too much of computer science. From a software engineering perspective of course these are just fine terms. But I think the use case here is that these are configuration parameters for this specific service package instance. So my thinking would be to go along the lines of something like "modified configuration parameters" -- I think that gets a little closer to the day-to-day usage envisioned.

Best regards,
-Erik

From: SMWG <smwg-bounces at mailman.ccsds.org<mailto:smwg-bounces at mailman.ccsds.org>> On Behalf Of Eddy, Wesley M. (GRC-LCN0)[MTI SYSTEMS, INC.]
Sent: Thursday, September 20, 2018 12:17
To: CCSDS Service Mgmt WG <smwg at mailman.ccsds.org<mailto:smwg at mailman.ccsds.org>>
Subject: [Smwg] terminology "respecified" versus "dynamically assigned"

Hello, in the course of moving away from using OIDs to indicate the respecified parameter values in the Service Package, there are a couple different alternative terms that people suggested that would replace the "OIDParameter" in the service package class description and schema.

Initially, John suggested "RespecificationParameter".  This sounds good to me.  It's what I've currently used in the latest draft of the book and XML schema description.

However, I found some meeting notes I'd jotted down that indicate someone had also suggested "dynamically assigned" as the terminology we could use.  I didn't capture the rationale, but I believe it might have been because the terminology of respecifiable parameters is rooted in the legacy SN messaging, so we wanted to distinguish the new standard from that, while having equivalent functionality.

Are there other books (e.g. on the service profile or agreement) where we're already using one or the other of these terms, so that we can make sure this is consistent?

Should I change to:
"DynamicallyAssignedParameter"
versus
"RespecificationParameter"
?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20180926/409647e5/attachment.html>