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

[Martin Björklund <[e-mail]>]

Hi,

Christian Hopps <[e-mail]> wrote:
> 
> 
> > On Sep 23, 2020, at 5:29 AM, Rafa Marin-Lopez <[e-mail]> 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.

Another alternative could be to move these containers to another
(new) module.


/martin



> 
> 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.
> > 
>