Subject: [OPSAWG] [Ladislav Lhotka] Re: Yangdoctors last call review of draft-ietf-opsawg-tacacs-yang-03

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 05 May 2020 16:31:51 +0200

Resending to the mailing lists - I changed my company mail address to [email-masked] and it causes problems once in a while.

Lada

-------------------- Start of forwarded message --------------------
From: Ladislav Lhotka <[email-masked]>
Date: Tue, 05 May 2020 16:16:27 +0200

"Joe Clarke (jclarke)" <[email-masked]> writes:

> Thank you for your review, Lada.  One item came up in WGLC about the server-type leaf (and you have called that out below).
>
> Right now, this is an enumeration.  As you say (and also Tom Petch
> pointed out) that typically a server will have multiple types (i.e.,

In fact, Tom pointed out other things that I also had in my review (I didn't know about that thread before, I swear:-).

> a server will be used for authn, authz, and acct).  So Bo proposed a
> leaf-list solution whereby one could specify multiple values for
> server-type.  Tom counter-proposed a bit string (akin to chmod and
> NACM CRUDX handling).  As a contributor, I liked the leaf-list idea,
> but Tom is still leaning toward the bit string.  We wanted to get
> YAND Doc’s opinion on this.

I was also thinking about the "bits" type, it is IMO designed for cases like this. Note that in XML or JSON representation (not in CBOR, though), the on-the-wire instance encoding is also self-describing, e.g.

<server-type>authentication authorization</server-type>

Lada

>
> The full thread can be found at https://mailarchive.ietf.org/arch/msg/opsawg/Q_ov6M-PZF4rlsCae0qZh1aE6tg/ .  If you could provide some guidance on this that would be appreciated.
>
> Joe
>
> On May 4, 2020, at 09:16, Ladislav Lhotka via Datatracker <[email-masked]<mailto:[email-masked]>> wrote:
>
> 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.'
>
> - Description of the leaf
> /ietf-system-tacacsplus:tacacsplus/statistics/sessions is cryptic and unclear.
>
> - Typo in error-message of
> /ietf-system:system/ietf-system-tacacsplus:tacacsplus: s/sysytem/system/
>
> - 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.
>
> - 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.
>
> - Security Considerations should specifically address the "shared-secret" leaf.
>
> - 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.
>
>
>

-- 
Ladislav Lhotka 
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67
-------------------- End of forwarded message --------------------

-- 
Ladislav Lhotka 
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

---

From: "Wubo (lana)" <[email-masked]>
Date: Thu, 7 May 2020 08:58:45 +0000

Hi Lada,

Many thanks for the suggestion. Understood, will remove the "case".

Thanks,
Bo

-----邮件原件-----
发件人: Ladislav Lhotka [mailto:[email-masked]] 
发送时间: 2020年5月7日 14:56
收件人: Wubo (lana) <[email-masked]>; [email-masked]
抄送: [email-masked]; [email-masked]; [email-masked]
主题: Re: Yangdoctors last call review of draft-ietf-opsawg-tacacs-yang-03

"Wubo (lana)" <[email-masked]> writes:
>
> - 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.

I am not suggesting to remove this choice, this is of course not YANG Doctor's business. My comment is related exclusively to YANG syntax: if you have a "case" statement containing only one data node, then the "case" statement can be omitted, see sec. 7.9.2 in RFC 7950. Such a shorthand is IMO preferable (less clutter), unless you want to leave the possibility of augmenting the case node later - I don't think though it is an option here.

Thanks, Lada

---

From: "Wubo (lana)" <[email-masked]>
Date: Wed, 13 May 2020 06:10:34 +0000

Hi John,

Currently, the accounting and authorization methods are not defined in System model. Therefore, although Tacacs+ defines accounting and authorization type, there is no way to use it. 

Regards,
Bo

-----邮件原件-----
发件人: john heasley [mailto:[email-masked]] 
发送时间: 2020年5月11日 13:42
收件人: Wubo (lana) <[email-masked]>
抄送: john heasley <[email-masked]>; Ladislav Lhotka <[email-masked]>; tom petch <[email-masked]>; Joe Clarke (jclarke) <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; [email-masked]
主题: Re: [Last-Call] Yangdoctors last call review of draft-ietf-opsawg-tacacs-yang-03

Fri, May 08, 2020 at 09:45:51AM +0000, Wubo (lana):
> I'll have to look at the model again; i do not recall if the model allows for particular accounting types w/o augmentation.
> 
> [Bo]  The accounting type you mentioned, I understand, is that the System model needs to be augmented. Currently, the System model only defines authentication.

Hey.  System model has no accounting that I see.  what am i missing; where are the accounting types defined?

> About the model, do you think the "all" bit is still necessary?

I am not advocating for nor against; only trying to explain how 'accounting'
type might be used, which seemed to be misunderstood.
[Bo] OK