Hi Bo, Thanks for the feedback.
Please see inline. Cheers, Med > -----Message d'origine----- > De : Wubo (lana) <lana.w...@huawei.com> > Envoyé : vendredi 7 juin 2024 11:40 > À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com>; > opsawg@ietf.org; draft-ietf-opsawg-tacacs-tl...@ietf.org > Cc : Qin Wu <bill...@huawei.com> > Objet : RE: I-D Action: draft-boucadair-opsawg-secure-tacacs- > yang-01.txt > > Hi Med, > > Thanks for working on the secure tacacs+ YANG. > > On the "dual-stack" and "keepalive", here are my comments: > > For dual-stack extension: I support this extension. With the > practice of Happy Eyeballs (RFC 8305) you mentioned and our > implementation experience, I think this is useful. [Med] Great. Thanks. > As the co-author of RFC 9105, I recall that early versions > supported dual stack and it was removed later based on the > comments received. [Med] Thanks for sharing this background. > I think "remote-address" is a bit confusing. The "address" of the > current model also refers to remote-address. Maybe we can call it > "dual-stack-address"? [Med] It is not only about dual-stack, but also to manage a redundancy group using the same AF. FWIW, I went with remote-address to be consistent with the use in draft-ietf-tcpm-yang-tcp and draft-ietf-netconf-tcp-client-server. I have also explored to reuse the grouping in draft-ietf-netconf-tcp-client-server as it is. I abandoned that because I'm not comfortable with how that grouping is designed. There are for sure many data nodes that are conditioned by the support of features but blindly reusing those in a model such as TACACS+ will import many useless data nodes and create redundant nodes (keepalive at the TCP level + keepalive at the TLS level). I would preferred a more modular approach in draft-ietf-netconf-tcp-client-server, but it is late to fix those. This is actually the reason I went for a pruning approach rather a reuse. > > For keepalives: I suggest we can keep this, though the tacacs+ > TLS 1.3 does not have a specific requirement for it. I see > syslog-yang defines in this approach. [Med] Agree this is present in the syslog ynag, but we need to have this clarified in the base spec. > > Additionally, the client credentials configuration is complex. > Can we support pre-defined reusable client credentials for > tacacs+ servers to reference? [Med] I don't see a problem with that. I'm OK to add it. Thanks. > > Thanks, > Bo > > -----Original Message----- > From: mohamed.boucad...@orange.com <mohamed.boucad...@orange.com> > Sent: Friday, June 7, 2024 2:55 PM > To: Wubo (lana) <lana.w...@huawei.com>; opsawg@ietf.org; draft- > ietf-opsawg-tacacs-tl...@ietf.org > Subject: RE: I-D Action: draft-boucadair-opsawg-secure-tacacs- > yang-01.txt > > Hi all, > > Bo raised a question about keepalives: > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2 > Fgithub.com%2Fboucadair%2Fsecure-tacacs- > yang%2Fissues%2F1&data=05%7C02%7Cmohamed.boucadair%40orange.com%7 > Cc3fcfb0cb6ed49d9b7b108dc86d5f0d8%7C90c7a20af34b40bfbc48b9253b6f5 > d20%7C0%7C0%7C638533500628011847%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi > MC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C > %7C%7C&sdata=%2FwK%2FC7x%2Fypi7zxqvocWE3XJnvXZ1N0LpYMMlTKujiKM%3D > &reserved=0 > > As indicated below, we don't have a clear view on whether this is > needed or not. My hope is to record the intended behavior in the > base secure tacacs+ spec. > > Cheers, > Med > > > -----Message d'origine----- > > De : mohamed.boucad...@orange.com > <mohamed.boucad...@orange.com> > > Envoyé : mardi 28 mai 2024 16:53 À : opsawg@ietf.org; > > draft-ietf-opsawg-tacacs-tl...@ietf.org > > Objet : [OPSAWG]TR: I-D Action: draft-boucadair-opsawg-secure- > > tacacs-yang-01.txt > > > > Hi all, > > > > In order to asses whether manageability considerations are well > > covered in draft-ietf-opsawg-tacacs-tls13, I edited this I-D to > > specify a module for managing secure tacacs+ clients, based on > > RFC9105. > > > > Key requirements as drawn in draft-ietf-opsawg-tacacs-tls13 are > > covered in this version. However, this exercise triggered some > > questions for which we have no text in the base spec: for > example, > > keepalive considerations. > > > > This spec also reveals some issues with 9105 such as the lack > of > > support of dual stack. Bo raised a comment offline whether we > define > > this draft as a bis or keep the current augmentation approach. > This > > point is recorded as a pending issue. > > > > Please note that the module does not reuse the tls-client > grouping > > from draft-ietf-netconf-tls-client-server but adopts a pruning > > approach. > > > > Comments and suggestions are more than welcome. > > > > Cheers, > > Med > > > > -----Message d'origine----- > > De : internet-dra...@ietf.org <internet-dra...@ietf.org> Envoyé > : > > mardi 28 mai 2024 16:27 À : i-d-annou...@ietf.org Objet : I-D > > Action: draft-boucadair-opsawg-secure-tacacs-yang-01.txt > > > > > > Internet-Draft draft-boucadair-opsawg-secure-tacacs-yang-01.txt > > is now available. > > > > Title: A YANG Model for Terminal Access Controller Access- > > Control System Plus (TACACS+) over TLS 1.3 > > Author: Mohamed Boucadair > > Name: draft-boucadair-opsawg-secure-tacacs-yang-01.txt > > Pages: 23 > > Dates: 2024-05-28 > > > > Abstract: > > > > This document defines a YANG module for Terminal Access > Controller > > Access-Control System Plus (TACACS+) over TLS 1.3. This > modules > > augments the YANG Data Model for Terminal Access Controller > > Access- > > Control System Plus (TACACS+) defined in the RFC 9105 with > > TLS- > > related data nodes. > > > > The IETF datatracker status page for this Internet-Draft is: > > > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2 > > Fdatatracker.ietf.org%2Fdoc%2Fdraft-boucadair-opsawg-secure- > > tacacs- > > > yang%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cdf56fa17d > > > 8d64f91ea1f08dc7f25f463%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C > > > 0%7C638525048204684318%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMD > > > AiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sda > > ta=PpSijI6HGOZp7vs7ZHJNEKCf1cgK5TaJaH5yV0c4PJ8%3D&reserved=0 > > > > There is also an HTML version available at: > > > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2 > > Fwww.ietf.org%2Farchive%2Fid%2Fdraft-boucadair-opsawg-secure- > > tacacs-yang- > > > 01.html&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cdf56fa17d > > > 8d64f91ea1f08dc7f25f463%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C > > > 0%7C638525048204698876%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMD > > > AiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sda > > > ta=G0NCidDOYDkOyS%2FQryI%2FscfmESg%2F4bSDaJltJCk2CKA%3D&reserved= > > 0 > > > > A diff from the previous version is available at: > > > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2 > > Fauthor-tools.ietf.org%2Fiddiff%3Furl2%3Ddraft-boucadair- > opsawg- > > secure-tacacs-yang- > > > 01&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cdf56fa17d8d64f > > > 91ea1f08dc7f25f463%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6 > > > 38525048204710333%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJ > > > QIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=Wk > > 0QHm%2B2NaNcdvLSa%2B8T506%2FTSg7SWuBh9yi9Z9kvds%3D&reserved=0 > > > > Internet-Drafts are also available by rsync at: > > rsync.ietf.org::internet-drafts > > > > > > _______________________________________________ > > I-D-Announce mailing list -- i-d-annou...@ietf.org To > unsubscribe send > > an email to i-d-announce-le...@ietf.org > > > _________________________________________________________________ > > ___________________________________________ > > Ce message et ses pieces jointes peuvent contenir des > informations > > confidentielles ou privilegiees et ne doivent donc pas etre > diffuses, > > exploites ou copies sans autorisation. Si vous avez recu ce > message > > par erreur, veuillez le signaler a l'expediteur et le detruire > ainsi > > que les pieces jointes. Les messages electroniques etant > susceptibles > > d'alteration, Orange decline toute responsabilite si ce message > a ete > > altere, deforme ou falsifie. Merci. > > > > This message and its attachments may contain confidential or > > privileged information that may be protected by law; they > should not > > be distributed, used or copied without authorisation. > > If you have received this email in error, please notify the > sender and > > delete this message and its attachments. > > As emails may be altered, Orange is not liable for messages > that have > > been modified, changed or falsified. > > Thank you. > > > > _______________________________________________ > > OPSAWG mailing list -- opsawg@ietf.org To unsubscribe send an > email to > > opsawg-le...@ietf.org > _________________________________________________________________ > ___________________________________________ > Ce message et ses pieces jointes peuvent contenir des > informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous > avez recu ce message par erreur, veuillez le signaler a > l'expediteur et le detruire ainsi que les pieces jointes. Les > messages electroniques etant susceptibles d'alteration, Orange > decline toute responsabilite si ce message a ete altere, deforme > ou falsifie. Merci. > > This message and its attachments may contain confidential or > privileged information that may be protected by law; they should > not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the > sender and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that > have been modified, changed or falsified. > Thank you. > ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ OPSAWG mailing list -- opsawg@ietf.org To unsubscribe send an email to opsawg-le...@ietf.org
