Re: [I2nsf] Can you make sure to include the changes suggested by Rakash in the revised terminology draft?

[John Strassner <[e-mail]>]

My replies to your comments are below:

   ACL (Acess Control List):  This is a mechanism that implements
      access control for a system resource by enumerating the system
      entities that are permitted to access the resource and stating,
      either implicitly or explicitly, the access modes granted to each
      entity [RFC4949]. A YANG description is defined in
      [I-D.ietf-netmod-acl-model].
[Rakesh & Anil] typo “Access” instead of “Access”
<jcs> Fixed <jcs>

   Capability Interface:  An interface dedicated to requesting,
      receiving, editing, and deleting capability information.
[Rakesh & Anil] What is the distinction between “Register” and “Capability
Interface”?
<jcs>
I believe you mean Registration Interface. That interface is for receiving,
editing, and deleting information in a Registry. This interface has nothing
to do with a Registry. The two are separate.
</jcs>

   Client:  See Consumer. [Editor's note: placeholder for gradually
      replacing Client with Consumer, since Client is too vague and
      has other connotations (e.g., client-server)].
[Rakesh & Anil] From a security controller’s perspective, the terms
client/consumer/northbound are all relative terms. It is hard to argue that
one is better than the other. Also, note that northbound/southbound, is
being
used in other IETF working group documents (e.g. SUPA, I2RS), so coming up
with yet another term is also confusing to the user/implementer who have to
go through multiple documents across different working groups.
<jcs>
Disagree.
The text above specifically says that client has unwanted meanings, which
Consumer does not have. Furthermore, we have already had a discussion and
reached consensus about northbound and southbound. Briefly, northbound is
NOT in fact relative, which is why we are NOT using northbound or
southbound.
Indeed, from a security perspective, northbound and southbound are too
ambiguous to be usable.
</jcs>

   Consumer:  A Consumer is a Role that is assigned to an I2NSF
      Component that can receive information from another I2NSF
      Component.  See also:  Provider, Role.
[Rakesh & Anil] Why do we need this, are we talking about “User”?
When we say “Role”, to me it is different than “User”.
<jcs>
Please see the definition of a Role.
Consumer is replacing Client (see Client above), which is why it is needed.
</jcs>

   Control Plane:  In the context of I2NSF, the Control Plane is an
      architectural Component that provides common control functions
      to all I2NSF Components, including some or all of the following:
      authentication, authorization, accounting, auditing, and
      Capability discovery and negotiation. The Control Plane
      orchestrates the operation of the Data Plane according to
      guidance and/or input from the Management Plane. I2NSF Components
      with Interfaces to the Control Plane have knowledge of the
      Capabilities of other I2NSF Components within a particular I2NSF
      administrative domain. This definition is based on that in
      [I-D.ietf-sacm-terminology].  See also: Data Plane, Management
      Plane.
[Rakesh & Anil] Why do we have “negotiation”? What are we trying to
negotiate?
<jcs>
We will use Capabilities to negotiate functionality that is agreed to be
used by both parties.
</jcs>

   Data Plane:  In the context of I2NSF, the Data Plane is an
      architectural Component that provides operational functions to
      enable an I2NSF Component to provide and consume packets and
      flows.  See also:  Control Plane, Management Plane.
[Rakesh & Anil] We don’t need this definition. I2NSF is not defining any
data plane related standards.
<jcs>
We will be affecting the Data Plane, so yes, we need this definition.
</jcs>

   Data Structure:  A low-level building block that is used in
      programming to implement an algorithm. A data model typically
      contains multiple types of data structures; however, a data
      structure does not contain a data model. Note the difference
      between a data **model** and a data **structure**.
[Rakesh & Anil] What is the usefulness of this definition here ?
Nothing specific to I2NSF. It is pretty standard definition; should be
removed.
<jcs>
There were questions between the difference of what a data model is,
and what a data structure is.
</jcs>

   Firewall (FW):  A function that restricts data communication traffic
      to and from one of the connected networks (the one said to be
      'inside' the firewall), and thus protects that network's system
      resources against threats from the other network (the one that
      is said to be 'outside' the firewall) [RFC4949].
      [I-D.ietf-opsawg-firewalls]
