Hi Paul, I will address your comments on the Security Section. Thanks for your valuable comments to improve our draft.
Best Regards, Paul Jeong On Wed, May 19, 2021 at 5:16 AM Paul Wouters via Datatracker < [email protected]> 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" ? > > > > > > >
_______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
