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

[Rakesh Kumar]

Hi,

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

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

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

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

Regards,
Rakesh

From: I2nsf <i2nsf-boun...@ietf.org> on behalf of "Diego R. Lopez" 
<diego.r.lo...@telefonica.com>
Date: Saturday, October 22, 2016 at 4:42 AM
To: "i2nsf@ietf.org" <i2nsf@ietf.org>
Subject: Re: [I2nsf] with regarding to WG adoption for the revised 
draft-kumar-i2nsf-client-facing-interface-req-01.txt

Hi,

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

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

On 20 Oct 2016, at 09:21 , John Strassner 
<straz...@gmail.com<mailto:straz...@gmail.com>> wrote:


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

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

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


  *   Section 1

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

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

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

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

[Diego R. Lopez]

Hi,

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

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

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


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

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


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

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

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

DRL> Reading the draft for the first time I had the same impression. I’d 
propose an alternate writing:
“In order to ease the deployment of security policies across different

developers and devices, the Interface to Network Security Functions
(I2NSF) working group in the IETF is defining a client-facing
interface from the security controller to clients [I-D. ietf-i2nsf-
framework] [I-D. ietf-i2nsf-terminology].  Deployment facilitation
should be agnostic to type of device, be it physical or virtual, or
type of the policy, be it dynamic or static.  Using these interfaces,
it would become possible to write different kinds of application (e.g.

GUI portal, template engine, etc.) to control the implementation of

security policies on security functional elements, though how these

applications are implemente are completely out of the scope of the I2NSF

working group, which is only focused on the interfaces"


 *   Section 3.2
 *   The first bullet ("Agnostic of network topology and NSF location in 
the network") conflicts with the principles expressed in section 3.1
 *   The second bullet (*Agnostic to the features and capabilities 
supported in NSFs") doesn't make sense to me. If I was defining either an API 
or a language 

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

[Linda Dunbar]

I2NSF participants:


The authors of draft-kumar-i2nsf-client-facing-interface-req have made an 
update aiming to address the comments made during the poll for WG adoption. Can 
you all please check that your comments were addressed and that we're ready to 
move ahead?

Thank you very much. 

Linda 


-Original Message-
From: Rakesh Kumar [mailto:rkku...@juniper.net] 
Sent: Friday, October 14, 2016 12:25 PM
To: Youjianjie 
Cc: Adrian Farrel ; Linda Dunbar 
; Rakesh Kumar 
Subject: Re: 答复: New Version Notification for 
draft-kumar-i2nsf-client-facing-interface-req-01.txt

Hi Jianjie and WG chairs,

The “user-group” requirement is there from day one in the draft (version 00 had 
it). We have mentioned this earlier that the requirement draft is a superset of 
all the requirements (including user-group defined in your draft). Please see 
the attached email.

In my opinion, I don’t think it is a good idea to have one draft per 
requirement (it would be too fragmented and cumbersome for developer). 
I propose to have set of draft for client interfaces as following: 

1. One single draft that captures set of requirements → we published one, we 
can add more requirements in that if anything missing.
2. One single draft that takes requirements and propose an informational model. 
We are working on it.
3. One single draft that proposes a YANG data model for the information model.

If we agree, then we should find a way to merge different ideas.

Thanks
Rakesh


On 10/13/16, 11:05 PM, "Youjianjie"  wrote:

Hi Rakesh,

I saw the draft also mentions user group and related policies. We already 
defined them in : 
https://tools.ietf.org/html/draft-you-i2nsf-user-group-based-policy-02 
Maybe it’s better to keep them aligned. 

Thanks,
Jianjie

> -邮件原件-
> 发件人: I2nsf [mailto:i2nsf-boun...@ietf.org] 代表 Rakesh Kumar
> 发送时间: 2016年10月10日 11:37
> 收件人: internet-dra...@ietf.org; Anil Lohiya; Xialiang (Frank); Nabil Bitar;
> i2nsf-cha...@ietf.org; Dave Qi; Senad Palislamovic
> 抄送: i2nsf@ietf.org
> 主题: Re: [I2nsf] New Version Notification for
> draft-kumar-i2nsf-client-facing-interface-req-01.txt
> 
> Hi all,
> 
> The authors updated the draft with -01 revision that includes changes 
made as
> per comments from the I2NSF working group members.
> 
> Regards,
> Rakesh
> 
> On 10/9/16, 8:32 PM, "internet-dra...@ietf.org" 
> wrote:
> 
> 
> A new version of I-D, 
draft-kumar-i2nsf-client-facing-interface-req-01.txt
> has been successfully submitted by Rakesh Kumar and posted to the
> IETF repository.
> 
> Name: draft-kumar-i2nsf-client-facing-interface-req
> Revision: 01
> Title:Requirements for Client-Facing Interface to 
Security
> Controller
> Document date:2016-10-09
> Group:i2nsf
> Pages:22
> URL:
> 
https://www.ietf.org/internet-drafts/draft-kumar-i2nsf-client-facing-interface-r
> eq-01.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-01
> Diff:
> 
https://www.ietf.org/rfcdiff?url2=draft-kumar-i2nsf-client-facing-interface-req-
> 01
> 
> Abstract:
>This document captures the requirements for the client-facing
>interface to security controller.  The interfaces are based on 
user-
>intent instead of developer-specific or device-centric approaches
>that would require deep knowledge of specific products and their
>security features.  The document identifies the requirements 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
> 
> 
> 
> ___
> I2nsf mailing list
> I2nsf@ietf.org
> https://www.ietf.org/mailman/listinfo/i2nsf


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