Hi Linda: > El 21 may 2019, a las 23:02, Linda Dunbar <[email protected]> escribió: > > 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.
Yes, that was clear from the beginning. One of the concern I see is the following: If the industry only wants to implement draft-ietf-i2nsf-sdn-ipsec-flow-protection for IPsec management, it can do it only if we leave the document as it is. In other words, the ideas in the document were designed to be standalone and that is why the container definition. For example, if you check https://tools.ietf.org/html/rfc8519 my understanding is a device can deploy that RFC to manage ACLs. It does not need to implement anything else. IPsec YANG model is defined in the same way. If we change from “container” to “grouping ..” then we would remove that option which, in my opinion, is not good. I think Paul’s suggestion is in this line as well when he mentioned that their data models assumed that the actual IPsec configuration will be handled by IPsec module through NETCONF (draft-ietf-i2nsf-sdn-ipsec-flow-protection), and our I2NSF interfaces will do nothing related to the IPsec configuration. In other words, it seems to me there is no need to integrate both. Best Regards. > 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] > <mailto:[email protected]>> wrote: > Hi Linda, Paul. > >> El 20 may 2019, a las 19:52, Linda Dunbar <[email protected] >> <mailto:[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] >> <mailto:[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] <mailto:[email protected]> > > > > _______________________________________________ > I2nsf mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/i2nsf
_______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
