Subject: [OPSAWG] Review of draft-zheng-opsawg-tacacs-yang-01

From: Joe Clarke <[email-masked]>
Date: Mon, 8 Apr 2019 15:26:20 -0400

As promised at the mic during opsawg at IETF 104, here is my more
detailed review of this draft.

As I stated during the meeting, I think the AAA module should be taken
out of this document.  I believe Alan has commented the same.  A AAA
module may be required, but I don't want to muddle the TACACS+ work with
that.  Plus, I'm not convinced opsawg would be the correct place for a
more general AAA module.

Secondly, I like the fact that you're extending the ietf-system module
in a manner similar to RADIUS.  I think that this work fits nicely there
for device admin.  I would remove the AAA moniker from the module for
now.  Leave it as ietf-tacacs-plus.

I recall seeing a comment on-list that any reference to "tacacs" must be
"tacacs+" or "tacacs_plus" or similar.  TACACS without the plus is a
very different beast.  Let's not confuse what we're trying to do here.

Maybe I'm being overly pedantic here, but why is "options" separated
from other rw objects by the statistics branch?  I would think you'd
want to group the rw objects together.

The word "accounting" is misspelled throughout this document.  In
general, I would run a spell checker over it.  After listening to
Heather at the keynote, we should do our best to help out RFC Editor,
even early on in the document lifecycle.

What is the intent of network-instance?  Is this like specifying a VRF
on which to reach the T+ server?  The description was not very clear.

You have a source IP option, but I know some vendors also implement a
source-interface.  I think it would be useful to have that as well
(maybe a choice there).

Joe

---

From: "Wubo (lana)" <[email-masked]>
Date: Tue, 9 Apr 2019 08:28:15 +0000

Hi Joe,

Many thanks for your valuable comments and suggestions.
Please see my in-line reply below.

Thanks,
Bo

-----邮件原件-----
发件人: OPSAWG [mailto:[email-masked]] 代表 Joe Clarke
发送时间: 2019年4月9日 3:26
收件人: [email-masked]
主题: [OPSAWG] Review of draft-zheng-opsawg-tacacs-yang-01

As promised at the mic during opsawg at IETF 104, here is my more detailed review of this draft.

As I stated during the meeting, I think the AAA module should be taken out of this document.  I believe Alan has commented the same.  A AAA module may be required, but I don't want to muddle the TACACS+ work with that.  Plus, I'm not convinced opsawg would be the correct place for a more general AAA module.
[Bo] Thanks, we will take out the AAA module and focus the draft on TACACS+ YANG model.

Secondly, I like the fact that you're extending the ietf-system module in a manner similar to RADIUS.  I think that this work fits nicely there for device admin.  I would remove the AAA moniker from the module for now.  Leave it as ietf-tacacs-plus.

I recall seeing a comment on-list that any reference to "tacacs" must be "tacacs+" or "tacacs_plus" or similar.  TACACS without the plus is a very different beast.  Let's not confuse what we're trying to do here.
[Bo] Thank you for the suggestion, the module name will be changed to ietf-tacacs-plus to avoid misunderstanding as the network access AAA or TACACS.

Maybe I'm being overly pedantic here, but why is "options" separated from other rw objects by the statistics branch?  I would think you'd want to group the rw objects together.
[Bo] Agree, the "options" container will be moved to the front of the tacacs-plus container to make the configuration parameters together.

The word "accounting" is misspelled throughout this document.  In general, I would run a spell checker over it.  After listening to Heather at the keynote, we should do our best to help out RFC Editor, even early on in the document lifecycle.
[Bo] Sure, spell checking will be done and corrected.

What is the intent of network-instance?  Is this like specifying a VRF on which to reach the T+ server?  The description was not very clear.
[Bo] Yes, this is the intention. More text will be added.

You have a source IP option, but I know some vendors also implement a source-interface.  I think it would be useful to have that as well (maybe a choice there).
[Bo] Ok, we can change "source-ip" to a choice statement to accommodate both implementation options. Thanks.

Joe

_______________________________________________
OPSAWG mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/opsawg