+1 Let's foster different APIs derived from (or relying on) the capability interface. That would the support of different use cases and help create diversity, so scarce in these days of one-OpenStack-fits-all...
-- Likely to be brief and not very elaborate as sent from my mobile Diego R. Lopez Telefonica I+D On 20 Jun 2016, at 20:32, John Strassner <[email protected]<mailto:[email protected]>> wrote: Hi Rajasekhar, the Capability Interface is used to announce the set of functions that are available. We haven't specified further details yet, though I assume that such functions would be limited to a common administrative domain. In that sense, Firewall, Anti-Virus, IDP, and others would be available. However, I do not think that the Capability Interface should be overloaded and turned into a programming interface. Precedence exists in, for example, OMA and other systems, where there are separate capability and programming interfaces. We should do the same in I2NSF. best regards, John On Mon, Jun 20, 2016 at 10:58 PM, Ganduri, Rajasekhar <[email protected]<mailto:[email protected]>> wrote: Hi John, Thanks for the note about the capability layer. I understand your point and I feel that abstraction may be more precise than abstraction layer. In your second definition of "Capability Layer", what can be the "set of features available to the Controller", for eg., in IDS or Firewall. I visualized the capability interface as the commanding interface which gives a set of instructions to the NSFs on what to do and receives feedback from the NSFs once the set of instructions are implemented. Regards, Rajasekhar ________________________________ From: John Strassner <[email protected]<mailto:[email protected]>> Sent: Sunday, June 19, 2016 10:17:42 PM To: Ganduri, Rajasekhar Cc: Linda Dunbar; [email protected]<mailto:[email protected]>; DIEGO LOPEZ GARCIA ([email protected]<mailto:[email protected]>); Susan Hares Subject: Re: [I2nsf] questions about some terminologies defined by draft-ietf-i2nsf-terminology-00 Hi Rajasekhar, please see my last reply to Linda. For me, I don't think that an abstraction **layer** makes sense. A layer should be used to abstract a common set of functionality - otherwise, you have a set of abstractions of different functions that mean different things. best regards, John On Sat, Jun 18, 2016 at 12:07 AM, Ganduri, Rajasekhar <[email protected]<mailto:[email protected]>> wrote: Hey, I am a novice in I2NSF IETF group and its capabilities but I am a regular follower of the current activities of I2NSF. According to my understanding, the term "abstraction layer" is used to specify that the end user/client need not have the complete visibility of the working or implementation of how the I2NSF controller communicates with the NSFs. This is what interested me in I2NSF, as this opens up to a new set of end users who need not have complete understanding of how a network operates. I implemented this in my research, where a web application tool is built that can be used by "any" end user to give simple natural language inputs through Interface1 (Service Layer) to the controller (or Openstack Cloud controller in my case) and the controller translates and transfers the security commands to the IDS and firewalls through Interface2(Capability layer). The way in which the controller transfers to the NSFs is hidden from the end user (or the end user need not know, details being hidden or abstracted) but the end user will have the authority over Interface2 in his/her own network. Please let me know if I understood wrongly. Thanks and Regards, Rajasekhar ________________________________ From: Linda Dunbar <[email protected]<mailto:[email protected]>> Sent: Friday, June 17, 2016 4:10 AM To: John Strassner Cc: [email protected]<mailto:[email protected]>; DIEGO LOPEZ GARCIA ([email protected]<mailto:[email protected]>); Susan Hares Subject: Re: [I2nsf] questions about some terminologies defined by draft-ietf-i2nsf-terminology-00 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:[email protected]<mailto:[email protected]>] Sent: Thursday, June 16, 2016 12:58 AM To: Linda Dunbar; John Strassner Cc: Susan Hares; DIEGO LOPEZ GARCIA ([email protected]<mailto:[email protected]>); [email protected]<mailto:[email protected]> 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 <[email protected]<mailto:[email protected]>> 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 -- regards, John ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción. The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição
_______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
