> On Sep 23, 2020, at 5:29 AM, Rafa Marin-Lopez <r...@um.es> wrote: > >> >> >> But I would like to check: My understanding is that the changes that Chris >> is proposing are pretty small. I.e. move the SA structure under >> ipsec-common, and put it under a YANG feature. Are you sure that it is >> impractical to accommodate this change which would allow a single ipsec >> module to be shared and extended via YANG augmentations? > > > In the context of our I-D, if we move SAD structure to ipsec-common, what we > are meaning is that IPsec SA configuration data (setting values to the SAD > structure) are common to the IKE case and the IKE-less cases, which are not. > It is confusing.
Something defined in a common module but marked as a feature does not imply that that feature has to be implemented by an importing module. This is not confusing to YANG implementers or users I think. If we are just talking about document flow here, then a sentence saying "the SAD feature is not required to implement IKE functionality" is quite enough to clear that up I think. Thanks, Chris. > Moreover, the usage of feature means that, after all, this “common” is not > “common” to both cases IKE case and IKE-less. Again, it seems confusing. In > the IKE case, the SDN/I2NSF controller does not configure the SAD at all but > the IKE implementation in the NSF. In our opinion, in order to properly add > this IPsec SA operational state to the IKE case we should include operational > data about the IPsec SAs (config false) to the ietf-ipsec-ike. Alternatively, > we have certain operational data (ro) in the SAD structure in the IKE-less > case. If only those are moved to the common part should be ok but we think it > does not solve the problem. >
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
