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

From: Linda Dunbar <[email-masked]>
Date: Fri, 14 Oct 2016 22:37:26 +0000

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:[email-masked]] 
Sent: Friday, October 14, 2016 12:25 PM
To: Youjianjie <[email-masked]>
Cc: Adrian Farrel <[email-masked]>; Linda Dunbar <[email-masked]>; Rakesh Kumar <[email-masked]>
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" <[email-masked]> 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:[email-masked]] 代表 Rakesh Kumar
    > 发送时间: 2016年10月10日 11:37
    > 收件人: [email-masked]; Anil Lohiya; Xialiang (Frank); Nabil Bitar;
    > [email-masked]; Dave Qi; Senad Palislamovic
    > 抄送: [email-masked]
    > 主题: 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, "[email-masked]" <[email-masked]>
    > 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
    > [email-masked]
    > https://www.ietf.org/mailman/listinfo/i2nsf

---

From: John Strassner <[email-masked]>
Date: Thu, 20 Oct 2016 00:21:25 -0700

Hi,

I still do not think that this draft is mature enough to be adopted as a WG
draft.

First, let me reply to what Rakesh stated:

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.
<jcs>
You forget that other client-facing drafts predate your requirements draft,
and that those drafts already had requirements in them.
</jcs>

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).
<jcs>
No one has said that. However, things develop at different paces. You are
proposing to stop all work and gather all requirements together. However,
many of the drafts are already advanced, and are past the requirements
stage. I don't think that this is a good thing to do.
</jcs>

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.
<jcs>
I don't agree with #1.
I don't agree with #2 - some drafts have an information model already,
others don't. I for one don't want to stop our work.
I don't agree with #3 - these are likely separate YANG modules, not a
single YANG model.
</jcs>

Now, let me provide further details as to why I don't think that this draft
is mature enough yet:

   - There are a multitude of typos and grammatical errors that make the
   document hard to read
   - 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
   - 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.
      - I don't follow your argument about virtual NSFs being different
      than physical ones - this needs a concrete example
      - The fifth bullet on page 3 states a fact, not a problem
      - 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?
   - Section 3
      - You write: "In essence, these interfaces provide a management
      framework...", which begs 2 questions: (1) how is this different than the
      framework I-D, and (2) a management framework is a LOT more than just 3
      interfaces!
      - Section 3.1
      - First paragraph, last sentence - I **think** that you are talking
      about context - why is this not an inherent part of translating business
      objectives into actionable policies?
      - Second paragraph - how is this different than ODL GBP?
      - After you answer the above, why doesn't the ability to define an
      application group require "deep knowledge" of the system?
   - 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 for I2NSF, I would choose nouns and verbs based upon a
      set of expected capabilities. Referring to DDoS as "foo" does no one any
      good.
      - Fourth bullet ("Agnostic to the network function type...) is
      unclear; is "routing" or "forwarding" an agnostic term?
      - Fifth bullet (Declarative instead of imperative): I agree in
      principle, but I don't understand your design enough to say
"yes". English
      is inherently ambiguous, and if you aren't using common terms from NSFs
      (from bullet #4), then you have a very complex mapping.

I am going to stop here, because as I continue, I get even more questions.
This document needs a thorough discussion in the mail list before it is
ready for adoption. In particular, I would suggest the authors remove
intent completely, unless they can provide a clear definition of what they
mean, with examples. As previously stated, this has not yet been done in
any SDO or fora, and should be a completely separate document, not hidden
in the requirements.

regards,
John

On Fri, Oct 14, 2016 at 3:37 PM, Linda Dunbar <[email-masked]>
wrote:

> 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
>
>
> Cc: Adrian Farrel <[email-masked]>; Linda Dunbar <
> [email-masked]>; Rakesh Kumar <[email-masked]>
> 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).
> 1. One single draft that captures set of requirements → we published one,
> we can add more requirements in that if anything missing.

-- 
regards,
John

---

From: "Diego R. Lopez" <[email-masked]>
Date: Sat, 22 Oct 2016 11:42:48 +0000

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 <[email-masked]<mailto:[email-masked]>> 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 for I2NSF, I would choose nouns and verbs based upon a set of expected capabilities. Referring to DDoS as "foo" does no one any good.
     *   Fourth bullet ("Agnostic to the network function type...) is unclear; is "routing" or "forwarding" an agnostic term?

DRL> I wonder whether using a term other than “agnostic” could make things clearer in these points. In my understanding we could substitute the problematic clauses by:
* “Not depending on particular topology properties or on the actual NSF location in the network”
* “Not requiring the exact knowledge of the concrete features and capabilities supported in the deployed NSFs”
* “Independent of the nature of the function that will apply the expressed policies”

Be goode,

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

---

From: Rakesh Kumar <[email-masked]>
Date: Fri, 28 Oct 2016 18:38:28 +0000

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 <[email-masked]> on behalf of "Diego R. Lopez" <[email-masked]>
Date: Saturday, October 22, 2016 at 4:42 AM
To: "[email-masked]" <[email-masked]>
Subject: Re: [I2nsf] with regarding to WG adoption for the revised draft-kumar-i2nsf-client-facing-interface-req-01.txt

Hi,

  *   Section 1

     *   Section 3.2

Be goode,

Dr Diego R. Lopez
Telefonica I+D