Hi, Sorry I missed this question. I think it probably can be solved; but see below. "Rob Wilton (rwilton)" <rwilton@xxxxxxxxx> wrote: > Hi draft authors, Chris, > > Can we also please try and close on this issue raised by Chris. > > Chris, I don’t think that there is any great way to solve this issue > using YANG features, but presumably the constraint could be enforced > with a must statement, or groupings could be used to copy parts of the > ipsec structure into an sdn specific ipsec tree structure. > > I understand that there isn't any great desire to delay these drafts > by trying to generalize the ipsec YANG model contained within it. > However, I think that means that the modules should have "-sdn-" in > their names to indicate that they are intended specifically for the > SDN use case, and should not be confused with the more generic ipsec > YANG modules that have been proposed. > > Regards, > Rob > > > > -----Original Message----- > > From: yang-doctors <yang-doctors-bounces@xxxxxxxx> On Behalf Of > > Christian > > Hopps > > Sent: 24 August 2020 18:08 > > To: Martin Björklund <mbj+ietf@xxxxxxx> > > Cc: i2nsf@xxxxxxxx; draft-ietf-i2nsf-sdn-ipsec-flow- > > protection.all@xxxxxxxx; ipsec@xxxxxxxx; last-call@xxxxxxxx; yang- > > doctors@xxxxxxxx > > Subject: Re: [yang-doctors] Yangdoctors last call review of > > draft-ietf- > > i2nsf-sdn-ipsec-flow-protection-08 > > > > [adding in ipsec@] > > > > Hi, > > > > This draft was discussed in ipsecme at the last IETF, and there was a > > desire to look closer at a couple changes that would make these models > > usable by ipsec generally rather than only for SDNs. Otherwise we will > > end > > up with 2 models that look very similar and duplicate almost all the > > functionality. This was going to be done during the next yang doctor > > review, but it looks like that happened in the meantime (ships in the > > night). > > > > At minimum the module names should include "-sdn-" if no other changes > > are > > made to indicate that they are only for sdn use; however, this is not > > the > > optimal solution. > > > > A better solution would be to move the containers currently under > > ikeless > > (for SA and Policy databases) under ipsec-common. Are we talking about /ipsec-ikeless/spd and /ipsec-ikeless/sad? If these are moved to another module, ipsec-ikeless becomes empty (if also the related notifs are moved). Why do you want to move them? It is b/c they are under "ipsec-ikeless"? If so, perhaps a simpler solution is to use another (more generic) name for the module and top-level container. If they are moved to ietf-ipsec-common, an implementation that implements ietf-ipsec-ike can still import ietf-ipsec-common, but choose to not implement it (it will show up as an 'import-only-module' in yang library). /martin > > The feedback I received from the authors was that the SDN controllers > > didn't care about the actual SAs and policies when using IKE so they > > didn't want to require someone implementing ike+common modules to have > > to > > support them. > > > > The YANG question I suppose is, is there an easy way to move these > > containers from ipsec-ikeless to ipsec-common, but still allow for > > them to > > be empty and/or unimplemented for the SDN IKE use case? If they were > > made > > features, is there a proper YANG way to indicate that if the ikeless > > module is present then those features must also be supported thus > > matching > > the functionality as defined by the current draft? > > > > Thanks, > > Chris. > > > > > > > > > On Aug 24, 2020, at 10:37 AM, Martin Björklund via Datatracker > > <noreply@xxxxxxxx> wrote: > > > > > > Reviewer: Martin Björklund > > > Review result: Ready with Nits > > > > > > I did an early YANG Doctor's review of this draft. Most of my > > > comments then have been addressed in this version. > > > > > > Comments: > > > > > > o As I wrote in my early review, the RFC editor enforces a common > > > format of YANG modules, so it is better to adhere to this format > > > before sending the draft to the RFC editor. Use > > > > > > pyang -f yang --yang-line-length 69 <FILE> > > > > > > to get a consistent look-and-feel for your module. > > > > > > (You will have to manually re-flow description statements after > > > this.) > > > > > > > > > o There are some leafs that are optional in the model, but w/o a > > > default value and w/o an explanation of what happens if that leaf > > > is not set. You should find those and either make them mandatory, > > > add a default value, or explain what it means when it isn't set. > > > As an example, > > > /ipsec-ike/pad/pad-entrypeer-authenticatin/pre-shared/secret > > > is optional. I suspect that this leaf needs to be mandatory. > > > Another example is the leaf espencap. > > > > > > > > > /martin > > > > > > > > > _______________________________________________ > > > yang-doctors mailing list > > > yang-doctors@xxxxxxxx > > > https://www.ietf.org/mailman/listinfo/yang-doctors > -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
