Subject: [I2nsf] FW: New Version Notification for draft-kumar-i2nsf-client-facing-interface-req-00.txt

From: Rakesh Kumar <[email-masked]>
Date: Tue, 2 Aug 2016 21:26:47 +0000

As discussed in the Berlin meeting, we have created this new draft with contents from https://tools.ietf.org/html/draft-kumar-i2nsf-controller-northbound-framework-00 and other inputs.

This draft captures the client interface requirements for the I2NSF security controller.

Regards,
Rakesh

On 8/2/16, 12:14 PM, "[email-masked]" <[email-masked]> wrote:

>
>A new version of I-D, draft-kumar-i2nsf-client-facing-interface-req-00.txt
>has been successfully submitted by Rakesh Kumar and posted to the
>IETF repository.
>
>Name:		draft-kumar-i2nsf-client-facing-interface-req
>Revision:	00
>Title:		Client Interface for Security Controller : A Framework for Security Policy Requirements
>Document date:	2016-08-02
>Group:		Individual Submission
>Pages:		17
>URL:            https://www.ietf.org/internet-drafts/draft-kumar-i2nsf-client-facing-interface-req-00.txt
>Status:         https://datatracker.ietf.org/doc/draft-kumar-i2nsf-client-facing-interface-req/
>Htmlized:       https://tools.ietf.org/html/draft-kumar-i2nsf-client-facing-interface-req-00
>
>
>Abstract:
>   This document provides a framework and information model for the
>   definition of northbound interfaces for a security controller.  The
>   interfaces are based on user-intent instead of vendor-specific or
>   device-centric approaches that would require deep knowledge of vendor
>   products and their security features.  The document identifies the
>   common interfaces needed to enforce the user-intent based policies
>   onto network security functions (NSFs) irrespective of how those
>   functions are realized.  The function may be physical or virtual in
>   nature and may be implemented in networking or dedicated appliances.
>
>                                                                                  
>
>
>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
>

---

From: "Diego R. Lopez" <[email-masked]>
Date: Wed, 3 Aug 2016 07:38:51 +0000

Hi Rakesh,

A few comments on the document:

1) I would prefer other terms to refer to the actors described in the introduction (and elsewhere) While the term “vendor” is clear and generally accepted, I’d prefer to use “developer” (as it is done in the framework draft) to incorporate as well NSFs provided by open-source communities and developed in-house, to name a couple of additional sources for them. Going further, the term “end-customer” is completely misleading, as in the networking environment is usually employed to refer to the people or organizations who are using the network services. I’d rather use “network operator”, or “NSF operator”, or even “security manager” if you do not like to use the term “operator”.

2) Regarding the term "user-intent”, and in order to avoid misinterpretations in despite of the clarification statement at the end of the introduction, I wonder whether another term could be used. I’d suggest “policy expressions”…

3) It is not clear to me what section 3.2 has to do with the rest of the document, as it deals with southbound interface deployment. I’d suggest to delete it, as it can be misinterpreted as a deployment recommendation and introduces a new element (the agent) that is not part of the I2NSF framework

4) In section 4 I see a very disparate set of requirements, ranging from identifying some role-based objects for RBAC (in 4.1) to listing potential data sources for telemetry (in 4.7), without a clear identification of what are the specific requirements in the style I have seen in many other IETF requirements documents. I am confident we will make the draft evolve in that direction in successive versions.

Be goode,

On 2 Aug 2016, at 23:26 , Rakesh Kumar <[email-masked]<mailto:[email-masked]>> wrote:

Regards,
Rakesh

On 8/2/16, 12:14 PM, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>> wrote:

Abstract:

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

The IETF Secretariat

_______________________________________________
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: Rakesh Kumar <[email-masked]>
Date: Thu, 4 Aug 2016 04:32:01 +0000

Hi Diego,

Thanks a lot for your  review.  Please see my response with [Rakesh].

Regards,
Rakesh

From: "Diego R. Lopez" <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, August 3, 2016 at 12:38 AM
To: Rakesh Kumar <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Anil Lohiya <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "Long, Xiaobo" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [I2nsf] New Version Notification for draft-kumar-i2nsf-client-facing-interface-req-00.txt

Hi Rakesh,

