Re: [dtn] Francesca Palombini's Discuss on draft-ietf-dtn-bpsec-default-sc-08: (with DISCUSS and COMMENT)

[Francesca Palombini <[e-mail]>]

Hi Ed! Thanks for the answer.

The update looks good, I will go ahead and remove my discuss, thank you for addressing all my comments!

I still think it would be worth to add the CDDL to the document, and Brian has provided some to the list: https://mailarchive.ietf.org/arch/msg/dtn/JGlZ7qaHxgwhdGyDfr5YiMuu1AU/ . I agree with him, that there is value to it, and at least it would have allowed readers to verify that the understanding of the text is correct, and that the examples match. However, I am not blocking the draft because of it, and I'll leave it up to the working group and responsible AD to decide.

Thanks,
Francesca

On 13/07/2021, 05:17, "Birrane, Edward J." <[e-mail]> wrote:

    Francesca,

      Thank you for spotting those two items related to your discusses D3 and D5.

      I agree with both comments and have published a -10 version of the document which I believe addresses these DISCUSSes.  

      Please see my comments below, and let me know if there are any remaining concerns.

    -Ed

    ---
    Edward J. Birrane, III, Ph.D. (he/him/his)
    Embedded Applications Group Supervisor
    Space Exploration Sector
    Johns Hopkins Applied Physics Laboratory
    (W) 443-778-7423 / (F) 443-228-3839


    > Hi Ed,
    > 
    > Thank you for your answers, and for implementing the changes. I have gone
    > through v-09 and I have some additional comments. I still have 2 blocking
    > points open: D3 and D5. Everything else looks good, or was minor so that I
    > don't mind the "no change".


    > >> 3. -----
    > >>
    > >>       - Bits 8-15 are unassigned.
    > >>
    > >> FP: I am wondering why the limit on Bit 15, marked as unassigned: I
    > >> think it would make sense to say Bits 8 and higher are unassigned.
    > >> (This change would need to be reflected in the IANA sections)
    > >
    > >D3: Recommend no change.
    > >
    > >To assist with hardware implementations, there is value in allowing
    > implementers to presume an upper-bound to the size of this field.
    > >
    > 
    > FP: I would agree, if such an upper-bound was specified. However this
    > section does not specify any such upper bound, and CBOR integers are not
    > implicitly limited to a certain size either. I see two options here: either 1.
    > specify the upper bound (for example stating that the maximum value of the
    > field is 65535) or 2. remove the limitation to 15 bits, both in this section and in
    > the IANA section, and add a statement that "this field is not expected to
    > have a value higher than 65535". Both these options seem ok to me.

    EJB: I better understand this comment now.  To correct, for both the IPPT and AAD scope flags, I have noted this is to be considered a 16-bit field with a maximum value of 65535 in the -10 version of the document.

    > >> 5. -----
    > >>
    > >>      [1, b'Twelve121212'] / Initialization Vector /,
    > >>
    > >> FP: I think the IV value is wrong here and should be
    > >> h'5477656c7665313231323132'.
    > >
    > >D5: Agree.
    > >
    > >h'5477656c7665313231323132' should be used here for clarity. We can
    > represent this value in this way in an upcoming -09 version of the document.
    > >
    > 
    > FP: Thanks for making the change. However, I noticed that you also made
    > one more change (which I assume must come from another AD?): the scope
    > flag is now encoded as a byte string throughout the Appendix A. However, its
    > definition has not changed, and it is still defined as a CBOR integer in section
    > 3.3.3. That is inconsistent, unless I am missing something, and should either
    > revert back to integer or change to byte string in a number of places where
    > it's still defined as unsigned integer.

    EJB: This was an error in the Appendix. The examples all use the (correct) unsigned integer encoding of the scope flags to generate data, but the diagnostic notation was in error (h'00' instead of 00, and h'07' instead of 07).  I have corrected the notation in the appendix in the -10 version.  Great catch!