+1 Hi. I am Hyunsik Yang. I joined I2NSF hackathon from IETF102 to IETF105 and I am an author of NFV draft.
I agree with Paul's opinion based on my experience of I2NSF Hackathon. In order to use I2NSF in a real environment, I think we should provide a document for guidelines on how to use it in addition to the basic framework. Although the document couldn't reflect all use cases, I think we can provide a basic direction to user who use I2NSF Framework. Therefore, security policy translator draft also can be a good guideline. In addition, from an implementation point of view, I think current interface is not enough since it only deal with internal interface. We also need to define additional interfaces or information model to use I2NSF in real world such as interface for VNFM and SFC controller. I knew that this is not part of the current I2NSF WG scope, but, if I2NSF WG is going to re-chartering phase, I think it is necessary to add those item to re-chartering. > 2019. 7. 26. 오후 12:40, Mr. Jaehoon Paul Jeong <[email protected]> 작성: > > Hi Roman and I2NSF WG, > Though the system components of the I2NSF system (e.g., security policy > translator) are not in the scope of > I2NSF WG, key components such as I2NSF User, Security Controller, and > Developer's Management System (DMS) > need standard documents to let developers and operators grasp what > information and parameters are required and > exchanged among those components. > > Those documents can be published as Informational RFCs to provide the > developers and operators with > the guidelines to build their own components interoperable with other > components in the I2NSF system. > > For an example, the security policy translation draft provides the audience > with such guidelines > in terms of the design of implementation of their own security policy > translator. > https://tools.ietf.org/html/draft-yang-i2nsf-security-policy-translation-04 > <https://tools.ietf.org/html/draft-yang-i2nsf-security-policy-translation-04> > > > To let the security policy translator perform security policy translation, it > requires > the relationship between the consumer-facing interface and the nsf-facing > interface data models. > This document explains such relationship (or mapping) between the two > interfaces. > With the explicit representation of such a mapping, the developers need to > figure it out. > It will be time-consuming and may mislead them. > > It also explains what information (e.g., IP addresses of a user's devices and > website URLs) should > be populated into the NSF database for security policy translation in the > Security Controller. > This information needs to delivered from the I2NSF User to the Security > Controller. > Assuming that the I2NSF User and the Security Controller are developed by two > different operators and vendors, > an interface between them should be standardized for interoperability. > As said during today's WG session, this security policy translation draft > will target at an Informational RFC. > > For another example, the draft of I2NSF on NFV reference architecture > provides the operators and > developers with the guidelines of how to build the I2NSF system on the NFV > architecture. > https://tools.ietf.org/html/draft-yang-i2nsf-nfv-architecture-05 > <https://tools.ietf.org/html/draft-yang-i2nsf-nfv-architecture-05> > > The draft explains the initial configuration procedure in NFV architecture. > When a proper NSF is not activated yet in the I2NSF system, the Security > Controller > sends an NSF initiation request to the DMSs which has (or may have) the > required NSF, > as shown in Figure 2 in the draft. > In this case, the DMS sends an NSF initiation request to the VNF Manager > (VNFM) using the Ve-Vnfm interface > that is an ETSI NFV interface. This DMS NSF initiation request should be > specified by > the I2NSF system. This draft will describe the contents and format of the > request in > the next revision. Thus, this will help the vendors and operators easily > implement the I2NSF > in the NSF architecture. > > During the last 9 I2NSF hackathon projects, my team recognized the necessity > of > the drafts for the functionality and parameters of the I2NSF system > components. > I believe that these drafts will accelerate the development and development > of > I2NSF in the real world. > > I think our I2NSF WG needs to recharter toward the second phase. > > Thanks. > > Best Regards, > Paul > > > On Thu, Jul 25, 2019 at 4:45 PM Roman Danyliw <[email protected] > <mailto:[email protected]>> wrote: > Hello! > > During today's F2F meeting, we discussed the need to check the charter scope > of the work proposed in draft-yang-i2nsf-security-policy-translation. Making > no value judgement on the utility of the work, in my review of the current > charter, this class of work is not in scope. The current charter doesn't > currently cover standardization activity inside the NSF/DMS/controller. > > If the WG wants to re-charter, by all means, let's have that conversation. > > Roman > > > _______________________________________________ > I2nsf mailing list > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/i2nsf > <https://www.ietf.org/mailman/listinfo/i2nsf> > > > -- > =========================== > Mr. Jaehoon (Paul) Jeong, Ph.D. > Associate Professor > Department of Software > Sungkyunkwan University > Office: +82-31-299-4957 > Email: [email protected] <mailto:[email protected]>, > [email protected] <mailto:[email protected]> > Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php > <http://cpslab.skku.edu/people-jaehoon-jeong.php> > _______________________________________________ > I2nsf mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/i2nsf
_______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
