Hi Paul,
Here are the revision letter and revised draft reflecting your comments.
You can find my responses to your comments from page 36 in the revision letter.
Patrick and I worked together for this revision.
Please let me know whether this version satisfies your comments or not.
Thanks.
Best Regards,
Paul Jeong
On Wed, May 19, 2021 at 5:16 AM Paul Wouters via Datatracker <noreply@xxxxxxxx> wrote:
Reviewer: Paul Wouters
Review result: Has Nits
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" ?
Attachment:
Revision-Letter-for-draft-ietf-i2nsf-capability-data-model-17-20210814.pdf
Description: Adobe PDF document
Attachment:
Revision-Letter-for-draft-ietf-i2nsf-capability-data-model-17-20210814.docx
Description: application/vnd.openxmlformats-officedocument.wordprocessingml.document
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
