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

[Stoloff, Michael J (393D)]

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] 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
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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/css-csts/attachments/20140117/0aa0672a/attachment.html