[Css-csts] RE: DPP Prototype ASN.1 definitions

[John Pietras]

Hello, Michael! Nice to hear from you.

Let me start by saying that the opinions that I am about to state are just my own and do not represent any position of the CSTSWG.

The "is 'user' the best term?" question pops up from time to time, triggered by concerns similar to yours. I don't have an objection to replacing "user" with a different term if such a term can be found that is obviously a better fit. However, I don't think I've come across any term that is obviously better. And to my knowledge there hasn't been any concern expressed within the CSTSWG about this, so I think that the WG is happy to continue using "user".

The use of "customer" has a precedent - the Space Network refers to its user as "customer" (to me, at least, "customer" carries a connotation of purchasing something, but obviously that's not the case for you or the Space Network).

I've seen other architectures where the peer of the Provider is called the Consumer. In the context of Cross Support services "consumer" is already defined in the Cross Support Reference Model , Part 1: SLE Services (also known as the SLE Reference Model) as a port that ingests the primary type of data carried by the port (the peer role is "supplier", which outputs that data). Although these designations were defined in the CSRM they have never actually been used in any f the SLE specs and are not used in the CSTS Framework, so we could repurpose the term if it would be deemed useful to do so.

I've also heard "client" used as the peer to provider. Back when we were starting SLE, the peer to the client role was "server", but I think the connotation of "client" has been generalized a bit over the intervening two decades (yikes!) so I think this might be a viable alternative if we were to decide that "user" is unacceptable.

For myself, I don't think that "user" is such a bad term. I agree that it is used in the contexts that you mention, but it also appears in "user spacecraft", "user mission" and "user MOC". There are all kinds of users in a space enterprise - as long as the context (in this case, CSTS user) is understood I think it's fine.

Best regards,
John

From: Stoloff, Michael J (393D) [mailto:michael.j.stoloff at jpl.nasa.gov]
Sent: Thursday, January 16, 2014 8:41 PM
To: John Pietras; Zoller, David A. (MSFC-EO50)[HOSC SERVICES CONTRACT]
Cc: css-csts at mailman.ccsds.org
Subject: RE: DPP Prototype ASN.1 definitions

John,

I concur with your retelling of the background and rationale regarding the two role pairs (performer/invoker, user/provider).  I also recall the CCSDS Green Book in which those terms (and others) were considered at length.

Nonetheless, for purposes of the CSTS Framework, I wonder if CCSDS would consider a slight revision, as follows:  It has been pointed out to me, on more than one occasion, that the term "user" is commonly heard only in connection with computers and drug addicts.  Perhaps in the CSTS books, it should be better to refer to that role pair as "Customer/Provider".  As a Service Provider, I find it natural to refer to those I serve as customers, whereas I always hesitate before writing "user".

--Best regards,
  Michael

From: css-csts-bounces at mailman.ccsds.org<mailto:css-csts-bounces at mailman.ccsds.org> [mailto:css-csts-bounces at mailman.ccsds.org] On Behalf Of John Pietras
Sent: Thursday, January 16, 2014 12:58 PM
To: Zoller, David A. (MSFC-EO50)[HOSC SERVICES CONTRACT]
Cc: css-csts at mailman.ccsds.org<mailto:css-csts at mailman.ccsds.org>
Subject: [Css-csts] RE: DPP Prototype ASN.1 definitions

David,
I'll let others in the WG respond to your other questions, but regarding the first one (Performer/Invoker vs. User/Provider), the role pairs are not synonymous. The Invoker is the entity that invokes (kicks off) the operation. The service User is the invoker for the BIND, UNBIND, START, STOP, PROCESS-DATA, GET, and EXECUTE-DIRECTIVE operations, but the Provider is the invoker of the TRANSFER-DATA, and NOTIFY operations (see table 2-1 of the CSTS SFW). You may asking why we don't just use one set of roles (e.g., User/Provider) and abandon the other (e.g., Invoker/Performer). There were two initial reasons for using the two sets of role terminology. First, the terminology used to describe Space Link Extension (SLE - the conceptual forerunner of CSTS) established the Invoker/Performer roles as the ones associated with the operations themselves,  whereas the User/Provider roles were characteristics of the entities that perform those roles. Since the ASN.1 is really defining the interfaces to the operations, the Invoker/Performer designations are most appropriate there. Second, the SLE Return service specifications formally allow either the User or Provider to initiate the service instance (that is, either the User or Provider can invoke the BIND operation), so (technically) for SLE return you can't always assume User = BIND invoker (although no SLE implementation currently supports Provider-initiated return SLE services). Even though provider initiation was dropped from CSTS, the separate role distinction still exists in the CSTS "DNA".

Hope this makes at least a little sense.

Best regards,
John

From: css-csts-bounces at mailman.ccsds.org<mailto:css-csts-bounces at mailman.ccsds.org> [mailto:css-csts-bounces at mailman.ccsds.org] On Behalf Of Zoller, David A. (MSFC-EO50)[HOSC SERVICES CONTRACT]
Sent: Thursday, January 16, 2014 3:27 PM
To: css-csts at mailman.ccsds.org<mailto:css-csts at mailman.ccsds.org>
Subject: [Css-csts] DPP Prototype ASN.1 definitions

Dear CSTS WG Members,
I have been updating the DPP Provider prototype with the latest ASN.1 definitions that I could find which I pulled from the document: 921x1r2[Draft_201310]_-_All_Services.docx. Please find below some comments on the ASN.1 definitions.


·         The ASN.1 uses Performer/Invoker while the document uses Provider/User

o   Is there a preferred terminology?

o   I am okay with using both as is ;-)



·         BIND and UNBIND invocations use a parameter name of invocationHeader while all of the other messages use standardInvocationHeader

o   I think it would be better if they were all consistent



·         StandardInvocationHeader.procedureInstanceId.procedureType usage

o   I wish to instantiate the appropriate performer type based on the invoker's specified ProcedureType

§  bufferedDataProcessing and sequenceControlledDataProcessing types are defined

§  It would be useful to be able to specify bufferedDataProcessingComplete and bufferedDataProcessingTimely types

o   Or will there be individual START formats for each of the types that I should key on?

o   Should these be part of the Framework baseline ASN.1 or would these be extensions for the prototype?



·         There were a few errors and warnings while processing the ASN.1

o   These have probably been corrected since the draft in October but let me know if anyone needs details



·         TransferBuffer with ProcessDataInvocations is not incorporated into the CstsFrameworkPdu structure yet

o   I am making use of the TransferBufferInvocation with TransferDataNotifications until the other is available

I recognize that this is a work in progress and I probably do not have the latest and greatest version. I am willing to help validate the DPP end of things as best I can if so desired.

Best regards,
David

David Zoller
COLSA Corporation
MSFC/HOSC - C107
*Office: (256) 544-1820
*EMail: david.a.zoller at nasa.gov<mailto:david.a.zoller at nasa.gov>

________________________________

Spam<https://filter.gst.com/canit/b.php?i=01LeIymz7&m=2e71a5e026e0&c=s>
Not spam<https://filter.gst.com/canit/b.php?i=01LeIymz7&m=2e71a5e026e0&c=n>
Forget previous vote<https://filter.gst.com/canit/b.php?i=01LeIymz7&m=2e71a5e026e0&c=f>
________________________________

Spam<https://filter.gst.com/canit/b.php?i=01LeNJO2k&m=b8ac29854558&c=s>
Not spam<https://filter.gst.com/canit/b.php?i=01LeNJO2k&m=b8ac29854558&c=n>
Forget previous vote<https://filter.gst.com/canit/b.php?i=01LeNJO2k&m=b8ac29854558&c=f>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/css-csts/attachments/20140117/f86fe158/attachment.html