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

From: Linda Dunbar <[email-masked]>
Date: Thu, 23 Jun 2016 22:31:34 +0000

I2NSF WG:

Need your opinion for a good name to represent "Client Facing Interface" and "NSF Facing Interface" of the I2NSF reference model:
              +-----------------------------------------------------+
              |      I2NSF Client                                   |
              | E.g. Overlay Network Mgnt, Enterprise network Mgnt  |
              |  another network domain's mgnt, etc.                |
              +----------+------------------------------------------+
                         |
                         |  Client Facing Interface
                         |
                   +-----+---------------+
                   |Network Operator mgmt|               +-------------+
                   | Security Controller | < --------- > | Developer's |
                   +----------+----------+  Registration | Mgnt System |
                              |              Interface   +-------------+
                              |
                              | NSF Facing Interface
                              |
       +----------------------+----------------------------+
       |                                                   |
       |                                                   |
   +---+--+         +------+             +------+       +--+---+
   + NSF-1+ ------- + NSF-n+             +NSF-1 + ----- +NSF-m +  . . .
   +------+         +------+             +------+       +------+

   Vendor A                                       Vendor B

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.

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".

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.

Therefore, continue using the  "Capability Interface" can cause more confusion in the future as its sound is too close to the "Capability 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 <-> controller"; and "Controller South Bound Interface" for "controller <-> NSF", or

Or you can provide a better option.

Thanks, Linda

---

From: "Diego R. Lopez" <[email-masked]>
Date: Fri, 24 Jun 2016 05:40:27 +0000

Hi Linda,

I have always found profoundly wrong the northbound and southbound terms, as they imply an absolute reference system that becomes challenged very soon, and then you have to start qualifying where are you talking north- or southbound. As an example, think on the current drafts dealing with SDN controllers at the “I2NSF southbound” interface, using it as a “SDN northbound”. I find this entirely confusing. So please let’s confine the North-South coordinates to the places where we can not get rid of them just for historical reasons.

I’d like to maintain the "service" and “capability” terms, and I do not understand:

* Why you say that capabilities of NSFs can be exposed through the service interface. Even if that was the case, the security controller should not expose them as “NSF capabilities” but as “security controller services", as the controller must abstract the underlying NSFs

* What you refer with “Event capability”, “Condition capability” and “Action capability”. NSF capabilities should be announced through the registration interface and managed through the capability interface (what you call southbound in your messages) according to the policies expressed in terms of ECA rules, but these rules (or their components) are not part of the capabilities whatsoever…

Be goode,

On 24 Jun 2016, at 24:31 , Linda Dunbar <[email-masked]<mailto:[email-masked]>> wrote:

I2NSF WG:

Need your opinion for a good name to represent “Client Facing Interface” and “NSF Facing Interface” of the I2NSF reference model:
              +-----------------------------------------------------+
              |      I2NSF Client                                   |
              | E.g. Overlay Network Mgnt, Enterprise network Mgnt  |
              |  another network domain’s mgnt, etc.                |
              +----------+------------------------------------------+
                         |
                         |  Client Facing Interface
                         |
                   +-----+---------------+
                   |Network Operator mgmt|               +-------------+
                   | Security Controller | < --------- > | Developer’s |
                   +----------+----------+  Registration | Mgnt System |
                              |              Interface   +-------------+
                              |
                              | NSF Facing Interface
                              |
       +----------------------+----------------------------+
       |                                                   |
       |                                                   |
   +---+--+         +------+             +------+       +--+---+
   + NSF-1+ ------- + NSF-n+             +NSF-1 + ----- +NSF-m +  . . .
   +------+         +------+             +------+       +------+

   Vendor A                                       Vendor B

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.

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

1.      Use “Client Facing Interface” for "Client <-> controller"; and “NSF Facing Interface” for "controller <-> NSF",
2.      Use “Controller North Bound Interface” for "Client <-> controller"; and “Controller South Bound Interface” for “controller <-> NSF", or

Thanks, Linda

