Re: [I2nsf] questions about some terminologies defined by draft-ietf-i2nsf-terminology-00
Hi John, Thanks for your response. Let me take a look the latest draft as you suggested and I would share my thoughts. I think there is a discussion scheduled on terminology topic (If I remember the agenda sent out recently), we can discuss further there. Thanks & Regards, Rakesh From: John Strassner mailto:john.sc.strass...@huawei.com>> Date: Monday, July 11, 2016 at 4:26 PM To: Rakesh Kumar mailto:rkku...@juniper.net>>, "Xialiang (Frank)" mailto:frank.xiali...@huawei.com>>, "Diego R. Lopez" mailto:diego.r.lo...@telefonica.com>>, John Strassner mailto:straz...@gmail.com>>, Linda Dunbar mailto:linda.dun...@huawei.com>> Cc: "Natale, Bob" mailto:rnat...@mitre.org>>, "I2NSF@ietf.org<mailto:I2NSF@ietf.org>" mailto:I2NSF@ietf.org>>, Dacheng Zhang mailto:dacheng....@alibaba-inc.com>> Subject: RE: [I2nsf] questions about some terminologies defined by draft-ietf-i2nsf-terminology-00 Hi Rakesh, please see inline... regards, John From: Rakesh Kumar [mailto:rkku...@juniper.net] Sent: Friday, July 08, 2016 11:57 AM To: Xialiang (Frank); Diego R. Lopez; John Strassner Cc: Natale, Bob; Susan Hares; John Strassner; i2nsf@ietf.org<mailto:i2nsf@ietf.org>; Dacheng Zhang; Linda Dunbar; Rakesh Kumar Subject: Re: [I2nsf] questions about some terminologies defined by draft-ietf-i2nsf-terminology-00 Hi Frank, Thanks for the comments. IMHO, it would be great if our terminology 1. Align well with other work in the industry (I am pretty sure there are other service orchestration system/controller in the standard bodies and open source). What does a security terminology draft have to do with orchestration? While there might be some overlap in some terms, many orchestration systems do not consider security at the level of detail that we need. We have already identified terminology that we do not want to reuse (e.g., "northbound" and "southbound"). Finally, I personally think that it would be better to align with other security WGs in the IETF (e.g., sacm) and THEN expand to outside of IETF security WGs. If you disagree, it would be helpful for you to send a specific example of terminology from another SDO or other open source project that you are worried about. 2. Communicates clearly the intention of these interface on terminology we choose. This implies that the definition of these terms is incorrect. Please review the latest draft (-01) and provide concrete suggestions to fix. 3. The end-customer/consumer find these interfaces intuitive. The end-customer could be * An uber-controller that uses I2NSF defined security controller to provision security policies * A GUI system used by admin to provision security policies * OSS/BSS system from service provider * Thirty party APP written on top of I2NSF controller Or an end-user. However, my point is that the terminology document will not define interfaces; it will only provide documentation on terms that interfaces use. Is there a specific point here for the terminology document to address? It would be great to discuss various options discussed so far in this group and see which ones are the most appropriate. Once we agree on top level, it would be great to create classification/categories for these interfaces on either side of the controller so that our work/drafts communicate clearly, the specific area[s] targeted. I just sent this classification to start a wider discussion. I look towards the group and help from chairs to see how to carry it forward and whether to fold this into existing draft or not. It would be great if we bring this up in Berlin. Thanks & Regards, Rakesh From: "Xialiang (Frank)" mailto:frank.xiali...@huawei.com>> Date: Sunday, July 3, 2016 at 7:39 PM To: "Diego R. Lopez" mailto:diego.r.lo...@telefonica.com>>, John Strassner mailto:john.sc.strass...@huawei.com>> Cc: Rakesh Kumar mailto:rkku...@juniper.net>>, "Natale, Bob" mailto:rnat...@mitre.org>>, Susan Hares mailto:sha...@ndzh.com>>, John Strassner mailto:straz...@gmail.com>>, "i2nsf@ietf.org<mailto:i2nsf@ietf.org>" mailto:i2nsf@ietf.org>>, Dacheng Zhang mailto:dacheng@alibaba-inc.com>>, Linda Dunbar mailto:linda.dun...@huawei.com>> Subject: Re: [I2nsf] questions about some terminologies defined by draft-ietf-i2nsf-terminology-00 Hi all, Firstly, I fully support John’s argument that we should avoid using the “northbound/southbound” concept here, since they are recursive and cannot be specific. Secondly, I like the idea from Rakesh of a clear classification for the I2NSF NSF-Facing interface, I think his current naming is ok, but we can maybe find more better names. In addition, I think “capability interface” and “programming interface” are also appli
Re: [I2nsf] questions about some terminologies defined by draft-ietf-i2nsf-terminology-00
Hi Rakesh, please see inline... regards, John From: Rakesh Kumar [mailto:rkku...@juniper.net] Sent: Friday, July 08, 2016 11:57 AM To: Xialiang (Frank); Diego R. Lopez; John Strassner Cc: Natale, Bob; Susan Hares; John Strassner; i2nsf@ietf.org; Dacheng Zhang; Linda Dunbar; Rakesh Kumar Subject: Re: [I2nsf] questions about some terminologies defined by draft-ietf-i2nsf-terminology-00 Hi Frank, Thanks for the comments. IMHO, it would be great if our terminology 1. Align well with other work in the industry (I am pretty sure there are other service orchestration system/controller in the standard bodies and open source). What does a security terminology draft have to do with orchestration? While there might be some overlap in some terms, many orchestration systems do not consider security at the level of detail that we need. We have already identified terminology that we do not want to reuse (e.g., "northbound" and "southbound"). Finally, I personally think that it would be better to align with other security WGs in the IETF (e.g., sacm) and THEN expand to outside of IETF security WGs. If you disagree, it would be helpful for you to send a specific example of terminology from another SDO or other open source project that you are worried about. 2. Communicates clearly the intention of these interface on terminology we choose. This implies that the definition of these terms is incorrect. Please review the latest draft (-01) and provide concrete suggestions to fix. 3. The end-customer/consumer find these interfaces intuitive. The end-customer could be * An uber-controller that uses I2NSF defined security controller to provision security policies * A GUI system used by admin to provision security policies * OSS/BSS system from service provider * Thirty party APP written on top of I2NSF controller Or an end-user. However, my point is that the terminology document will not define interfaces; it will only provide documentation on terms that interfaces use. Is there a specific point here for the terminology document to address? It would be great to discuss various options discussed so far in this group and see which ones are the most appropriate. Once we agree on top level, it would be great to create classification/categories for these interfaces on either side of the controller so that our work/drafts communicate clearly, the specific area[s] targeted. I just sent this classification to start a wider discussion. I look towards the group and help from chairs to see how to carry it forward and whether to fold this into existing draft or not. It would be great if we bring this up in Berlin. Thanks & Regards, Rakesh From: "Xialiang (Frank)" mailto:frank.xiali...@huawei.com>> Date: Sunday, July 3, 2016 at 7:39 PM To: "Diego R. Lopez" mailto:diego.r.lo...@telefonica.com>>, John Strassner mailto:john.sc.strass...@huawei.com>> Cc: Rakesh Kumar mailto:rkku...@juniper.net>>, "Natale, Bob" mailto:rnat...@mitre.org>>, Susan Hares mailto:sha...@ndzh.com>>, John Strassner mailto:straz...@gmail.com>>, "i2nsf@ietf.org<mailto:i2nsf@ietf.org>" mailto:i2nsf@ietf.org>>, Dacheng Zhang mailto:dacheng@alibaba-inc.com>>, Linda Dunbar mailto:linda.dun...@huawei.com>> Subject: Re: [I2nsf] questions about some terminologies defined by draft-ietf-i2nsf-terminology-00 Hi all, Firstly, I fully support John’s argument that we should avoid using the “northbound/southbound” concept here, since they are recursive and cannot be specific. Secondly, I like the idea from Rakesh of a clear classification for the I2NSF NSF-Facing interface, I think his current naming is ok, but we can maybe find more better names. In addition, I think “capability interface” and “programming interface” are also applied to the I2NSF Consumer-Facing Interface. Thanks! B.R. Frank 发件人: Diego R. Lopez [mailto:diego.r.lo...@telefonica.com] 发送时间: 2016年7月2日 15:40 收件人: John Strassner 抄送: Rakesh Kumar; Natale, Bob; Susan Hares; John Strassner; I2NSF@ietf.org<mailto:I2NSF@ietf.org>; Xialiang (Frank); Dacheng Zhang; Linda Dunbar 主题: Re: [I2nsf] questions about some terminologies defined by draft-ietf-i2nsf-terminology-00 On 2 Jul 2016, at 03:36 , John Strassner mailto:john.sc.strass...@huawei.com>> wrote: Based on my understanding of “Capability Layer” as defined in the I2NSF, is the controller southbound interface. it is the interface from controller to Network Security Function (NSF/vNSF). Is that ok if we define southbound interface as set of interfaces with categorization along the functional line? ... No, both Diego and I have argued that "northbound" and "southbound" should not be used. Please look at the mail thread. In addition, a Controller can announce its capabilities, just like an NSF can.
Re: [I2nsf] questions about some terminologies defined by draft-ietf-i2nsf-terminology-00
Hi Frank, Thanks for the comments. IMHO, it would be great if our terminology 1. Align well with other work in the industry (I am pretty sure there are other service orchestration system/controller in the standard bodies and open source). 2. Communicates clearly the intention of these interface on terminology we choose. 3. The end-customer/consumer find these interfaces intuitive. The end-customer could be * An uber-controller that uses I2NSF defined security controller to provision security policies * A GUI system used by admin to provision security policies * OSS/BSS system from service provider * Thirty party APP written on top of I2NSF controller It would be great to discuss various options discussed so far in this group and see which ones are the most appropriate. Once we agree on top level, it would be great to create classification/categories for these interfaces on either side of the controller so that our work/drafts communicate clearly, the specific area[s] targeted. I just sent this classification to start a wider discussion. I look towards the group and help from chairs to see how to carry it forward and whether to fold this into existing draft or not. It would be great if we bring this up in Berlin. Thanks & Regards, Rakesh From: "Xialiang (Frank)" mailto:frank.xiali...@huawei.com>> Date: Sunday, July 3, 2016 at 7:39 PM To: "Diego R. Lopez" mailto:diego.r.lo...@telefonica.com>>, John Strassner mailto:john.sc.strass...@huawei.com>> Cc: Rakesh Kumar mailto:rkku...@juniper.net>>, "Natale, Bob" mailto:rnat...@mitre.org>>, Susan Hares mailto:sha...@ndzh.com>>, John Strassner mailto:straz...@gmail.com>>, "i2nsf@ietf.org<mailto:i2nsf@ietf.org>" mailto:i2nsf@ietf.org>>, Dacheng Zhang mailto:dacheng....@alibaba-inc.com>>, Linda Dunbar mailto:linda.dun...@huawei.com>> Subject: Re: [I2nsf] questions about some terminologies defined by draft-ietf-i2nsf-terminology-00 Hi all, Firstly, I fully support John’s argument that we should avoid using the “northbound/southbound” concept here, since they are recursive and cannot be specific. Secondly, I like the idea from Rakesh of a clear classification for the I2NSF NSF-Facing interface, I think his current naming is ok, but we can maybe find more better names. In addition, I think “capability interface” and “programming interface” are also applied to the I2NSF Consumer-Facing Interface. Thanks! B.R. Frank 发件人: Diego R. Lopez [mailto:diego.r.lo...@telefonica.com] 发送时间: 2016年7月2日 15:40 收件人: John Strassner 抄送: Rakesh Kumar; Natale, Bob; Susan Hares; John Strassner; I2NSF@ietf.org<mailto:I2NSF@ietf.org>; Xialiang (Frank); Dacheng Zhang; Linda Dunbar 主题: Re: [I2nsf] questions about some terminologies defined by draft-ietf-i2nsf-terminology-00 On 2 Jul 2016, at 03:36 , John Strassner mailto:john.sc.strass...@huawei.com>> wrote: Based on my understanding of “Capability Layer” as defined in the I2NSF, is the controller southbound interface. it is the interface from controller to Network Security Function (NSF/vNSF). Is that ok if we define southbound interface as set of interfaces with categorization along the functional line? ... No, both Diego and I have argued that "northbound" and "southbound" should not be used. Please look at the mail thread. In addition, a Controller can announce its capabilities, just like an NSF can. And I wholeheartedly support this idea of recursion. It is an essential part of any approach to a network functional moel. Be goode, regards, John From: I2nsf [mailto:i2nsf-boun...@ietf.org] On Behalf Of Rakesh Kumar Sent: Friday, July 01, 2016 4:06 PM To: Natale, Bob; Susan Hares; DIEGO LOPEZ GARCIA; John Strassner Cc: I2NSF@ietf.org<mailto:I2NSF@ietf.org>; Xialiang (Frank); Rakesh Kumar; Dacheng Zhang; Linda Dunbar Subject: Re: [I2nsf] questions about some terminologies defined by draft-ietf-i2nsf-terminology-00 Based on my understanding of “Capability Layer” as defined in the I2NSF, is the controller southbound interface. it is the interface from controller to Network Security Function (NSF/vNSF). Is that ok if we define southbound interface as set of interfaces with categorization along the functional line? Something like as following. I2NSF Southbound Interfaces 1. Capability Interface: Interface to discover NSF/vNSF capability so that controller can determine whether a NSF is capable of enforcing a given policy. This could be either a query interface (controller queries from a NSF for specific functionality) or a report interface where each NSF sends its supported capabilities such as feature, scale, performance. The NSF state is not changed by this interface. 2. Programming Interface (or some other better name): Interface used by controller to program a specific NSF
Re: [I2nsf] questions about some terminologies defined by draft-ietf-i2nsf-terminology-00
Hi all, Firstly, I fully support John’s argument that we should avoid using the “northbound/southbound” concept here, since they are recursive and cannot be specific. Secondly, I like the idea from Rakesh of a clear classification for the I2NSF NSF-Facing interface, I think his current naming is ok, but we can maybe find more better names. In addition, I think “capability interface” and “programming interface” are also applied to the I2NSF Consumer-Facing Interface. Thanks! B.R. Frank 发件人: Diego R. Lopez [mailto:diego.r.lo...@telefonica.com] 发送时间: 2016年7月2日 15:40 收件人: John Strassner 抄送: Rakesh Kumar; Natale, Bob; Susan Hares; John Strassner; I2NSF@ietf.org; Xialiang (Frank); Dacheng Zhang; Linda Dunbar 主题: Re: [I2nsf] questions about some terminologies defined by draft-ietf-i2nsf-terminology-00 On 2 Jul 2016, at 03:36 , John Strassner mailto:john.sc.strass...@huawei.com>> wrote: Based on my understanding of “Capability Layer” as defined in the I2NSF, is the controller southbound interface. it is the interface from controller to Network Security Function (NSF/vNSF). Is that ok if we define southbound interface as set of interfaces with categorization along the functional line? ... No, both Diego and I have argued that "northbound" and "southbound" should not be used. Please look at the mail thread. In addition, a Controller can announce its capabilities, just like an NSF can. And I wholeheartedly support this idea of recursion. It is an essential part of any approach to a network functional moel. Be goode, regards, John From: I2nsf [mailto:i2nsf-boun...@ietf.org] On Behalf Of Rakesh Kumar Sent: Friday, July 01, 2016 4:06 PM To: Natale, Bob; Susan Hares; DIEGO LOPEZ GARCIA; John Strassner Cc: I2NSF@ietf.org<mailto:I2NSF@ietf.org>; Xialiang (Frank); Rakesh Kumar; Dacheng Zhang; Linda Dunbar Subject: Re: [I2nsf] questions about some terminologies defined by draft-ietf-i2nsf-terminology-00 Based on my understanding of “Capability Layer” as defined in the I2NSF, is the controller southbound interface. it is the interface from controller to Network Security Function (NSF/vNSF). Is that ok if we define southbound interface as set of interfaces with categorization along the functional line? Something like as following. I2NSF Southbound Interfaces 1. Capability Interface: Interface to discover NSF/vNSF capability so that controller can determine whether a NSF is capable of enforcing a given policy. This could be either a query interface (controller queries from a NSF for specific functionality) or a report interface where each NSF sends its supported capabilities such as feature, scale, performance. The NSF state is not changed by this interface. 2. Programming Interface (or some other better name): Interface used by controller to program a specific NSF to enforce a security policy. This might change the state of NSF if successful. 3. Notification Interface: Interface used to send notification (event/alarm) by NSF to controller (if registered for). The controller may directly take an action based on the event. This is a report and registry interface. This does not change the state of NSF. 4. Telemetry Interface: Interface to get telemetry information from NSF. This could be query or report/registry interface. This does not change the state of NSF. Any thoughts ? Regards, Rakesh From: I2nsf mailto:i2nsf-boun...@ietf.org>> on behalf of "Natale, Bob" mailto:rnat...@mitre.org>> Date: Wednesday, June 29, 2016 at 9:38 PM To: Susan Hares mailto:sha...@ndzh.com>>, DIEGO LOPEZ GARCIA mailto:diego.r.lo...@telefonica.com>>, John Strassner mailto:straz...@gmail.com>> Cc: "I2NSF@ietf.org<mailto:I2NSF@ietf.org>" mailto:I2NSF@ietf.org>>, "Xialiang (Frank)" mailto:frank.xiali...@huawei.com>>, Dacheng Zhang mailto:dacheng....@alibaba-inc.com>>, Linda Dunbar mailto:linda.dun...@huawei.com>> Subject: Re: [I2nsf] questions about some terminologies defined by draft-ietf-i2nsf-terminology-00 I would have gone with John’s first definition of the Capability Layer below. It is not a case of reusing the defined term in the definition. The “Capability Layer” is a distinct concept from “Capability” and, as John’s first definition says, consists of “the set of capabilities” and remembering that “Capability” is already defined as “a set of features”. Avanti, BobN From: I2nsf [mailto:i2nsf-boun...@ietf.org] On Behalf Of Susan Hares Sent: Wednesday, June 22, 2016 4:42 PM To: DIEGO LOPEZ GARCIA mailto:diego.r.lo...@telefonica.com>>; John Strassner mailto:straz...@gmail.com>> Cc: I2NSF@ietf.org<mailto:I2NSF@ietf.org>; Xialiang (Frank) mailto:frank.xiali...@huawei.com>>; Dacheng Zhang mailto:dacheng....@alibaba-inc.com>>; Linda Dunbar mailto:linda.dun...@huawei.com>> Subject: Re: [I2nsf] questions abo
Re: [I2nsf] questions about some terminologies defined by draft-ietf-i2nsf-terminology-00
On 2 Jul 2016, at 03:36 , John Strassner mailto:john.sc.strass...@huawei.com>> wrote: Based on my understanding of “Capability Layer” as defined in the I2NSF, is the controller southbound interface. it is the interface from controller to Network Security Function (NSF/vNSF). Is that ok if we define southbound interface as set of interfaces with categorization along the functional line? ... No, both Diego and I have argued that "northbound" and "southbound" should not be used. Please look at the mail thread. In addition, a Controller can announce its capabilities, just like an NSF can. And I wholeheartedly support this idea of recursion. It is an essential part of any approach to a network functional moel. Be goode, regards, John From: I2nsf [mailto:i2nsf-boun...@ietf.org] On Behalf Of Rakesh Kumar Sent: Friday, July 01, 2016 4:06 PM To: Natale, Bob; Susan Hares; DIEGO LOPEZ GARCIA; John Strassner Cc: I2NSF@ietf.org<mailto:I2NSF@ietf.org>; Xialiang (Frank); Rakesh Kumar; Dacheng Zhang; Linda Dunbar Subject: Re: [I2nsf] questions about some terminologies defined by draft-ietf-i2nsf-terminology-00 Based on my understanding of “Capability Layer” as defined in the I2NSF, is the controller southbound interface. it is the interface from controller to Network Security Function (NSF/vNSF). Is that ok if we define southbound interface as set of interfaces with categorization along the functional line? Something like as following. I2NSF Southbound Interfaces 1. Capability Interface: Interface to discover NSF/vNSF capability so that controller can determine whether a NSF is capable of enforcing a given policy. This could be either a query interface (controller queries from a NSF for specific functionality) or a report interface where each NSF sends its supported capabilities such as feature, scale, performance. The NSF state is not changed by this interface. 2. Programming Interface (or some other better name): Interface used by controller to program a specific NSF to enforce a security policy. This might change the state of NSF if successful. 3. Notification Interface: Interface used to send notification (event/alarm) by NSF to controller (if registered for). The controller may directly take an action based on the event. This is a report and registry interface. This does not change the state of NSF. 4. Telemetry Interface: Interface to get telemetry information from NSF. This could be query or report/registry interface. This does not change the state of NSF. Any thoughts ? Regards, Rakesh From: I2nsf mailto:i2nsf-boun...@ietf.org>> on behalf of "Natale, Bob" mailto:rnat...@mitre.org>> Date: Wednesday, June 29, 2016 at 9:38 PM To: Susan Hares mailto:sha...@ndzh.com>>, DIEGO LOPEZ GARCIA mailto:diego.r.lo...@telefonica.com>>, John Strassner mailto:straz...@gmail.com>> Cc: "I2NSF@ietf.org<mailto:I2NSF@ietf.org>" mailto:I2NSF@ietf.org>>, "Xialiang (Frank)" mailto:frank.xiali...@huawei.com>>, Dacheng Zhang mailto:dacheng....@alibaba-inc.com>>, Linda Dunbar mailto:linda.dun...@huawei.com>> Subject: Re: [I2nsf] questions about some terminologies defined by draft-ietf-i2nsf-terminology-00 I would have gone with John’s first definition of the Capability Layer below. It is not a case of reusing the defined term in the definition. The “Capability Layer” is a distinct concept from “Capability” and, as John’s first definition says, consists of “the set of capabilities” and remembering that “Capability” is already defined as “a set of features”. Avanti, BobN From: I2nsf [mailto:i2nsf-boun...@ietf.org] On Behalf Of Susan Hares Sent: Wednesday, June 22, 2016 4:42 PM To: DIEGO LOPEZ GARCIA mailto:diego.r.lo...@telefonica.com>>; John Strassner mailto:straz...@gmail.com>> Cc: I2NSF@ietf.org<mailto:I2NSF@ietf.org>; Xialiang (Frank) mailto:frank.xiali...@huawei.com>>; Dacheng Zhang mailto:dacheng....@alibaba-inc.com>>; Linda Dunbar mailto:linda.dun...@huawei.com>> Subject: Re: [I2nsf] questions about some terminologies defined by draft-ietf-i2nsf-terminology-00 John and Diego I agree the second one is better. Sue Sent via the Samsung Galaxy Note5, an AT&T 4G LTE smartphone Original message From: DIEGO LOPEZ GARCIA mailto:diego.r.lo...@telefonica.com>> Date: 6/16/2016 2:07 AM (GMT-05:00) To: John Strassner mailto:straz...@gmail.com>> Cc: I2NSF@ietf.org<mailto:I2NSF@ietf.org>, "Xialiang (Frank)" mailto:frank.xiali...@huawei.com>>, Susan Hares mailto:sha...@ndzh.com>>, Dacheng Zhang mailto:dacheng@alibaba-inc.com>>, Linda Dunbar mailto:linda.dun...@huawei.com>> Subject: Re: [I2nsf] questions about some terminologies defined by draft-ietf-i2nsf-terminology-00 In order to avoid using the defined term (even pa
Re: [I2nsf] questions about some terminologies defined by draft-ietf-i2nsf-terminology-00
Based on my understanding of “Capability Layer” as defined in the I2NSF, is the controller southbound interface. it is the interface from controller to Network Security Function (NSF/vNSF). Is that ok if we define southbound interface as set of interfaces with categorization along the functional line? ... No, both Diego and I have argued that "northbound" and "southbound" should not be used. Please look at the mail thread. In addition, a Controller can announce its capabilities, just like an NSF can. regards, John From: I2nsf [mailto:i2nsf-boun...@ietf.org] On Behalf Of Rakesh Kumar Sent: Friday, July 01, 2016 4:06 PM To: Natale, Bob; Susan Hares; DIEGO LOPEZ GARCIA; John Strassner Cc: I2NSF@ietf.org; Xialiang (Frank); Rakesh Kumar; Dacheng Zhang; Linda Dunbar Subject: Re: [I2nsf] questions about some terminologies defined by draft-ietf-i2nsf-terminology-00 Based on my understanding of “Capability Layer” as defined in the I2NSF, is the controller southbound interface. it is the interface from controller to Network Security Function (NSF/vNSF). Is that ok if we define southbound interface as set of interfaces with categorization along the functional line? Something like as following. I2NSF Southbound Interfaces 1. Capability Interface: Interface to discover NSF/vNSF capability so that controller can determine whether a NSF is capable of enforcing a given policy. This could be either a query interface (controller queries from a NSF for specific functionality) or a report interface where each NSF sends its supported capabilities such as feature, scale, performance. The NSF state is not changed by this interface. 2. Programming Interface (or some other better name): Interface used by controller to program a specific NSF to enforce a security policy. This might change the state of NSF if successful. 3. Notification Interface: Interface used to send notification (event/alarm) by NSF to controller (if registered for). The controller may directly take an action based on the event. This is a report and registry interface. This does not change the state of NSF. 4. Telemetry Interface: Interface to get telemetry information from NSF. This could be query or report/registry interface. This does not change the state of NSF. Any thoughts ? Regards, Rakesh From: I2nsf mailto:i2nsf-boun...@ietf.org>> on behalf of "Natale, Bob" mailto:rnat...@mitre.org>> Date: Wednesday, June 29, 2016 at 9:38 PM To: Susan Hares mailto:sha...@ndzh.com>>, DIEGO LOPEZ GARCIA mailto:diego.r.lo...@telefonica.com>>, John Strassner mailto:straz...@gmail.com>> Cc: "I2NSF@ietf.org<mailto:I2NSF@ietf.org>" mailto:I2NSF@ietf.org>>, "Xialiang (Frank)" mailto:frank.xiali...@huawei.com>>, Dacheng Zhang mailto:dacheng....@alibaba-inc.com>>, Linda Dunbar mailto:linda.dun...@huawei.com>> Subject: Re: [I2nsf] questions about some terminologies defined by draft-ietf-i2nsf-terminology-00 I would have gone with John’s first definition of the Capability Layer below. It is not a case of reusing the defined term in the definition. The “Capability Layer” is a distinct concept from “Capability” and, as John’s first definition says, consists of “the set of capabilities” and remembering that “Capability” is already defined as “a set of features”. Avanti, BobN From: I2nsf [mailto:i2nsf-boun...@ietf.org] On Behalf Of Susan Hares Sent: Wednesday, June 22, 2016 4:42 PM To: DIEGO LOPEZ GARCIA mailto:diego.r.lo...@telefonica.com>>; John Strassner mailto:straz...@gmail.com>> Cc: I2NSF@ietf.org<mailto:I2NSF@ietf.org>; Xialiang (Frank) mailto:frank.xiali...@huawei.com>>; Dacheng Zhang mailto:dacheng....@alibaba-inc.com>>; Linda Dunbar mailto:linda.dun...@huawei.com>> Subject: Re: [I2nsf] questions about some terminologies defined by draft-ietf-i2nsf-terminology-00 John and Diego I agree the second one is better. Sue Sent via the Samsung Galaxy Note5, an AT&T 4G LTE smartphone Original message From: DIEGO LOPEZ GARCIA mailto:diego.r.lo...@telefonica.com>> Date: 6/16/2016 2:07 AM (GMT-05:00) To: John Strassner mailto:straz...@gmail.com>> Cc: I2NSF@ietf.org<mailto:I2NSF@ietf.org>, "Xialiang (Frank)" mailto:frank.xiali...@huawei.com>>, Susan Hares mailto:sha...@ndzh.com>>, Dacheng Zhang mailto:dacheng@alibaba-inc.com>>, Linda Dunbar mailto:linda.dun...@huawei.com>> Subject: Re: [I2nsf] questions about some terminologies defined by draft-ietf-i2nsf-terminology-00 In order to avoid using the defined term (even partially) into the definition I’d go for the second one… Be goode, On 16 Jun 2016, at 15:05 , John Strassner mailto:straz...@gmail.com>> wrote: Hi Dacheng, I agree that "I2NSF system" is not well defined. Your definition is better, but it should
Re: [I2nsf] questions about some terminologies defined by draft-ietf-i2nsf-terminology-00
Based on my understanding of “Capability Layer” as defined in the I2NSF, is the controller southbound interface. it is the interface from controller to Network Security Function (NSF/vNSF). Is that ok if we define southbound interface as set of interfaces with categorization along the functional line? Something like as following. I2NSF Southbound Interfaces 1. Capability Interface: Interface to discover NSF/vNSF capability so that controller can determine whether a NSF is capable of enforcing a given policy. This could be either a query interface (controller queries from a NSF for specific functionality) or a report interface where each NSF sends its supported capabilities such as feature, scale, performance. The NSF state is not changed by this interface. 2. Programming Interface (or some other better name): Interface used by controller to program a specific NSF to enforce a security policy. This might change the state of NSF if successful. 3. Notification Interface: Interface used to send notification (event/alarm) by NSF to controller (if registered for). The controller may directly take an action based on the event. This is a report and registry interface. This does not change the state of NSF. 4. Telemetry Interface: Interface to get telemetry information from NSF. This could be query or report/registry interface. This does not change the state of NSF. Any thoughts ? Regards, Rakesh From: I2nsf mailto:i2nsf-boun...@ietf.org>> on behalf of "Natale, Bob" mailto:rnat...@mitre.org>> Date: Wednesday, June 29, 2016 at 9:38 PM To: Susan Hares mailto:sha...@ndzh.com>>, DIEGO LOPEZ GARCIA mailto:diego.r.lo...@telefonica.com>>, John Strassner mailto:straz...@gmail.com>> Cc: "I2NSF@ietf.org<mailto:I2NSF@ietf.org>" mailto:I2NSF@ietf.org>>, "Xialiang (Frank)" mailto:frank.xiali...@huawei.com>>, Dacheng Zhang mailto:dacheng@alibaba-inc.com>>, Linda Dunbar mailto:linda.dun...@huawei.com>> Subject: Re: [I2nsf] questions about some terminologies defined by draft-ietf-i2nsf-terminology-00 I would have gone with John’s first definition of the Capability Layer below. It is not a case of reusing the defined term in the definition. The “Capability Layer” is a distinct concept from “Capability” and, as John’s first definition says, consists of “the set of capabilities” and remembering that “Capability” is already defined as “a set of features”. Avanti, BobN From: I2nsf [mailto:i2nsf-boun...@ietf.org] On Behalf Of Susan Hares Sent: Wednesday, June 22, 2016 4:42 PM To: DIEGO LOPEZ GARCIA mailto:diego.r.lo...@telefonica.com>>; John Strassner mailto:straz...@gmail.com>> Cc: I2NSF@ietf.org<mailto:I2NSF@ietf.org>; Xialiang (Frank) mailto:frank.xiali...@huawei.com>>; Dacheng Zhang mailto:dacheng@alibaba-inc.com>>; Linda Dunbar mailto:linda.dun...@huawei.com>> Subject: Re: [I2nsf] questions about some terminologies defined by draft-ietf-i2nsf-terminology-00 John and Diego I agree the second one is better. Sue Sent via the Samsung Galaxy Note5, an AT&T 4G LTE smartphone Original message From: DIEGO LOPEZ GARCIA mailto:diego.r.lo...@telefonica.com>> Date: 6/16/2016 2:07 AM (GMT-05:00) To: John Strassner mailto:straz...@gmail.com>> Cc: I2NSF@ietf.org<mailto:I2NSF@ietf.org>, "Xialiang (Frank)" mailto:frank.xiali...@huawei.com>>, Susan Hares mailto:sha...@ndzh.com>>, Dacheng Zhang mailto:dacheng@alibaba-inc.com>>, Linda Dunbar mailto:linda.dun...@huawei.com>> Subject: Re: [I2nsf] questions about some terminologies defined by draft-ietf-i2nsf-terminology-00 In order to avoid using the defined term (even partially) into the definition I’d go for the second one… Be goode, On 16 Jun 2016, at 15:05 , John Strassner 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. regards, John On Wed, Jun 15, 2016 at 8:55 PM, Dacheng Zhang mailto:dacheng@alibaba-inc.com>> wrote: I think I agree with Frank. The confusion is caused by the 'I2NSF system’. Maybe we should change the definition in the terminology draft to Capability Layer: Defines an abstraction layer that exposes a set of capabilities of the NSF? 发件人: I2nsf mailto:i2nsf-boun...@ietf.org>> on behalf of "Xialiang (Fran
Re: [I2nsf] questions about some terminologies defined by draft-ietf-i2nsf-terminology-00
I would have gone with John’s first definition of the Capability Layer below. It is not a case of reusing the defined term in the definition. The “Capability Layer” is a distinct concept from “Capability” and, as John’s first definition says, consists of “the set of capabilities” and remembering that “Capability” is already defined as “a set of features”. Avanti, BobN From: I2nsf [mailto:i2nsf-boun...@ietf.org] On Behalf Of Susan Hares Sent: Wednesday, June 22, 2016 4:42 PM To: DIEGO LOPEZ GARCIA ; John Strassner Cc: I2NSF@ietf.org; Xialiang (Frank) ; Dacheng Zhang ; Linda Dunbar Subject: Re: [I2nsf] questions about some terminologies defined by draft-ietf-i2nsf-terminology-00 John and Diego I agree the second one is better. Sue Sent via the Samsung Galaxy Note5, an AT&T 4G LTE smartphone Original message From: DIEGO LOPEZ GARCIA mailto:diego.r.lo...@telefonica.com>> Date: 6/16/2016 2:07 AM (GMT-05:00) To: John Strassner mailto:straz...@gmail.com>> Cc: I2NSF@ietf.org<mailto:I2NSF@ietf.org>, "Xialiang (Frank)" mailto:frank.xiali...@huawei.com>>, Susan Hares mailto:sha...@ndzh.com>>, Dacheng Zhang mailto:dacheng@alibaba-inc.com>>, Linda Dunbar mailto:linda.dun...@huawei.com>> Subject: Re: [I2nsf] questions about some terminologies defined by draft-ietf-i2nsf-terminology-00 In order to avoid using the defined term (even partially) into the definition I’d go for the second one… Be goode, On 16 Jun 2016, at 15:05 , John Strassner 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. regards, John On Wed, Jun 15, 2016 at 8:55 PM, Dacheng Zhang mailto:dacheng@alibaba-inc.com>> wrote: I think I agree with Frank. The confusion is caused by the 'I2NSF system’. Maybe we should change the definition in the terminology draft to Capability Layer: Defines an abstraction layer that exposes a set of capabilities of the NSF? 发件人: I2nsf mailto:i2nsf-boun...@ietf.org>> on behalf of "Xialiang (Frank)" mailto:frank.xiali...@huawei.com>> 日期: 2016年6月16日 星期四 上午11:47 至: Linda Dunbar mailto:linda.dun...@huawei.com>>, John Strassner mailto:straz...@gmail.com>>, Susan Hares mailto:sha...@ndzh.com>>, "DIEGO LOPEZ GARCIA (diego.r.lo...@telefonica.com<mailto:diego.r.lo...@telefonica.com>)" mailto:diego.r.lo...@telefonica.com>> 抄送: "I2NSF@ietf.org<mailto:I2NSF@ietf.org>" mailto:I2NSF@ietf.org>> 主题: [I2nsf] 答复: questions about some terminologies defined by draft-ietf-i2nsf-terminology-00 Hi Linda, Frankly, I don’t see the essential difference for the meaning of terminology “capability” between them. We just need to make some modification in two places to keep consistence. We can do it during the update of I2NSF terminology draft. B.R. Frank 发件人: I2nsf [mailto:i2nsf-boun...@ietf.org] 代表 Linda Dunbar 发送时间: 2016年6月15日 23:40 收件人: John Strassner; Susan Hares; DIEGO LOPEZ GARCIA (diego.r.lo...@telefonica.com<mailto:diego.r.lo...@telefonica.com>) 抄送: I2NSF@ietf.org<mailto:I2NSF@ietf.org> 主题: [I2nsf] questions about some terminologies defined by draft-ietf-i2nsf-terminology-00 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 allow
Re: [I2nsf] questions about some terminologies defined by draft-ietf-i2nsf-terminology-00
John and Diego I agree the second one is better. Sue Sent via the Samsung Galaxy Note5, an AT&T 4G LTE smartphone Original message From: DIEGO LOPEZ GARCIA Date: 6/16/2016 2:07 AM (GMT-05:00) To: John Strassner Cc: I2NSF@ietf.org, "Xialiang (Frank)" , Susan Hares , Dacheng Zhang , Linda Dunbar Subject: Re: [I2nsf] questions about some terminologies defined by draft-ietf-i2nsf-terminology-00 In order to avoid using the defined term (even partially) into the definition I’d go for the second one… Be goode, On 16 Jun 2016, at 15:05 , John Strassner 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. regards, John On Wed, Jun 15, 2016 at 8:55 PM, Dacheng Zhang wrote: I think I agree with Frank. The confusion is caused by the 'I2NSF system’. Maybe we should change the definition in the terminology draft to Capability Layer: Defines an abstraction layer that exposes a set of capabilities of the NSF? 发件人: I2nsf on behalf of "Xialiang (Frank)" 日期: 2016年6月16日 星期四 上午11:47 至: Linda Dunbar , John Strassner , Susan Hares , "DIEGO LOPEZ GARCIA (diego.r.lo...@telefonica.com)" 抄送: "I2NSF@ietf.org" 主题: [I2nsf] 答复: questions about some terminologies defined by draft-ietf-i2nsf-terminology-00 Hi Linda, Frankly, I don’t see the essential difference for the meaning of terminology “capability” between them. We just need to make some modification in two places to keep consistence. We can do it during the update of I2NSF terminology draft. B.R. Frank 发件人: I2nsf [mailto:i2nsf-boun...@ietf.org] 代表 Linda Dunbar 发送时间: 2016年6月15日 23:40 收件人: John Strassner; Susan Hares; DIEGO LOPEZ GARCIA (diego.r.lo...@telefonica.com) 抄送: I2NSF@ietf.org 主题: [I2nsf] questions about some terminologies defined by draft-ietf-i2nsf-terminology-00 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 ___ I2nsf mailing list I2nsf@ietf.org https://www.ietf.org/mailman/listinfo/i2nsf -- regards, John -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D http://people.tid.es/diego.lopez/ e-mail: diego.r.lo...@telefonica.com Tel: +34 913 129 041 Mobile: +34 682 051 091 -- 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 en
Re: [I2nsf] questions about some terminologies defined by draft-ietf-i2nsf-terminology-00
+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
mailto:straz...@gmail.com>> 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
mailto:rajasekhargand...@my.unt.edu>> 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 mailto:straz...@gmail.com>>
Sent: Sunday, June 19, 2016 10:17:42 PM
To: Ganduri, Rajasekhar
Cc: Linda Dunbar; I2NSF@ietf.org<mailto:I2NSF@ietf.org>; DIEGO LOPEZ GARCIA
(diego.r.lo...@telefonica.com<mailto:diego.r.lo...@telefonica.com>); 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
mailto:rajasekhargand...@my.unt.edu>> 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 mailto:linda.dun...@huawei.com>>
Sent: Friday, June 17, 2016 4:10 AM
To: John Strassner
Cc: I2NSF@ietf.org<mailto:I2NSF@ietf.org>; DIEGO LOPEZ GARCIA
(diego.r.lo...@telefonica.com<mailto:diego.r.lo...@telefonica.com>); 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:straz...@gmail.com<mailto:straz...@gmail.com>]
Sent:
Re: [I2nsf] questions about some terminologies defined by draft-ietf-i2nsf-terminology-00
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 <
rajasekhargand...@my.unt.edu> 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
> *Sent:* Sunday, June 19, 2016 10:17:42 PM
> *To:* Ganduri, Rajasekhar
> *Cc:* Linda Dunbar; I2NSF@ietf.org; DIEGO LOPEZ GARCIA (
> diego.r.lo...@telefonica.com); 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 <
> rajasekhargand...@my.unt.edu> 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
>> *Sent:* Friday, June 17, 2016 4:10 AM
>> *To:* John Strassner
>> *Cc:* I2NSF@ietf.org; DIEGO LOPEZ GARCIA (diego.r.lo...@telefonica.com);
>> 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.
>
Re: [I2nsf] questions about some terminologies defined by draft-ietf-i2nsf-terminology-00
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
Sent: Sunday, June 19, 2016 10:17:42 PM
To: Ganduri, Rajasekhar
Cc: Linda Dunbar; I2NSF@ietf.org; DIEGO LOPEZ GARCIA
(diego.r.lo...@telefonica.com); 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
mailto:rajasekhargand...@my.unt.edu>> 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 mailto:linda.dun...@huawei.com>>
Sent: Friday, June 17, 2016 4:10 AM
To: John Strassner
Cc: I2NSF@ietf.org<mailto:I2NSF@ietf.org>; DIEGO LOPEZ GARCIA
(diego.r.lo...@telefonica.com<mailto:diego.r.lo...@telefonica.com>); 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: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
mailto:linda.dun...@huawei.com>> wrote:
Dear Authors:
The term “Capability Layer” defined by th
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 <
rajasekhargand...@my.unt.edu> 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
> *Sent:* Friday, June 17, 2016 4:10 AM
> *To:* John Strassner
> *Cc:* I2NSF@ietf.org; DIEGO LOPEZ GARCIA (diego.r.lo...@telefonica.com);
> 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: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);
> 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
> 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 s
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.
> 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.
On 16 Jun 2016, at 15:05 , John Strassner 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
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]
> *Sent:* Thursday, June 16, 2016 12:58 AM
> *To:* Linda Dunbar; John Strassner
> *Cc:* Susan Hares; DIEGO LOPEZ GARCIA (diego.r.lo...@telefonica.com);
> 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
> 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 cli
Re: [I2nsf] questions about some terminologies defined by draft-ietf-i2nsf-terminology-00
Rajasekhar,
Your explanation of "abstraction layer" makes great sense. Thank you.
Your implementation sounds quite interesting. Is it possible for you to write a
high level description and share with the group?
Thanks, Linda
From: Ganduri, Rajasekhar [mailto:rajasekhargand...@my.unt.edu]
Sent: Friday, June 17, 2016 10:08 AM
To: Linda Dunbar; John Strassner
Cc: I2NSF@ietf.org; DIEGO LOPEZ GARCIA (diego.r.lo...@telefonica.com); Susan
Hares
Subject: Re: [I2nsf] questions about some terminologies defined by
draft-ietf-i2nsf-terminology-00
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 mailto:linda.dun...@huawei.com>>
Sent: Friday, June 17, 2016 4:10 AM
To: John Strassner
Cc: I2NSF@ietf.org<mailto:I2NSF@ietf.org>; DIEGO LOPEZ GARCIA
(diego.r.lo...@telefonica.com<mailto:diego.r.lo...@telefonica.com>); 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: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
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 emp
Re: [I2nsf] questions about some terminologies defined by draft-ietf-i2nsf-terminology-00
John,
I see your point now.
Is my following understanding correct?
Controller’s North Bound Interface and the South Bound Interface are referring
to the Controller’s physical interfaces, whereas the “Capability Layer” is
about the functions that NSF can perform.
Yes, it would be helpful to add those explanation to the Terminology draft.
Does the “Service Layer” in the Terminology draft means a “software, like a
management system or controller”?
Service Layer: Software that enables clients to manage security
policies for their specific flows. This is also called the
Client-Facing Interface.
Thanks, Linda
From: John Strassner [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);
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
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
___
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf
Re: [I2nsf] questions about some terminologies defined by draft-ietf-i2nsf-terminology-00
Hi Linda, As I said in a previous message, I don’t see the difference in the meaning, and probably the apparent conflict could be solved by incorporating part of the charter text into the definition in the terminology draft: Capability Layer: Defines an abstraction layer that exposes a set of capabilities of the I2NSF system. Through this layer it is possible to control and monitor NSFs at a functional implementation level. Does it sounds better to you? Be goode, On 15 Jun 2016, at 17:40 , Linda Dunbar 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 -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D http://people.tid.es/diego.lopez/ e-mail: diego.r.lo...@telefonica.com Tel:+34 913 129 041 Mobile: +34 682 051 091 -- 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 I2nsf@ietf.org https://www.ietf.org/mailman/listinfo/i2nsf
Re: [I2nsf] questions about some terminologies defined by draft-ietf-i2nsf-terminology-00
--Apple-Mail=_1EFF15CC-95EA-4A35-8535-3E217B94E3CA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=utf-8
Hi Linda,
The abstraction layer here is the one =E2=80=9Con top=E2=80=9D the NSFs, =
that expose their features as capabilities that are manageable by the =
controller. Using an analogy with OpenFlow, the OpenFlow protocol =
provides an abstraction layer so the forwarding elements can translate =
their status and events in terms of the protocol commands and responses.
Be goode,
=20
> On 17 Jun 2016, at 11:10 , Linda Dunbar =
wrote:
>=20
> John,
> =20
> My thinking maybe too simplistic.
> I picture a =E2=80=9CController=E2=80=9D having two ports,
> -one port connecting to clients (which can be another domain =
controller or Overlay network controller), interface from this port is =
=E2=80=9CService layer interface=E2=80=9D
> -another port connecting to NSFs, the interface from this port =
is =E2=80=9Ccapability layer interface=E2=80=9D.
> =20
> 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.
> =20
> What extra meaning does it carry with the wording =E2=80=9Cabstraction =
Layer=E2=80=9D ?
> 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.
> =20
> Linda
> =20
> From: John Strassner [mailto:straz...@gmail.com =
]=20
> Sent: Thursday, June 16, 2016 12:58 AM
> To: Linda Dunbar; John Strassner
> Cc: Susan Hares; DIEGO LOPEZ GARCIA (diego.r.lo...@telefonica.com =
); I2NSF@ietf.org =
> Subject: Re: questions about some terminologies defined by =
draft-ietf-i2nsf-terminology-00
> =20
> HI Linda,
> =20
> I don't see the conflict in the two definitions. If I substitute the =
first (within braces) into the second, I get:
> =20
> Capability Layer: Defines an abstraction layer that exposes a set of =
{features that are available from a managed entity} of the I2NSF system.
> =20
> 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.
> =20
> Features (i.e., capabilities) are independent of interface (northbound =
or southbound). Would you like us to add that point to the terminology =
I-D?
> =20
> best regards,
> John
> =20
> =20
> On Wed, Jun 15, 2016 at 8:40 AM, Linda Dunbar mailto:linda.dun...@huawei.com>> wrote:
> Dear Authors:
> =20
> The term =E2=80=9CCapability Layer=E2=80=9D defined by the =
=E2=80=9Cdraft-ietf-i2nsf-terminology-00=E2=80=9D carries different =
meaning than the =E2=80=9CCapability Layer=E2=80=9D used by the I2NSF =
charter.
> =20
> =E2=80=9Cdraft-ietf-i2nsf-terminology-00=E2=80=9D:
> Capability: Defines a set of features that are available from a =
managed entity (see also I2NSF Capability).
> =20
> Capability Layer: Defines an abstraction layer that exposes a set of =
capabilities of the I2NSF system.
> =20
> I2NSF Charter:
> I2NSF will specify interfaces at two functional levels for the control =
and monitoring of network security functions:
>=20
> 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.
>=20
> 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.
>=20
> =20
> If we use the definitions by the =
=E2=80=9Cdraft-ietf-i2nsf-terminology-00=E2=80=9D, we should create a =
different terminology to represent the =E2=80=9CSouth bound Interface=E2=80=
=9D between Controller and NSF.
> =20
> Thanks, Linda
> =20
> =20
>=20
>=20
>=20
> --=20
> regards,
> John
--
"Esta vez no fallaremos, Doctor Infierno"
Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/
e-mail: diego.r.lo...@telefonica.com
Tel:+34 913 129 041
Mobile: +34 682 051 091
--
--Apple-Mail=_1EFF15CC-95EA-4A35-8535-3E217B94E3CA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=utf-8
Hi Linda,The abstraction layer here is the one =E2=80=9Con top=E2=80=9D =
the NSFs, that expose their features as capabilities that are manageable =
by the controller. Using an analogy with OpenFlow, the OpenFlow
Re: [I2nsf] questions about some terminologies defined by draft-ietf-i2nsf-terminology-00
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
Sent: Friday, June 17, 2016 4:10 AM
To: John Strassner
Cc: I2NSF@ietf.org; DIEGO LOPEZ GARCIA (diego.r.lo...@telefonica.com); 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: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);
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
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
___
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf
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: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);
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
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
___
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf
Re: [I2nsf] questions about some terminologies defined by draft-ietf-i2nsf-terminology-00
In order to avoid using the defined term (even partially) into the definition I’d go for the second one… Be goode, On 16 Jun 2016, at 15:05 , John Strassner 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. regards, John On Wed, Jun 15, 2016 at 8:55 PM, Dacheng Zhang mailto:dacheng@alibaba-inc.com>> wrote: I think I agree with Frank. The confusion is caused by the 'I2NSF system’. Maybe we should change the definition in the terminology draft to Capability Layer: Defines an abstraction layer that exposes a set of capabilities of the NSF? 发件人: I2nsf mailto:i2nsf-boun...@ietf.org>> on behalf of "Xialiang (Frank)" mailto:frank.xiali...@huawei.com>> 日期: 2016年6月16日 星期四 上午11:47 至: Linda Dunbar mailto:linda.dun...@huawei.com>>, John Strassner mailto:straz...@gmail.com>>, Susan Hares mailto:sha...@ndzh.com>>, "DIEGO LOPEZ GARCIA (diego.r.lo...@telefonica.com<mailto:diego.r.lo...@telefonica.com>)" mailto:diego.r.lo...@telefonica.com>> 抄送: "I2NSF@ietf.org<mailto:I2NSF@ietf.org>" mailto:I2NSF@ietf.org>> 主题: [I2nsf] 答复: questions about some terminologies defined by draft-ietf-i2nsf-terminology-00 Hi Linda, Frankly, I don’t see the essential difference for the meaning of terminology “capability” between them. We just need to make some modification in two places to keep consistence. We can do it during the update of I2NSF terminology draft. B.R. Frank 发件人: I2nsf [mailto:i2nsf-boun...@ietf.org] 代表 Linda Dunbar 发送时间: 2016年6月15日 23:40 收件人: John Strassner; Susan Hares; DIEGO LOPEZ GARCIA (diego.r.lo...@telefonica.com<mailto:diego.r.lo...@telefonica.com>) 抄送: I2NSF@ietf.org<mailto:I2NSF@ietf.org> 主题: [I2nsf] questions about some terminologies defined by draft-ietf-i2nsf-terminology-00 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 ___ I2nsf mailing list I2nsf@ietf.org<mailto:I2nsf@ietf.org> https://www.ietf.org/mailman/listinfo/i2nsf -- regards, John -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D http://people.tid.es/diego.lopez/ e-mail: diego.r.lo...@telefonica.com Tel:+34 913 129 041 Mobile: +34 682 051 091 -- 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 t
Re: [I2nsf] 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
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
___
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf
[I2nsf] questions about some terminologies defined by draft-ietf-i2nsf-terminology-00
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 ___ I2nsf mailing list I2nsf@ietf.org https://www.ietf.org/mailman/listinfo/i2nsf
