Hi Alex, Thanks for your valuable comments, please see my reply inline below:
-----邮件原件----- 发件人: Alex Campbell [mailto:alex.campb...@aviatnet.com] 发送时间: 2018年7月4日 8:00 收件人: Wubo (lana) <lana.w...@huawei.com>; net...@ietf.org; opsawg@ietf.org 主题: Re: EXTERNAL: Re: [netmod] New Version Notification for draft-zheng-netmod-tacacs-yang-01.txt Hi Bo, My comments: (ignoring simple typos and placeholder values as this is a first draft) * What is a TACACS+ template? To my knowledge this is not a standard concept. The word "template" does not appear in draft-ietf-opsawg-tacacs-10. [Bo]TACACS+ template is used to configure a sets of TACACS+ server with the defined domain. Each domain defined maintains a user list in the "user@domain" format. When a TACACS+ client receives a request from a user, the TACACS+ template is selected based on the domain carried with the user. * What is a domain name, in the context of usernames? "domain" also does not appear in draft-ietf-opsawg-tacacs-10. [Bo] Domain is used for management purpose same as the first comment. * I don't think ipv4-address-no-zone should be used by default, unless there is a good reason to prohibit the use of zones. Systems that do not implement zones can reject addresses containing zones; but some systems may require zones. [Bo] Good suggestion, we will consider to modify this type in the next version. * This module seems to imply a particular server selection algorithm (with the use of primary/secondary and current servers). What is the algorithm? Our TACACS+ code does not have a concept of a primary, secondary or current server. It has a prioritized list of servers, and tries each request towards each server in turn until it receives a pass or fail response (as opposed to an error). The assumption in this design is that servers are up most of the time. [Bo] Our proposal is that in each template there are only one primary server and several secondary servers which can be configured. Therefore, the primary server is selected first, and then the secondary server is selected according to the configuration order. The difference from your implementation is that we specify the primary server. We think specifying a primary server can help distribute user request processing. * Many of the leaves seem unnecessary and not terribly useful. For example, sec-author-srv-num (Total number of configured secondary authorization servers in the template). Is this value needed so frequently that it needs to be available as a separate value - instead of having the management client simply read the whole list of servers, and count how many are secondary and used for authentication? [Bo] Good point! In this version, we try to provide complete operational statistics. And I agree with you that it seems redundant, and if most folks believe it need to be simplified that we would like to refine this statistics leaves in the next version. * What is the public net? [Bo] Public net is used to specify whether a TACACS+ server is used in public Internet. * Why is there a maximum of 32 servers? [Bo] Good catch, it is a implementation limitation, we will remove it in the next version. * There should not need to be separate lists for ipv4 and ipv6 servers. I see that ipv6 servers don't support public-net, so I'll reserve judgment until I find out what public-net does. [Bo] Good suggestion, we will consider to use one merged list to represent two address families of a TACACS+ server. * What should implementations do if they don't support ietf-network-instance? [Bo]Good comment. Though we use ietf-network-instance as a key to configure TACACS+ server and our assumption is most TACACS+ clients can support VPN functionality, this may lead to an issue in some case. We will try to address this issue in the next version. As a related side note, I'd really like to see a standard for TACACS+ over TLS. Regards, Alex ________________________________________ From: netmod <netmod-boun...@ietf.org> on behalf of Wubo (lana) <lana.w...@huawei.com> Sent: Monday, 2 July 2018 8:07 p.m. To: net...@ietf.org; opsawg@ietf.org Subject: EXTERNAL: Re: [netmod] New Version Notification for draft-zheng-netmod-tacacs-yang-01.txt Dear Netmod, Opsawg, Please see our newly uploaded draft of TACACS+ YANG data model, which can be found at https://www.ietf.org/internet-drafts/draft-zheng-netmod-tacacs-yang-01.txt. This data model draft is based on the TACACS+ working group draft - https://tools.ietf.org/html/draft-ietf-opsawg-tacacs-10. TACACS+ provides Device Administration for routers, network access TACACS+ servers and other networked computing devices via one or more centralized servers. With various TACACS+ Implementation, service provider may need different TACACS+ YANG modules to manipulate massive devices. So we propose to define a generic TACACS+ data model to alleviate this issue. We are looking forward to receiving your response. Best regards. Bo -----邮件原件----- 发件人: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] 发送时间: 2018年7月2日 14:15 收件人: wangzitao <wangzi...@huawei.com>; Wubo (lana) <lana.w...@huawei.com>; Zhengguangying (Walker) <zhengguangy...@huawei.com>; Wubo (lana) <lana.w...@huawei.com>; wangzitao <wangzi...@huawei.com> 主题: New Version Notification for draft-zheng-netmod-tacacs-yang-01.txt A new version of I-D, draft-zheng-netmod-tacacs-yang-01.txt has been successfully submitted by Bo Wu and posted to the IETF repository. Name: draft-zheng-netmod-tacacs-yang Revision: 01 Title: Yang data model for Terminal Access Controller Access Control System Plus Document date: 2018-07-01 Group: Individual Submission Pages: 33 URL: https://www.ietf.org/internet-drafts/draft-zheng-netmod-tacacs-yang-01.txt Status: https://datatracker.ietf.org/doc/draft-zheng-netmod-tacacs-yang/ Htmlized: https://tools.ietf.org/html/draft-zheng-netmod-tacacs-yang-01 Htmlized: https://datatracker.ietf.org/doc/html/draft-zheng-netmod-tacacs-yang Diff: https://www.ietf.org/rfcdiff?url2=draft-zheng-netmod-tacacs-yang-01 Abstract: This document describes a data model of Terminal Access Controller Access Control System Plus (TACACS+). The YANG data model in this document conforms to the Network Management Datastore Architecture (NMDA) defined in [RFC8342]. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat _______________________________________________ netmod mailing list net...@ietf.org https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
