Re: [I2nsf] what is the "client" to I2NSF controller? (was RE: Should we call "South Bound Interface" for the interface between "controller <-> NSF", and "North Bound Interface" for the interface betw

[Diego R. Lopez]

I agree with John’s suggestions, and just to add another option we could talk 
of “consumers” and “providers” (of I2NSF services)

Be goode,

On 30 Jun 2016, at 06:17 , John Strassner 
mailto:straz...@gmail.com>> wrote:

Hi Linda,

As I said, all of the examples are not really **clients**, but **servers** (I 
view the admin as having a "server" role, since the admin is using at least one 
application to configure or monitor functionality).

I'm not sure if this is a "better" name, but I am a distributed systems person, 
and to me, "client" implies "client-server" computing. I see no reason to 
restrict (or imply a restriction of) I2NSF to this model of computing.

I personally prefer "peer". An even more neutral term would be "requestor" (vs 
"provider").

best regards,
John

On Sun, Jun 26, 2016 at 6:28 AM, Linda Dunbar 
mailto:linda.dun...@huawei.com>> wrote:
John,

The draft-ietf-i2nsf-framework has those examples of I2NSF clients:

•An overlay network Mgr (e.g. Video Conference Network Mgr) who needs 
to dynamically inform the underlay network to allow, rate limiting or deny 
flows (some of which are encrypted) based on specific fields in the packets for 
a certain time span.

•Enterprise Administrators and management system need to request 
provider network to enforce some rules to their specific flows.

•A IoT management system sending requests to underlay network to block 
flows that match their specific conditions.

Simply put, “I2NSF client” can be users (administrators), different domain 
manager, orchestration system, or others,  who need to specify their desired 
flow policies.

Is there a better name?


Linda

From: John Strassner [mailto:straz...@gmail.com]
Sent: Saturday, June 25, 2016 9:02 PM
To: Linda Dunbar; John Strassner
Cc: I2NSF@ietf.org
Subject: Re: [I2nsf] Should we call "South Bound Interface" for the interface 
between "controller <-> NSF", and "North Bound Interface" for the interface 
between "Client <-> controller"?

Hi Linda,


During the I2NSF early stage (before the WG was created), "capability 
interface" was used to represent the interface between controller <-> NSF, and 
"service interface" was used to represent the interface between the Client <-> 
controller.


The term "capability interface" doesn't bother me. However, I don't think that 
we are using it to its full potential - see below.

The term "client interface" does bother me, because
1) to me, it implies a client-server architecture (or a 3-tier architecture 
on a stretch), and I don't understand why we should be limited to that
2) what is the client? To me, a client is a host. Aren't we talking about 
the application here? The examples in your figure are arguably SERVERS,
not CLIENTS. :-)

Warning, this is probably just me, but...

...I do NOT like "layers", because abstractions should work for everything, not 
just sometimes. Look at our "layers" - we repeatedly violate the true notion of 
a layer (e.g., MPLS). Look at all of the "inter-layer" compatibility problems 
we've had over the years. Why do we need to use layers in I2NSF? I would 
strongly argue to use "interface"; if that is not acceptable, then choose a 
different term (e.g., planes) that does not have the traditional limitations of 
layers.


The I2NSF Terminology Draft has defined the "Capability Layer" (independent of 
which interface to the controller) for exposing the capability of a domain 
(over Client Facing   Interface), or for exposing the capability of a NSF (over 
the NSF Facing Interface).

By this definition, ECA Policy’s "Event" capability can be discovered 
independently from the "Condition" capability, or "Action" capability.


Sorry, I disagree.

Events, conditions, and actions are NOT capabilities. Capabilities are defined 
in the Capabilities Draft as:

Capabilities are functions that NSFs can perform. This interface
is used to advertise, select, and activate capabilities of selected
NSFs in a vendor-independent manner.

Put another way, Capabilities are used to define functions that MAY be used. 
There is no guarantee that they will be actually used. Furthermore, Events, 
Conditions, and Actions are used to construct an ECA policy rule. Events, 
Conditions, and Actions are types of Boolean statements (at least in ECA rules) 
and have nothing to do with Capabilities.

While you MAY be able to relate a rule to Capabilities, they are two completely 
separate things.

Therefore, continue using the  “Capability Interface” can cause more confusion 
in the future as its sound is too close to the “Capability layer”.


