[SIS-CFDPV1] final (I hope) test plan document

[Burleigh, Scott C (US 312B)]

Yup, the more changes we make to the spec, the more we need to test.  Happily, I believe we’re done now.

On (1), yes, if we were starting from scratch I would definitely reorganize along the lines you propose.  But since we have already got interoperability test results that reference the original test plan organization, I would rather leave it as is.  Reorganizing would take some work and I don’t think it would make anything clearer to the reader.

On (2), good point, I’ll be sure to make a note of the checksum algorithm that was used for those tests.  I don’t think we need to mandate any specific algorithm for these tests, since it doesn’t bear on the behavior we’re testing, but the checksum algorithm does have to be something that both the sender and receiver support.

On (3), as I was reading the test plan I wondered if ‘1011’ might be misunderstood by somebody who hadn’t read the specification quite closely.  Written this way, it would be easy to think that the condition code was one thousand eleven (decimal, the default when there’s no notational cue) rather than binary 1011 (decimal 11).  Since the code of any implementation is going to test for the integer value 11, I think that’s the least ambiguous way to document the test.  I changed condition code 0100 to 4 in one of the earlier tests for the same reason.

Scott

From: 구철회 <chkoo at kari.re.kr>
Sent: Wednesday, March 4, 2020 4:42 PM
To: Burleigh, Scott C (US 312B) <scott.c.burleigh at jpl.nasa.gov>
Cc: sis-cfdpv1 at mailman.ccsds.org
Subject: [EXTERNAL] RE: final (I hope) test plan document

Hi, Scott.

It seems the Test Plan document is getting complex as the CFDP specification is getting revised.
Please find my comments as follow:
 1) as the CFDP specification is revised, especially checksum handling perspective, now 3.1 (checksum types) can be merged with 3.6 (mandatory checksum algorithms) because these section are mentioning the validation of checksum algorithm implementations. My suggestion is to remove 3.1, and to add CRC test case in 3.6.
2) as now CFDP specification allows checksum type selection when a transaction starts rather than getting one from MIB, 3.2 (closure requests) has to define a default checksum type, e.g. modular, for conducting following test cases.
3) the condition code for 3.7.2 shall be ‘1011’ rather than ‘11’

That’s all what I got here now after a very short review. I will get back to here when I get more.

Best,

Cheol


From: SIS-CFDPV1 <sis-cfdpv1-bounces at mailman.ccsds.org<mailto:sis-cfdpv1-bounces at mailman.ccsds.org>> On Behalf Of Burleigh, Scott C (US 312B) via SIS-CFDPV1
Sent: Thursday, March 5, 2020 7:58 AM
To: sis-cfdpv1 at mailman.ccsds.org<mailto:sis-cfdpv1 at mailman.ccsds.org>
Subject: [SIS-CFDPV1] final (I hope) test plan document

Hi.  I just now posted to CWE a new Test Plan document for the CFDP Revisions that I believe is final.  Over the next couple of days I will be plugging interoperability testing results into that Plan to turn it into a Report, which I hope to send to Tom Gannett very soon.

Scott
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sis-cfdpv1/attachments/20200305/2fa0cc44/attachment-0001.htm>