_______________________________________________
I2nsf mailing list
[email-masked]<mailto:[email-masked]>
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: [email-masked]
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

---

From: <[email-masked]>
Date: Fri, 24 Jun 2016 07:58:25 +0000

Hi Linda, all,

I fully agree with Diego about the North-South coordinates thing.

Client-facing interface and NSF-facing interface terms are just fine to refer to these interfaces.

Cheers,
Med

De : I2nsf [mailto:[email-masked]] De la part de Diego R. Lopez
Envoyé : vendredi 24 juin 2016 07:40
À : Linda Dunbar
Cc : [email-masked]
Objet : 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,

Be goode,

I2NSF WG:

   Vendor A                                       Vendor B

Thanks, Linda

Dr Diego R. Lopez
Telefonica I+D

e-mail: [email-masked]<mailto:[email-masked]>
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------

---

From: John Strassner <[email-masked]>
Date: Sat, 25 Jun 2016 19:02:25 -0700

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.

<jcs>
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. :-)
</jcs

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".

<jcs>
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.
</jcs>

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.

<jcs>
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.
</jcs>

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

<jcs>
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".
</jcs>

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 <-> controller";
and “Controller South Bound Interface” for “controller <-> NSF", or

<jcs>

I choose option 3. :-)

The problem with "Client-Facing Interface" is that I'm not sure what a
"Client" is in NSF.

NSF-Facing Interface is OK; my problem is, why are we introducing Yet
Another Term?

The problem with Northbound and Southbound is that there is no clear
"north" and "south" here. Look at all of the projects that propose various
data models at both the device interface level AND the network management
application layer. So tell me, which is "south" here? :-)

Now, as for option 3, I'm thinking about it. However, I do think that you
have spotted an important inconsistency, so let's take time to fix it and
not rush into rash decisions.
</jcs>

best regards,

John

On Thu, Jun 23, 2016 at 3:31 PM, Linda Dunbar <[email-masked]>
wrote:

> I2NSF WG:
>
>
>
> Need your opinion for a good name to represent “Client Facing Interface”
> and “NSF Facing Interface” of the I2NSF reference model:
>
> 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.
>
>
>
> 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".
>
>
>
> 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.
>
>
>
> Therefore, continue using the  “Capability Interface” can cause more
> confusion in the future as its sound is too close to the “Capability
> layer”.
>
>
>
> 1.      Use “Client Facing Interface” for "Client <-> controller"; and
> “NSF Facing Interface” for "controller <-> NSF",
>
> 2.      Use “Controller North Bound Interface” for "Client <->
> controller"; and “Controller South Bound Interface” for “controller <->
> NSF", or
>
>
>
> [email-masked]

-- 
regards,
John

---

From: Loa Andersson <[email-masked]>
Date: Sun, 26 Jun 2016 12:41:27 +0200

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:
> interface" was used to represent the interface between controller <->
> NSF, and "service interface" was used to represent the interface between
> the Client <-> controller. ____
>
> <jcs>
> The term "capability interface" doesn't bother me. However, I don't
> think that we are using it to its full potential - see below.
>
> architecture on a stretch), and I don't understand why we should be
> limited to that
> being interchangeably used with "Capability Layer", and "Service
> Interface" being interchangeably used with "Service Layer". ____
>
> <jcs>
> ...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.
> </jcs>
>
> the capability of a NSF (over the NSF Facing Interface). ____
>
> 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.
>
> Controller functions. Thus, there is no "layer" in the classical
> definition of the term "layer".
> </jcs>
>
> __ __
>
> 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 <->
> NSF", or ____
> __ __
> "north" and "south" here. Look at all of the projects that propose
> various data models at both the device interface level AND the network
> management application layer. So tell me, which is "south" here? :-)
>
>
> Now, as for option 3, I'm thinking about it. However, I do think that
> you have spotted an important inconsistency, so let's take time to fix
> it and not rush into rash decisions.
> </jcs>
>
>
> best regards,
>
> John
>
>
>
>
> On Thu, Jun 23, 2016 at 3:31 PM, Linda Dunbar <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     I2NSF WG:____
>
>     __ __
>
>     Need your opinion for a good name to represent “Client Facing
>     Interface” and “NSF Facing Interface” of the I2NSF reference model: ____
>
>                   +-----------------------------------------------------+____
>
>                   |      I2NSF Client
>     |____
>
>                   | E.g. Overlay Network Mgnt, Enterprise network Mgnt
>     |____
>
>                   |  another network domain’s mgnt, etc.
>     |____
>
>
>     +----------+------------------------------------------+____
>
>                              |____
>
>                              |  Client Facing Interface ____
>
>                              |____
>
>                        +-----+---------------+        ____
>
>                        |Network Operator mgmt|
>     +-------------+____
>
>                        | Security Controller | < --------- > |
>     Developer’s |____
>
>                        +----------+----------+  Registration | Mgnt
>     System |____
>
>                                   |              Interface
>     +-------------+____
>
>                                   |           ____
>
>                                   | NSF Facing Interface____
>
>                                   |____
>
>            +----------------------+----------------------------+____
>
>            |                                                   |____
>
>            |                                                   |____
>
>        +---+--+         +------+             +------+       +--+---+____
>
>        + NSF-1+ ------- + NSF-n+             +NSF-1 + ----- +NSF-m +  .
>     . . ____
>
>        +------+         +------+             +------+       +------+____
>
>     __ __
>
>        Vendor A                                       Vendor B____
>
>     __ __
>
>     __ __
>
>     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. ____
>
>     __ __
>
>     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".
>     ____
>
>     __ __
>
>     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. ____
>
>     __ __
>
>     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 <->
>     controller"; and “Controller South Bound Interface” for “controller
>     <-> NSF", or ____
>
>     __ __
>
>     Or you can provide a better option. ____
>
>     __ __
>
>     Thanks, Linda ____
>
>     __ __
>
>     __ __
>
>
>     [email-masked] <mailto:[email-masked]>

---

From: Linda Dunbar <[email-masked]>
Date: Sun, 26 Jun 2016 13:28:33 +0000

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:[email-masked]]
Sent: Saturday, June 25, 2016 9:02 PM
To: Linda Dunbar; John Strassner
Cc: [email-masked]
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,

<jcs>
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. :-)
</jcs

<jcs>

...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.
</jcs>

<jcs>
Sorry, I disagree.

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

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.
</jcs>
Therefore, continue using the  “Capability Interface” can cause more confusion in the future as its sound is too close to the “Capability layer”.

<jcs>
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".
</jcs>

<jcs>
I choose option 3. :-)

The problem with "Client-Facing Interface" is that I'm not sure what a "Client" is in NSF.
NSF-Facing Interface is OK; my problem is, why are we introducing Yet Another Term?

The problem with Northbound and Southbound is that there is no clear "north" and "south" here. Look at all of the projects that propose various data models at both the device interface level AND the network management application layer. So tell me, which is "south" here? :-)

Now, as for option 3, I'm thinking about it. However, I do think that you have spotted an important inconsistency, so let's take time to fix it and not rush into rash decisions.
</jcs>

best regards,
John

On Thu, Jun 23, 2016 at 3:31 PM, Linda Dunbar <[email-masked]<mailto:[email-masked]>> wrote:

I2NSF WG:

   Vendor A                                       Vendor B

Thanks, Linda

--
regards,
John

---

From: John Strassner <[email-masked]>
Date: Wed, 29 Jun 2016 20:17:32 -0700

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 <[email-masked]>
wrote:

> ·        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:[email-masked]]
> *Sent:* Saturday, June 25, 2016 9:02 PM
> *To:* Linda Dunbar; John Strassner
> *Cc:* [email-masked]
> *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,
>
>
>
> 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.
> </jcs>
>

-- 
regards,
John

---

From: John Strassner <[email-masked]>
Date: Wed, 29 Jun 2016 20:22:53 -0700

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