Agree. So let's get rid of Capability **layer**. It isn't a layer, because...

...wait for it...

...Capabilities could be used to describe NSF functions as well as Controller 
functions. Thus, there is no "layer" in the classical definition of the term 
"layer".


Therefore, we are asking people to state which of  the fol

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

[Natale, Bob]

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, "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>>
抄送: "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)
抄送: 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” bet

Re: [I2nsf] Starting to think about an agenda for I2NSF in Berlin

[John Strassner]

I will try and help Jianjie update the UAGP draft.
Diego, I'm happy to help with your attestation draft if you need it.

best regards,
John

On Thu, Jun 23, 2016 at 1:33 PM, Diego R. Lopez <
diego.r.lo...@telefonica.com> wrote:

> Hi,
>
> Though I have not been able to update the attestation draft (and the
> framework one in accordance) I am reasonably sure I will be able to do so
> before the cut-off date, so I’d ask for 5-10 minutes to talk about these
> updates, under requirements and protocols,.
>
> Be goode,
>
> On 20 Jun 2016, at 19:00 , Adrian Farrel  wrote:
>
> Hi working group,
>
> Linda and I have been thinking about the agenda for Berlin. We think that
> we
> should continue to focus on our charter and deliverables doing what is
> necessary
> to advance our milestones. Broadly we could split our 2 hours as:
>
> 30 minutes status of WG and progress of WG documents
> 30 minutes requirements for and selection of protocols (and security
> considerations)
> 30 minutes information model discussion
> 30 minutes other drafts and discussions
>
> We'd like to hear your proposals for things that need to be discussed in
> these
> categories so that we can start to put a detailed agenda together.
>
> Thanks,
> Adrian and Linda
>
>
>
> ___
> I2nsf mailing list
> I2nsf@ietf.org
> https://www.ietf.org/mailman/listinfo/i2nsf
>
>
> --
> "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
>
>


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

Re: [I2nsf] I2NSF Terminology draft : Is it better to have two distinct terminologies to differentiate the “Client to controller” from the “Client to NSFs”?

[John Strassner]

I personally think that it is better to not use the term "client", since it
is describing two different interactions. I find that confusing, and I am
still bothered by the implication that this is a client-server (or even an
n-tier) architecture. I would like the freedom to build a distributed
implementation without those constraints.

best regards,
John

On Sat, Jun 18, 2016 at 2:08 PM, Linda Dunbar 
wrote:

> Dear authors of the I2NSF terminology draft:
>
>
>
> I2NSF framework has two different types of clients:
>
> 1.  One type of client sending inquiry/request for Flow Security
> Policy to a controller (who controls a network). For example: an overlay
> network controller sending inquiry/request for Flow Security Policy to an
> underlay network controller.
>
> 2.  Another type of client is the controller sending Flow Security
> Policy to individual NSFs.
>
>
>
> Simply put, the client described in 1) is making request to the (I2NSF)
> Controller (i.e. the controller’s North Bound Interface); and the “client”
> described in 2) is making request to the NSFs ( i.e. the controller’s South
> Bound Interface).
>
>
>
> It seems to me that the “I2NSF Client” described in the current I2NSF
> Terminology draft is performing the “controller” function, and the “I2NSF
> Agent” is residing in the NSF for receiving the flow security policies from
> the “Controller”.
>
>
>
>
>
> Is it better to have two distinct terminologies to differentiate the
> “Client to controller” from the “Client to NSFs”?
>
>
>
> Any suggestions?
>
>
>
> Linda
>
>
>



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

Re: [I2nsf] Should we call "South Bound Interface" for the interface between "controller <-> NSF", and "North Bound Interface" for the interface between "Client <-> controller"?

[John Strassner]

Hi,

I think it is better to have crisp and clear terminology, and make the
changes now, rather than wait and end up with ambiguous or confusing
documents.

While your clarifications are helpful, I don't think that they address my
concerns, and they definitely don't address Diego's concerns (which I
wholeheartedly agree with). Furthermore, I don't see what absolute
coordinates (north vs. south) really buys you. What if you have stacked
controllers (e.g., a controller that is managing multiple controllers)?
Finally, what if you don't have a controller, but some other entity?

best regards,
John

On Sun, Jun 26, 2016 at 3:41 AM, Loa Andersson  wrote:

> Folks,
>
> I think this comment would have been fine, and I guess I supported it if
> it would have been here two years ago. As it is now I think there are to
> much water under the bridges, and actually to many documents involved.
> We have a common usage of "North Bound" or "Northbound" and South Bound"
> or Southbound". The pain in changing is much greater than the gain.
>
> However, I would support adding text to the terminology section like
> this:
>
> North Bound Interface - the interface between the client and the
> controller
>
> South Bound Interface - the interface between the controller and the NSF
>
> /Loa
>
> On 2016-06-26 04:02, John Strassner wrote:
>
>> Hi Linda,
>>
>> During the I2NSF early stage (before the WG was created), "capability
>> interface" was used to represent the interface between controller <->
>> NSF, and "service interface" was used to represent the interface between
>> the Client <-> controller. 
>>
>> 
>> The term "capability interface" doesn't bother me. However, I don't
>> think that we are using it to its full potential - see below.
>>
>> The term "client interface" does bother me, because
>> 1) to me, it implies a client-server architecture (or a 3-tier
>> architecture on a stretch), and I don't understand why we should be
>> limited to that
>> 2) what is the client? To me, a client is a host. Aren't we talking
>> about the application here? The examples in your figure are arguably
>> SERVERS,
>> not CLIENTS. :-)
>> >
>> As many people use the terminologies loosely, the "Capability Interface"
>> being interchangeably used with "Capability Layer", and "Service
>> Interface" being interchangeably used with "Service Layer". 
>>
>> 
>> Warning, this is probably just me, but...
>>
>> ...I do NOT like "layers", because abstractions should work for
>> everything, not just sometimes. Look at our "layers" - we repeatedly
>> violate the true notion of a layer (e.g., MPLS). Look at all of the
>> "inter-layer" compatibility problems we've had over the years. Why do we
>> need to use layers in I2NSF? I would strongly argue to use "interface";
>> if that is not acceptable, then choose a different term (e.g., planes)
>> that does not have the traditional limitations of layers.
>> 
>>
>> The I2NSF Terminology Draft has defined the "Capability Layer"
>> (independent of which interface to the controller) for exposing the
>> capability of a domain (over Client Facing   Interface), or for exposing
>> the capability of a NSF (over the NSF Facing Interface). 
>>
>> By this definition, ECA Policy’s "Event" capability can be discovered
>> independently from the "Condition" capability, or "Action" capability.
>>
>> 
>> Sorry, I disagree.
>>
>> Events, conditions, and actions are NOT capabilities. Capabilities are
>> defined in the Capabilities Draft as:
>>
>> Capabilities are functions that NSFs can perform. This interface
>> is used to advertise, select, and activate capabilities of selected
>> NSFs in a vendor-independent manner.
>>
>> Put another way, Capabilities are used to define functions that MAY be
>> used. There is no guarantee that they will be actually used.
>> Furthermore, Events, Conditions, and Actions are used to construct an
>> ECA policy rule. Events, Conditions, and Actions are types of Boolean
>> statements (at least in ECA rules) and have nothing to do with
>> Capabilities.
>>
>> While you MAY be able to relate a rule to Capabilities, they are two
>> completely separate things.
>> 
>>
>> Therefore, continue using the  “Capability Interface” can cause more
>> confusion in the future as its sound is too close to the “Capability
>> layer”.
>>
>>
>> 
>> Agree. So let's get rid of Capability **layer**. It isn't a layer,
>> because...
>>
>>
>> ...wait for it...
>>
>>
>> ...Capabilities could be used to describe NSF functions as well as
>> Controller functions. Thus, there is no "layer" in the classical
>> definition of the term "layer".
>> 
>>
>> __ __
>>
>> Therefore, we are asking people to state which of  the following options
>> should be used:
>>
>> __ __
>>
>> __1.  __Use “Client Facing Interface” for "Client <-> controller";
>> and “NSF Facing Interface” for "controller <-> NSF", 
>>
>> __2.  __Use “Controller North Bound Interface” for "Client 

Re: [I2nsf] what is the "client" to I2NSF controller? (was RE: Should we call "South Bound Interface" for the interface between "controller <-> NSF", and "North Bound Interface" for the interface betw

[John Strassner]

Hi Linda,

As I said, all of the examples are not really **clients**, but **servers**
(I view the admin as having a "server" role, since the admin is using at
least one application to configure or monitor functionality).

I'm not sure if this is a "better" name, but I am a distributed systems
person, and to me, "client" implies "client-server" computing. I see no
reason to restrict (or imply a restriction of) I2NSF to this model of
computing.

I personally prefer "peer". An even more neutral term would be "requestor"
(vs "provider").

best regards,
John

On Sun, Jun 26, 2016 at 6:28 AM, Linda Dunbar 
wrote:

> John,
>
>
>
> The draft-ietf-i2nsf-framework has those examples of I2NSF clients:
>
> ·An overlay network Mgr (e.g. Video Conference Network Mgr) who
> needs to dynamically inform the underlay network to allow, rate limiting or
> deny flows (some of which are encrypted) based on specific fields in the
> packets for a certain time span.
>
> ·Enterprise Administrators and management system need to request
> provider network to enforce some rules to their specific flows.
>
> ·A IoT management system sending requests to underlay network to
> block flows that match their specific conditions.
>
>
>
> Simply put, “I2NSF client” can be users (administrators), different domain
> manager, orchestration system, or others,  who need to specify their
> desired flow policies.
>
>
>
> Is there a better name?
>
>
>
>
>
> Linda
>
>
>
> *From:* John Strassner [mailto:straz...@gmail.com]
> *Sent:* Saturday, June 25, 2016 9:02 PM
> *To:* Linda Dunbar; John Strassner
> *Cc:* I2NSF@ietf.org
> *Subject:* Re: [I2nsf] Should we call "South Bound Interface" for the
> interface between "controller <-> NSF", and "North Bound Interface" for the
> interface between "Client <-> controller"?
>
>
>
> Hi Linda,
>
>
>
> During the I2NSF early stage (before the WG was created), "capability
> interface" was used to represent the interface between controller <-> NSF,
> and "service interface" was used to represent the interface between the
> Client <-> controller.
>
> 
> The term "capability interface" doesn't bother me. However, I don't think
> that we are using it to its full potential - see below.
>
> The term "client interface" does bother me, because
> 1) to me, it implies a client-server architecture (or a 3-tier
> architecture on a stretch), and I don't understand why we should be limited
> to that
> 2) what is the client? To me, a client is a host. Aren't we talking
> about the application here? The examples in your figure are arguably
> SERVERS,
> not CLIENTS. :-)
> 
> As many people use the terminologies loosely, the "Capability Interface"
> being interchangeably used with "Capability Layer", and "Service Interface"
> being interchangeably used with "Service Layer".
>
> 
> Warning, this is probably just me, but...
>
> ...I do NOT like "layers", because abstractions should work for
> everything, not just sometimes. Look at our "layers" - we repeatedly
> violate the true notion of a layer (e.g., MPLS). Look at all of the
> "inter-layer" compatibility problems we've had over the years. Why do we
> need to use layers in I2NSF? I would strongly argue to use "interface"; if
> that is not acceptable, then choose a different term (e.g., planes) that
> does not have the traditional limitations of layers.
> 
>
> The I2NSF Terminology Draft has defined the "Capability Layer"
> (independent of which interface to the controller) for exposing the
> capability of a domain (over Client Facing   Interface), or for exposing
> the capability of a NSF (over the NSF Facing Interface).
>
> By this definition, ECA Policy’s "Event" capability can be discovered
> independently from the "Condition" capability, or "Action" capability.
>
> 
> Sorry, I disagree.
>
> Events, conditions, and actions are NOT capabilities. Capabilities are
> defined in the Capabilities Draft as:
>
> Capabilities are functions that NSFs can perform. This interface
> is used to advertise, select, and activate capabilities of selected
> NSFs in a vendor-independent manner.
>
> Put another way, Capabilities are used to define functions that MAY be
> used. There is no guarantee that they will be actually used. Furthermore,
> Events, Conditions, and Actions are used to construct an ECA policy rule.
> Events, Conditions, and Actions are types of Boolean statements (at least
> in ECA rules) and have nothing to do with Capabilities.
>
> While you MAY be able to relate a rule to Capabilities, they are two
> completely separate things.
> 
>
> Therefore, continue using the  “Capability Interface” can cause more
> confusion in the future as its sound is too close to the “Capability
> layer”.
>
>
> 
> Agree. So let's get rid of Capability **layer**. It isn't a layer,
> because...
>
>
>
> ...wait for it...
>
>
>
> ...Capabilities could be used to describe NSF functions as well as
> Controller functions. Thus, there is no "layer" in the clas

