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

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Thu, 13 May 2021 12:17:36 -0700

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.