-- 
regards,
John

---

From: "Diego R. Lopez" <[email-masked]>
Date: Thu, 30 Jun 2016 06:26:16 +0000

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 <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>> wrote:
John,

•        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.

Is there a better name?

Linda

From: John Strassner [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Saturday, June 25, 2016 9:02 PM
To: Linda Dunbar; John Strassner
Cc: [email-masked]<mailto:[email-masked]>
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,

<jcs>

<jcs>

<jcs>
Sorry, I disagree.

<jcs>

...wait for it...

<jcs>
I choose option 3. :-)

best regards,
John

I2NSF WG:

   Vendor A                                       Vendor B

Thanks, Linda

--
regards,
John

Dr Diego R. Lopez
Telefonica I+D

---

From: Linda Dunbar <[email-masked]>
Date: Thu, 30 Jun 2016 12:54:30 +0000

John and Diego,

Thank you very much for the explanation.

We probably need to further differentiate the following two requesters because one is Flow Security Policy over a domain and the other is a Flow Security Policy in an individual NSF.

-        “Requester for Flow Security Policies from a Controller” which can have higher level condition matching, such as Tenant/customer ID, or higher level event such as if the Tenant is AAA certified.

-        “Requester for Flow Security Policies from an individual NSF” which matches on concrete fields of packets or state of the flows.

Thanks, Linda

From: Diego R. Lopez [mailto:[email-masked]]
Sent: Thursday, June 30, 2016 1:26 AM
To: John Strassner
Cc: Linda Dunbar; [email-masked]
Subject: 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 between "Client <-> controller"?

Be goode,

Hi Linda,

best regards,
John

Is there a better name?

Linda

Hi Linda,

<jcs>

...wait for it...

<jcs>
I choose option 3. :-)

best regards,
John

   Vendor A                                       Vendor B

Thanks, Linda

--
regards,
John

Dr Diego R. Lopez
Telefonica I+D

---

From: "Diego R. Lopez" <[email-masked]>
Date: Thu, 30 Jun 2016 13:00:06 +0000

Hi Linda,

I’d say the former you name is what I’d call the “consumer” or “requester”. And that the second is the controller. Or am I missing something?

Be goode,

On 30 Jun 2016, at 15:54 , Linda Dunbar <[email-masked]<mailto:[email-masked]>> wrote:

John and Diego,

Thanks, Linda

From: Diego R. Lopez [mailto:[email-masked]]
Sent: Thursday, June 30, 2016 1:26 AM
To: John Strassner
Cc: Linda Dunbar; [email-masked]<mailto:[email-masked]>
Subject: 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 between "Client <-> controller"?

Be goode,

Hi Linda,

best regards,
John

Is there a better name?

Linda

Hi Linda,

<jcs>

...wait for it...

<jcs>
I choose option 3. :-)

best regards,
John

   Vendor A                                       Vendor B

Thanks, Linda

--
regards,
John

Dr Diego R. Lopez
Telefonica I+D

Dr Diego R. Lopez
Telefonica I+D

---

From: Linda Dunbar <[email-masked]>
Date: Thu, 30 Jun 2016 13:06:44 +0000

Diego,

Got it. Can the I2NSF Terminology authors update the draft to reflect it?

Thanks, Linda

From: Diego R. Lopez [mailto:[email-masked]]
Sent: Thursday, June 30, 2016 8:00 AM
To: Linda Dunbar
Cc: John Strassner; [email-masked]
Subject: Re: Is "Requester " a better name? (was RE: [I2nsf] what is the "client" to I2NSF controller?

Hi Linda,

Be goode,

John and Diego,

Thanks, Linda

Be goode,

Hi Linda,

best regards,
John

Is there a better name?

Linda

Hi Linda,

<jcs>

...wait for it...

<jcs>
I choose option 3. :-)

best regards,
John

   Vendor A                                       Vendor B

Thanks, Linda

--
regards,
John

Dr Diego R. Lopez
Telefonica I+D

Dr Diego R. Lopez
Telefonica I+D

