[OPSAWG] I-D Action: draft-ietf-opsawg-tacacs-yang-04.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Operations and Management Area Working Group WG of the IETF. Title : Yang data model for TACACS+ Authors : Guangying Zheng Michael Wang Bo Wu Filename: draft-ietf-opsawg-tacacs-yang-04.txt Pages : 15 Date: 2020-05-08 Abstract: This document defines YANG modules that augment the System Management data model defined in the RFC 7317 with TACACS+ client model. The data model of Terminal Access Controller Access Control System Plus (TACACS+) client allows the configuration of TACACS+ servers for centralized Authentication, Authorization and Accounting. The YANG modules in this document conforms to the Network Management Datastore Architecture (NMDA) defined in RFC 8342. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsawg-tacacs-yang/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-opsawg-tacacs-yang-04 https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-tacacs-yang-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-tacacs-yang-04 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
[OPSAWG] Secdir last call review of draft-ietf-opsawg-tacacs-yang-03
Reviewer: Yaron Sheffer Review result: Has Nits This document defines a YANG module for the configuration of TACACS+ clients. The document is short and straightforward, and I only have one significant comment. * I am not familiar with common security practices for the devices covered by this protocol. But I am wondering, should the "shared-secret" field be made optional, so that it can be entered "out of band" in applications that prefer not to keep it stored in the YANG configuration store and available to network management tools? * Not a security comment: the YANG module includes a reference to draft-ietf-opsawg-tacacs-18, but I assume that you'll want to replace it with the RFC number for that draft once it is published. Yet I don't see an RFC Editor note mentioning that. * It is confusing that "messages-received" is for messages received by the server, and "errors-received" is for errors received *from* the server. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] [Last-Call] Yangdoctors last call review of draft-ietf-opsawg-tacacs-yang-03
Hi John,
Thanks for the review. Please see inline.
Regards,
Bo
-邮件原件-
发件人: john heasley [mailto:h...@shrubbery.net]
发送时间: 2020年5月8日 2:10
收件人: Ladislav Lhotka
抄送: tom petch ; Wubo (lana) ; Joe
Clarke (jclarke) ; yang-doct...@ietf.org; opsawg@ietf.org;
draft-ietf-opsawg-tacacs-yang@ietf.org; last-c...@ietf.org
主题: Re: [Last-Call] Yangdoctors last call review of
draft-ietf-opsawg-tacacs-yang-03
Thu, May 07, 2020 at 03:02:24PM +0200, Ladislav Lhotka:
> > [Bo] Please see if the definition below is correct:
> > typedef tcsplus-server-type {
> >type bits {
> > bit authentication {
> >description
> > "When set, the server is an authentication server.";
> > }
> > bit authorization {
> >description
> > "When set, the server is an authorization server.";
> > }
> > bit accounting {
> >description
> > "When set, the server is an accounting server.";
> > }
> > bit all {
> >description
> > "When set, the server can be all types of TACACS+ servers.";
> > }
> >
> >}
> >description
> > "server-type can be set to authentication/authorization/accounting
> > or any combination of the three types.
> > When all three types are supported, either "all" or the three
> > bits setting can be used;
> > }
> >
> >
> > I would drop the all. I know that I suggested it, or an asterisk, but I
> > was thinking that this was a common case. Joe suggests that no accounting
> > is the commoner - I do not have sufficient exposure to know - in which case
> > I would not bother with 'all'. Whether or not to make auth/auth the
> > default I have no particular view on - as I say, I lack the exposure to be
> > confident about that.
> >
> > Having 'all' adds complexity, two ways to something, while making a small
> > saving in message size - on balance, not worth it.
>
> Agreed. Lada
Note that enabling certain types of accounting is rare, at least in my opinion.
eg: enabling login accounting is not rare, while command accounting is rare
because it is expensive esp. on some particular devices.
Also, rare or not, enabling it for a tacacs server is sort of orthogonal.
it will not be used for that purpose unless some form of accounting is enabled.
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.
About the model, do you think the "all" bit is still necessary?
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Tsvart last call review of draft-ietf-opsawg-sdi-08
Hi Warren, See inline. > On 7. May 2020, at 21:27, Warren Kumari wrote: > > On Tue, May 5, 2020 at 11:28 AM Mirja Kühlewind via Datatracker > wrote: >> >> Reviewer: Mirja Kühlewind >> Review result: Ready >> >> This document has been reviewed as part of the transport area review team's >> ongoing effort to review key IETF documents. These comments were written >> primarily for the transport area directors, but are copied to the document's >> authors and WG to allow them to address any issues raised and also to the >> IETF >> discussion list for information. >> >> When done at the time of IETF Last Call, the authors should consider this >> review as part of the last-call comments they receive. Please always CC >> tsv-...@ietf.org if you reply to or forward this review. >> >> This document specifies a process to encrypt an initial configuration file. >> The >> process of fetching the config file is not altered and as such there are no >> new >> transport related issue. >> >> However, one quick question/comment regarding the following sentence in >> section >> 4.3.: "if parsing the >> configurations fails, the device will either abort the auto-install >> process, or will repeat this process until it succeeds." >> Is this supposed to indicate that the whole process, including fetching the >> file should be repeated? If so, there needs to be guidance that one should >> not >> immediately fetch again but wait for a period of maybe seconds (or minutes?) >> and a limit for maximum number of retries must be implemented. Yes, this is >> not >> necessarily part of the process that is altered in this document but if this >> guidance is given it should be correct. If similar guidance is already >> provides >> in other documents, a pointer to those docs might work as well. > > Thank you! This solution does not need to be particularly agile -- the > "initial" install of a device only happens once (or possibly a few > times if the config is deleted / hard disks die, etc), and so I've > recommended: > "When retrying, care should be taken to not > overwhelm the server hosting the encrypted configuration files. It is > recommended > that the device retry every 5 minutes for the first hour, and then > every hour after > that. As it is expected that devices may be installed well before the > configuration file is ready, a maximum number of retrys is not specified." > > I could see situations where a device gets installed and the engineers > haven't finished writing the configs when the device is first turned > on -- I don't want things to end up in a situation where devices try > for a few days and then give up and require someone to poke them to > restart this process. > The "try every hour" is somewhat arbitrary, but even a tiny web server > should be able to happily handle ~1000QPS, which means that it could > support ~3.6M devices all stuck in an infinite retry loop… > Thanks! I guess it could still be good to at least mention that there should be some termination condition (and that it should be in order of multiple days). > >> >> Editorial comment: >> I would recommend to use more generic company names than Sirius Cybernetics >> Corp and Acme Network Widgets to avoid that these names can be mistaken as >> real >> companies. I know it's boring but Vendor A and Operator B would probably work >> just fine. >> >> > > Sad panda, but you are right I replaced Sirrius and Acme with > Operator_A and Vendor_B… That works for me as well ;-) Mirja > > Thank you again for your review, I'm publishing a new version with > these addressed now. > W > > > > -- > I don't think the execution is relevant when it was obviously a bad > idea in the first place. > This is like putting rabid weasels in your pants, and later expressing > regret at having chosen those particular rabid weasels and that pair > of pants. > ---maf > ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