[I2nsf] I-D Action: draft-ietf-i2nsf-framework-01.txt

[internet-drafts]

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   : Framework for Interface to Network Security Functions
Authors : Edward Lopez
  Diego Lopez
  Linda Dunbar
  John Strassner
  XiaoJun Zhuang
  Joe Parrott
  Ramki Krishnan
  Seetharama Rao Durbha
Filename: draft-ietf-i2nsf-framework-01.txt
Pages   : 23
Date: 2016-06-29

Abstract:
   This document describes the framework for the Interface to Network
   Security Functions (I2NSF), and defines a reference model (including
   major functional components) for I2NSF. Network security functions
   (NSFs) are packet-processing engines that inspect and optionally
   modify packets traversing networks, either directly or in the
   context of sessions in which the packet is associated.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-i2nsf-framework/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-i2nsf-framework-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-i2nsf-framework-01


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

Re: [I2nsf] New Version Notification for draft-mglt-i2nsf-ssf-collaboration-00.txt

[mohamed.boucadair]

Hi Daniel, all,

Thank you for sharing this draft.

I have some high-level questions about this proposal: 
* In which deployment case you think that a service function will take the 
responsibility to contact another service function located in another domain to 
ask for collaboration? Wouldn't that be the responsibility of the respective 
administrative entities managing those domains?
* Based on which criteria an SSF may decide that it needs collaboration with 
another SSF? Wouldn't that be driven by service requirements and objectives 
(that are not visible to a monolithic SSF)?
* Given that service functions deployed in a given domain are unlikely to be 
disclosed outside that domain, how SSF discovery is achieved? 
* Would collaboration be tied to the 'initiator' and 'provider' instances which 
are involved in a CA? Is that optimal given that multiple instances of the same 
SSF may be deployed in a given domain for various reasons (load-balancing, 
resiliency, etc.)? 

Thank you.

Cheers,
Med

> -Message d'origine-
> De : Dots [mailto:dots-boun...@ietf.org] De la part de Daniel Migault
> Envoyé : mardi 28 juin 2016 17:43
> À : i2nsf@ietf.org; d...@ietf.org
> Cc : Alireza Ranjbar; mglt.i...@gmail.com
> Objet : Re: [Dots] New Version Notification for draft-mglt-i2nsf-ssf-
> collaboration-00.txt
> 
> Hi,
> 
> Please find our draft for elaborating a collaboration between security
> services locate in different administrative domains.
> 
> Feed backs /Comments are welcome!
> BR,
> Daniel
> 
> -Original Message-
> From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
> Sent: Tuesday, June 28, 2016 6:40 PM
> To: Daniel Migault; Alireza Ranjbar
> Subject: New Version Notification for draft-mglt-i2nsf-ssf-collaboration-
> 00.txt
> 
> 
> A new version of I-D, draft-mglt-i2nsf-ssf-collaboration-00.txt
> has been successfully submitted by Daniel Migault and posted to the IETF
> repository.
> 
> Name: draft-mglt-i2nsf-ssf-collaboration
> Revision: 00
> Title:Collaboration Agreement for Security Service Function
> Document date:2016-06-28
> Group:Individual Submission
> Pages:13
> URL:https://www.ietf.org/internet-drafts/draft-mglt-i2nsf-ssf-
> collaboration-00.txt
> Status: https://datatracker.ietf.org/doc/draft-mglt-i2nsf-ssf-
> collaboration/
> Htmlized:   https://tools.ietf.org/html/draft-mglt-i2nsf-ssf-
> collaboration-00
> 
> 
> Abstract:
>This document specifies a collaboration agreement protocol.  The
>collaboration agreement makes possible individual security services
>functions (SSF) to collaborate with each other.  The collaboration is
>mostly intended for SSF located in different administrative domains,
>in which case the collaboration cannot be performed by a shared
>orchestrator.
> 
>The collaboration between SSF in different domains assumes the
>traffic is steered through the two domains.
> 
> 
> 
> 
> 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
> 
> ___
> Dots mailing list
> d...@ietf.org
> https://www.ietf.org/mailman/listinfo/dots

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