[alto] Roman Danyliw's Discuss on draft-ietf-alto-oam-yang-16: (with DISCUSS and COMMENT)

[Roman Danyliw via Datatracker <[e-mail]>]

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)?

-- Would it be best practice to be able to read all of the authorized users?

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?


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

Thank you to Rich Salz for the SECDIR review.

Thank you for addressed by COMMENT and DISCUSS feedback.