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 : [email protected] [mailto:[email protected]] > Envoyé : lundi 6 novembre 2017 15:58 > À : Juergen Schoenwaelder > Cc : [email protected]; [email protected]; > [email protected] > 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:[email protected]] > > Envoyé : mercredi 1 novembre 2017 11:04 > > À : BOUCADAIR Mohamed IMT/OLN > > Cc : [email protected]; [email protected]; > > [email protected] > > Objet : Re: Yangdoctors early review of draft-ietf-opsawg-nat-yang-06 > > > > On Tue, Oct 31, 2017 at 09:55:46AM +0000, [email protected] > > 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 _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
