Re: [I2nsf] questions about some terminologies defined by draft-ietf-i2nsf-terminology-00

[John Strassner]

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)" 
>
Date: Sunday, July 3, 2016 at 7:39 PM
To: "Diego R. Lopez" 
>, John 
Strassner >
Cc: Rakesh Kumar >, "Natale, 
Bob" >, Susan Hares 
>, John Strassner 
>, 
"i2nsf@ietf.org" 
>, Dacheng Zhang 
>, Linda Dunbar 
>
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; 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 
> 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 

[I2nsf] IETF 96 I2NSF preliminary agenda has been posted

[Linda Dunbar]

Here is the preliminary agenda for I2NSF in Berlin.
https://www.ietf.org/proceedings/96/agenda/agenda-96-i2nsf

Please let us know if your requests are not lumped in the right category.

Since there are many drafts on  NSF Facing Interface, we will have a side pre 
I2NSF F2F meeting among the authors who contributed drafts on NSF Facing 
Interface (listed below) to discuss if there are overlaps or/and the 
differentiation among their proposed schemes.

-   NSF Facing interface:
*draft-xia-i2nsf-capability-interface-im-06
*draft-baspez-i2nsf-capabilities-00
*hares-i2nsf-capability-yang-00
*draft-zhang-i2nsf-info-model-monitoring-01
*draft-jeong-i2nsf-sdn-security-services-04
*draft-jeong-i2nsf-capability-interface-yang-00
*draft-hyun-i2nsf-sfc-enabled-i2nsf-00
*Rafa: IPSec policy exchange between Controller and network functions
*draft-you-i2nsf-user-group-policy-capability


Please enter your available time at this poll: 
http://doodle.com/poll/7vcpm7agpx7ci5da

Thank you very much.

Adrian & Linda

From: Linda Dunbar
Sent: Friday, July 08, 2016 10:46 AM
To: I2NSF@ietf.org
Cc: adr...@olddog.co.uk
Subject: Berlin I2NSF F2F meeting agenda consideration, and how to align 
mutliple drafts on the "Customer Facing Interface" and "NSF facing interface"

I2NSF Participants,

At  Berlin I2NSF F2F meeting, we are going to group presentations based on the 
if they are applicable to "Customer Facing Interface (A)" or "NSF Facing 
Interface (B)", as shown in the I2NSF reference model.
After glancing through the drafts contributed so far, we have grouped them in 
the following categories. Please let us know if we are wrong.

-   Service Requester facing interface (was Client facing interface)
*draft-mglt-i2nsf-ssf-collaboration-00 (Flow Policy between Cloud 
network and Provider network)
*draft-kumar-i2nsf-controller-northbound-framework (Rakesh Kumar)
*draft-pastor-i2nsf-vnsf-attestation-02 (Requester to controller 
validation)
*draft-kim-i2nsf-security-management-architecture-01
*draft-you-i2nsf-user-group-based-policy (10 minutes)

-   NSF Facing interface:
*draft-xia-i2nsf-capability-interface-im-06
*draft-baspez-i2nsf-capabilities-00
*hares-i2nsf-capability-yang-00
*draft-zhang-i2nsf-info-model-monitoring-01
*draft-jeong-i2nsf-sdn-security-services-04
*draft-jeong-i2nsf-capability-interface-yang-00
*draft-hyun-i2nsf-sfc-enabled-i2nsf-00
*Rafa: IPSec policy exchange between Controller and network functions
*draft-you-i2nsf-user-group-policy-capability

To make the Face to Face meeting more productive, we are going to have a side 
pre-meeting among the authors on each interface to discuss if there are 
overlaps or/and the differentiation among their proposed schemes. I will send 
out a Doodle poll for each of the side discussion.


  +-+
  |  I2NSF Client   |
  | E.g. Overlay Network Mgnt, Enterprise network Mgnt  |
  |  another network domain's mgnt, etc.|
  +--+--+
 |
 |  Client Facing Interface (A)
 |
   +-+---+
   |Network Operator mgmt|   +-+
   | Security Controller | < - > | Developer's |
   +---+-+  Registration | Mgnt System |
   | Interface   +-+
   |
   | NSF Facing Interface (B)
   |
  +---+---+
   |   |
   |   |
   +---+--+ +--+ +--+   +--+---+
   + NSF-1+ --- + NSF-n+ +NSF-1 + - +NSF-m +  . . .
   +--+ +--+ +--+   +--+

   Developer A Developer B
Figure 1: I2NSF Reference Model


Thank you very much for the contributions,

Linda and Adrian.


___
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf