[I2nsf] Fwd: New Version Notification for draft-kumar-i2nsf-client-facing-interface-im-03.txt

[Rakesh Kumar]

Updated the information model to align with the requirement draft
identified in draft-ietf-i2nsf-client-facing-interface-req. I missed the
deadline to upload last week.

Thanks
Rakesh

-- Forwarded message --
From: <internet-dra...@ietf.org>
Date: Sun, Jul 16, 2017 at 10:23 PM
Subject: New Version Notification for draft-kumar-i2nsf-client-
facing-interface-im-03.txt
To: Dave Qi <d...@bloomberg.net>, Rakesh Kumar <rakeshkumarcl...@gmail.com>,
Senad Palislamovic <senad.palislamo...@nokia.com>, Liang Xia <
frank.xiali...@huawei.com>, Anil Lohiya <aloh...@juniper.net>, Dave Qi <
d...@bloomberg.net>, Nabil Bitar <nabil.bi...@nokia.com>, Liang Xia <
frank.xiali...@huawei.com>



A new version of I-D, draft-kumar-i2nsf-client-facing-interface-im-03.txt
has been successfully submitted by Rakesh Kumar and posted to the
IETF repository.

Name:   draft-kumar-i2nsf-client-facing-interface-im
Revision:   03
Title:  Information model for Client-Facing Interface to Security
Controller
Document date:  2017-07-16
Group:  Individual Submission
Pages:  18
URL:https://www.ietf.org/internet-drafts/draft-kumar-i2nsf-clien
t-facing-interface-im-03.txt
Status: https://datatracker.ietf.org/doc/draft-kumar-i2nsf-client-f
acing-interface-im/
Htmlized:   https://tools.ietf.org/html/draft-kumar-i2nsf-client-facing
-interface-im-03
Htmlized:   https://datatracker.ietf.org/doc/html/draft-kumar-i2nsf-cli
ent-facing-interface-im-03
Diff:   https://www.ietf.org/rfcdiff?url2=draft-kumar-i2nsf-client-
facing-interface-im-03

Abstract:
   This document defines information model for Client-Facing interface
   to Security Controller based on the requirements identified in
   [I-D.ietf-i2nsf-client-facing-interface-req].  The information model
   defines various managed objects and relationship among these objects
   needed to build the interface.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

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

Re: [I2nsf] I-D Action: draft-ietf-i2nsf-client-facing-interface-req-02.txt

[Rakesh Kumar]

I am attaching the latest draft which I could not upload.

Thanks
Rakesh

From: I2nsf <i2nsf-boun...@ietf.org<mailto:i2nsf-boun...@ietf.org>> on behalf 
of Rakesh Kumar <rkku...@juniper.net<mailto:rkku...@juniper.net>>
Date: Monday, July 3, 2017 at 5:46 PM
To: "Mr. Jaehoon Paul Jeong" 
<jaehoon.p...@gmail.com<mailto:jaehoon.p...@gmail.com>>
Cc: "i2nsf@ietf.org<mailto:i2nsf@ietf.org>" 
<i2nsf@ietf.org<mailto:i2nsf@ietf.org>>, 
"internet-dra...@ietf.org<mailto:internet-dra...@ietf.org>" 
<internet-dra...@ietf.org<mailto:internet-dra...@ietf.org>>
Subject: Re: [I2nsf] I-D Action: 
draft-ietf-i2nsf-client-facing-interface-req-02.txt

Hi,

