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

Hi,

Sorry I missed this question.

I think it probably can be solved; but see below.

"Rob Wilton (rwilton)" <rwilton@cisco.com> 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@ietf.org> On Behalf Of
> > Christian
> > Hopps
> > Sent: 24 August 2020 18:08
> > To: Martin Björklund <mbj+ietf@4668.se>
> > Cc: i2nsf@ietf.org; draft-ietf-i2nsf-sdn-ipsec-flow-
> > protection.all@ietf.org; ipsec@ietf.org; last-call@ietf.org; yang-
> > doctors@ietf.org
> > 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@ietf.org> 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@ietf.org
> > > https://www.ietf.org/mailman/listinfo/yang-doctors
> 