Hi John, My comments inline: 发件人: I2nsf [mailto:i2nsf-boun...@ietf.org] 代表 John Strassner 发送时间: 2016年6月19日 13:02 收件人: Linda Dunbar; John Strassner 抄送: I2NSF@ietf.org; Dacheng Zhang; DIEGO LOPEZ GARCIA (diego.r.lo...@telefonica.com); Susan Hares 主题: Re: [I2nsf] questions about some terminologies defined by draft-ietf-i2nsf-terminology-00
Hi Linda, these are two different questions: > My thinking maybe too simplistic. > I picture a “Controller” having two ports, > one port connecting to clients ..., interface from this port is “Service > layer interface” > another port connecting to NSFs, the interface from this port is “capability > layer interface”. I think this could be a bit ambiguous. When I think of "southbound interface", I think of a programming interface. The Capability Layer Interface is not a pure programming interface; rather, it is an interface that advertises the set of functions available. It does not define how to program those functions. [Frank]: About the programming interface, I think the capability interface does have this ability. The capability interface can program what security capabilities should be enabled and how they are used by “Event-Condition-Action” (ECA) modeling. In summary, we try to acquire a balance between making the controller to have the largest and most fine-grain control over NSFs and hiding the implementation details that cannot be standardized. > What extra meaning does it carry with the wording “abstraction Layer” ? from my last note, I posited that we did not have an abstraction **layer** - indeed, I'm not sure I know what that means. Rather, we have a **set of abstractions** (which are, of course, the capabilities, which represent a (sub)set of all possible features in the NSFs in a vendor-neutral way). Here is the text of the last note; Diego and Dacheng liked the second of my proposed definitions. [Frank]: For the following definitions, I personally think the first definition is more consistent, but I don’t oppose the second one if most of us think it’s better. On 16 Jun 2016, at 15:05 , John Strassner <straz...@gmail.com<mailto:straz...@gmail.com>> wrote: Hi Dacheng, I agree that "I2NSF system" is not well defined. Your definition is better, but it should apply for all NSFs (not 'the NSF'). In addition, the Capability Layer is not an abstraction layer, it a simply a collection of abstractions (the capabilities). So how about: Capability Layer: Defines the set of capabilities available to the Controller for the set of NSFs that the Controller manages. or Capability Layer: Defines the set of features available to the Controller for the set of NSFs that the Controller manages. On Fri, Jun 17, 2016 at 6:10 PM, Linda Dunbar <linda.dun...@huawei.com<mailto:linda.dun...@huawei.com>> wrote: John, My thinking maybe too simplistic. I picture a “Controller” having two ports, - one port connecting to clients (which can be another domain controller or Overlay network controller), interface from this port is “Service layer interface” - another port connecting to NSFs, the interface from this port is “capability layer interface”. So I thought that the Service Layer interface is the North Bound interface to the Controller, the capability interface is the south bound to the controller. What extra meaning does it carry with the wording “abstraction Layer” ? Capability Layer: Defines an abstraction layer that exposes a set of {features that are available from a managed entity} of the I2NSF system. Thank you. Linda From: John Strassner [mailto:straz...@gmail.com<mailto:straz...@gmail.com>] Sent: Thursday, June 16, 2016 12:58 AM To: Linda Dunbar; John Strassner Cc: Susan Hares; DIEGO LOPEZ GARCIA (diego.r.lo...@telefonica.com<mailto:diego.r.lo...@telefonica.com>); I2NSF@ietf.org<mailto:I2NSF@ietf.org> Subject: Re: questions about some terminologies defined by draft-ietf-i2nsf-terminology-00 HI Linda, I don't see the conflict in the two definitions. If I substitute the first (within braces) into the second, I get: Capability Layer: Defines an abstraction layer that exposes a set of {features that are available from a managed entity} of the I2NSF system. When I look at the Charter's Capability Layer, I think we're still OK - the Charter "...specifies how to control and monitor NSFs at a functional level...", and Capabilities (the features that are available) are essential for planning how to control and monitor NSFs. Features (i.e., capabilities) are independent of interface (northbound or southbound). Would you like us to add that point to the terminology I-D? best regards, John On Wed, Jun 15, 2016 at 8:40 AM, Linda Dunbar <linda.dun...@huawei.com<mailto:linda.dun...@huawei.com>> wrote: Dear Authors: The term “Capability Layer” defined by the “draft-ietf-i2nsf-terminology-00” carries different meaning than the “Capability Layer” used by the I2NSF charter. “draft-ietf-i2nsf-terminology-00”: Capability: Defines a set of features that are available from a managed entity (see also I2NSF Capability). Capability Layer: Defines an abstraction layer that exposes a set of capabilities of the I2NSF system. I2NSF Charter: I2NSF will specify interfaces at two functional levels for the control and monitoring of network security functions: The I2NSF Capability Layer specifies how to control and monitor NSFs at a functional implementation level. The term "Functional Implementation" is used to emphasize that the rules (for control and monitor) of NSFs have to be implementable by most NSFs. I2NSF will standardize a set of interfaces by which a security controller can invoke, operate, and monitor NSFs. The I2NSF Service Layer defines how clients' security policies may be expressed to a security controller. The controller implements its policies according to the various capabilities provided by the I2NSF Capability Layer. The I2NSF Service Layer also allows the client to monitor the client specific policies. If we use the definitions by the “draft-ietf-i2nsf-terminology-00”, we should create a different terminology to represent the “South bound Interface” between Controller and NSF. Thanks, Linda -- regards, John -- regards, John
_______________________________________________ I2nsf mailing list I2nsf@ietf.org https://www.ietf.org/mailman/listinfo/i2nsf
