[Css-csts] topics for discussion in telecon

Ray, Timothy J. (GSFC-5830) timothy.j.ray at nasa.gov
Wed Aug 12 15:17:25 EDT 2009


Dear Yves,

Thanks for the quick response.  Your answers are very helpful.  I finally understand how the EmbeddedPDV will be used (and how extension-data is connected to the standard PDU structures).  This understanding is allowing me to make some good progress on a Framework implementation.

Thanks,
Tim



-----Original Message-----
From: Yves.Doat at esa.int [mailto:Yves.Doat at esa.int] 
Sent: Tuesday, August 11, 2009 3:54 AM
To: Ray, Timothy J. (GSFC-5830)
Cc: css-csts at mailman.ccsds.org; css-csts-bounces at mailman.ccsds.org
Subject: Re: [Css-csts] topics for discussion in telecon

Dear Tim,

Please find below some answers to your questions:

Where does our spec say that a Start is not allowed while Unbound?  (I don’t
see it in section 3.7 on the Start operation)
In the section "Binding", the requirement 4.3.3.1.2.1 states "Except as
provided in 4.3.3.1.2.3, the Service User shall not invoke any further
operations for this service instance until the return from the Service
Provider is received".
This requirement is supposed to cover that case as we did not want to repeat
for each Operation/Procedure a common behaviour.

Where does our spec say that the Transport Mapping Layer is used underneath
the Framework?  i.e. that a connection has to be established as part of a
Bind?  (I don’t see it in section 4.3 on “Association Control”).
The section 2.6.3 states "... The mapping of CSTS PDUs to an underlying
communications service is intentionally outside the scope of this Recommended
Standard.  In order to achieve interoperability, the Service User and Service
Provider must conform not only to the service specification based on this
Recommended Standard but also to an agreed upon specification of the mapping
of the service to the underlying communications service ...".
The document includes a reference to ISP.


Where does our spec say how to insert data into an Extended structure?
Annex D specifies:
D1.9 The extension capability may or may not be used using the Extended
parameter. If not used the Extended parameter shall carry a NULL value.
D1.10 Extension is defined by means of “EMBEDDED PDV”. The ASN.1 EMBEDDED PDV
type is a useful type used to include non-ASN.1 or other data within an ASN.1
encoded message. This type is described using the following ASN.1 SEQUENCE:
      EMBEDDED PDV ::= [UNIVERSAL 11] SEQUENCE
      {     identification CHOICE
            {     syntaxes SEQUENCE
                  {     abstract OBJECT IDENTIFIER,
                        transfer OBJECT IDENTIFIER
                  },
                  syntax                  OBJECT IDENTIFIER,
                  presentation-context-id       INTEGER,
                  context-negotiation     SEQUENCE
                        {     presentation-context-id       INTEGER,
                              transfer-syntax         OBJECT IDENTIFIER
                        },
                  transfer-syntax   OBJECT IDENTIFIER,
                  fixed             NULL
            },
            data-value OCTET STRING
      }


D1.12  The  nextension  shall make use of the “transfer-syntax” definition in
the   “identification”   CHOICE.   The   “transfer-syntax”   is  assigned  an
object-identifier (see C4.7) unique for all extensions that clearly indicates
that  all  external  syntaxes  carried by this definition belong to the Cross
Support Services


D1.13The  transfer  syntax  used  for the extension (see D1.11) shall be  the
transfer-syntaxes defined in C4.7.


Is anything in chapter 2 normative?
The chapter 2 ias descriptive only. Is there any requirement that should be
moved to section 3 or 4?

In section 4.2.1, do any of the subsections apply to the User side?  If so,
which ones?  (I realize that most of them do apply to both User and Provider,
but a new person might be confused ).   Can we be more clear?  For example,
4.2.1.3 gives the impression that this section applies to the Provider, but I
think our intention is that the whole section applies to both User and
Provider unless otherwise specified.
As for SLE the Recommendation is written toward the behaviour of the provider
and explain what the provider shall do depending on the user received
interactions. Every time a requirement refers to the reception of an
operation, it implies the operation is sent by the user. This approach worked
fine for the SLE Recommendations.
Would a statement such as "On reception of an UNBIND invocation from the
User, the Association Control procedure shall issue a ‘terminate’ event to
all procedure instances of the service instance" add clarity?

Best regards
Yves



                                                                             
             "Ray, Timothy J.                                                
             (GSFC-5830)"                                                    
             <timothy.j.ray at nas                                           To 
             a.gov>                     "css-csts at mailman.ccsds.org"         
             Sent by:                   <css-csts at mailman.ccsds.org>         
             css-csts-bounces at m                                           cc 
             ailman.ccsds.org                                                
                                                                     Subject 
                                        [Css-csts] topics for discussion in  
             11/08/2009 00:20           telecon                              
                                                                             
                                                                             
                                                                             
                                                                             
                                                                             
                                                                             




Dear Working Group,

General comment:  I could develop a User implementation based on the
knowledge gained from attending our meetings.  But that would not be a good
test of our specification.      Instead, I am trying to stick to the
specification as my only guide.
Here are some questions for discussion in tomorrow’s telecom:

      ·         Where does our spec say that a Start is not allowed while
      Unbound?  (I don’t see it in section 3.7 on the Start operation)
      ·         Where does our spec say that the Transport Mapping Layer is
      used underneath the Framework?  i.e. that a connection has to be
      established as part of a Bind?  (I don’t see it in section 4.3 on
      “Association Control”).
      ·         Where does our spec say how to insert data into an Extended
      structure?
      ·         Is anything in chapter 2 normative?
      ·         In section 4.2.1, do any of the subsections apply to the User
      side?  If so, which ones?  (I realize that most of them do apply to
      both User and Provider, but a new person might be confused ).   Can we
      be more clear?  For example, 4.2.1.3 gives the impression that this
      section applies to the Provider, but I think our intention is that the
      whole section applies to both User and Provider unless otherwise
      specified.
Best regards,
Tim

 _______________________________________________
Css-csts mailing list
Css-csts at mailman.ccsds.org
http://mailman.ccsds.org/cgi-bin/mailman/listinfo/css-csts


More information about the Css-csts mailing list