Default Security Contexts for Bundle Protocol Security (BPSec)
draft-ietf-dtn-bpsec-default-sc-11

Thank you for addressing my comments.

Thanks for the new Section 5.4.  I would suggest not referring to the DTN working group as a review body, as it might not exist forever.  The guidance you publish here should still be valid even after the working group closes.

My original comments, for posterity:

I support Francesca's first DISCUSS point.

Since the shepherd writeup was written earlier this year, six revisions have been posted, the IESG has rotated (so the responsible AD in the writeup has changed), two authors have been added, two new registries were proposed (the writeup claims there are none), and a considerable amount of text has been added or changed.  The current writeup thus feels markedly stale; I suggest that in such situations, the shepherd should consider updating the writeup so that it appears to be more current when it gets to the IESG.

Appendix B could be simplified a bit:

   Amy Alford of the Johns Hopkins University
   Applied Physics Laboratory contributed useful review and analysis of
   these security contexts.

Thank you to Christian Huitema for the SECDIR review.

I support the DISCUSS positions of Martin Duke, Francesca Palombini and Benjamin Kaduk whose substantive positions have already noted what would have been my feedback.

** Section 4.5.  Per “The total number of bytes processed with a single key for AES-GCM is recommended to be less than 2^64, as described in Appendix B of [AES-GCM].”  It would also be worth nothing that in additional to the number of process bytes, that there is a limit of 2^32 of invocations with the same key per Section 8.3 of [AES-GCM].

Thank you for the work put into this document. 

Special thanks for the doc shepherd write-up about the WG process / consensus. Please note that I did not review the CBOR-encoded examples.

Please find below some non-blocking COMMENT points (but replies would be appreciated).

I hope that this helps to improve the document,

Regards,

-éric

Is the document limited to SHA-2 and AES-GCM ? How can it be extended to other crypto algorithms ?

-- Section 3.3.1 --
Why is the CBOR encoding specified here ? The text says nothing about serialization or message format, so, I do not understand why CBOR encoding is required.

-- Sections 3.3.3 and 4.3.4 ---
Same comment as above but if there is transmission, what is the difference between the reserved and the unassigned bits ? How should they be transmitted ? How should they be processed by any receiver ?

-- Sections 3.3.4 and 4.3.5 --
Why putting the "0x" prefix in  "0x7" but not for "6" in table 2 ?

Thanks for addressing my DISCUSS and COMMENTs.