Subject: [dtn] Murray Kucherawy's Discuss on draft-ietf-dtn-bpsec-default-sc-08: (with DISCUSS and COMMENT)

From: Murray Kucherawy via Datatracker <[email-masked]>
Date: Thu, 01 Jul 2021 00:53:26 -0700

Murray Kucherawy has entered the following ballot position for
draft-ietf-dtn-bpsec-default-sc-08: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dtn-bpsec-default-sc/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Sections 5.2 and 5.3 declare new IANA registries with Specification Required
policies.  BCP 26 (RFC 8126) says of such registries that "clear guidance to
the designated expert should be provided when defining the registry", but none
is provided here.  While that's obviously not a MUST, I would like to have a
short discussion about why no such guidance is appropriate (or get some crafted
and added).

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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.

---

From: "Birrane, Edward J." <[email-masked]>
Date: Sun, 4 Jul 2021 15:17:12 +0000

Murray,

  Thank you for your review and comments on the -08 draft.

  I have enumerated the DISCUSSes as D# and the COMMENTS as C# below to aid in reference.

  If the DISCUSS and COMMENTs are dispositioned as proposed below in a forthcoming -09, would these address your concerns regarding this document?

-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

> policies.  BCP 26 (RFC 8126) says of such registries that "clear guidance to the
> designated expert should be provided when defining the registry", but none
> short discussion about why no such guidance is appropriate (or get some
> crafted and added).

D1: Agreed and excellent catch. Update in a -09.

RFC8126 provides a pointer to Section 5.1 of rfc7752 as an exemplar for guidance, and I can draft a similar section in a -09 version of this document.

C1: Recommend no change

The WG does agree that having security contexts that are extensible is a value, and there is another security context specification in the DTNWG for that purpose. However, the default security contexts are, by design, 1-1 (security context to algorithm) to simplify implementations and establish a baseline for implementation. 

> 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.

C2: Recommend no change

Agree to the comment, but do not see a change to the specification itself. We will ask the document shepherd to update the writeup.

>    Applied Physics Laboratory contributed useful review and analysis of

C3: Agreed. Update in a -09.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 7 Jul 2021 20:34:51 -0700

On Sun, Jul 4, 2021 at 8:17 AM Birrane, Edward J. <[email-masked]>
wrote:

>   If the DISCUSS and COMMENTs are dispositioned as proposed below in a
> forthcoming -09, would these address your concerns regarding this document?
>
> -Ed
>
> ---
> RFC8126 provides a pointer to Section 5.1 of rfc7752 as an exemplar for
> guidance, and I can draft a similar section in a -09 version of this
> document.
>

Good stuff, I'll review that when it appears.

> The WG does agree that having security contexts that are extensible is a
> value, and there is another security context specification in the DTNWG for
> that purpose. However, the default security contexts are, by design, 1-1
> (security context to algorithm) to simplify implementations and establish a
> baseline for implementation.
>

I think if Francesca concurs that this satisfies the concern, it satisfies
me too.

> Agree to the comment, but do not see a change to the specification itself.
> We will ask the document shepherd to update the writeup.
>

Right, this wasn't about your document's content but rather is a remark
about the shepherd writeup of it.  They're very useful to us when they're
current, but their utility diminishes when they diverge to this extent.

> C3: Agreed. Update in a -09.

Thanks!

-MSK