Re: [Last-Call] [I2nsf] [yang-doctors] Yangdoctors last call review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-08

[Christian Hopps <chopps@xxxxxxxxxx>]

On Sep 23, 2020, at 5:29 AM, Rafa Marin-Lopez <rafa@xxxxx> 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. 

Attachment: signature.asc
Description: Message signed with OpenPGP

-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call