Re: [yang-doctors] Yangdoctors early review of draft-ietf-opsawg-nat-yang-06

[<[e-mail]>]

Hi Juergen, all, 

An updated version integrating your comments is available online: 
https://datatracker.ietf.org/doc/draft-ietf-opsawg-nat-yang/ 

Major changes are: 
- use of features
- remove the logging configuration parameters 
- update the security section
- add a section to discuss the relationship with the NAT MIB
 
Cheers,
Med

> -----Message d'origine-----
> De : [e-mail] [mailto:[e-mail]]
> Envoyé : lundi 6 novembre 2017 15:58
> À : Juergen Schoenwaelder
> Cc : [e-mail]; [e-mail];
> [e-mail]
> Objet : RE: Yangdoctors early review of draft-ietf-opsawg-nat-yang-06
> 
> Hi Juergen,
> 
> Thank you for the follow-up and for the suggestions.
> 
> I made the following changes to address your comments:
> 
> - Revert back to the use of features.
> - Leave out the logging container for a future extension.
> - Remove the "VRF" part from the module, but maintain an extensible design
> to easily support VRF in the future.
> 
> FWIW, the updated version of the module which integrates those comments is
> available at:
> https://github.com/boucadair/draft-ietf-opsawg-nat-yang/blob/master/ietf-
> nat%402017-11-06.yang
> 
> Unless you have any further comment, I'm planning to submit this version
> early next week.
> 
> Cheers,
> Med
> 
> > -----Message d'origine-----
> > De : Juergen Schoenwaelder [mailto:[e-mail]]
> > Envoyé : mercredi 1 novembre 2017 11:04
> > À : BOUCADAIR Mohamed IMT/OLN
> > Cc : [e-mail]; [e-mail];
> > [e-mail]
> > Objet : Re: Yangdoctors early review of draft-ietf-opsawg-nat-yang-06
> >
> > On Tue, Oct 31, 2017 at 09:55:46AM +0000, [e-mail]
> > wrote:
> > > > >  That said, there are a number of details where I doubt
> > > > > > the model is correct and things where I believe things are
> > incomplete.
> > > > > > Given that there are many different NAT functions, I also
> expected
> > to
> > > > > > see usage of YANG features.
> > > > >
> > > > > [Med] We used to make use of "features", but there was a comment
> > during
> > > > the WG call for adoption that requested us to make use of
> identities,
> > > > instead.
> > > >
> > > > But these are not the same thing.
> > >
> > > [Med] You are right. Sorry for not being clear.
> > >
> > > What I meant is that the module used, for example, "if-feature nat64"
> > and so on to refer to NAT flavors. We replaced those with "when"
> > statements that points to the actual capabilities of an implementation.
> > > Another change we made, is that we used to have "Boolean" to indicate
> > the support of a given tarnation scheme (e.g., nat64-support, nat44-
> > support), but we updated those to make use of identities.
> >
> > I do not recall having seen these when expressions. But even if there
> > were when expressions, this does not the same as features. A when
> > expression puts a constraint on a valid configuration, a feature
> > expresses that not all parts of a model may be implemented. This is
> > implementation time partitioning vs. configuration time partitioning.
> >
> > >  If I am not a nat64, then apparently
> > > > several objects to not apply to me.
> > >
> > > [Med] Yes. We tried to cover this by "when" statements.
> > >
> > >  This is what features allow you to
> > > > express. Perhaps someone wanted identities for something different,
> I
> > > > do not know. I think it is reasonable to assume that not all NAT
> > > > implementations will support all types of NATs that the model
> supports
> > > > and hence the model should reflect this.
> > > >
> > >
> > > [Med] The module indicates what a given implementation has to support
> > based on its capabilities. This is handled by means of "when"
> statements.
> >
> > This seems to be a mis-understanding of what when expressions do. See
> > above for the explanation.
> >
> > > > > > - What is the vrf-routing-instance identity good for?
> > > > >
> > > > > [Med] This is used to bind a NAT function to an external VRF
> routing
> > > > instance. Please check https://www.ietf.org/mail-
> > > > archive/web/opsawg/current/msg05117.html
> > > > >
> > > >
> > > > I very much doubt that an identity identifies a VRF instance. I am
> not
> > > > questioning the need to identify a VRF, I am questioning that the
> > > > solution put in place achieves this.
> > >
> > > [Med] Thank you for clarifying. This is actually a good point. The
> > options we considered are as follows:
> > >
> > > (1) Use an Identity to avoid struggling with semantics of how a VRF
> can
> > be defined.
> > > (2) Point to draft-ietf-rtgwg-ni-model, likely (?) as a normative
> > reference.
> > > (3) Remove the VRF thing from the draft; future extensions can be
> > defined.
> > >
> > > Given that "VRFs" are not required for all NATs and some reviewers
> asked
> > to add VRFs in addition to interfaces, we went for option (1). Having a
> > dependency on a YANG module under development is not justified for all
> > implementations.
> > >
> >
> > But (1) is broken as far as I can tell. You either work out with the
> > routing guys how to properly refer to a VRF or you better leave this
> > out.
> >
> > > > If leafs are not configurable, then they should be config false.
> > >
> > > [Med] I will revert config to false as we used to have in previous
> > versions. As I said earlier, pyang will cry. I don't know how to fix
> that