Re: [yang-doctors] Yangdoctors last call review of draft-ietf-opsawg-tacacs-yang-03

"Wubo (lana)" <lana.wubo@huawei.com> Wed, 06 May 2020 06:40 UTC

Return-Path: <lana.wubo@huawei.com>
X-Original-To: yang-doctors@ietfa.amsl.com
Delivered-To: yang-doctors@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01C163A05AC; Tue, 5 May 2020 23:40:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EzjmFk87-zVz; Tue, 5 May 2020 23:40:37 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44CA73A05AA; Tue, 5 May 2020 23:40:37 -0700 (PDT)
Received: from lhreml739-chm.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 04473EC1CBD81B0C7924; Wed, 6 May 2020 07:40:35 +0100 (IST)
Received: from dggeme751-chm.china.huawei.com (10.3.19.97) by lhreml739-chm.china.huawei.com (10.201.108.189) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.1913.5; Wed, 6 May 2020 07:40:34 +0100
Received: from dggeme752-chm.china.huawei.com (10.3.19.98) by dggeme751-chm.china.huawei.com (10.3.19.97) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Wed, 6 May 2020 14:40:32 +0800
Received: from dggeme752-chm.china.huawei.com ([10.6.80.76]) by dggeme752-chm.china.huawei.com ([10.6.80.76]) with mapi id 15.01.1913.007; Wed, 6 May 2020 14:40:32 +0800
From: "Wubo (lana)" <lana.wubo@huawei.com>
To: Ladislav Lhotka <lhotka@nic.cz>, "yang-doctors@ietf.org" <yang-doctors@ietf.org>
CC: "last-call@ietf.org" <last-call@ietf.org>, "draft-ietf-opsawg-tacacs-yang.all@ietf.org" <draft-ietf-opsawg-tacacs-yang.all@ietf.org>, "opsawg@ietf.org" <opsawg@ietf.org>
Thread-Topic: Yangdoctors last call review of draft-ietf-opsawg-tacacs-yang-03
Thread-Index: AdYjT9W0uXEquu2YRrCOd1HA6ONNiQ==
Date: Wed, 06 May 2020 06:40:32 +0000
Message-ID: <ddcdeabe7c6b4a9eb13132a17bc2d236@huawei.com>
Accept-Language: en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.138.33.83]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/yang-doctors/SpWfUuovYwI0hD-_J4NnYgh7hX0>
Subject: Re: [yang-doctors] Yangdoctors last call review of draft-ietf-opsawg-tacacs-yang-03
X-BeenThere: yang-doctors@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Email list of the yang-doctors directorate <yang-doctors.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/yang-doctors>, <mailto:yang-doctors-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/yang-doctors/>
List-Post: <mailto:yang-doctors@ietf.org>
List-Help: <mailto:yang-doctors-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/yang-doctors>, <mailto:yang-doctors-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 May 2020 06:40:39 -0000

Hi Lada,

Thanks for the review. Please see the response inline.

Regards,
Bo

-----邮件原件-----
发件人: Ladislav Lhotka via Datatracker [mailto:noreply@ietf.org] 
发送时间: 2020年5月4日 21:17
收件人: yang-doctors@ietf.org
抄送: last-call@ietf.org; draft-ietf-opsawg-tacacs-yang.all@ietf.org; opsawg@ietf.org
主题: Yangdoctors last call review of draft-ietf-opsawg-tacacs-yang-03

Reviewer: Ladislav Lhotka
Review result: Ready with Nits

The YANG module specified in this I-D defines a relatively simple augmentation of the "ietf-system" module that enables configuration of TACACS+ authentication. The ietf-system-tacacsplus module is in a good shape, I found no substantial problems.

**** Comments

- In sec. 3, the text says: 'The ietf-system-tacacsplus module is intended to augment the "/sys:system" path defined in the ietf-system module with "tacacsplus" grouping.' It would be more precise to say '... with the contents of the "tacacsplus" grouping.'
[Bo] OK, I will change as suggested.

- Description of the leaf
/ietf-system-tacacsplus:tacacsplus/statistics/sessions is cryptic and unclear.
[Bo] OK, I will change as follows:
"Number of sessions completed with the server. If the Single Connection Mode was not enabled, the number of sessions is the same as the number of connection opens. 
If the Mode was enabled, a single TCP connection may contain multiple TACACS+ sessions."

- Typo in error-message of
/ietf-system:system/ietf-system-tacacsplus:tacacsplus: s/sysytem/system/
[Bo] OK, will correct.

- Is it correct that the server type may be either one of "authentication", "authorization" or "accounting", or all of them? Is it impossible for a server to be authentication & authorization but not accounting? Such a variant cannot be configured.
[Bo] OK, will correct when the final guidance on this issue is received.

- The "case" statements in ietf-system-tacacsplus:tacacsplus/source-type are unnecessary because each contains only one leaf of the same name; I suggest to remove them.
[Bo] I need to wait for the further guidance from WG. The "choice case" is added based on the email discussion of the WG, which provides some flexibility in specifying the IP address for server communication. Some vendors prefer IP addresses, and some vendors derive IP addresses through interfaces.

- Security Considerations should specifically address the "shared-secret" leaf.
[Bo] OK, will add this and also some other nodes as Tom Petch commented.

- The purpose of Appendix A is unclear, the information it provides is (or should be) in the previous text, the YANG module, and RFC 7317. Instead, it would be useful to provide an example of TACACS+ configuration, e.g. in JSON representation.
[Bo] OK, will change Appendix A into an example of TACACS+ configuration.