I did not realize that time has passed for IETF upload. I think it was end of 
business day PST but it looks like UTC :-(.

I will upload once it opens.

Thanks
Rakesh


From: I2nsf <i2nsf-boun...@ietf.org<mailto:i2nsf-boun...@ietf.org>> on behalf 
of Rakesh Kumar <rkku...@juniper.net<mailto:rkku...@juniper.net>>
Date: Monday, July 3, 2017 at 3:09 PM
To: "Mr. Jaehoon Paul Jeong" 
<jaehoon.p...@gmail.com<mailto:jaehoon.p...@gmail.com>>
Cc: "i2nsf@ietf.org<mailto:i2nsf@ietf.org>" 
<i2nsf@ietf.org<mailto:i2nsf@ietf.org>>, 
"internet-dra...@ietf.org<mailto:internet-dra...@ietf.org>" 
<internet-dra...@ietf.org<mailto:internet-dra...@ietf.org>>, 
"i-d-annou...@ietf.org<mailto:i-d-annou...@ietf.org>" 
<i-d-annou...@ietf.org<mailto:i-d-annou...@ietf.org>>
Subject: Re: [I2nsf] I-D Action: 
draft-ietf-i2nsf-client-facing-interface-req-02.txt

HI Paul,

I plan to do soon (few hours).

Thanks
Rakesh

From: "Mr. Jaehoon Paul Jeong" 
<jaehoon.p...@gmail.com<mailto:jaehoon.p...@gmail.com>>
Date: Monday, July 3, 2017 at 3:07 PM
To: Rakesh Kumar <rkku...@juniper.net<mailto:rkku...@juniper.net>>
Cc: "internet-dra...@ietf.org<mailto:internet-dra...@ietf.org>" 
<internet-dra...@ietf.org<mailto:internet-dra...@ietf.org>>, 
"i2nsf@ietf.org<mailto:i2nsf@ietf.org>" 
<i2nsf@ietf.org<mailto:i2nsf@ietf.org>>, 
"i-d-annou...@ietf.org<mailto:i-d-annou...@ietf.org>" 
<i-d-annou...@ietf.org<mailto:i-d-annou...@ietf.org>>
Subject: Re: [I2nsf] I-D Action: 
draft-ietf-i2nsf-client-facing-interface-req-02.txt

Hi Rakesh,
when you will post your updated  information model later, I will update our 
data model correspondingly.

Thanks.

Best Regards,
Paul

2017. 7. 4. 오전 6:42에 "Rakesh Kumar" 
<rkku...@juniper.net<mailto:rkku...@juniper.net>>님이 작성:
Hi,

I updated number of sections based on past feedback and added/updated few 
sections based on customer interaction in industry forums (ONUG).

Thanks
Rakesh




On 7/3/17, 2:39 PM, "I2nsf on behalf of 
internet-dra...@ietf.org<mailto:internet-dra...@ietf.org>" 
<i2nsf-boun...@ietf.org<mailto:i2nsf-boun...@ietf.org> on behalf of 
internet-dra...@ietf.org<mailto:internet-dra...@ietf.org>> wrote:

>
>A New Internet-Draft is available from the on-line Internet-Drafts directories.
>This draft is a work item of the Interface to Network Security Functions of 
>the IETF.
>
>Title   : Requirements for Client-Facing Interface to Security 
> Controller
>Authors : Rakesh Kumar
>  Anil Lohiya
>  Dave Qi
>  Nabil Bitar
>  Senad Palislamovic
>  Liang Xia
>   Filename: draft-ietf-i2nsf-client-facing-interface-req-02.txt
>   Pages   : 24
>   Date: 2017-07-03
>
>Abstract:
>   This document captures requirements for Client-Facing interface to
>   the Security Controller as defined by [I-D.ietf-i2nsf-framework].
>   The interface is expressed using objects and constructs understood by
>   Security Admin as opposed to vendor or device specific expressions
>   associated with individual product and feature.  This document
>   identifies a broad set of requirements needed to express Security
>   Policies based on User-constructs which are well understood by the
>   User Community.  This gives ability to decouple policy definition
>   from policy enforcement on a specific security functional element, be
>   it a physical or virtual.
>
>
>The IETF datatracker status page for this draft is:
>https://datatracker.ietf.org/doc/draft-ietf-i2nsf-client-facing-interface-req/
>
>There are also htmlized versions available at:
>https://tools.ietf.org/html/draft-ietf-i2nsf-client-facing-interface-req-02
>https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-client-facing-interface-req-02
>
>A 

Re: [I2nsf] I-D Action: draft-ietf-i2nsf-client-facing-interface-req-02.txt

[Rakesh Kumar]

Hi,

I did not realize that time has passed for IETF upload. I think it was end of 
business day PST but it looks like UTC :-(.

I will upload once it opens.

Thanks
Rakesh


From: I2nsf <i2nsf-boun...@ietf.org<mailto:i2nsf-boun...@ietf.org>> on behalf 
of Rakesh Kumar <rkku...@juniper.net<mailto:rkku...@juniper.net>>
Date: Monday, July 3, 2017 at 3:09 PM
To: "Mr. Jaehoon Paul Jeong" 
<jaehoon.p...@gmail.com<mailto:jaehoon.p...@gmail.com>>
Cc: "i2nsf@ietf.org<mailto:i2nsf@ietf.org>" 
<i2nsf@ietf.org<mailto:i2nsf@ietf.org>>, 
"internet-dra...@ietf.org<mailto:internet-dra...@ietf.org>" 
<internet-dra...@ietf.org<mailto:internet-dra...@ietf.org>>, 
"i-d-annou...@ietf.org<mailto:i-d-annou...@ietf.org>" 
<i-d-annou...@ietf.org<mailto:i-d-annou...@ietf.org>>
Subject: Re: [I2nsf] I-D Action: 
draft-ietf-i2nsf-client-facing-interface-req-02.txt

HI Paul,

I plan to do soon (few hours).

Thanks
Rakesh

From: "Mr. Jaehoon Paul Jeong" 
<jaehoon.p...@gmail.com<mailto:jaehoon.p...@gmail.com>>
Date: Monday, July 3, 2017 at 3:07 PM
To: Rakesh Kumar <rkku...@juniper.net<mailto:rkku...@juniper.net>>
Cc: "internet-dra...@ietf.org<mailto:internet-dra...@ietf.org>" 
<internet-dra...@ietf.org<mailto:internet-dra...@ietf.org>>, 
"i2nsf@ietf.org<mailto:i2nsf@ietf.org>" 
<i2nsf@ietf.org<mailto:i2nsf@ietf.org>>, 
"i-d-annou...@ietf.org<mailto:i-d-annou...@ietf.org>" 
<i-d-annou...@ietf.org<mailto:i-d-annou...@ietf.org>>
Subject: Re: [I2nsf] I-D Action: 
draft-ietf-i2nsf-client-facing-interface-req-02.txt

Hi Rakesh,
when you will post your updated  information model later, I will update our 
data model correspondingly.

Thanks.

Best Regards,
Paul

2017. 7. 4. 오전 6:42에 "Rakesh Kumar" 
<rkku...@juniper.net<mailto:rkku...@juniper.net>>님이 작성:
Hi,

I updated number of sections based on past feedback and added/updated few 
sections based on customer interaction in industry forums (ONUG).

Thanks
Rakesh




On 7/3/17, 2:39 PM, "I2nsf on behalf of 
internet-dra...@ietf.org<mailto:internet-dra...@ietf.org>" 
<i2nsf-boun...@ietf.org<mailto:i2nsf-boun...@ietf.org> on behalf of 
internet-dra...@ietf.org<mailto:internet-dra...@ietf.org>> wrote:

>
>A New Internet-Draft is available from the on-line Internet-Drafts directories.
>This draft is a work item of the Interface to Network Security Functions of 
>the IETF.
>
>Title   : Requirements for Client-Facing Interface to Security 
> Controller
>Authors : Rakesh Kumar
>  Anil Lohiya
>  Dave Qi
>  Nabil Bitar
>  Senad Palislamovic
>  Liang Xia
>   Filename: draft-ietf-i2nsf-client-facing-interface-req-02.txt
>   Pages   : 24
>   Date: 2017-07-03
>
>Abstract:
>   This document captures requirements for Client-Facing interface to
>   the Security Controller as defined by [I-D.ietf-i2nsf-framework].
>   The interface is expressed using objects and constructs understood by
>   Security Admin as opposed to vendor or device specific expressions
>   associated with individual product and feature.  This document
>   identifies a broad set of requirements needed to express Security
>   Policies based on User-constructs which are well understood by the
>   User Community.  This gives ability to decouple policy definition
>   from policy enforcement on a specific security functional element, be
>   it a physical or virtual.
>
>
>The IETF datatracker status page for this draft is:
>https://datatracker.ietf.org/doc/draft-ietf-i2nsf-client-facing-interface-req/
>
>There are also htmlized versions available at:
>https://tools.ietf.org/html/draft-ietf-i2nsf-client-facing-interface-req-02
>https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-client-facing-interface-req-02
>
>A diff from the previous version is available at:
>https://www.ietf.org/rfcdiff?url2=draft-ietf-i2nsf-client-facing-interface-req-02
>
>
>Please note that it may take a couple of minutes from the time of submission
>until the htmlized version and diff are available at 
>tools.ietf.org<http://tools.ietf.org>.
>
>Internet-Drafts are also available by anonymous FTP at:
>ftp://ftp.ietf.org/internet-drafts/
>
>___
>I2nsf mailing list
>I2nsf@ietf.org<mailto:I2nsf@ietf.org>
>https://www.ietf.org/mailman/listinfo/i2nsf
___
I2nsf mailing list
I2nsf@ietf.org<mailto:I2nsf@ietf.org>
https://www.ietf.org/mailman/listinfo/i2nsf

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

Re: [I2nsf] I-D Action: draft-ietf-i2nsf-client-facing-interface-req-02.txt

[Rakesh Kumar]

HI Paul,

I plan to do soon (few hours).

Thanks
Rakesh

From: "Mr. Jaehoon Paul Jeong" 
<jaehoon.p...@gmail.com<mailto:jaehoon.p...@gmail.com>>
Date: Monday, July 3, 2017 at 3:07 PM
To: Rakesh Kumar <rkku...@juniper.net<mailto:rkku...@juniper.net>>
Cc: "internet-dra...@ietf.org<mailto:internet-dra...@ietf.org>" 
<internet-dra...@ietf.org<mailto:internet-dra...@ietf.org>>, 
"i2nsf@ietf.org<mailto:i2nsf@ietf.org>" 
<i2nsf@ietf.org<mailto:i2nsf@ietf.org>>, 
"i-d-annou...@ietf.org<mailto:i-d-annou...@ietf.org>" 
<i-d-annou...@ietf.org<mailto:i-d-annou...@ietf.org>>
Subject: Re: [I2nsf] I-D Action: 
draft-ietf-i2nsf-client-facing-interface-req-02.txt

Hi Rakesh,
when you will post your updated  information model later, I will update our 
data model correspondingly.

Thanks.

Best Regards,
Paul

2017. 7. 4. 오전 6:42에 "Rakesh Kumar" 
<rkku...@juniper.net<mailto:rkku...@juniper.net>>님이 작성:
Hi,

I updated number of sections based on past feedback and added/updated few 
sections based on customer interaction in industry forums (ONUG).

Thanks
Rakesh




On 7/3/17, 2:39 PM, "I2nsf on behalf of 
internet-dra...@ietf.org<mailto:internet-dra...@ietf.org>" 
<i2nsf-boun...@ietf.org<mailto:i2nsf-boun...@ietf.org> on behalf of 
internet-dra...@ietf.org<mailto:internet-dra...@ietf.org>> wrote:

>
>A New Internet-Draft is available from the on-line Internet-Drafts directories.
>This draft is a work item of the Interface to Network Security Functions of 
>the IETF.
>
>Title   : Requirements for Client-Facing Interface to Security 
> Controller
>Authors : Rakesh Kumar
>  Anil Lohiya
>  Dave Qi
>  Nabil Bitar
>  Senad Palislamovic
>  Liang Xia
>   Filename: draft-ietf-i2nsf-client-facing-interface-req-02.txt
>   Pages   : 24
>   Date: 2017-07-03
>
>Abstract:
>   This document captures requirements for Client-Facing interface to
>   the Security Controller as defined by [I-D.ietf-i2nsf-framework].
>   The interface is expressed using objects and constructs understood by
>   Security Admin as opposed to vendor or device specific expressions
>   associated with individual product and feature.  This document
>   identifies a broad set of requirements needed to express Security
>   Policies based on User-constructs which are well understood by the
>   User Community.  This gives ability to decouple policy definition
>   from policy enforcement on a specific security functional element, be
>   it a physical or virtual.
>
>
>The IETF datatracker status page for this draft is:
>https://datatracker.ietf.org/doc/draft-ietf-i2nsf-client-facing-interface-req/
>
>There are also htmlized versions available at:
>https://tools.ietf.org/html/draft-ietf-i2nsf-client-facing-interface-req-02
>https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-client-facing-interface-req-02
>
>A diff from the previous version is available at:
>https://www.ietf.org/rfcdiff?url2=draft-ietf-i2nsf-client-facing-interface-req-02
>
>
>Please note that it may take a couple of minutes from the time of submission
>until the htmlized version and diff are available at 
>tools.ietf.org<http://tools.ietf.org>.
>
>Internet-Drafts are also available by anonymous FTP at:
>ftp://ftp.ietf.org/internet-drafts/
>
>___
>I2nsf mailing list
>I2nsf@ietf.org<mailto:I2nsf@ietf.org>
>https://www.ietf.org/mailman/listinfo/i2nsf
___
I2nsf mailing list
I2nsf@ietf.org<mailto:I2nsf@ietf.org>
https://www.ietf.org/mailman/listinfo/i2nsf

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

Re: [I2nsf] Someone please say something! [Was: Working group last call on draft-ietf-i2nsf-framework]

[Rakesh Kumar]

The draft provides a very good framework for modern security policy management.
I support WGLC.

Thanks
Rakesh




On 6/23/17, 1:09 AM, "I2nsf on behalf of Adrian Farrel"  wrote:

>I know a few of you commented before the start of this last call, but reviews
>from the rest would be really welcome.
>
>Thanks,
>Adrian
>
>> -Original Message-
>> From: I2nsf [mailto:i2nsf-boun...@ietf.org] On Behalf Of Adrian Farrel
>> Sent: 16 June 2017 01:23
>> To: i2nsf@ietf.org
>> Subject: [I2nsf] Working group last call on draft-ietf-i2nsf-framework
>> 
>> All,
>> 
>> This is to start a two week working group last call on
>> draft-ietf-i2nsf-framework-05
>> 
>> Please send your comments of support, your reviews, and your concerns to this
>> list by close of business on June 29th.
>> 
>> Note that when I called for reviews at the end of last month, we received
>> feedback from Med, Christian, and Frank. The authors should consider those as
>> WG
>> last call comments : the comments don't need to be resubmitted and do need to
>> be
>> addressed.
>> 
>> John and Bob also said they had reviews in the pipe, and we would surely
>> welcome
>> those.
>> 
>> My own review will follow this email.
>> 
>> Thanks,
>> Adrian
>> 
>> ___
>> I2nsf mailing list
>> I2nsf@ietf.org
>> https://www.ietf.org/mailman/listinfo/i2nsf
>
>___
>I2nsf mailing list
>I2nsf@ietf.org
>https://www.ietf.org/mailman/listinfo/i2nsf
___
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf

Re: [I2nsf] FW: I-D Action: draft-ietf-i2nsf-problem-and-use-cases-07.txt

[Rakesh Kumar]

Hi Susan,

Xiaobo Long had requested earlier that her name be removed from all 
publications since she did not get permission from her organization. I hope we 
can honor her request in the next edit you plan to do. The changes look good to 
me.

I really appreciate your hard work in making all these edits.

Regards,
Rakesh

On 1/28/17, 4:40 PM, "I2nsf on behalf of Susan Hares" <i2nsf-boun...@ietf.org 
on behalf of sha...@ndzh.com> wrote:

Linda and Adrian: 

I believe captures all the edits and fixes all IDNITS in the draft.One
warning exists on line 872 for a tab that turns to 8 characters.  I cannot
find the tab in the xml it is complaining about.   I've sent an email to
Adrian that indicates the resolution of all comments (Adrian's,  David Qi,
and Paul Jeong's).  I appreciate the detailed review by each of these
people.  Since these are public comments to accept or not-to accept, I have
published the edited version.  I rejected a few of Adrian's and Paul Jeong's
edits - so I would like to ask Adrian, Paul, and my co-authors to verify you
are good with all differences.

I do need Adrian to respond on 2 requested changes.   Therefore, there will
be a version-08 on Monday. 

Cheers, 
Sue 

-Original Message-
From: I2nsf [mailto:i2nsf-boun...@ietf.org] On Behalf Of
internet-dra...@ietf.org
Sent: Saturday, January 28, 2017 7:38 PM
To: i-d-annou...@ietf.org
Cc: i2nsf@ietf.org
Subject: [I2nsf] I-D Action: draft-ietf-i2nsf-problem-and-use-cases-07.txt


A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Interface to Network Security Functions of
the IETF.

Title   : I2NSF Problem Statement and Use cases
Authors : Susan Hares
  Diego R. Lopex
  Myo Zarny
  Christian Jacquenet
      Rakesh Kumar
  Jaehoon Paul Jeong
Filename: draft-ietf-i2nsf-problem-and-use-cases-07.txt
Pages   : 27
Date: 2017-01-28

Abstract:
   This document describes the problem statement for Interface to
   Network Security Functions (I2NSF) as well as some companion use
   cases.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-i2nsf-problem-and-use-cases/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-i2nsf-problem-and-use-cases-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-i2nsf-problem-and-use-cases-07


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

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


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

Re: [I2nsf] Suggested updaste from Paul Jeong

[Rakesh Kumar]

HI Linda,

I just uploaded the version -05 with the updates listed below in this thread.

Thanks
Rakesh
From: Linda Dunbar <linda.dun...@huawei.com>
Date: Monday, December 5, 2016 at 1:44 PM
To: Rakesh Kumar <rkku...@juniper.net>, Susan Hares <sha...@ndzh.com>, "'Diego 
R. Lopez'" <diego.r.lo...@telefonica.com>
Cc: 'Myo Zarny' <myo.za...@gmail.com>, "christian.jacque...@orange.com" 
<christian.jacque...@orange.com>, "i2nsf@ietf.org" <i2nsf@ietf.org>
Subject: RE: Suggested updaste from Paul Jeong

Rakesh,

I would think uploading soon (ASAP), so we can get over the WGLC by end of the 
year.

Linda

From: Rakesh Kumar [mailto:rkku...@juniper.net]
Sent: 2016年12月5日 15:41
To: Linda Dunbar <linda.dun...@huawei.com>; Susan Hares <sha...@ndzh.com>; 
'Diego R. Lopez' <diego.r.lo...@telefonica.com>
Cc: 'Myo Zarny' <myo.za...@gmail.com>; christian.jacque...@orange.com; 
i2nsf@ietf.org
Subject: Re: Suggested updaste from Paul Jeong

Linda,

Let me know when do you want me to upload this version.

Thanks
Rakesh
From: Linda Dunbar <linda.dun...@huawei.com<mailto:linda.dun...@huawei.com>>
Date: Monday, December 5, 2016 at 11:37 AM
To: Rakesh Kumar <rkku...@juniper.net<mailto:rkku...@juniper.net>>, Susan Hares 
<sha...@ndzh.com<mailto:sha...@ndzh.com>>, "'Diego R. Lopez'" 
<diego.r.lo...@telefonica.com<mailto:diego.r.lo...@telefonica.com>>
Cc: 'Myo Zarny' <myo.za...@gmail.com<mailto:myo.za...@gmail.com>>, 
"christian.jacque...@orange.com<mailto:christian.jacque...@orange.com>" 
<christian.jacque...@orange.com<mailto:christian.jacque...@orange.com>>, 
"i2nsf@ietf.org<mailto:i2nsf@ietf.org>" <i2nsf@ietf.org<mailto:i2nsf@ietf.org>>
Subject: RE: Suggested updaste from Paul Jeong

Is there anyone objecting adding Paul as co-author?
If not, please go ahead adding his name and upload the draft. So that we can 
start the WGLC.

Linda

From: Rakesh Kumar [mailto:rkku...@juniper.net]
Sent: 2016年12月5日 13:19
To: Linda Dunbar <linda.dun...@huawei.com<mailto:linda.dun...@huawei.com>>; 
Susan Hares <sha...@ndzh.com<mailto:sha...@ndzh.com>>; 'Diego R. Lopez' 
<diego.r.lo...@telefonica.com<mailto:diego.r.lo...@telefonica.com>>
Cc: 'Myo Zarny' <myo.za...@gmail.com<mailto:myo.za...@gmail.com>>; 
christian.jacque...@orange.com<mailto:christian.jacque...@orange.com>; 
i2nsf@ietf.org<mailto:i2nsf@ietf.org>; Rakesh Kumar 
<rkku...@juniper.net<mailto:rkku...@juniper.net>>
Subject: Re: Suggested updaste from Paul Jeong

HI Linda,

I think, we should add Paul’s name.
We can put his name as contributing author or as a co-author as others feel 
appropriate.

Thanks
Rakesh

From: Linda Dunbar <linda.dun...@huawei.com<mailto:linda.dun...@huawei.com>>
Date: Monday, December 5, 2016 at 10:03 AM
To: Rakesh Kumar <rkku...@juniper.net<mailto:rkku...@juniper.net>>, Susan Hares 
<sha...@ndzh.com<mailto:sha...@ndzh.com>>, "'Diego R. Lopez'" 
<diego.r.lo...@telefonica.com<mailto:diego.r.lo...@telefonica.com>>
Cc: 'Myo Zarny' <myo.za...@gmail.com<mailto:myo.za...@gmail.com>>, 
"myo.za...@gs.com<mailto:myo.za...@gs.com>" 
<myo.za...@gs.com<mailto:myo.za...@gs.com>>, 
"christian.jacque...@orange.com<mailto:christian.jacque...@orange.com>" 
<christian.jacque...@orange.com<mailto:christian.jacque...@orange.com>>, 
"i2nsf@ietf.org<mailto:i2nsf@ietf.org>" <i2nsf@ietf.org<mailto:i2nsf@ietf.org>>
Subject: RE: Suggested updaste from Paul Jeong

Sue, Rakesh, Diego, et al,

Do you think the version updated by Rakesh is good enough for WGLC?
We are hoping to get the process started & finished by 2017.

Thanks, Linda

From: Rakesh Kumar [mailto:rkku...@juniper.net]
Sent: 2016年11月30日 13:59
To: Susan Hares <sha...@ndzh.com<mailto:sha...@ndzh.com>>; 'Diego R. Lopez' 
<diego.r.lo...@telefonica.com<mailto:diego.r.lo...@telefonica.com>>
Cc: 'Myo Zarny' <myo.za...@gmail.com<mailto:myo.za...@gmail.com>>; 
myo.za...@gs.com<mailto:myo.za...@gs.com>; 
christian.jacque...@orange.com<mailto:christian.jacque...@orange.com>; Linda 
Dunbar <linda.dun...@huawei.com<mailto:linda.dun...@huawei.com>>; Rakesh Kumar 
<rkku...@juniper.net<mailto:rkku...@juniper.net>>
Subject: Re: Suggested updaste from Paul Jeong

Hi Susan and all,

I took as much as possible from Pau’l contributions and added one section on 
“Regulatory and compliance” which I wanted to add.

Please find the attached “xml” document. I added following to the document sent 
by Diego. I don’t know how to diff between Diego’s version and mine.


1.  Section 3.1.1, Added a new item “Centralized or Distributed 

Re: [I2nsf] Suggested updaste from Paul Jeong

[Rakesh Kumar]

HI Linda,

I think, we should add Paul’s name.
We can put his name as contributing author or as a co-author as others feel 
appropriate.

Thanks
Rakesh

From: Linda Dunbar <linda.dun...@huawei.com>
Date: Monday, December 5, 2016 at 10:03 AM
To: Rakesh Kumar <rkku...@juniper.net>, Susan Hares <sha...@ndzh.com>, "'Diego 
R. Lopez'" <diego.r.lo...@telefonica.com>
Cc: 'Myo Zarny' <myo.za...@gmail.com>, "myo.za...@gs.com" <myo.za...@gs.com>, 
"christian.jacque...@orange.com" <christian.jacque...@orange.com>, 
"i2nsf@ietf.org" <i2nsf@ietf.org>
Subject: RE: Suggested updaste from Paul Jeong

Sue, Rakesh, Diego, et al,

Do you think the version updated by Rakesh is good enough for WGLC?
We are hoping to get the process started & finished by 2017.

Thanks, Linda

From: Rakesh Kumar [mailto:rkku...@juniper.net]
Sent: 2016年11月30日 13:59
To: Susan Hares <sha...@ndzh.com>; 'Diego R. Lopez' 
<diego.r.lo...@telefonica.com>
Cc: 'Myo Zarny' <myo.za...@gmail.com>; myo.za...@gs.com; 
christian.jacque...@orange.com; Linda Dunbar <linda.dun...@huawei.com>; Rakesh 
Kumar <rkku...@juniper.net>
Subject: Re: Suggested updaste from Paul Jeong

Hi Susan and all,

I took as much as possible from Pau’l contributions and added one section on 
“Regulatory and compliance” which I wanted to add.

Please find the attached “xml” document. I added following to the document sent 
by Diego. I don’t know how to diff between Diego’s version and mine.


1.  Section 3.1.1, Added a new item “Centralized or Distributed security 
functions:”

2.  Section 3.4, Added a new section “Software-Defined Networks”

3.  Section 4.4, Added section “Preventing Distributed DoS, Malware and 
Botnet attacks”

4.  Section 4.5, Added section “Regulatory and compliance security policies”

5.  In my opinion, we should add Paul’s name back. I have not done in the 
attached document but I feel we should.


Thanks
Rakesh
From: Susan Hares <sha...@ndzh.com<mailto:sha...@ndzh.com>>
Date: Tuesday, November 29, 2016 at 5:49 PM
To: Rakesh Kumar <rkku...@juniper.net<mailto:rkku...@juniper.net>>, "'Diego R. 
Lopez'" <diego.r.lo...@telefonica.com<mailto:diego.r.lo...@telefonica.com>>
Cc: 'Myo Zarny' <myo.za...@gmail.com<mailto:myo.za...@gmail.com>>, 
"myo.za...@gs.com<mailto:myo.za...@gs.com>" 
<myo.za...@gs.com<mailto:myo.za...@gs.com>>, 
"christian.jacque...@orange.com<mailto:christian.jacque...@orange.com>" 
<christian.jacque...@orange.com<mailto:christian.jacque...@orange.com>>, 'Linda 
Dunbar' <linda.dun...@huawei.com<mailto:linda.dun...@huawei.com>>
Subject: RE: Suggested updaste from Paul Jeong

Rakesh:

Thank you for letting me know.

Sue

From: Rakesh Kumar [mailto:rkku...@juniper.net]
Sent: Tuesday, November 29, 2016 11:42 AM
To: Susan Hares; 'Diego R. Lopez'
Cc: 'Myo Zarny'; myo.za...@gs.com<mailto:myo.za...@gs.com>; 
christian.jacque...@orange.com<mailto:christian.jacque...@orange.com>; 'Linda 
Dunbar'
Subject: Re: Suggested updaste from Paul Jeong

Hi Susan,

I will send you the changes in next couple of days.

Thanks
Rakesh

From: Susan Hares <sha...@ndzh.com<mailto:sha...@ndzh.com>>
Date: Monday, November 28, 2016 at 1:28 AM
To: "'Diego R. Lopez'" 
<diego.r.lo...@telefonica.com<mailto:diego.r.lo...@telefonica.com>>, Rakesh 
Kumar <rkku...@juniper.net<mailto:rkku...@juniper.net>>
Cc: 'Myo Zarny' <myo.za...@gmail.com<mailto:myo.za...@gmail.com>>, 
"myo.za...@gs.com<mailto:myo.za...@gs.com>" 
<myo.za...@gs.com<mailto:myo.za...@gs.com>>, 
"christian.jacque...@orange.com<mailto:christian.jacque...@orange.com>" 
<christian.jacque...@orange.com<mailto:christian.jacque...@orange.com>>, 'Linda 
Dunbar' <linda.dun...@huawei.com<mailto:linda.dun...@huawei.com>>
Subject: RE: Suggested updaste from Paul Jeong

Diego and Rakesh:

Let me know who has the token.  If Rakesh wants to send changes, I will update 
to this work.

Wi will unavailable via email during normal hours (8am-5pm ET) due to jury duty 
in the US.   I will be working 5pm (2pm PT) to 12pm ET, and 6-7 ET (am).

Sue

From: Diego R. Lopez [mailto:diego.r.lo...@telefonica.com]
Sent: Sunday, November 27, 2016 5:22 PM
To: Rakesh Kumar
Cc: Susan Hares; Myo Zarny; myo.za...@gs.com<mailto:myo.za...@gs.com>; 
christian.jacque...@orange.com<mailto:christian.jacque...@orange.com>; Linda 
Dunbar
Subject: Re: Suggested updaste from Paul Jeong

Hi Rakesh,

Good! I am attaching the latest version Sue shared with us.

Be goode,


On 27 Nov 2016, at 21:41 , Rakesh Kumar 
<rkku...@juniper.net<mailto:rkku...@juniper.net>> wrote:

I will do it.

Please send me the latest copy otherwise I will take t

Re: [I2nsf] RFC or not RFC in I2NSF?

[Rakesh Kumar]

Hi,

It looks good but I hope, we would publish the information model as well, it is 
the basis for development as different vendors/supplier may build differently 
capable systems. Here is a quote from RFC3444 (section 3.0).

“An important characteristic of IMs is that they can (and generally
   should) specify relationships between objects.  Organizations may use
   the contents of an IM to delimit the functionality that can be
   included in a DM.”
 
I am curious, whether other IETF WGs such as I2RS are publishing information 
model.

Regards, 
Rakesh

On 11/2/16, 11:42 AM, "I2nsf on behalf of Adrian Farrel" 
 wrote:

Hi,

We have a charter action and milestone to decide whether to publish our 
work as
RFCs or not. The milestone reads:

> WG decides whether to progress adopted drafts for publication as RFCs (use
cases,
> framework, information model, and examination of existing secure 
communication
> mechanisms) 

We had some (light) conversations on the list and arrived at the following
position, I think. This is your chance to scream if you disagree - 
otherwise,
this is the email of record documenting our plan.

use cases
draft-ietf-i2nsf-problem-and-use-cases
Pursue publication

framework
draft-ietf-i2nsf-framework
Pursue publication

information model
Not yet clear, but some feeling that we should publish.
Pending adoption and more work.

gap analysis for protocols
draft-ietf-i2nsf-gap-analysis
Do not publish
Keep draft alive for as long as it is useful, then archive

requirements for protocol extensions
Covered as part of draft-ietf-i2nsf-client-facing-interface-req-00 
Pursue publication

examination of existing secure communication mechanisms
Aim to add this to  draft-ietf-i2nsf-client-facing-interface-req-00 
Pursue publication

terminology
draft-ietf-i2nsf-terminology
Pursue publication

Cheers,
Adrian

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


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

[I2nsf] draft-kim-i2nsf-consumer-facing-interface-dm-00 and draft-kim-i2nsf-security-management-architecture-03

[Rakesh Kumar]

Hi Paul,

Regarding the two drafts draft-kim-i2nsf-consumer-facing-interface-dm-00 and 
draft-kim-i2nsf-security-management-architecture-03 and merging these with 
other drafts as mentioned in other threads. I have responded to 
“draft-kim-i2nsf-security-management-architecture-03” earlier but here is the 
consolidated input on both.

Here is my understanding based on reading the two candidate drafts for merge:


1.   draft-kim-i2nsf-security-management-architecture-03: As per WG 
suggestion that we merge this draft with 
“draft-kumar-i2nsf-client-facing-interface-req-01”. I have responded earlier 
but now that draft has become WG draft 
“draft-ietf-i2nsf-client-facing-interface-req”. I see your draft has few main 
themes:

oI2NSF user architecture: As I stated earlier that 
“draft-ietf-i2nsf-client-facing-interface-req” does not focus on specifics of a 
client/user system. As far as I know, this is outside the scope of I2NSF 
charter since focus is on the client-interface; so I don’t see this as a 
candidate for merge. We can discuss if you think my understanding is incorrect.

oSecurity requirements for VoIP/VolTE :  I see security requirements such 
as malware domains,  URL/IP filtering which can be enforced dynamically based 
on time calendar. This definitely falls into the scope of 
“draft-ietf-i2nsf-client-facing-interface-req”. We have defined these 
requirements and scheduling methods already but in a more generic way like 
threat feeds (IP, URL) in section 4.8. The use-case could be as VoIP/VoLTE 
security as you mentioned but if you think it is not coming out clearly then we 
can modify the text. Let us work on it.

oSecurity management system architecture:  This is not in the scope of 
“draft-ietf-i2nsf-client-facing-interface-req”. As far as I know, this is 
outside the scope of I2NSF charter since focus is on the NSF-interface; so I 
don’t see this as a candidate for merge. We can discuss if you think my 
understanding is incorrect.

2.   draft-kim-i2nsf-consumer-facing-interface-dm-00: This is a candidate 
for merge with draft-kumar-i2nsf-client-facing-interface-im as you and Linda 
pointed out but our draft is an information model, not a data model as yours. 
Anyway, I feel, we have defined these in section 5.1 and 5.3 but we can work 
with you to see whether you want to add or modify.

I know, this is one of the agenda items in Seoul, we should hash this out while 
in Seoul. I look forward to working with you on this.

Thanks & Regards,
Rakesh

--- Begin Message ---
Hi Paul,

 

Based on suggestion from Diego to see if we could merge 
draft-kim-i2nsf-security-management-architecture-01 with 
draft-kumar-i2nsf-client-facing-interface-req-01.

Our draft deals with interfaces client would use to interact with the security 
controller/management system. We are discussing only the client interfaces and 
not the client structure itself. 

 

We should have a discussion to see what can be merged. I look forward to 
working with you.

 

Thanks & Regards,

Rakesh

From: I2nsf  on behalf of "Mr. Jaehoon Paul Jeong" 

Date: Sunday, October 23, 2016 at 10:43 PM
To: "Diego R. Lopez" 
Cc: "i2nsf@ietf.org" , "Prof. Hyoungshick Kim" 
, "paulje...@skku.edu" , 
"skku_secu-brain_...@googlegroups.com" , 
Linda Dunbar 
Subject: Re: [I2nsf] questions about 
draft-kim-i2nsf-security-management-architecture-01

 

Hi Diego, 

Thanks for your comments.

 

Our draft can be aligned with draft-kumar-i2nsf-client-facing-interface-req-01 
in that

ours deals with the interface between I2NSF Client and Security Controller.

However, draft-kumar-i2nsf-client-facing-interface-req-01 does not clarify the 
structure of 

I2NSF Client in a detailed level, but our draft proposes such a detailed 
structure for I2NSF Client.

 

In addition, our draft considers the policy update in I2NSF through the report 
from an NSF 

for a security attack (e.g., DDoS attack) or an event (e.g., the detection of a 
new malware)

toward I2NSF Client. This updated policy is disseminated to the whole I2NSF 
systems

for spontaneous reaction to the new security attack or event.

 

Like this, our draft is closely related to the the I2NSF framework.

Let us prepare for the text for the I2NSF framework draft, and then discuss

whether our text can fit the I2NSF framework.

 

Thanks.

 

Best Regards,

Paul

 

 

 

 

On Sat, Oct 22, 2016 at 7:49 PM, Diego R. Lopez  
wrote:

Hi Paul, 

 

While I find agreeable that your draft could be merged with another one (or 
other ones) in order to consolidate the documents to be produced by I2NSF, I am 
not 100% sure it should be the framework draft. Looking at the proposals you 
make  in your draft I see it more aligned with what the drafts dealing with the 

Re: [I2nsf] Security for security :-)

[Rakesh Kumar]

Hi Adrian,

Thanks for pointing this out.
We will look into this and make changes.


Regards,
Rakesh
On 11/2/16, 11:33 AM, "Adrian Farrel"  wrote:

Hi,

Looking at draft-ietf-i2nsf-client-facing-interface-req I think it may be
lacking some discussion of security for the interface itself.

I think sections 4.2 through 4.5 cover some of this. But maybe there should 
also
be something in section 5?

A really good prompt for things you might need to cover is RFC 3552. Have a 
look
and see whether it causes any ideas.

Additionally, you will require a "Security Considerations" section. *if* you
have everything covered elsewhere this section can be a summary of issues 
and
resolutions complete with pointers to the relevant sections.

Thanks!

Adrian
--
Support an author and your imagination.
Tales from the Wood - Eighteen new fairy tales.
More Tales from the Wood - Eighteen MORE new fairy tales.
https://www.feedaread.com/profiles/8604/
http://www.amazon.co.uk/Tales-Wood-Adrian-Farrel/dp/1786100924
Or buy from me direct.






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

Re: [I2nsf] Will you provide more details on the Rules' Information model in draft-kumar-i2nsf-client-facing-interface-im-00.txt?

[Rakesh Kumar]

Hi Linda,

One more thing regarding how a policy/rule is to be enforced. We see two 
distinct requirements:


1.   Static security posture --> The security admin determines what 
security policies need to be enforced in their network based on their business 
needs (access policies such as who can access what) and/or regulatory 
compliance (HIPPA, FISA). These policies usually stay in the network unless 
manually removed. In my experience, majority of security policies fall under 
this category.

2.   Dynamic  security posture --> Some of the policies may be created but 
not always enforced. A security admin may want to increase or decrease its 
security posture based on an event. The event could be a time-based or threat 
based. For example, a policy is enforced only during weekend or a policy is 
enforced only when a DDoS event is detected.

I don’t have any name for first one but the second one is ECA (Event Condition 
Action). We wanted to take both of them for interfaces to be meaningful in real 
security world. I hope this clarifies our thinking. We can add a section in our 
draft to put similar text there if you think that would be helpful.

Thanks & Regards,
Rakesh


From: I2nsf <i2nsf-boun...@ietf.org> on behalf of Rakesh Kumar 
<rkku...@juniper.net>
Date: Tuesday, November 1, 2016 at 11:56 AM
To: Linda Dunbar <linda.dun...@huawei.com>, "i2nsf@ietf.org" <i2nsf@ietf.org>
Cc: Adrian Farrel <afar...@juniper.net>
Subject: Re: [I2nsf] Will you provide more details on the Rules' Information 
model in draft-kumar-i2nsf-client-facing-interface-im-00.txt?

Hi Linda,

Thanks a lot for the review.

One of the biggest challenges in the security world today is that, it is too 
complex with each vendor having their own set of features and functionality 
exposed in a very proprietary manner.  We have to simplify this with I2NSF 
client-facing interface so that a security admin can express their business 
needs without having to worry about the complexity.

It is very important that security requirements be expressed by security admin 
with simple rules. But it is easier said than done, this is one of the most 
complex problem as how to make rules simple but at the same time able to 
capture wide variety of use-cases in different environment.

The work done so far in this draft is just the beginning and we should brain 
storm and see how to make it more complete. I will look at the link you have 
sent and see how to leverage from there. Even if we develop very generic rules, 
we still need to define some basic constructs which would be used to build a 
policy. We have taken a step in that direction, but this is just a start and 
work will continue with ideas from folks in this WG.


Regards,
Rakesh

From: Linda Dunbar <linda.dun...@huawei.com>
Date: Tuesday, November 1, 2016 at 10:55 AM
To: Rakesh Kumar <rkku...@juniper.net>, "i2nsf@ietf.org" <i2nsf@ietf.org>
Cc: Adrian Farrel <afar...@juniper.net>
Subject: RE: [I2nsf] Will you provide more details on the Rules' Information 
model in draft-kumar-i2nsf-client-facing-interface-im-00.txt?

Rakesh,

By the way, the I2NSF framework has specified to use ECA (Event Condition 
Action) to describe “Rules”.
https://datatracker.ietf.org/doc/draft-xibassnez-i2nsf-capability/ has the 
detailed description on how “Rules” information model.

Is there any issue to utilize those information model?

Thanks,
Linda

From: I2nsf [mailto:i2nsf-boun...@ietf.org] On Behalf Of Linda Dunbar
Sent: 2016年11月1日 12:10
To: Rakesh Kumar <rkku...@juniper.net>; i2nsf@ietf.org
Cc: Adrian Farrel <afar...@juniper.net>
Subject: [I2nsf] Will you provide more details on the Rules' Information model 
in draft-kumar-i2nsf-client-facing-interface-im-00.txt?

Rakesh,

Thank you very much for contributing the draft. Just curious, the current IM 
for Rules doesn't have much details:


[cid:image001.jpg@01D234E9.B3807410]

Will you add more in future revision?

Linda Dunbar

-Original Message-
From: I2nsf [mailto:i2nsf-boun...@ietf.org] On Behalf Of Rakesh Kumar
Sent: 2016年10月31日 12:14
To: i2nsf@ietf.org<mailto:i2nsf@ietf.org>
Cc: Adrian Farrel <afar...@juniper.net<mailto:afar...@juniper.net>>; Linda 
Dunbar <linda.dun...@huawei.com<mailto:linda.dun...@huawei.com>>
Subject: [I2nsf] FW: New Version Notification for 
draft-kumar-i2nsf-client-facing-interface-im-00.txt

We posted a new draft that captures an information model for the client-facing 
interfaces based on “draft-ietf-i2nsf-client-facing-interface-req”.
This is an initial version, we plan to update this as we evolve based on new 
requirements and information.


Thanks & Regards,
Rakesh and other co-authors.


On 10/31/16, 10:08 AM, 
"internet-dra...@ietf.org<mailto:internet-dra...@ietf.org>" 
<internet-dra...@ietf.org<mailto:internet-dra...@ietf.org>> wrote:


A new version of

Re: [I2nsf] Will you provide more details on the Rules' Information model in draft-kumar-i2nsf-client-facing-interface-im-00.txt?

[Rakesh Kumar]

Hi Linda,

Thanks a lot for the review.

One of the biggest challenges in the security world today is that, it is too 
complex with each vendor having their own set of features and functionality 
exposed in a very proprietary manner.  We have to simplify this with I2NSF 
client-facing interface so that a security admin can express their business 
needs without having to worry about the complexity.

It is very important that security requirements be expressed by security admin 
with simple rules. But it is easier said than done, this is one of the most 
complex problem as how to make rules simple but at the same time able to 
capture wide variety of use-cases in different environment.

The work done so far in this draft is just the beginning and we should brain 
storm and see how to make it more complete. I will look at the link you have 
sent and see how to leverage from there. Even if we develop very generic rules, 
we still need to define some basic constructs which would be used to build a 
policy. We have taken a step in that direction, but this is just a start and 
work will continue with ideas from folks in this WG.


Regards,
Rakesh

From: Linda Dunbar <linda.dun...@huawei.com>
Date: Tuesday, November 1, 2016 at 10:55 AM
To: Rakesh Kumar <rkku...@juniper.net>, "i2nsf@ietf.org" <i2nsf@ietf.org>
Cc: Adrian Farrel <afar...@juniper.net>
Subject: RE: [I2nsf] Will you provide more details on the Rules' Information 
model in draft-kumar-i2nsf-client-facing-interface-im-00.txt?

Rakesh,

By the way, the I2NSF framework has specified to use ECA (Event Condition 
Action) to describe “Rules”.
https://datatracker.ietf.org/doc/draft-xibassnez-i2nsf-capability/ has the 
detailed description on how “Rules” information model.

Is there any issue to utilize those information model?

Thanks,
Linda

From: I2nsf [mailto:i2nsf-boun...@ietf.org] On Behalf Of Linda Dunbar
Sent: 2016年11月1日 12:10
To: Rakesh Kumar <rkku...@juniper.net>; i2nsf@ietf.org
Cc: Adrian Farrel <afar...@juniper.net>
Subject: [I2nsf] Will you provide more details on the Rules' Information model 
in draft-kumar-i2nsf-client-facing-interface-im-00.txt?

Rakesh,

Thank you very much for contributing the draft. Just curious, the current IM 
for Rules doesn't have much details:


[cid:image001.jpg@01D23437.0C337430]

Will you add more in future revision?

Linda Dunbar

-Original Message-
From: I2nsf [mailto:i2nsf-boun...@ietf.org] On Behalf Of Rakesh Kumar
Sent: 2016年10月31日 12:14
To: i2nsf@ietf.org<mailto:i2nsf@ietf.org>
Cc: Adrian Farrel <afar...@juniper.net<mailto:afar...@juniper.net>>; Linda 
Dunbar <linda.dun...@huawei.com<mailto:linda.dun...@huawei.com>>
Subject: [I2nsf] FW: New Version Notification for 
draft-kumar-i2nsf-client-facing-interface-im-00.txt

We posted a new draft that captures an information model for the client-facing 
interfaces based on “draft-ietf-i2nsf-client-facing-interface-req”.
This is an initial version, we plan to update this as we evolve based on new 
requirements and information.


Thanks & Regards,
Rakesh and other co-authors.


On 10/31/16, 10:08 AM, 
"internet-dra...@ietf.org<mailto:internet-dra...@ietf.org>" 
<internet-dra...@ietf.org<mailto:internet-dra...@ietf.org>> wrote:


A new version of I-D, draft-kumar-i2nsf-client-facing-interface-im-00.txt
has been successfully submitted by Rakesh Kumar and posted to the
IETF repository.

Name:   draft-kumar-i2nsf-client-facing-interface-im
Revision:   00
Title:  Information model for Client-Facing Interface to 
Security Controller
Document date:  2016-10-31
Group:  Individual Submission
Pages:  17
URL:
https://www.ietf.org/internet-drafts/draft-kumar-i2nsf-client-facing-interface-im-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-kumar-i2nsf-client-facing-interface-im/
Htmlized:   
https://tools.ietf.org/html/draft-kumar-i2nsf-client-facing-interface-im-00


Abstract:
   This document defines information model for the client-facing
   interface to security controller based on the requirements identfied
   in the [I-D.kumar-i2nsf-client-facing-interface-req].  The
   information model defines various managed objects and the
   relationship among these objects needed to build the client
   interfaces.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat



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

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

[I2nsf] FW: New Version Notification for draft-kumar-i2nsf-client-facing-interface-im-01.txt

[Rakesh Kumar]

I have bunch of indentation issues in the -00 version. I fixed those with -01 
version.

Thanks
Rakesh

On 10/31/16, 3:44 PM, "internet-dra...@ietf.org" <internet-dra...@ietf.org> 
wrote:


A new version of I-D, draft-kumar-i2nsf-client-facing-interface-im-01.txt
has been successfully submitted by Rakesh Kumar and posted to the
IETF repository.

Name:   draft-kumar-i2nsf-client-facing-interface-im
Revision:   01
Title:  Information model for Client-Facing Interface to 
Security Controller
Document date:  2016-10-31
Group:  Individual Submission
Pages:  17
URL:
https://www.ietf.org/internet-drafts/draft-kumar-i2nsf-client-facing-interface-im-01.txt
Status: 
https://datatracker.ietf.org/doc/draft-kumar-i2nsf-client-facing-interface-im/
Htmlized:   
https://tools.ietf.org/html/draft-kumar-i2nsf-client-facing-interface-im-01
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-kumar-i2nsf-client-facing-interface-im-01

Abstract:
   This document defines information model for the client-facing
   interface to security controller based on the requirements identfied
   in the [I-D.kumar-i2nsf-client-facing-interface-req].  The
   information model defines various managed objects and the
   relationship among these objects needed to build the client
   interfaces.


  


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat



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

Re: [I2nsf] with regarding to WG adoption for the revised draft-kumar-i2nsf-client-facing-interface-req-01.txt

[Rakesh Kumar]

Hi,

I want to thank Diego and John for useful suggestions and comments. We have 
incorporated most of the changes suggested here (some of them verbatim).

We also did a thorough analysis of the document and removed/modified any 
confusing and incorrect text.
We have done following changes across the board:

1.   Change developer back to vendor, I see even other working group draft 
are using this term. The “developer” caused confusion as rightly pointed by 
John.
2.   Change “user-intent” to “user-construct”. Even though, authors have 
some reservation, but in light of showing consensus we changed it. I could not 
find better term
  to describe what we want to accomplish.

I just posed the updated draft 
https://tools.ietf.org/html/draft-kumar-i2nsf-client-facing-interface-req-02 
with above changes.

Regards,
Rakesh

From: I2nsf  on behalf of "Diego R. Lopez" 

Date: Saturday, October 22, 2016 at 4:42 AM
To: "i2nsf@ietf.org" 
Subject: Re: [I2nsf] with regarding to WG adoption for the revised 
draft-kumar-i2nsf-client-facing-interface-req-01.txt

Hi,

When going through the document I found that most of my original comments were 
addressed and therefore I was not going to object adoption, taking into account 
the urgency that many in the WG see for this adoption, but after reading John’s 
comments I think there are a couple of issues that require further discussion 
before. The first and foremost is the question of intent and how the term is 
used and developed in the document, as this is a term that cannot be considered 
only in the realm of this document, and in the current version the definition 
of what intent is and the proposed constructs seems key for the evolution of 
the draft. The second, that I must confess I originally overlooked but I see as 
a serious aspect, is the discussion on how this draft is going to be combined 
with other existing ones that predate it and that also include requirements. I 
support John’s request of a detailed discussion and agreement at least in these 
two points, that I think that are essential.

A few other comments inline below. I’ve trimmed John’s original message to make 
text more readable.

On 20 Oct 2016, at 09:21 , John Strassner 
> wrote:


  *   You continue to say that the "interfaces are based on user-intent instead 
of ..." but do not define what user-intent is

 *   The "definition" in the paragraph above section 2 on page 4 doesn't 
make sense. You state that it is not "some free-form natural language", but 
rather "client-oriented expressions such as application names, application 
groups, device groups, user groups etc." - this is starting to describe a 
language, which is completely out of scope of I2NSF
 *   You continue "with a vocabulary of verbs (e.g., drop, tap, throttle), 
prepositions, conjunctions, conditionals, adjectives, and nouns instead of 
using standard n-tuples from the packet header" - you are now describing a 
language that looks a lot like English, but have not defined either the 
grammatical rules for using such language elements, or where these come from 
and how they are defined (plus, it is completely out of scope of I2NSF)
 *   Worse, you allude to mapping intent to device functions, but do not 
describe how this is done

DRL> In a separate discussion with Rakesh I suggested to refer to an external 
definition of intent, well accepted in the networking community (I think Sue 
can be of an invaluable help for this) and consider the list of constructs as 
requirements of what a proper support of intent would have to provide. Instead 
of defining the language (mandating constructs) the draft would define what any 
proper language should have to incorporate, in the spirit of a requirements 
document


  *   Section 1

 *   Your use of "developer" is confusing. For example, "developer's 
specific devices" is not (I hope) what you mean - I'm a developer and I don't 
have a device; in fact, I write programs for devices from multiple vendors.
 *   The bulk of section 1 assumes a "single developer" approach, which is, 
as you say, not valid. What I **think** you are talking about is a single 
development environment. However, this needs to be substantiated.

DRL> I feel guilty for this. I insisted in having the term “vendor” substituted 
by “developer” through the whole document, to reflect that NSFs could be 
provided as open-source software. Facing how this substitution works, I agree 
we need to think in more detail where to use each term.

 *   The 2nd paragraph above section 2 on page 4 ("In order to...working 
group") doesn't make sense. You allude to ease (not easiness), but then say 
that this is completely out of scope. What, then, is the point you are trying 
to make?

DRL> Reading the draft for the first time I had the same impression. I’d 
propose an alternate 

Re: [I2nsf] questions about draft-kim-i2nsf-security-management-architecture-01

[Rakesh Kumar]

Hi Paul,

Based on suggestion from Diego to see if we could merge 
draft-kim-i2nsf-security-management-architecture-01 with 
draft-kumar-i2nsf-client-facing-interface-req-01.
Our draft deals with interfaces client would use to interact with the security 
controller/management system. We are discussing only the client interfaces and 
not the client structure itself.

We should have a discussion to see what can be merged. I look forward to 
working with you.

Thanks & Regards,
Rakesh
From: I2nsf  on behalf of "Mr. Jaehoon Paul Jeong" 

Date: Sunday, October 23, 2016 at 10:43 PM
To: "Diego R. Lopez" 
Cc: "i2nsf@ietf.org" , "Prof. Hyoungshick Kim" 
, "paulje...@skku.edu" , 
"skku_secu-brain_...@googlegroups.com" , 
Linda Dunbar 
Subject: Re: [I2nsf] questions about 
draft-kim-i2nsf-security-management-architecture-01

Hi Diego,
Thanks for your comments.

Our draft can be aligned with draft-kumar-i2nsf-client-facing-interface-req-01 
in that
ours deals with the interface between I2NSF Client and Security Controller.
However, draft-kumar-i2nsf-client-facing-interface-req-01 does not clarify the 
structure of
I2NSF Client in a detailed level, but our draft proposes such a detailed 
structure for I2NSF Client.

In addition, our draft considers the policy update in I2NSF through the report 
from an NSF
for a security attack (e.g., DDoS attack) or an event (e.g., the detection of a 
new malware)
toward I2NSF Client. This updated policy is disseminated to the whole I2NSF 
systems
for spontaneous reaction to the new security attack or event.

Like this, our draft is closely related to the the I2NSF framework.
Let us prepare for the text for the I2NSF framework draft, and then discuss
whether our text can fit the I2NSF framework.

Thanks.

Best Regards,
Paul




On Sat, Oct 22, 2016 at 7:49 PM, Diego R. Lopez 
> wrote:
Hi Paul,

While I find agreeable that your draft could be merged with another one (or 
other ones) in order to consolidate the documents to be produced by I2NSF, I am 
not 100% sure it should be the framework draft. Looking at the proposals you 
make in your draft I see it more aligned with what the drafts dealing with the 
client-facing interface are considering than with the general framework. In 
particular, 
draft-kumar-i2nsf-client-facing-interface-req-01
 has a section(3.3) that discusses management deployment models, and I am under 
the impression this architecture you propose could be seen as a refinement of 
those models.

Be goode,

On 21 Oct 2016, at 02:54 , Mr. Jaehoon Paul Jeong 
> wrote:

Hi Linda,
Are you agreeing at merging our draft 
(draft-kim-i2nsf-security-management-architecture-02)
into draft-ietf-i2nsf-framework-03?

Thanks.

Best Regards,
Paul

On Fri, Oct 7, 2016 at 5:32 AM, Mr. Jaehoon Paul Jeong 
> wrote:
Hi Linda,
As a coauthor of this draft, I will answer your questions inline below.

On Wed, Oct 5, 2016 at 1:34 PM, Linda Dunbar 
> wrote:
Hyoungshick, et al,

How would you position your draft-kim-i2nsf-security-management-architecture-01 
with regard to the I2NSF framework draft? I find there are  a lot of duplicated 
content to the I2nsf framework draft.

 [Paul] We would like to merge our draft into the i2nsf framework draft
 because our draft has one depth more detailed architecture.
 This detailed architecture will be helpful to implement the i2nsf framework.


There are some differences,  such as the following: Are you trying to define 
how “security policy” is structured?



 [Paul] Our architecture allows an NSF to update a low-level policy and apply 
it to the related high-level policy
 via the control path of Security Controller and Policy Collector (renamed 
Event Collector in version 02) in Figure 1
 of our version 02:
 https://tools.ietf.org/html/draft-kim-i2nsf-security-management-architecture-02

 For example, if an NSF of firewall detects a new DoS-attack host, it reports 
the updated blacklist having
 the IP address of such a host to Application Logic in I2NSF Client via 
Security Controller and Event Collector.
 Application Logic asks Policy Updater to disseminate the updated blacklist to 
the security controllers
 under the administration of the same I2NSF Client.

Will the “High Level security management” eventually lead to Client Facing 
Policy data models?

 [Paul] Yes, as explained above, the High-level security management leads to 
update and handle Client facing policy
 data models.

Do you plan to define interfaces between all those components depicted in 

Re: [I2nsf] Info models and draft-zhang-i2nsf-info-model-monitoring

[Rakesh Kumar]

I also prefer that we have two separate publications based on RFC3444 
guidelines.


1.   Information model --> plain text is enough to describe managed objects 
and their relationship

2.   Data model --> YANG or some other representation

Thanks & Regards,
Rakesh
From: I2nsf  on behalf of John Strassner 

Date: Wednesday, October 26, 2016 at 8:40 AM
To: "Diego R. Lopez" , John Strassner 

Cc: "i2nsf@ietf.org" , "adr...@olddog.co.uk" 

Subject: Re: [I2nsf] Info models and draft-zhang-i2nsf-info-model-monitoring

Hi all,

The main reason for publishing an information model is to support multiple data 
models that are derived from it.

I realize that the IETF is worried mainly about YANG data models. That is 
perfectly well and good. However, security controllers will need to interface 
with compute, storage, and other systems that have poor (if any) YANG coverage. 
As soon as I go into a data center or a cloud, YANG is simply not used for 
compute and storage solutions.

This means that we can either ignore that, and build a silo, or take it into 
account, or not.

   If we choose to ignore, there is no reason to publish the info model.
   If we choose not to ignore, and want to support other data models, then we 
SHOULD publish the info model as well. Even if we only have 1 data model now.

Hence, I personally would prefer two publications - one for the info model, and 
one for the YANG data model.


best,
John

On Sat, Oct 22, 2016 at 4:29 AM, Diego R. Lopez 
> wrote:
Hi Adrian,

Agree: it is a useful tool but should not be a separate publication. The only 
reason for publishing the information model could be to do so in the same 
document as the data model, as rationale supporting it, and even giving the 
opportunity for alternate data models using other data representations (TOSCA, 
for example, very much in fashion in cloudspace).

Be goode,

On 14 Oct 2016, at 11:54 , Adrian Farrel 
> wrote:

Thanks, all, for the useful comments about this document.

It seems clear that there is support for developing this work and producing a
data model for monitoring.

Two points:

1. As noted by Sue, there is a BoF/WG planned for IETF-98 on "Security Events".
I suggest you go to that. I will also make sure the AD is aware of the potential
overlap/interaction.

2. It seems reasonable to me that producing an information model (such as in
draft-zhang-i2nsf-info-model-monitoring) is a useful step toward producing a
data model. I have no objection to using a structured approach. However, my
question about "publication" could be phrased as follows:
- Suppose we decide we want a data model for monitoring
- Suppose we use draft-zhang-i2nsf-info-model-monitoring to guide
  our work on that data model
- Suppose that we push ahead with the data model quite soon so
  that it starts to catch up with the info model
If all of those things apply, why would we need to publish an RFC that captures
the information model given that we will be publishing a data model shortly
afterwards?
Presumably, once the data model is published, no one will ever read the
information model.
So the information model would be a valuable document working document in which
the WG would capture its thoughts and consensus, but would be discarded once the
work to make the data model was complete.

Or am I wrong?

Thanks,
Adrian


-Original Message-
From: Susan Hares [mailto:sha...@ndzh.com]
Sent: 13 October 2016 14:49
To: adr...@olddog.co.uk; 
i2nsf@ietf.org
Subject: RE: [I2nsf] Thoughts on draft-zhang-i2nsf-info-model-monitoring

Adrian:

Why: Monitoring is a key component to I2NSF for monitoring NSF devices.
Monitoring is not the same as NSF devices sending notifications - which is a
push from the NSF devices.  Monitoring may encompasses specific requests to
the device.   Monitoring is different than the DOTS - "help me" cry from a
device under attack.
While I see the security ADs are proposing Security event, it is important
that the I2NSF create monitoring concepts that work with all of the
functions (e.g. querying capabilities, sending/receiving notification, and
events).

Data model versus Information model:  Since we do not seem to have a clear
idea of what the data model should be, it is important to create the
informational models.

The content of the draft is a good first step.

Sue Hares



-Original Message-
From: I2nsf [mailto:i2nsf-boun...@ietf.org] On Behalf Of Adrian Farrel
Sent: Tuesday, October 11, 2016 5:22 PM
To: i2nsf@ietf.org
Subject: [I2nsf] Thoughts on draft-zhang-i2nsf-info-model-monitoring

Working Group,

Linda and I would like to hear some more from you about

Re: [I2nsf] Call for WG adoption of draft-kumar-i2nsf-client-facing-interface-req

[Rakesh Kumar]

HI Ed,

I would be happy to address your concerns and/or incorporate new ideas you may 
have into the draft as we proceed in the WG. We would definitely take 
suggestions about the content and way to express requirements.

Regards,
Rakesh

From: I2nsf  on behalf of "elopez.i...@nym.hush.com" 

Date: Tuesday, September 27, 2016 at 11:41 AM
To: Linda Dunbar , "i2nsf@ietf.org" 
Subject: Re: [I2nsf] Call for WG adoption of 
draft-kumar-i2nsf-client-facing-interface-req

I am good with the framework, but I have reservations on the functional and 
operational requirements.  I'm good to adopt this as a WG document, in the 
intent that we need to focus our effort on this, but I'm not comfortable with 
the content in its current state

- Ed

On 9/21/2016 at 1:55 PM, "Linda Dunbar"  wrote:
Dear WG:

This email serves as a call for WG adoption of 
draft-kumar-i2nsf-client-facing-interface-req as a WG document. The call for 
adoption will run for 2 weeks ending Oct 5, 2016.
The requirement document is one of the key deliverables specified by the  I2NSF 
charter.

Please note that this is a call for adoption, and not a last call for content 
of the document. Adopting a WG document simply means that the WG will focus its 
efforts on that particular draft going forward, and use that document for 
resolving open issues and documenting the WG’s decisions.

Please indicate whether you support adoption for not, and if not why. Issues 
you have with the current document itself can also be raised, but they should 
be raised in the context of what should be changed in the document going 
forward, rather than a pre-condition for adoption.

Finally, now is also a good time to poll for knowledge of any IPR that applies 
to this draft, in line with the IPR disclosure obligations for WG participants 
(see RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed as a 
document author please respond to this email (to the chairs) whether or not you 
are aware of any relevant IPR
https://tools.ietf.org/id/draft-kumar-i2nsf-client-facing-interface-req-00.txt


Authors: there are some editorial changes needed to comply with the I2NSF 
terminologies that the WG has agreed, in particular:

-Abstract: needs to change the starting sentence to “This document 
provides a framework and requirement ….”

-Change all reference of “North Bound Interface” to “Client/consumer 
facing interface”.

Thank you,

Linda & Adrian

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

Re: [I2nsf] I2NSF Terminology's definition on "ACL" is different from ietf-netmod-acl-model

[Rakesh Kumar]

Hi Linda,

As evident (https://en.wikipedia.org/wiki/Access_control_list), the ACL has 
different meaning to different folks (IT, Network). John rightly pointed out 
that originally it meant some kind of permission but networking industry 
adopted this to associate with packet filtering as you pointed out.

History aside, the ACL have evolved dramatically over the years for various 
reasons:

· Vendor want to give admin control over operational state of the 
networking device (override protocols or control plane)

· SDN controller use ACL to configure operational state instead of 
running control plane

· Feature (forwarding/Security/QoS/Monitoring) 
innovation/differentiations by vendors

In my opinion, ACL can be lot more than filtering or permission (of course each 
vendor has different capability) but I am not sure what is our (I2NSF) specific 
goal behind this discussion.

Do we just make sure that definition is same across all IETF work no matter how 
outdated?
Do we want to make sure that it aligns with where the networking industry is?
Do we want to make sure that it aligns with the security work we are doing in 
I2NSF?

Thanks & Regards,
Rakesh


From: I2nsf  on behalf of John Strassner 

Date: Monday, September 12, 2016 at 5:31 PM
To: Linda Dunbar , John Strassner 
, DIEGO LOPEZ GARCIA , 
"Xialiang (Frank)" 
Cc: "i2nsf@ietf.org" , Susan Hares 
Subject: Re: [I2nsf] I2NSF Terminology's definition on "ACL" is different from 
ietf-netmod-acl-model

Hi Linda,

My vote is NO.

With all due respect, RFC4949 predates the acl model by almost 7 years. 
Furthermore, ACLs may or may not **filter** traffic. The roots of ACLs go much 
farther back (at least to 1997 that I can find) and, fundamentally, are 
permissions. A permission is not the same as filtering. Finally, we would then 
have to define ACEs, and not all ACL models have ACEs.

regards,
John

On Mon, Sep 12, 2016 at 10:06 AM, Linda Dunbar 
> wrote:
John, et al,

The “ietf-netmod-acl-model” has “ACL” defined as:
An ACL is an ordered set of rules that is used to filter traffic on a
networking device. Each rule is represented by an Access Control
Entry (ACE).

The “draft-ietf-i2nsf-terminology-01” has ACL as:

ACL (Acess Control List):  This is a mechanism that implements
  access control for a system resource by enumerating the system
  entities that are permitted to access the resource and stating,
  either implicitly or explicitly, the access modes granted to each
  entity [RFC4949]. A YANG description is defined in
  [I-D.ietf-netmod-acl-model].



Can we make I2NSF’s ACL definition consistent with the ““ietf-netmod-acl-model”?

Thanks,
Linda



--
regards,
John
___
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf

Re: [I2nsf] Why do we have "negotiation" for the "Control Plane"

[Rakesh Kumar]

Hi Linda,

The example you mentioned below seem like a capability discovery and an 
appropriate action taken based on that.  A negotiation is different in my 
opinion, for example IPSEC peers negotiate hashing and encryption algorithm to 
establish a secured connection.

Even before we go into this question, we have to clarify I2NSF control plane. 
In my opinion, I2NSF defines the management plane (controller interfaces) for 
NSF. The control plane and data plane of NSF should be out of scope for I2NSF 
(Look at draft https://datatracker.ietf.org/doc/draft-ietf-i2nsf-framework).

The NSF control plane and data plane, is for each VNF/PNF vendor to define and 
as long as NSF provides I2NSF management interface (NSF-facing interface), it 
should be sufficient.

Thanks & Regards,
Rakesh

From: Linda Dunbar <linda.dun...@huawei.com>
Date: Monday, September 12, 2016 at 12:59 PM
To: Rakesh Kumar <rkku...@juniper.net>
Cc: "i2nsf@ietf.org" <i2nsf@ietf.org>
Subject: Why do we have "negotiation" for the "Control Plane"

Rakesh,

Here is a use case to address your following  question: Cloud (Overlay) Network 
needs the underlay network to enforce Rule A & B  Not sure of the capability 
of the underlay network, the Overlay Network can send an inquiry to the 
underlay network asking if it supports Rule A  The underlay network may 
respond with “Only Rule A”. Then the Overlay network can only send “Rule A” to 
be enforced by the Underlay network.


Control Plane:  In the context of I2NSF, the Control Plane is an
  architectural Component that provides common control functions
  to all I2NSF Components, including some or all of the following:
  authentication, authorization, accounting, auditing, and
  Capability discovery and negotiation.

[Rakesh & Anil] Why do we have “negotiation”? What are we trying to negotiate?


Cheers,
Linda


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

Re: [I2nsf] A New I-D on Northbound Interfaces for Security Policy Controllers : A Framework and Information Model

[Rakesh Kumar]

Hi Linda,

You are absolutely correct about assumption sometime made that “user-intent” 
means some kind of natural language input (just the way you mentioned below). 
This point was also raised by Adrian during my discussion with him. But we 
don’t mean that, what we mean is that when client express policy, they would 
use the object defined in the draft such as “user-group” instead of using L3-L4 
information which is not very intuitive approach.

I would appreciate if you are Adrian can help us put some clarification in the 
draft with regards to this. If you are okay with above explanation, I can add 
this as well.

Please let me know your thoughts.

Regards,
Rakesh

From: Linda Dunbar <linda.dun...@huawei.com<mailto:linda.dun...@huawei.com>>
Date: Friday, July 8, 2016 at 2:47 PM
To: Rakesh Kumar <rkku...@juniper.net<mailto:rkku...@juniper.net>>, 
"i2nsf@ietf.org<mailto:i2nsf@ietf.org>" <i2nsf@ietf.org<mailto:i2nsf@ietf.org>>
Cc: Dave Qi <d...@bloomberg.net<mailto:d...@bloomberg.net>>, Anil Lohiya 
<aloh...@juniper.net<mailto:aloh...@juniper.net>>, Xiaobo Long 
<long.xia...@gmail.com<mailto:long.xia...@gmail.com>>, Adrian Farrel 
<adr...@olddog.co.uk<mailto:adr...@olddog.co.uk>>
Subject: RE: [I2nsf] A New I-D on Northbound Interfaces for Security Policy 
Controllers : A Framework and Information Model

Rakesh,

Absolutely, “user-group”, “application-group” etc, should be included for 
client facing interface.

There are several “Intent” initiatives in the industry. We want to make it 
clear that abstract “intent” will not be in the scope, such as  “I want my 
traffic secure”, or “I don’t want DDoS attacks”  etc.

The Flow Security Policies on the Service Facing Interface should be able to be 
converted to flow policies to NSFs with deterministic logics

Linda

From: Rakesh Kumar [mailto:rkku...@juniper.net]
Sent: Friday, July 08, 2016 3:51 PM
To: Linda Dunbar; i2nsf@ietf.org<mailto:i2nsf@ietf.org>
Cc: Dave Qi; Anil Lohiya; Xiaobo Long; Adrian Farrel; Rakesh Kumar
Subject: Re: [I2nsf] A New I-D on Northbound Interfaces for Security Policy 
Controllers : A Framework and Information Model

Hi Linda,

I appreciate your comment. Please see response below.

Regards,
Rakesh

From: Linda Dunbar <linda.dun...@huawei.com<mailto:linda.dun...@huawei.com>>
Date: Friday, July 8, 2016 at 11:14 AM
To: Rakesh Kumar <rkku...@juniper.net<mailto:rkku...@juniper.net>>, 
"i2nsf@ietf.org<mailto:i2nsf@ietf.org>" <i2nsf@ietf.org<mailto:i2nsf@ietf.org>>
Cc: Dave Qi <d...@bloomberg.net<mailto:d...@bloomberg.net>>, Anil Lohiya 
<aloh...@juniper.net<mailto:aloh...@juniper.net>>, Xiaobo Long 
<long.xia...@gmail.com<mailto:long.xia...@gmail.com>>, Adrian Farrel 
<adr...@olddog.co.uk<mailto:adr...@olddog.co.uk>>
Subject: RE: [I2nsf] A New I-D on Northbound Interfaces for Security Policy 
Controllers : A Framework and Information Model

Rakesh,

Thank you very much for contributing the draft.
Finally got chance to read through.

Your draft has described  very good  requirement for Customer Facing interface. 
 It seems more reasonable to call the draft as  i2nsf-customer-facing-req than 
“framework”. What do you think?
[rakesh] This is fine with me if you think this reflects the content more 
accurately. We wanted to show what information model need to be considered for 
the Customer Facing Interface.

“user-intent”  is brought up  in your draft.  Since there could be many depths 
or types of customer facing policies, I2NSF Charter has the following bullets 
further clarify the scope of I2NSF:

·   Only the simple Service Layer policies that are modeled as closely as 
possible on the Capability Layer are within the scope.
Simple Service Layer policies can be directly translated to capability layer 
rules with a direct mapping that might include a customer ID to be translated 
to tags carried by packets, but might not specify the NSF. This flexibility in 
the simple Service Layer enables a security controller to handle issues like 
multi-tenancy and the choice between available NSFs for a given policy.
[rakesh] We should discuss this topic more in Berlin. But here is our thought 
process.

  1.  We can not just translate/expose I2NSF southbound/NSF interface as 
northbound/client interface from security controller. There has to be some 
abstraction. In that case, security controller would just become a API proxy 
agent.
  2.  The “user-intent” means the interface should abstraction as defined in 
our draft such as “user-group”, “application-group” when expressing 
northbound/client policy interface.
  3.  The whole idea behind defining/using “security policy controller” is to 
make security deployment less complex otherwise one can directly use I2NSF 
southbound/NSF interface without a need for controller.





Thanks, Linda