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

[구철회]

(2), Yes, that note would clarify a condition that supportable checksum types on both entities shall be selected from a sending entity.
(3), Good catch! And I am personally thinking; From CFDP implementers, ‘1001’ notation can be read easily as binary type as CFDP specification writes all values in field and condition codes as like this.
    It would be clear to read the Test Plan document if 1011b or 11_10(subscript) are used. I would go with ‘1011’ or 1011b as the CFDP specification document writes.

Cheol

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

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<mailto: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<mailto:scott.c.burleigh at jpl.nasa.gov>>
Cc: sis-cfdpv1 at mailman.ccsds.org<mailto: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/4946de8e/attachment.htm>