Thanks for the quick response, Med. > A diff to track the changes can be found here: https://author-tools.ietf.org/api/iddiff?url_1=https://boucadair.github.io/attachment-circuit-model/draft-ietf-opsawg-teas-attachment-circuit.txt&url_2=https://boucadair.github.io/attachment-circuit-model/opsdir-review/draft-ietf-opsawg-teas-attachment-circuit.txt. 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. >> 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. -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