[Rakesh & Anil] Should be removed. Nothing specific to I2NSF.
<jcs>
It is present in several documents, and people wanted a definition.
</jcs>

   I2NSF Consumer Interface:  An Interface dedicated to requesting and
      using I2NSF Services. For example, this Interface could be used
      to request a set of Flow Security policies from an I2NSF
      Controller or from one or more individual NSFs. The difference is
      that the former uses more abstract Condition matching (e.g.,
      based on tenant or customer ID), whereas the latter uses more
      low-level Condition matching (e.g., based on flow state or fields
      in a flow or packet).  See also:  Interface, I2NSF Provider
      Interface, Client-Facing Interface, NSF-Facing Interface.
[Rakesh & Anil] I find hard to follow consumer/provider terms. I would
prefer “Admin”.
<jcs>
An "Admin" is a completely different Role! What, specifically, is
confusing about "Consumer" and "Provider"?
</jcs>

   I2NSF Provider Interface:  An Interface dedicated to providing I2NSF
      Services. For example, this could provide Anti-Virus, (D)DoS, or
      IPS Services.  See also:  Interface, I2NSF Provider Interface,
      Client-Facing Interface, NSF-Facing Interface.
[Rakesh & Anil] I would prefer “NSF” interface instead of some other term
which is not very clear.
<jcs>
There are TWO interfaces - one between an I2NSF and a Consumer, and one
between an I2NSF and a Provider. Please reread the definitions of
Consumer, Provider, I2NSF Consumer Interface, and I2NSF Provider Interface.
</jcs>

   I2NSF Registry:  A registry that contains I2NSF capability
      information, which can be controlled by the I2NSF Management
      System.  See also: Registry.
[Rakesh & Anil] We already have Capability Interface? Why is that not
sufficient.
<jcs>
A Registry is a completely different Functional Block.
</jcs>

   Producer:  A Producer is a Role that is assigned to an I2NSF
      Component that can send information and/or commands to another
      I2NSF Component.  See also: Consumer, Role.
[Rakesh & Anil] I am not sure if I follow this role.
<jcs>
Think of an ESB, and the Roles of Consumers and Providers.
</jcs>

   Registration Interface:  An interface dedicated to requesting,
      receiving, editing, and deleting information in a Registry.
[Rakesh & Anil] Why “Capability interface” not enough?
<jcs>
See previous comments
</jcs>

   Role:  An abstraction of a Component that models context-specific
      views and responsibilities of an object as separate Role objects.
      Role objects can optionally be attached to, and removed from, the
      object that the Role object describes at runtime. This provides
      three important benefits. First, it enables different behavior
      to be supported by the same Component for different contexts.
      Second, it enables the behavior of a Component to be adjusted
      dynamically (i.e., at runtime, in response to changes in context)
      by using one or more Roles to define the behavior desired for
      each context. Third, it decouples the Roles of a Component from
      the Applications use that Component.
[Rakesh & Anil] Do we want to add RBAC?
<jcs>
We have not yet talked about formal access control mechanisms. Note that
Role is independent of access mechanisms, and is a generic modeling
construct.
</jcs>

   Service Provider Security Controller:  TBD (Editorial: Place holder
      for a split between controller and security controller
      definitions.)
[Rakesh & Anil] I am not sure why we want to restrict to “Service provider”.
Since anyone in any market segment can use “Security Controller” and the
I2NSF interfaces.
<jcs>
It is a **placeholder**. The important thing is to distinguish between a
Controller and an entity that only is responsible for making security
decisions.
</jcs>

   Tenant:  A group of users that share common access privileges to
      the same software.  An I2NSF tenant may be physical or virtual,
      and may run on a variety of systems or servers.
[Rakesh & Anil] It is not necessary for all the users in the same tenant
to have common access privileges. A tenant is just a group of resources
for purpose of managing access control.
<jcs>
Disagree. Access control is not just a simple rwxd, but specific to
different resources and users. Think of RBAC, which you brought up
earlier. By this logic, you would have an exponential number of Roles
(also called Role Explosion), since if you enable different resources
to have different permissions to the same resource,
  num_tenants = num_resources X num_permissions X num_users
</jcs>

   Vendor-Facing Interface:  An Interface dedicated to registering and
      vendor-specific NSFs and Capabilities. It is also used to invoke
      vendor-specific functionality. This is also called the NSF-Facing
      Interface.
