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" <[email protected]> Tue, 09 August 2016 17:37 UTCShow header<https://mailarchive.ietf.org/arch/msg/i2nsf/nKbb546VyxO7fOD46Pf3QKf5G5s> Return-Path: <[email protected]> X-Original-To: [email protected] Delivered-To: [email protected] Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B85E12D1C2 for <[email protected]>; 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 <[email protected]>; 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 <[email protected]>; 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" <[email protected]> To: Rakesh Kumar <[email protected]> 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: <[email protected]> References: <[email protected]> <[email protected]> <[email protected]> <[email protected]> In-Reply-To: <[email protected]> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) [email protected]; 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+1ophq5c2uBKFo9uYlnDcup2LMdCZdOqnMvPpfpmE6wlmNiJ8wBd6HJMgcjmIBOH9wkdnB1nFsU6pKtl3jfPihYHA3tlhu4/bygJTYECOlix9evOijRRv4Sbkj8oy0pkO6r9pxsHuX3YUoFskQeI1MqY6ErO/umzq2UkG406xYsNwtdD2c/tI0JrMtnEOZm3DIA=; 5:jZI5CdXpH+7NiQJWgCwOC91/Ppw5HlcT4IlCy1HRWoe65L1t7faGqXDSi1uvwova6ZYsjhiuRuXkqo46CAxZDrhbC7liMk0JaNHEQjACYRD/KPbtdXOX0LhWcKfQfRvqBvi1Efn6tSEGHF63j/YxIw==; 24:FVV74vhB97t7jlECxJD5bUlFnLvTuzCG9THaR0Rs3J5VDJKXgRDb5QH/0Xo12JpJawjnNNlhKWfvGv0wLmlbP9aiHz1QtOZsQU/nGHHsJOQ=; 7:FEE5J9EXb2h7OvODsYHwuvCDw6SqrKZS5jkhdHGyFMf/DR2Inuhk6Z3uToepL6cnbTBMO27i6ohMF5FcqvGGZ+QMit7e6AC5i+hRdPZ4I05vYYpAqBWZWTIek01nm4u6uONyXVrFCTGwc7GqaDAWdtiMHc0zYOUfYfLrGoSikRJal0pIXnpBeiAWDu+Q6lh8GX/KwQZZ4q+bunrtxJQgm2fvVutj63b5VHLA04gvQse87J/rRHcIqDFL9BGwlml0 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB6PR0601MB2167; x-microsoft-antispam-prvs: <db6pr0601mb21672bed4aada8dae68b1a1cdf...@db6pr0601mb2167.eurprd06.prod.outlook.com> 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: "[email protected]" <[email protected]>, Anil Lohiya <[email protected]>, "[email protected]" <[email protected]>, "Long, Xiaobo" <[email protected]> Subject: Re: [I2nsf] New Version Notification for draft-kumar-i2nsf-client-facing-interface-req-00.txt X-BeenThere: [email protected] 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:[email protected]?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/i2nsf/> List-Post: <mailto:[email protected]> List-Help: <mailto:[email protected]?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/i2nsf>, <mailto:[email protected]?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 <[email protected]<mailto:[email protected]>> 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: [email protected] Tel: +34 913 129 041 Mobile: +34 682 051 091 ----------------------------------
_______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