---

From: John Strassner <[email-masked]>
Date: Thu, 30 Jun 2016 08:04:30 -0700

I am starting to update the terminology draft, and will send to my
co-authors first and then to the list.

best regards,
John

On Thu, Jun 30, 2016 at 6:06 AM, Linda Dunbar <[email-masked]>
wrote:

> *From:* Diego R. Lopez [mailto:[email-masked]]
> *Sent:* Thursday, June 30, 2016 8:00 AM
> *To:* Linda Dunbar
> *Cc:* John Strassner; [email-masked]
> *Subject:* Re: Is "Requester " a better name? (was RE: [I2nsf] what is
> the "client" to I2NSF controller?
>
>
>
> Hi Linda,
>
>
>
> I’d say the former you name is what I’d call the “consumer” or
> “requester”. And that the second is the controller. Or am I missing
> something?
>
>
>
> Be goode,
>
>
>
> On 30 Jun 2016, at 15:54 , Linda Dunbar <[email-masked]> wrote:
>
>
>
> John and Diego,
>
>
>
> We probably need to further differentiate the following two requesters
> because one is Flow Security Policy over a domain and the other is a Flow
> Security Policy in an individual NSF.
>
> -        “Requester for Flow Security Policies from a Controller” which
> can have higher level condition matching, such as Tenant/customer ID, or
> higher level event such as if the Tenant is AAA certified.
>
> -        “Requester for Flow Security Policies from an individual NSF”
> which matches on concrete fields of packets or state of the flows.
>
>
>
> Thanks, Linda
>
>
>
> *From:* Diego R. Lopez [mailto:[email-masked]
> <[email-masked]>]
> *Sent:* Thursday, June 30, 2016 1:26 AM
> *To:* John Strassner
> *Cc:* Linda Dunbar; [email-masked]
> *Subject:* 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 between
> "Client <-> controller"?
>
>
>
> 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 <[email-masked]> wrote:
>
>
>
> Hi Linda,
>
>
>
> ------------------------------
>
>
> 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
>
>
>
> --
> ------------------------------
>
>
> 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
>

-- 
regards,
John

---

From: Rakesh Kumar <[email-masked]>
Date: Thu, 30 Jun 2016 15:49:16 +0000

Hi Linda,

In my humble opinion, any terminology we use, there must be some reference or context since without that it is hard to discern completely based on the term alone.
A controller may provide interfaces to higher entity in the operational stack and at the same time uses interfaces from lower entity in the operational stack. So an entity may act like a client or consumer at the same time but of course with respect to different entities.

I think I2NSF (Security) controller northbound and southbound interfaces sounds reasonable to me and aligns with how other controller publish interfaces.

Thanks & Regards,
Rakesh

From: I2nsf <[email-masked]<mailto:[email-masked]>> on behalf of Linda Dunbar <[email-masked]<mailto:[email-masked]>>
Date: Thursday, June 30, 2016 at 6:06 AM
To: "Diego R. Lopez" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, John Strassner <[email-masked]<mailto:[email-masked]>>
Subject: Re: [I2nsf] Is "Requester " a better name? (was RE: what is the "client" to I2NSF controller?

Diego,

Thanks, Linda

From: Diego R. Lopez [mailto:[email-masked]]
Sent: Thursday, June 30, 2016 8:00 AM
To: Linda Dunbar
Cc: John Strassner; [email-masked]<mailto:[email-masked]>
Subject: Re: Is "Requester " a better name? (was RE: [I2nsf] what is the "client" to I2NSF controller?

Hi Linda,

Be goode,

John and Diego,

Thanks, Linda

Be goode,

Hi Linda,

best regards,
John

Is there a better name?

Linda

Hi Linda,

<jcs>

...wait for it...

<jcs>
I choose option 3. :-)

best regards,
John

   Vendor A                                       Vendor B

Thanks, Linda

--
regards,
John

Dr Diego R. Lopez
Telefonica I+D

Dr Diego R. Lopez
Telefonica I+D