Subject: [Gen-art] Genart last call review of draft-ietf-dtn-bpsec-default-sc-07

From: Thomas Fossati via Datatracker <[email-masked]>
Date: Tue, 25 May 2021 03:13:35 -0700

Reviewer: Thomas Fossati
Review result: Ready with Nits

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-dtn-bpsec-default-sc-??
Reviewer: Thomas Fossati
Review Date: 2021-05-25
IETF LC End Date: 2021-06-01
IESG Telechat date: Not scheduled for a telechat

Summary:

This document defines two default security contexts (clear-text integrity and
authenticated encryption) for the BPSec protocol.  The raison d'être of this
specification is to provide basic security services for interop testing and
operational use on the terrestrial Internet.

This is a very well written document.  I have checked the CBOR examples and
they look good (as noted in the Nits section below, the use of CBOR Sequences
might be more explicitly indicated.)  The requests to IANA are clear and
actionable.

(Just a note: in my experience as an implementer -- albeit not of this
particular security protocol -- I have found that relying on canonicalisation
tends to make interop an arcane job.  I trust the DTN people have weighed their
pro and cons and made this choice consciously.)

Major issues: None

Minor issues: None

Nits/editorial comments:

* The references to Table 7 of RFC8152 might be replaced by references to Table
3. of draft-ietf-cose-rfc8152bis-algs (now in RFC-Ed queue) * The references to
Table 9 of RFC8152 might be replaced by references to Table 5. of
draft-ietf-cose-rfc8152bis-algs * In Section 5.1, the name of the registry
should be "BPSec Security Context Identifiers" (plural "Identifiers") * Since
the document examples make use of CBOR Sequences, it'd be worth stating that in
the relevant places (e.g., A.1.3.2) -- and maybe sticking a reference to
RFC8742.