Hi all, Thanks for the review and comments. v-12 is posted to resolve the comments on the description for the "security" choice. Please check the diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-tacacs-yang-12
Thanks, Bo -----邮件原件----- 发件人: Roman Danyliw via Datatracker [mailto:[email protected]] 发送时间: 2021年5月14日 3:18 收件人: The IESG <[email protected]> 抄送: [email protected]; [email protected]; [email protected]; Joe Clarke <[email protected]>; [email protected] 主题: Roman Danyliw's No Objection on draft-ietf-opsawg-tacacs-yang-11: (with COMMENT) Roman Danyliw has entered the following ballot position for draft-ietf-opsawg-tacacs-yang-11: No Objection 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/iesg/statement/discuss-criteria.html for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-opsawg-tacacs-yang/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you to Yaron Sheffer for the SECDIR review, and for the changes in response. Thanks for addressing my DISCUSS around compatibility with RFC8907 and the COMMENT feedback. Per my DISCUSS on publishing this document as a proposed standard and characterizing it as new functionality that standardizes an API to an insecure protocol (that is itself has informational status), I will clear per the discussion had in the IESG: -- I’m persuaded that with -11, the YANG module is feature equivalent to RFC8907 (so there isn't any new functionality). Surprisingly, despite this module being focused on RFC8907, it now foreshadows future changes in Section 4 of the "choice security" with "... a future encryption mechanism will result in a non-backwards-compatible change" which suggests that this YANG module isn't tied solely to RFC8907. -- As to the API mechanism being new functionality, I question the value of making it easier to manage a fundamentally insecure protocol with this new capability and whether publication of this document (unlike RFC8907) does provide the basis for future improvements. Nevertheless, there are operational realities of how widely TACACS+ is already deployed that necessitate improvement management of the as-is infrastructure while an improved protocol is built. -- As to the issue of the underlying protocol having a “lower” status (information for RFC8907) than the associated YANG module (PS for this document), I leave that to the convention of OPS area. _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
