Re-,
Good catch. Please see
https://github.com/boucadair/secure-tacacs-yang/pull/13/files
Thanks.
Cheers,
Med
De : Joe Clarke (jclarke) <jclarke=40cisco....@dmarc.ietf.org>
Envoyé : vendredi 7 mars 2025 17:19
À : Joe Clarke (jclarke) <jclarke=40cisco....@dmarc.ietf.org>; opsawg@ietf.org
Objet : [OPSAWG]Re: WGLC/Shepherd comments for TACACS+ TLS YANG
(draft-ietf-opsawg-secure-tacacs-yang)
Adding on to this, there is an issue with the YANG module, which is throwing a
warning.
OLD:
leaf vrf-instance {
type leafref {
path "/ni:network-instances/ni:network-instance/ni:name";
}
must "(not(../source-interface)) or "
+ "(current() = /if:interfaces/if:interface"
+ "[if:name = current()/../source-interface]"
+ "/bind-ni-name)" {
error-message
"VRF instance must match the network instance of the
source interface.";
}
NEW:
leaf vrf-instance {
type leafref {
path "/ni:network-instances/ni:network-instance/ni:name";
}
must "(not(../source-interface)) or "
+ "(current() = /if:interfaces/if:interface"
+ "[if:name = current()/../source-interface]"
+ "/ni:bind-ni-name)" {
error-message
"VRF instance must match the network instance of the
source interface.";
}
That is, fix the namespace for bind-ni-name.
Joe
From: Joe Clarke (jclarke)
<jclarke=40cisco....@dmarc.ietf.org<mailto:jclarke=40cisco....@dmarc.ietf.org>>
Date: Friday, March 7, 2025 at 10:58
To: opsawg@ietf.org<mailto:opsawg@ietf.org>
<opsawg@ietf.org<mailto:opsawg@ietf.org>>
Subject: [OPSAWG]WGLC/Shepherd comments for TACACS+ TLS YANG
(draft-ietf-opsawg-secure-tacacs-yang)
I have reviewed the latest version of this draft, and I think it's in good
shape overall. However, I did find a few typos and I have a few requests for
clarification and changes. I like Med's approach to the "track changes", so
I'm attaching the PDF of that here. To summarize my more substantive comments:
· I'd like to see discontinuity defined more clearly
· The PSK context should have a length reflected in YANG
· While more for the main TACACS+ TLS draft, the use of Server vs.
server should probably be normalized
And while not in my track changes comments, I have a question. In your
appendix B, you have examples with SNI enabled where each of the four specified
servers uses the same domain name. Is that an approach that is typically done?
In my TACACS+ deployments, I generally have primary and secondary servers, but
each have their own FQDN. And I imagine when I deploy TACACS+ TLS, I would
have the same server certificates. That is, each server would have its own
FQDN/SNI. Though I admit v4 and v6 would be two sides of the same server.
Joe
____________________________________________________________________________________________________________
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
