Subject: [i2rs] Gaps analysis (draft-zhang-gap-analysis-01) revisions - MIDCOM, SACM, PCP, and AAA

From: "Susan Hares" <[email-masked]>
Date: Fri, 6 Feb 2015 19:04:33 -0500

Dan:

This is response to the email: 

http://www.ietf.org/mail-archive/web/i2nsf/current/msg00233.html

I think that this group needs to dig a bit deeper to compare the MIDCOM
architecture, protocol requirements, and protocol primitives to determine
how vNSF  based on the ETSI document.  The I2NSF gap analysis leaves the
MIDCOM section blank which is problem for a healthy discussion of the vNSF
functions.  

The gap analysis for I2NSF needs a review of MIDCOM and a review of ETSI
specification Diego mentions. While the high level comments
(http://www.ietf.org/mail-archive/web/i2nsf/current/msg00219.html) from
Melinda was helpful to point to the midcom work  - we need the following
details in the gap analysis: 

.         Use case scenario of 2015 with NFV, managed services, and
pervasive E2E encryption is different than the midcom deployment.  We need a
section that discusses whether this is a new scenarios or redefinition of
midcom scenarios for the virtual environment.  

.         Telefonica needs open mechanisms to establish trust between the
user environment and security services hosted on a virtualized
infrastructure, and to manage and operate them, in order to include those
services in our product portfolio. Telefonica does not think this is the
current security standards, and we see the results from open-source
initiatives very much focused on particular deployment models and too coarse
to support the services we have in mind.

.         Midcom's protocol analysis needs to be updated 10 years later.
The Midcom protocol analysis needs to examined: SNMP, RSIP, Megaco,
Diameter and Cops as potential protocol.   It would be important to update
this list to determine if netconf/netmod, RSIP (current), Megaco (current),
and Diameter (current) support for the revised scenarios is sufficient.
Does I2RS provide some valuable additions to dynamic nature of managing the
security box? 

Dan these points need to discuss these points on the list before removing
some of the Firewall and IDS/IPS sections in the charter.  I suspect your
tightly worded email hints that these answers are key to creating a tightly
scoped WG forming BOF.  

I want to thank Melinda for her pointer to the MIDCOM work, and I hope she
will provide additional response to Diego's email. 

Sue Hares