Hi Adrian, Thank you for the follow-up.
I merged these changes right now and also reflected some of them in the other documents of the AC I-Ds set. Please see inline. Cheers, Med > -----Message d'origine----- > De : Adrian Farrel <adr...@olddog.co.uk> > Envoyé : mercredi 8 janvier 2025 19:04 > À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com>; > ops-...@ietf.org > Cc : draft-ietf-opsawg-teas-attachment-circuit....@ietf.org; > last-c...@ietf.org; opsawg@ietf.org > Objet : RE: [Last-Call] Re: Opsdir telechat review of draft-ietf- > opsawg-teas-attachment-circuit-18 > > > Thanks for the quick response, Med. > > > A diff to track the changes can be found here: > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2 > Fauthor- > tools.ietf.org%2Fapi%2Fiddiff%3Furl_1%3Dhttps%3A%2F%2Fboucadair.g > ithub.io%2Fattachment-circuit-model%2Fdraft-ietf-opsawg-teas- > attachment- > circuit.txt%26url_2%3Dhttps%3A%2F%2Fboucadair.github.io%2Fattachm > ent-circuit-model%2Fopsdir-review%2Fdraft-ietf-opsawg-teas- > attachment- > circuit.txt&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C3e852 > e3a53c84ff249e108dd300ee03a%7C90c7a20af34b40bfbc48b9253b6f5d20%7C > 0%7C0%7C638719562630950158%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcG > kiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIld > UIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=R1KeNYQjOIJsFz8VtyP2AD7udW5xDbn5 > z9i3BmY7Jmo%3D&reserved=0. Also fixed some nits here and there. > > All very good changes. > Just continuing two minor points. > > No need to respond to me (unless you want to): just fix or don't > fix according to what is the right thing to do. > > Cheers, > Adrian > > >> 6.1 > >> > >> I was surprised that there are so few identities defined in > base > >> bearer-type. Does this reflect reality or convenience? > > > > [Med] The goal was not to be exhaustive but have the key ones. > > It's OK. I was just thinking about whether (and how) people will > need to add new bearer types in the future. > [Med] This is an issue which is not specific to this module. Things would be much more simple if we proceed with approaches such as what is proposed in https://datatracker.ietf.org/doc/draft-boucadair-veloce-yang/ With the current practices, new identities can be added in a future revision of the module or by deviation. Defining arbitrary identities for exhaustiveness is not better either because there is currently no way in YANG/RC/NC that a subset of identities are not implemented. This is an issue that is queued for yang-next, e.g., https://github.com/netmod-wg/yang-next/issues/107. I can point to other relevant issues. This is the reason the draft has only the key ones. > >> 7. > >> > >> I like that you flag 'customer-name' as a vulnerability. But I > don't > >> understand what solution you offer. I suspect that the > solution lies > >> in authentication being applied to control read access not > only to > >> the whole module, but to specific sub-trees in the module. > This needs > >> a little additional text to make it clear. > > > > [Med] This is a covered by this text: > > > > "These > > protocols have to use a secure transport layer (e.g., SSH > [RFC4252], > > TLS [RFC8446], and QUIC [RFC9000]) and have to use mutual > > authentication." > > > > Please note that we are using the security template defined in > > draft-ietf-netmod-rfc8407bis. > > I'm not arguing against anything in the template text or what you > have written. > I am asking whether the authentication grants access to the whole > module or only specific parts. In other words, can someone from > customer A see: > - the existence of customer B > - any information about customer B > A secure transport layer doesn't provide that protection. > And "mutual authentication" is unclear. > [Med] Thank you for clarifying. This is indeed a separate aspect that is covered by the para next the one quoted above. This is related the RBAC guards used out there. The client identity is used to tag which piece of data/operation a client is entitled to. We don't repeat this considerations here as this is covered by rfc8341#section-3.4.5. After thinking about this, I don't think it is harmful to remind this. I made this change: OLD: The Network Configuration Access Control Model (NACM) [RFC8341] provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. NEW: Servers MUST verify that requesting clients are entitled to access and manipulate a given bearer or AC. For example, a given customer must have access only to its bearers/ACs and be discarded access to bearers/ACs of other customers. The Network Configuration Access Control Model (NACM) [RFC8341] provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. ____________________________________________________________________________________________________________ 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
