Gabriel and Rofa, Just to clarify: the purpose of asking you changing from "container.." to "grouping.." is for "i2nsf-nsf-facing-interface-dm" to the "ikev2" and "ietf-ipsec" structure defined in draft-ietf-i2nsf-sdn-ipsec-flow-protection. Not other way around, i.e. not asking draft-ietf-i2nsf-sdn-ipsec-flow-protection to import other properties.
By the way, i2nsf-nsf-facing-interface-dm only imported two other data structure "ietf-inet-types" & "ietf-yang-types" besides the "ikev2" and "ietf-ipsec". It has nothing to do with other modules for TTL, SSL, etc. Thanks, Linda On Tue, May 21, 2019 at 3:42 AM Gabriel Lopez <[email protected]> wrote: > Hi Linda, Paul. > > El 20 may 2019, a las 19:52, Linda Dunbar <[email protected]> escribió: > > Gabriel, > > Thanks for the explanation. > > Agree with you that *"it does not imply to extend the NSF client > interface to include all the available yang models for every security > service a NSF can support.". * > But a network function that supports I2NSF should be allowed to your IPsec > module, should it? > > > Sure. > > Regards, Gabi. > > P.D. Linda, be aware you have included other email destination addresses > in the “subject” field of our email. > > > > > > what does it mean by you saying the following? > "the Actual IPsec Configuration" is not same as "our I2NSF interface"? > > *That is, our data models assume that the actual IPsec configuration will > be handled by Rafa's IPsec module through NETCONF, and* > *our I2NSF interfaces will do nothing related to the IPsec configuration.* > > > Thanks, Linda > > > ---------------------- > > Hi Paul, Linda. > > > Thanks again for your comments. > > > El 18 may 2019, a las 7:11, Mr. Jaehoon Paul Jeong <[email protected]> > escribió: > > > Hi Linda, > For your first question, > it seems like Gabriel does not like to modify their code to let NSF-Facing > Interface data module import ikev2 and ietf-ipsec (i.e., ike-less) > according to IETF YANG conventions such as TLS, SSH, IDS, and ACL. > In our data models, we will specify whether an NSF supports an IPsec > configuration mechanism (IKEv2 or IKEless), > or does not support any IPsec configuration mechanism. > That is, our data models assume that the actual IPsec configuration will > be handled by Rafa's IPsec module through NETCONF, and > our I2NSF interfaces will do nothing related to the IPsec configuration. > > > > > > > The question is not whether I (we) like or don't like to modify the model.. > The question is whether it is the best technical approach or not. > As said before, the ipsec model has been designed to work in a standalone > mode in a NSF, so the controller can configure ipsec on NSFs without any > other module. > > > You mention the consensous on the last meeting, but what I get from this > consensous is to study how, making use of the capability model, the > controller can learn if the NSF node supports IKE case or IKE-less case, > and then in the discussion there is a mention to a "reference" to the > corresponding data model implementing these capabilities (our model) (here > the "reference" clause could be used). But it does not imply to extend the > NSF client interface to include all the available yang models for every > security service a NSF can support. > > > Our main concerns is if the objective of the nsf-client-dm is: > > > - To import all other models (SSH, TLS, ALCs, etc...) just for sake of > having all of them gathered in a single model (nsf-client-dm). But I don't > see the benefit. In fact, SSH or TLS yang models are designed to be used by > other yang model for especific applications, such as a model for HTTPS > importing the TLS model or a model for a SSH server importing the SSH > model. What is the service in this case?. In the case of the ACL yang > module, it is also defined to work in a standalone mode (no main grouping > based). In the case of IDS, could you point out the yang module? > > > - To adapt them in some way to the ECA model. The ECA model is the > keystone of the nsf-client-dm, as described in section 4. If it is the > case, then it is difficult to see examples of how they can be adapted. > > > > > Said that, the draft is a WG item and the WG has to decide what is the > right way to proceed. > > > Regards, Gabi. > > > ----------------------------------------------------------- > Gabriel López Millán > Departamento de Ingeniería de la Información y las Comunicaciones > University of Murcia > Spain > Tel: +34 868888504 > Fax: +34 868884151 > email: [email protected] <[email protected]> > > > >
_______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
