Subject: Re: [OPSAWG] Roman Danyliw's No Objection on draft-ietf-opsawg-tacacs-yang-11: (with COMMENT)

From: "Wubo (lana)" <[email-masked]>
Date: Fri, 14 May 2021 07:37:55 +0000

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-masked]] 
发送时间: 2021年5月14日 3:18
收件人: The IESG <[email-masked]>
抄送: [email-masked]; [email-masked]; [email-masked]; Joe Clarke <[email-masked]>; [email-masked]
主题: 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.

---

From: Roman Danyliw <[email-masked]>
Date: Fri, 14 May 2021 14:52:29 +0000

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-masked]> On Behalf Of Wubo (lana)
> Sent: Friday, May 14, 2021 3:38 AM
> To: Roman Danyliw <[email-masked]>; The IESG <[email-masked]>
> Cc: [email-masked]; Joe Clarke <[email-masked]>; [email-masked];
> [email-masked]
> Subject: Re: Roman Danyliw's No Objection on draft-ietf-opsawg-tacacs-yang-
> 11: (with COMMENT)
> 
> Hi all,
> 抄送: [email-masked]; [email-masked];
> [email-masked]; Joe Clarke <[email-masked]>; [email-masked]
> 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.)
> 
> 
> 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:
> 
> 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.
> 
>