[Css-csts] Interim inter-operability test results

[Ray, Timothy J. (GSFC-5830)]

Dear Martin,

Yes, I see what you mean.  Unless someone has an objection, I'll simply delete that test from the test suite.

Best regards,
Tim

From: Martin Götzelmann [mailto:martin.goetzelmann at vega.de]
Sent: Wednesday, April 14, 2010 3:53 AM
To: Ray, Timothy J. (GSFC-5830)
Cc: Felix.Flentge at esa.int; Alexandra.Prilop at esa.int; css-csts at mailman.ccsds.org; Martin Karch; Christian Laroque
Subject: RE: [Css-csts] Interim inter-operability test results

Dear Tim,

It is good to hear that the interoperability tests are progressing well. Just one remark from my side concerning test 5.e.

In clause 3.4.2.5, NOTE 3  the Framework Specification says: "The responder-port-identifier parameter is included in the BIND invocation to support its possible use by particular kinds of gateways."

This has been adopted from the SLE specifications and in my understanding means that a provider is not supposed to verify that user has called the correct address - this information might however be required if the request were routed through a gateway or other intermediary such as a security device in order to route the request to the provider the user wanted to reach. In that case the gateway would have to report an unknown responder port to the user with the indicated diagnostic.

Because of this, the provider side prototype does not check this parameter - the ESA SLE API implementation does not check that parameter either.

Kind Regards, Martin

________________________________
From: css-csts-bounces at mailman.ccsds.org [mailto:css-csts-bounces at mailman.ccsds.org] On Behalf Of Ray, Timothy J. (GSFC-5830)
Sent: 13 April 2010 23:28
To: css-csts at mailman.ccsds.org
Cc: Felix.Flentge at esa.int; Alexandra.Prilop at esa.int
Subject: [Css-csts] Interim inter-operability test results
Dear WG members,

An inter-operability test was performed today (using the ESA Provider prototype and NASA User prototype).  This is *not* the final test.  In fact, for this test, there was no ESA representative.  ESA simply left the Provider prototype running, I ran the NASA prototype, performed the tests that I could, and noted the results.   Overall, a pretty successful test.  For example, the User and Provider successfully ran multiple concurrent Buffered-Ascii-Data-Delivery procedures.  Details...

The following tests were not performed:

*         Tests 2 and 3 - ESA side needs to be configured to use authentication.

*         Tests 7.g through 7.k - couldn't be performed due to a failure in test 7.f.

*         Test 10.C2 - ESA person needs to be involved in order to initiate a peer-abort at the Provider side.

*         Test 10.D3 - I couldn't get the desired test condition to occur (to have two invocations, with the same invoke-id, pending at the same time).  The response to the first Start-Invocation was received before the User could issue a second Start-Invocation.  Perhaps we should remove this test, or find some way (on the Provider side) to keep the first Start-Invocation pending long enough for the "duplicate invoke-id" situation to occur.  Plus, consider this: the action specified in our test plan is apparently not compliant with our specification!  That is, a duplicate invoke-id shall trigger a negative result (not a peer-abort!).  My mistake (but no one else caught it).  I suggest removing this test.

The following test could not be fully validated:

*         Test 10.A2 - ESA personnel are needed in order to verify that the peer-abort issued by the User is received by the Provider.  However, the socket went away as it should, and a re-bind was successful.


With the following exceptions, all the other tests were passed:

*         Test 5.e - the Provider accepted a Bind-Invocation with an invalid responder-port-identifier.

*         Test 7.f - The Provider implementation sent a Notify-Invocation (that was surely meant to indicate data-discarded-due-to-excessive-backlog), but decoding of the PDU failed on the User side.  File attached to this email shows details (See 'decode_error.txt').  Basically, it appears that the field 'ccsdsFormatMilliseconds' has a length of zero (invalid length).

A copy of the test plan is attached (in case that is helpful).

Best regards,
Tim

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/css-csts/attachments/20100414/98f6f150/attachment.htm