Linda, I read the draft. https://datatracker.ietf.org/doc/draft-ietf-i2nsf-client-facing-interface-req/
We will provide some comments from the point of view of our network security automation use case. # Our team especially studies about security operation automation between controller and NSF, not between user and controller. So we want to provide only general comments. - About Basic rules for Client-Facing Interface definition Vendor-independence is very important thing for carrier NW's operation. We think independence of NSF's version is important too. We think it's problem that client-facing interface depends on NSF's version. If client-facing interface depends on NSF's version, it means I2NSF RESTful API depends on NSF's version. So it means automation program which uses the API has to be changed at every version up. - About attack traffic transport We consider that network security operators want to analyze attack traffic by using appropriate NSFs, so network should transport attack traffic to the NSFs easily. We think it's important thing that client-facing interface enables network security operator to do so easily. Yuhei ----------------------------------------- Nippon Telegraph and Telephone Corporation Network Service Systems Laboratories Transport Service Systems Development Project Transport Service Platform Innovation Project Yuhei Hayashi 0422-59-3485 [email protected] _______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