1) I would prefer other terms to refer to the actors described in the introduction (and elsewhere) While the term “vendor” is clear and generally accepted, I’d prefer to use “developer” (as it is done in the framework draft) to incorporate as well NSFs provided by open-source communities and developed in-house, to name a couple of additional sources for them. Going further, the term “end-customer” is completely misleading, as in the networking environment is usually employed to refer to the people or organizations who are using the network services. I’d rather use “network operator”, or “NSF operator”, or even “security manager” if you do not like to use the term “operator”.
[Rakesh] Sure.  Is there any other better term for “ vendor” (I have not seen developer term being used in the context of vendor)?
Instead of “end-customer”, we can use “Security Admin” .

2) Regarding the term "user-intent”, and in order to avoid misinterpretations in despite of the clarification statement at the end of the introduction, I wonder whether another term could be used. I’d suggest “policy expressions”…
[Rakesh] Let me think about this.

3) It is not clear to me what section 3.2 has to do with the rest of the document, as it deals with southbound interface deployment. I’d suggest to delete it, as it can be misinterpreted as a deployment recommendation and introduces a new element (the agent) that is not part of the I2NSF framework
[Rakesh] The reason we put this, was to articulate that client interface are independent of how a security controller interact with NSF.  Basically client interface remain the same, independent of  deployment model. The I2NSF only deals with client interface (northbound side) and NSF interface (southbound), everything else is implementation dependent and outside the scope of I2NSF.  It is  hard to make this point without any pictorial context since not everyone may be well versed with all the concepts.

4) In section 4 I see a very disparate set of requirements, ranging from identifying some role-based objects for RBAC (in 4.1) to listing potential data sources for telemetry (in 4.7), without a clear identification of what are the specific requirements in the style I have seen in many other IETF requirements documents. I am confident we will make the draft evolve in that direction in successive versions.
[Rakesh] I think we added details in each one but please let us know if you want add some more or put it in different format.

Be goode,

Regards,
Rakesh

Abstract:

The IETF Secretariat

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: "Diego R. Lopez" <[email-masked]>
Date: Tue, 9 Aug 2016 17:36:22 +0000

Hi Rakesh,

A few replies inline below. I’ve trimmed a little bit the text to make the whole message more readable…

On 4 Aug 2016, at 06:32 , Rakesh Kumar <[email-masked]<mailto:[email-masked]>> wrote:

H1) I would prefer other terms to refer to the actors described in the introduction (and elsewhere) While the term “vendor” is clear and generally accepted, I’d prefer to use “developer” (as it is done in the framework draft) to incorporate as well NSFs provided by open-source communities and developed in-house, to name a couple of additional sources for them. Going further, the term “end-customer” is completely misleading, as in the networking environment is usually employed to refer to the people or organizations who are using the network services. I’d rather use “network operator”, or “NSF operator”, or even “security manager” if you do not like to use the term “operator”.
[Rakesh] Sure.  Is there any other better term for “ vendor” (I have not seen developer term being used in the context of vendor)?
Instead of “end-customer”, we can use “Security Admin” .

DRL> I know the traditional name for the provider of hardware and software is “vendor” and it is constantly (and consistently) used elsewhere, but I think it would be interesting to reflect the new trends in the industry, especially when it comes to open source projects and in-house tailored developments, and therefore I’d prefer to start changing the term into the more neutral “developer”, that considers in a better way these other scenarios.

DRL> Regarding the “security admin” term, I am more than happy with it.

DRL> OK. What I’d like to avoid is a clash with the other ongoing activities around other interpretations of the term, and spare all of us the need of providing explanations once and again.

DRL> A possible away would be to clearly state we are talking about exemplary deployments styles, and merge the discussion with other sections, so it becomes clear there are no specific recommendations on particular southbound implementation or deployment patterns.

DRL> The problem I see is that the level of detail and the depth of the requirements are somehow not completely aligned among them and in particular with other IETF requirements documents (as a couple of examples pointing in the direction of my comment, have a look at https://datatracker.ietf.org/doc/draft-mglt-sfc-security-environment-req/ or https://datatracker.ietf.org/doc/draft-ietf-i2rs-security-environment-reqs/) As I said, I am rather sure the document will evolve in this direction so it was more a remark on the desired path to follow than anything else.

Be goode,

Dr Diego R. Lopez
Telefonica I+D