[Rakesh & Anil] Why do we need this? Why NSF interface is not sufficient.
<jcs>
Please read the framework spec.
</jcs>


regards,
John

On Fri, Sep 30, 2016 at 1:42 PM, Rakesh Kumar <[e-mail]> wrote:

> Hi John and Sue,
>
>
>
> In the interim meeting, we were not able to proceed past couple of things.
>
> Could you please take a look at all the comments ?
>
>
>
> Thanks & Regards,
>
> Rakesh
>
>
>
> *From: *John Strassner <[e-mail]>
> *Date: *Friday, September 30, 2016 at 10:43 AM
> *To: *Linda Dunbar <[e-mail]>
> *Cc: *Rakesh Kumar <[e-mail]>, Adrian Farrel <
> [e-mail]>, Susan Hares <[e-mail]>, Anil Lohiya <
> [e-mail]>
> *Subject: *Re: Can you make sure to include the changes suggested by
> Rakash in the revised terminology draft?
>
>
>
> Yes, I will incorporate the comments that we agreed to and send out an
> authors draft to check my work before I send out the draft to the list.
>
>
>
> best,
>
> John
>
>
>
> On Fri, Sep 30, 2016 at 8:32 AM, Linda Dunbar <[e-mail]>
> wrote:
>
> John and Sue,
>
>
>
> I think that we have gone through most of Rakesh’s comments on Terminology
> over the Interim meeting. But just want to make sure that you will
> incorporate his suggestions in the revised draft.
>
>
>
> Attached is the draft with his comments marked.
>
>
>
> Also attached is the Terminology discussion meeting minutes.
>
>
>
> Linda
>
>
>
> *From:* Rakesh Kumar [mailto:[e-mail]]
> *Sent:* Friday, September 30, 2016 12:44 AM
> *To:* Linda Dunbar; Adrian Farrel
> *Cc:* Anil Lohiya; Rakesh Kumar
> *Subject:* Re: what are the terminology comments? Sue Hares is working on
> the revision of the terminology now.
>
>
>
> Hi Linda and Adrian,
>
>
>
> I am attaching the email that has our comments on terminology draft.
>
> It would be good if you could ask Sue to work with us on this since we
> have tried so many times without any luck. We got stuck with two terms in
> last interim meeting and after that no one has approached us.
>
>
>
> Regards,
>
> Rakesh
>
>
>
> *From: *Rakesh Kumar <[e-mail]>
> *Date: *Thursday, September 29, 2016 at 1:22 PM
> *To: *Linda Dunbar <[e-mail]>
> *Cc: *Anil Lohiya <[e-mail]>, Rakesh Kumar <[e-mail]
> >
> *Subject: *Re: what are the terminology comments? Sue Hares is working on
> the revision of the terminology now.
>
>
>
> I have sent multiple times to I2NSF.
>
> Could you please tell Sue to work with us on that?
>
>
>
> Regards
>
> Rakesh
>
>
> Sent from my iPhone
>
>
> On Sep 29, 2016, at 12:30 PM, Linda Dunbar <[e-mail]>
> wrote:
>
> Rakesh,
>
>
>
> Can you re-send the comments / suggestions for the terminology draft? Sue
> Hares is working on the revision of the terminology now. Shouldn’t be hard
> to incorporate.
>
>
>
> Linda
>
>
>
> *From:* Rakesh Kumar [mailto:[e-mail] <[e-mail]>]
> *Sent:* Thursday, September 29, 2016 2:21 PM
> *To:* Linda Dunbar
> *Cc:* Rakesh Kumar; Anil Lohiya
> *Subject:* Re: revised draft can wait for other people, but an email
> reply to Diego answering his questions would be very good.
>
>
>
> + Anil,
>
>
>
> I am working with my co-authors and making changes and soon will send for
> review with the folks who sent comments.
>
>
>
> Could you please help us on terminology draft comments from Anil and me?
>
> We have waited patiently for months and there is no response. We did not
> make any progress in last interim meeting.
>
> May be, you can send email to authors of that draft and work with us to
> resolve all the comments?
>
>
>
> Thanks
>
> Rakesh
>
>
>
> *From: *Linda Dunbar <[e-mail]>
> *Date: *Thursday, September 29, 2016 at 12:14 PM
> *To: *Rakesh Kumar <[e-mail]>
> *Subject: *revised draft can wait for other people, but an email reply to
> Diego answering his questions would be very good.
>
>
>
> Rakesh,
>
>
>
> Agree with your approach that you can include all people’s comments into
> the next draft revision. An email reply to Diego answering his questions
> would be very good. Potentially invite him to be the co-authors, so that
> requirement from Telefonica can be incorporated in.
>
>
>
> Thanks, Linda
>
>
>
> *From:* Rakesh Kumar [mailto:[e-mail] <[e-mail]>]
> *Sent:* Wednesday, September 28, 2016 6:30 PM
> *To:* Linda Dunbar
> *Cc:* [e-mail]
> *Subject:* Re: could you please address comments from Diego Lopez on
> draft-kumar-i2nsf-client-facing-interface-req-00 and revise the draft
> accordingly?
>
>
>
> Hi Linda,
>
>
>
> I have communicated earlier through private channel to folks who provided
> comments that we would create a new revision but I am still waiting on
> inputs from couple of other folks. I wanted to combine all the comments
> into one update, avoid unnecessary cycles and save time.
>
>
>
> Thanks & Regards,
>
> Rakesh
>
>
>
> *From: *Linda Dunbar <[e-mail]>
> *Date: *Wednesday, September 28, 2016 at 2:23 PM
> *To: *Rakesh Kumar <[e-mail]>
> *Cc: *"[e-mail]" <[e-mail]>
> *Subject: *could you please address comments from Diego Lopez on
> draft-kumar-i2nsf-client-facing-interface-req-00 and revise the draft
> accordingly?
>
>
>
> Rakesh,
>
>
>
> Searching through the mailing list achieve, I find the comments from Diego
> Lopez on your draft hasn’t been addressed nor reflect in your draft. Can
> you address them and revise the draft accordingly?
>
>
>
> Thank you very much.
>
>
>
> Linda
>
>
>
>
>
> https://mailarchive.ietf.org/arch/search/?email_list=i2nsf&
> f_from=diego.r.lopez%40telefonica.com
>
>
>
>
>
>
>
> *Re: [I2nsf] New Version Notification for
> draft-kumar-i2nsf-client-facing-interface-req-00.txt*
>
> "Diego R. Lopez" <[e-mail]> Tue, 09 August 2016 17:37
> UTCShow header
> <https://mailarchive.ietf.org/arch/msg/i2nsf/nKbb546VyxO7fOD46Pf3QKf5G5s>
>
> Return-Path: <[e-mail]>
> X-Original-To: [e-mail]
> Delivered-To: [e-mail]
> Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com
> (Postfix) with ESMTP id 9B85E12D1C2 for <[e-mail]>; Tue, 9
> Aug 2016 10:37:32 -0700 (PDT)
> X-Virus-Scanned: amavisd-new at amsl.com
> X-Spam-Flag: NO
> X-Spam-Score: -3.867
> X-Spam-Level:
> X-Spam-Status: No, score=-3.867 tagged_above=-999 required=5
> tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7,
> RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.247,
> SPF_PASS=-0.001] autolearn=ham autolearn_force=no
> Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com
> [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5G-Tb8kz3Zbe for <
> [e-mail]>; Tue, 9 Aug 2016 10:37:29 -0700 (PDT)
> Received: from smtptc.telefonica.com (smtptc.telefonica.com
> [195.76.34.108]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256
> bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with
> ESMTPS id 9CC3412D128 for <[e-mail]>; Tue, 9 Aug 2016 10:37:27
> -0700 (PDT)
> Received: from smtptc.telefonica.com (tgtim3c01.telefonica.com
> [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 756C04610C6; Tue, 9 Aug 2016
> 19:37:25 +0200 (CEST)
> Received: from ESTGVMSP113.EUROPE.telefonica.corp (unknown [10.92.4.9])
> (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN
> "ESTGVMSP113", Issuer "ESTGVMSP113" (not verified)) by
> smtptc.telefonica.com (Postfix) with ESMTPS id 5CA494610C0; Tue, 9 Aug
> 2016 19:37:25 +0200 (CEST)
> Received: from EUR01-HE1-obe.outbound.protection.outlook.com
> (10.92.5.139) by tls.telefonica.com (10.92.6.55) with Microsoft SMTP
> Server (TLS) id 14.3.266.1; Tue, 9 Aug 2016 19:37:24 +0200
> Received: from DB6PR0601MB2167.eurprd06.prod.outlook.com (10.168.57.26)
> by DB6PR0601MB2167.eurprd06.prod.outlook.com (10.168.57.26) with
> Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384)
> id 15.1.549.15; Tue, 9 Aug 2016 17:36:22 +0000
> Received: from DB6PR0601MB2167.eurprd06.prod.outlook.com ([10.168.57.26])
> by DB6PR0601MB2167.eurprd06.prod.outlook.com ([10.168.57.26]) with mapi
> id 15.01.0549.025; Tue, 9 Aug 2016 17:36:22 +0000
> From: "Diego R. Lopez" <[e-mail]>
> To: Rakesh Kumar <[e-mail]>
> Thread-Topic: [I2nsf] New Version Notification for
> draft-kumar-i2nsf-client-facing-interface-req-00.txt
> Thread-Index: AQHR7PIbXhBDGEx5R0SFVyRAslmcjqA1uecAgAEgWwCAAOjJAIAJLCaA
> Date: Tue, 9 Aug 2016 17:36:22 +0000
> Message-ID: <[e-mail]>
> References: <[e-mail]> <
> [e-mail]> <
> [e-mail]> <
> [e-mail]>
> In-Reply-To: <[e-mail]>
> Accept-Language: en-US
> Content-Language: en-US
> X-MS-Has-Attach:
> X-MS-TNEF-Correlator:
> authentication-results: spf=none (sender IP is )
> smtp.mailfrom=[e-mail];
> x-ms-exchange-messagesentrepresentingtype: 1
> x-originating-ip: [83.44.247.131]
> x-ms-office365-filtering-correlation-id: 7329b5ab-9356-4f2c-9190-
> 08d3c07bae2c
> x-microsoft-exchange-diagnostics: 1; DB6PR0601MB2167; 6:
> 834Gwi9df0wv6LxJ8zPioiFqzAwhDRIQF1fct/ZA2Vg+wx+eNRKA3AWnFHJ1BL/
> OCfNEjxY4QUj6p3PVcwJSS+CBIakGNd5pokYkyXk4+1ophq5c2uBKFo9uYlnDcup2LMdCZdO
> qnMvPpfpmE6wlmNiJ8wBd6HJMgcjmIBOH9wkdnB1nFsU6pKtl3jfPihYHA3tlhu4/
> bygJTYECOlix9evOijRRv4Sbkj8oy0pkO6r9pxsHuX3YUoFskQeI1MqY6ErO
> /umzq2UkG406xYsNwtdD2c/tI0JrMtnEOZm3DIA=; 5:jZI5CdXpH+7NiQJWgCwOC91/
> Ppw5HlcT4IlCy1HRWoe65L1t7faGqXDSi1uvwova6ZYsjhiuRuXkqo46CAxZ
> DrhbC7liMk0JaNHEQjACYRD/KPbtdXOX0LhWcKfQfRvqBvi1Efn6tSEGHF63j/YxIw==; 24:
> FVV74vhB97t7jlECxJD5bUlFnLvTuzCG9THaR0Rs3J5VDJKXgRDb5QH/
> 0Xo12JpJawjnNNlhKWfvGv0wLmlbP9aiHz1QtOZsQU/nGHHsJOQ=; 7:
> FEE5J9EXb2h7OvODsYHwuvCDw6SqrKZS5jkhdHGyFMf/DR2Inuhk6Z3uToepL6cnbTBMO27i6o
> hMF5FcqvGGZ+QMit7e6AC5i+hRdPZ4I05vYYpAqBWZWTIek01nm4u6
> uONyXVrFCTGwc7GqaDAWdtiMHc0zYOUfYfLrGoSikRJal0pIXnpBeiAWDu+
> Q6lh8GX/KwQZZ4q+bunrtxJQgm2fvVutj63b5VHLA04gvQse87J/rRHcIqDFL9BGwlml0
> x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB6PR0601MB2167;
> x-microsoft-antispam-prvs: <DB6PR0601MB21672BED4AADA8DAE6
> [e-mail]>
> x-exchange-antispam-report-test: UriScan:(40392960112811)(
> 120809045254105)(192374486261705)(35073007944872)(138986009662008)(
> 5213294742642);
> x-exchange-antispam-report-cfa-test: BCL:0; PCL:0;
> RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046);
> SRVR:DB6PR0601MB2167; BCL:0; PCL:0; RULEID:; SRVR:DB6PR0601MB2167;
> x-forefront-prvs: 0029F17A3F
> x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(
> 252514010)(24454002)(189002)(199003)(2420400007)(11100500001)(2906002)(
> 50986999)(106356001)(15975445007)(10710500007)(10400500002)(2950100001)(
> 19580395003)(77096005)(66066001)(15650500001)(19617315012)(2900100001)(
> 586003)(82746002)(8666005)(86362001)(97736004)(110136002)
> (7110500001)(189998001)(33656002)(93886004)(4326007)(
> 83716003)(16236675004)(230783001)(3660700001)(102836003)(105586002)(
> 101416001)(8936002)(1941001)(106116001)(5002640100001)(
> 68736007)(92566002)(7906003)(36756003)(8676002)(76176999)(
> 81166006)(7736002)(7846002)(81156014)(3280700002)(87936001)(19580405001)(
> 54356999)(122556002)(6116002)(3846002)(7059030)(104396002); DIR:OUT;
> SFP:1102; SCL:1; SRVR:DB6PR0601MB2167; H:DB6PR0601MB2167.eurprd06.
> prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
> received-spf: None (protection.outlook.com: telefonica.com does not
> designate permitted sender hosts)
> spamdiagnosticoutput: 1:99
> spamdiagnosticmetadata: NSPM
> Content-Type: multipart/alternative; boundary="_000_
> 53D8B62D6C064DC5BFCE29A1734143F4telefonicacom_"
> MIME-Version: 1.0
> X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Aug 2016 17:36:22.2656
> (UTC)
> X-MS-Exchange-CrossTenant-fromentityheader: Hosted
> X-MS-Exchange-CrossTenant-id: 9744600e-3e04-492e-baa1-25ec245c6f10
> X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0601MB2167
> X-OriginatorOrg: telefonica.com
> X-TM-AS-GCONF: 00
> Archived-At: <https://mailarchive.ietf.org/arch/msg/i2nsf/
> nKbb546VyxO7fOD46Pf3QKf5G5s>
> Cc: "[e-mail]" <[e-mail]>, Anil Lohiya <[e-mail]>,
> "[e-mail]" <[e-mail]>, "Long, Xiaobo" <
> [e-mail]>
> Subject: Re: [I2nsf] New Version Notification for draft-kumar-i2nsf-client-
> facing-interface-req-00.txt
> X-BeenThere: [e-mail]
> X-Mailman-Version: 2.1.17
> Precedence: list
> List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" <
> i2nsf.ietf.org>
> List-Unsubscribe: <https://www.ietf.org/mailman/options/i2nsf>, <
> mailto:[e-mail]?subject=unsubscribe
> <[e-mail]?subject=unsubscribe>>
> List-Archive: <https://mailarchive.ietf.org/arch/browse/i2nsf/>
> List-Post: <mailto:[e-mail] <[e-mail]>>
> List-Help: <mailto:[e-mail]?subject=help
> <[e-mail]?subject=help>>
> List-Subscribe: <https://www.ietf.org/mailman/listinfo/i2nsf>, <
> mailto:[e-mail]?subject=subscribe
> <[e-mail]?subject=subscribe>>
> X-List-Received-Date: Tue, 09 Aug 2016 17:37:32 -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 <[e-mail]<mailto:
> [e-mail]>> 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.
>
>
>
>
>
> 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.
>
>
>
> 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.
>
>
>
>
>
> 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.
>
>
>
> 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.
>
>
>
> 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.
>
>
>
> 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,
>
>
>
> --
>
> "Esta vez no fallaremos, Doctor Infierno"
>
>
>
> Dr Diego R. Lopez
>
> Telefonica I+D
>
> http://people.tid.es/diego.lopez/
>
>
>
> e-mail: [e-mail]
>
> Tel:    [phone]
>
> Mobile: [phone]
>
> ----------------------------------
>
>
>
>
>
>
>
>
> --
>
> regards,
>
> John
>



-- 
regards,
John