Hi Roman, Many thanks for your further feedback. We just uploaded revision -17 to address your comments.
HTML: https://datatracker.ietf.org/doc/html/draft-ietf-alto-oam-yang-17 Diff: https://author-tools.ietf.org/iddiff?url2=draft-ietf-alto-oam-yang-17 Please see our detailed responses inline below. If there are others needed, please let us know. Thanks, Jensen On Thu, Jan 18, 2024 at 10:50 PM Roman Danyliw via Datatracker < nore...@ietf.org> wrote: > Roman Danyliw has entered the following ballot position for > draft-ietf-alto-oam-yang-16: 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/about/groups/iesg/statements/handling-ballot-positions/ > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-alto-oam-yang/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Per -15 ballot review: > > ** Section 8. Per the guidance on writeable data, aren’t significant > parts of > alto-server/listen sensitive as one could alter the stored keys for the > server > or client; or the username/password combinations (in > http-server-parameters)? > > ** Section 8. Per the guidance about readable data: > > -- isn’t tls-server-parameters sensitive since it could contain raw private > keys (e.g., ks:inline-or-keystore-symmetric-key-grouping)? > Agree. We should make it clear. Writeable data nodes in 'http-server-parameters' and 'tls-server-parameters' are sensitive. We added the list of the concrete sensitive data nodes and their referenced groupings and modules. The security considerations of the corresponding I-Ds are applied to them. > > -- Would it be best practice to be able to read all of the authorized > users? > The admin should be able to operate the access control of the authorized users. Therefore, accessing the identifiers of the authorized users is a minimal requirement. But more sensitive user information is not required. > > Thanks for the response at > https://mailarchive.ietf.org/arch/msg/alto/tD88zktK20QDBIbd-jbGt5JJDLc/ > > > Yes, some groupings in alto-server/listen are also sensitive. But they > are > > defined in other RFCs, thus the security considerations in those RFCs > also > > apply to them. > > This described approach is inconsistent with my observation on how the YANG > security template is used. If there is a path which has security > considerations, the issues are typically highlighted regardless of whether > there is reuse. Setting aside that this is a YANG module, my experience > with > any protocol document is that if there is a mechanism reused by reference > and > it introduces a relevant security dependency, it would have been cited in > the > Security Considerations as applicable. Neither of these approach appear > to be > taken here. Is there a reason why not? > Make sense. We added the security considerations for the reused data nodes. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thank you to Rich Salz for the SECDIR review. > > Thank you for addressed by COMMENT and DISCUSS feedback. > > > >
_______________________________________________ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
