Hi Bo! Thanks for the follow up and updates in -12. From my perspective, all my feedback is resolved.
Roman > -----Original Message----- > From: iesg <[email protected]> On Behalf Of Wubo (lana) > Sent: Friday, May 14, 2021 3:38 AM > To: Roman Danyliw <[email protected]>; The IESG <[email protected]> > Cc: [email protected]; Joe Clarke <[email protected]>; [email protected]; > [email protected] > Subject: Re: Roman Danyliw's No Objection on draft-ietf-opsawg-tacacs-yang- > 11: (with COMMENT) > > 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
