Re: [Nsaas] Existing work, other things

Wangyuchen <wangyuchen@huawei.com> Mon, 15 September 2014 00:46 UTC

Return-Path: <wangyuchen@huawei.com>
X-Original-To: nsaas@ietfa.amsl.com
Delivered-To: nsaas@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53D7F1A045C for <nsaas@ietfa.amsl.com>; Sun, 14 Sep 2014 17:46:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.852
X-Spam-Level:
X-Spam-Status: No, score=-5.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001] autolearn=ham
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 MnyF2snpgKuO for <nsaas@ietfa.amsl.com>; Sun, 14 Sep 2014 17:46:33 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36D8C1A0415 for <NSaaS@ietf.org>; Sun, 14 Sep 2014 17:46:32 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BMN89589; Mon, 15 Sep 2014 00:46:30 +0000 (GMT)
Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 15 Sep 2014 01:46:29 +0100
Received: from NKGEML507-MBX.china.huawei.com ([169.254.5.43]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0158.001; Mon, 15 Sep 2014 08:46:17 +0800
From: Wangyuchen <wangyuchen@huawei.com>
To: "NSaaS@ietf.org" <NSaaS@ietf.org>
Thread-Topic: Re: [Nsaas] Existing work, other things
Thread-Index: Ac/QfnQWkl4jp+QyS9CgEwV1ZzLNYQ==
Date: Mon, 15 Sep 2014 00:46:16 +0000
Message-ID: <27749866F6024B4F8F9DA61CAD52375F51F6593F@nkgeml507-mbx.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.111.60.69]
Content-Type: multipart/alternative; boundary="_000_27749866F6024B4F8F9DA61CAD52375F51F6593Fnkgeml507mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/nsaas/QFXTFtBJ7HkX7-WpOkyg3ammTOQ
X-Mailman-Approved-At: Mon, 15 Sep 2014 05:24:25 -0700
Cc: "Zhangdacheng (Dacheng)" <zhangdacheng@huawei.com>, "melinda.shore@gmail.com" <melinda.shore@gmail.com>, Linda Dunbar <linda.dunbar@huawei.com>
Subject: Re: [Nsaas] Existing work, other things
X-BeenThere: nsaas@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "*NSaaS: Network Security as a Service mailing list*" <nsaas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nsaas>, <mailto:nsaas-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsaas/>
List-Post: <mailto:nsaas@ietf.org>
List-Help: <mailto:nsaas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsaas>, <mailto:nsaas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Sep 2014 00:46:35 -0000

Again, there's been work done in the IETF on some of this (for example, network endpoint assessment (http://datatracker.ietf.org/wg/nea/charter/),

tunnel endpoint discovery, ipsp, and so on.  I think my more general concern is that recently there's been a great deal of work being brought into the IETF that's not product-driven and doesn't have "organic"

support, and it turns out to chew up a lot of IETF resources and frustrate the heck out of its proponents.



[YuChen] I am from the Security Product side. For many years, we have delivered physical boxes for FW, AntiDoS, IPSec etc. For the next generation products, we have been asked by our customers to provide value added service. Therefore, having a standard interface for Network Security functions are essential to enable the services.







No technical work comes out of it and nobody's happy.  Because it's not product-driven there tends not to be a clear, existing framework to slip it into along with real-world requirements and expectations for how it might work.

I don't think the problem statement/framework/requirements process that's developed is working well for the organization, IETF participants, or the industry, and I think that it might be time to take lessons learned about process and apply them here.



That is to say, rather than getting mired in the same old unsuccessful process, it might be a better idea to identify a narrowly-scoped piece of work that *needs* to be done and focus on that.  Talk to product people before bringing a proposal in and asking for a BOF.  I tend to see this effort as going the way of the "cloud" effort, and so on, but it's early enough that it doesn't have to proceed down that same path.  Talk to product people *NOW*, and identify why this work belongs in the IETF.  It should never be the case that the problem you're trying to solve is how to create an IETF working group, but rather how to accomplish a specific piece of technical work that improves networks and networking.



That is to say, talk to people who build products and talk to people who run networks, see what they need.  Bring your product managers into the process.



[YuChen] We will be participating in the NSaaS discussion.



Melinda