Skip to main content

Last Call Review of draft-ietf-i2nsf-capability-data-model-16
review-ietf-i2nsf-capability-data-model-16-secdir-lc-wouters-2021-05-18-00

Request Review of draft-ietf-i2nsf-capability-data-model
Requested revision No specific revision (document currently at 32)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2020-09-08
Requested 2020-08-25
Authors Susan Hares , Jaehoon Paul Jeong , Jinyong Tim Kim , Robert Moskowitz , Qiushi Lin
I-D last updated 2021-05-18
Completed reviews Yangdoctors Last Call review of -05 by Carl Moberg (diff)
Secdir Last Call review of -16 by Paul Wouters (diff)
Genart Last Call review of -09 by Dan Romascanu (diff)
Tsvart Early review of -13 by Michael Scharf (diff)
Secdir Last Call review of -21 by Paul Wouters (diff)
Secdir Telechat review of -23 by Paul Wouters (diff)
Assignment Reviewer Paul Wouters
State Completed
Request Last Call review on draft-ietf-i2nsf-capability-data-model by Security Area Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/secdir/0M2g4ku0c5cmOqQo9O3EFryzDG8
Reviewed revision 16 (document currently at 32)
Result Has nits
Completed 2021-05-18
review-ietf-i2nsf-capability-data-model-16-secdir-lc-wouters-2021-05-18-00
I have reviewed this document as part of the security directorate's  ongoing
effort to review all IETF documents being processed by the  IESG.  These
comments were written primarily for the benefit of the security area directors.
 Document editors and WG chairs should treat these comments just like any other
last call comments.

The summary of the review Has Nits

The issues that  Michael Scharf raised regarding TOS have been addressed. Thank
you. I have no items that are serious issues, just some comments that you may
take into consideration for a minor update.

Nits:

The privacy section talks about a trade-off between privacy and security. But I
do not understand what trade-off is meant. The document does not seem to make
any trade-off. It just defines capabilities that can be used, some of which
might process private material. But the trade-offs of that are really at the
protocol level (like they did use TLS or IPsec or why not). I dont think
describing technical capabilities is a trade-off of security vs privacy.
Perhaps the section could talk about the discovery and/or usage of capabilities
and that those capabilities handling private information should attempt to
report their usage/findings/events underst conditions that preserve the privacy
(eg require TLS or IPsec between SG and NSF ?)

The Security section talks about layers that "can use" SSH or TLS for security.
I'm not sure why it does not say SHOULD or MUST ? I would rewrite "need to be
tightly secured and monitored" to "MUST be tightly secured, monitored and
audited".

Section 3.1 states:

    These capabilities MAY have their access control restricted by a policy;

In light of the other recommendations in the Security Section, I think this MAY
should really be a SHOULD or even MUST. Alternatively, perhaps say "Some of
these capabilities SHOULD" ?