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 4G LTE smartphone
 Original message 
From: DIEGO LOPEZ GARCIA 
>
Date: 6/16/2016 2:07 AM (GMT-05:00)
To: John Strassner >
Cc: I2NSF@ietf.org, "Xialiang (Frank)" 
>, Susan Hares 
>, Dacheng Zhang 
>, Linda Dunbar 
>
Subject: Re: [I2nsf] questions about some terminologies defined by 
draft-ietf-i2nsf-terminology-00

In order to avoid using the defined term (even partially) into the definition 
I’d go for the second one…

Be goode,

On 16 Jun 2016, at 15:05 , John Strassner 
> wrote:

Hi Dacheng,

I agree that "I2NSF system" is not well defined. Your definition is better, but 
it should apply for all NSFs (not 'the NSF'). In addition, the Capability Layer 
is not an abstraction layer, it a simply a collection of abstractions (the 
capabilities). So how about:

Capability Layer:  Defines the set of capabilities available to the 
Controller for the set of NSFs that the Controller manages.

or

Capability Layer:  Defines the set of features available to the Controller 
for the set of NSFs that the Controller manages.


regards,
John

On Wed, Jun 15, 2016 at 8:55 PM, Dacheng Zhang 
> wrote:
I think I agree with Frank. The confusion is caused by the 'I2NSF system’. 
Maybe we should change the definition in the terminology draft to Capability 
Layer: Defines an abstraction layer that exposes a set of capabilities of the 
NSF?

发件人: I2nsf > on behalf of 
"Xialiang (Frank)" >
日期: 2016年6月16日 星期四 上午11:47
至: Linda Dunbar >, John 
Strassner >, Susan Hares 
>, "DIEGO LOPEZ GARCIA 
(diego.r.lo...@telefonica.com)" 
>
抄送: "I2NSF@ietf.org" 
>
主题: [I2nsf] 答复: questions about some terminologies defined by 
draft-ietf-i2nsf-terminology-00

Hi Linda,
Frankly, I don’t see the essential difference for the meaning of terminology 
“capability” between  them.  We just need to make some modification in two 
places to keep consistence.
We can do it during the update of I2NSF terminology draft.

B.R.
Frank

发件人: I2nsf [mailto:i2nsf-boun...@ietf.org] 代表 Linda Dunbar
发送时间: 2016年6月15日 23:40
收件人: John Strassner; Susan Hares; DIEGO LOPEZ GARCIA 
(diego.r.lo...@telefonica.com)
抄送: I2NSF@ietf.org
主题: [I2nsf] questions about some terminologies defined by 
draft-ietf-i2nsf-terminology-00

Dear Authors:

The term “Capability Layer” defined by the “draft-ietf-i2nsf-terminology-00” 
carries different  meaning than the “Capability Layer” used by the I2NSF 
charter.

“draft-ietf-i2nsf-terminology-00”:
Capability: Defines a set of features that are available from a managed entity 
(see also I2NSF Capability).

Capability Layer: Defines an abstraction layer that exposes a set of 
capabilities of the I2NSF system.

I2NSF Charter:
I2NSF will specify interfaces at two functional levels for the control and 
monitoring of network security functions:
The I2NSF Capability Layer specifies how to control and monitor NSFs at a 
functional implementation level. The term "Functional Implementation" is used 
to emphasize that the rules (for control and monitor) of NSFs have to be 
implementable by most NSFs. I2NSF will standardize a set of interfaces by which 
a security controller can invoke, operate, 

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] 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” 

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