[netmod] Genart last call review of draft-ietf-netmod-geo-location-08
Reviewer: Linda Dunbar Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-netmod-geo-location-?? Reviewer: Linda Dunbar Review Date: 2021-04-26 IETF LC End Date: 2021-05-03 IESG Telechat date: Not scheduled for a telechat Summary: This draft describes the Geo-location object for YANG. The document is written very clear. I don't see any problem., except for one question: The "pattern ’[ -@\[-\^_-~]*’" is used by leaf astronomical-body and container geodetic-system. Why not creating a Constant for the pattern to be referenced? in case you want to make changes to the pattern. Major issues: None. Minor issues: None. Nits/editorial comments: None. Best Regards, Linda Dunbar ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] PANIC Bar BoF Tonight @ 6:30pm CDT
David, Will PANIC initiative cover the "security posture" for "workload" moved to 3rd party cloud DC? Just finished attending ONUG (Open Network User Group - an enterprise centric forum) Spring meeting. Many enterprise users are saying that they are moving their workload to multiple Cloud DC (AWS, Azure, Salesforce, IBM, etc) to achieve data portability, app sharing, and built-in redundancy. One of the biggest issue is how to make security risk visible, so that they can better manage the security risks. Possible to have mechanism to properly identify the security posture of "Endpoint in 3rd party DC"? Is it part of PANIC scope? Linda -Original Message- From: mile [mailto:mile-boun...@ietf.org] On Behalf Of Waltermire, David A. (Fed) Sent: Monday, May 01, 2017 3:55 PM To: s...@ietf.org; ops...@ietf.org; netc...@ietf.org; netmod@ietf.org; s...@ietf.org; m...@ietf.org; i2...@ietf.org Subject: Re: [mile] PANIC Bar BoF Tonight @ 6:30pm CDT The Posture Assessment Through Network Information Collection (PANIC) group held an informal bar BoF at IETF 98 to discuss available protocols and data models for assessing the posture of network equipment devices. A description of PANIC is below, and a slide deck is attached describing the group's goals and requirements. We had a productive discussion about the group's scope, and agreed to continue the conversation on a non-working group mailing list. The PANIC mailing list is now available for subscribers at this link: https://www.ietf.org/mailman/listinfo/panic. If you are interested in the effort, please join the mailing list. A scoping draft will be posted to the list in the next week. We look forward to your feedback on it. Regards, Dave PANIC Description: The IETF SACM work group has been working to standardize the collection of endpoint configuration and other posture information from enterprise endpoints. Collecting this information is critical to support automation of common network security tasks, including asset, software, vulnerability, and configuration management. Thus far, our efforts have focused primarily on standards to collect information in support of asset, software and vulnerability management use cases for classical endpoint devices (e.g., servers, laptops, etc), and has worked with other IETF members to determine what data would need to be to be collected, and how that data would be securely communicated across the network. Through such exchanges an organization can know what client endpoints are connected to their network, and if they are vulnerable to attack. Given the proliferation of attacks against network infrastructure devices, it is clear that the next step in our enterprise security automation effort must be to enable standardized reporting of similar information from network infrastructure devices. With the growing number of Yang models and increased adoption of NETCONF, RESTCONF, and related protocol work, we believe the time is right to work out how these standards can be used to measure the health of network devices. This information will, as in our efforts in SACM for client devices, support asset, software, vulnerability, and configuration management use cases. We hope to use existing management protocols to report this information from network infrastructure devices, supporting multiple use cases using the same set of management protocols. Such a mechanism will help network defenders protect against known attacks, and provide the necessary knowledge to detect and mitigate future attacks. > -Original Message- > From: Waltermire, David A. (Fed) > Sent: Wednesday, March 29, 2017 4:42 PM > To: 's...@ietf.org' ; 'ops...@ietf.org' > ; 'netc...@ietf.org' ; 'netmod@ietf.org' > > Subject: PANIC Bar BoF Tonight @ 6:30pm CDT > > > Just a quick reminder... the Posture Assessment through Network > Information Collection (PANIC) bar BoF is tonight right after the IETF > 98 Technical and Administrative Plenary at 6:30pm CDT in Vevey 4 at > the Swissotel Conference Center. We are hoping to start a discussion > about how to leverage the existing IETF network management protocols > to best address security automation for network infrastructure > devices. We would like your ideas on how to best pursue this work, and > your insights into network infrastructure security problems that will impact > our networks in the future. > We are holding a side meeting at IETF 98 on Wednesday, March 29th at > 6:30pm CDT to start a discussion about how to move forward on this topic. > > Given the late hour, we will have some light snacks. We hope to see > you there. > > Regards, > David Waltermire ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Can you remove the "Identity acl-base" defined in draft-ietf-netmod-acl-model-07
Lisa,
My difficulty was not being able to see the value of one comment based on
another comment.
Now I understand it is really just personal preference. Having an extra step
doesn't hurt the bottom line end result. It is Ok.
Linda
-Original Message-
From: Lisa (Yi) Huang [mailto:lyihu...@juniper.net]
Sent: Tuesday, May 10, 2016 12:06 PM
To: Linda Dunbar; Juergen Schoenwaelder
Cc: draft-ietf-netmod-acl-mo...@ietf.org; 'netmod@ietf.org'; Thomas D. Nadeau
Subject: Re: Can you remove the "Identity acl-base" defined in
draft-ietf-netmod-acl-model-07
Linda,
Could you elaborate what difficulty you are facing?
The draft defines
typedef acl-type {
type identityref {
base acl-base;
}
}
This allows the acl-type to be ipv4-acl or ipv6-acl, or other new types that
inherit from acl-type.
Hope this helps.
Thanks,
Lisa
On 5/10/16, 9:55 AM, "Linda Dunbar" wrote:
>Juergen,
>
>Of course, it is not confusing to you because you are in the box (vs.
>many of us are outside the box looking in).
>
>RFC 6020 doesn't say all identities have to have a sub-identity.
>
>
>My opinion only.
>
>
>Linda
>
>
>-Original Message-
>From: Juergen Schoenwaelder
>[mailto:j.schoenwael...@jacobs-university.de]
>Sent: Tuesday, May 10, 2016 10:38 AM
>To: Linda Dunbar
>Cc: draft-ietf-netmod-acl-mo...@ietf.org; 'netmod@ietf.org'; Thomas D.
>Nadeau
>Subject: Re: Can you remove the "Identity acl-base" defined in
>draft-ietf-netmod-acl-model-07
>
>On Tue, May 10, 2016 at 03:07:30PM +, Linda Dunbar wrote:
>> Juergen,
>>
>> If "acl-base" has some content more than the comment (i.e. the
>>description), then it makes sense.
>>
>> The comments in the "identity ipv4-acl" is enough to describe the
>>identity. Same with the identity ipv6-acl.
>>
>> I find it is very confusing to have the recursive reference of
>>identity (all of them are simply the description).
>>
>
>I fail to see anything confusing here. Did you read the relevant
>sections of RFC 6020? What is unclear about identities and how they work?
>
>/js
>
>--
>Juergen Schoenwaelder Jacobs University Bremen gGmbH
>Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
>Fax: +49 421 200 3103 <http://www.jacobs-university.de/>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Can you remove the "Identity acl-base" defined in draft-ietf-netmod-acl-model-07
Juergen, Of course, it is not confusing to you because you are in the box (vs. many of us are outside the box looking in). RFC 6020 doesn't say all identities have to have a sub-identity. My opinion only. Linda -Original Message- From: Juergen Schoenwaelder [mailto:j.schoenwael...@jacobs-university.de] Sent: Tuesday, May 10, 2016 10:38 AM To: Linda Dunbar Cc: draft-ietf-netmod-acl-mo...@ietf.org; 'netmod@ietf.org'; Thomas D. Nadeau Subject: Re: Can you remove the "Identity acl-base" defined in draft-ietf-netmod-acl-model-07 On Tue, May 10, 2016 at 03:07:30PM +, Linda Dunbar wrote: > Juergen, > > If "acl-base" has some content more than the comment (i.e. the description), > then it makes sense. > > The comments in the "identity ipv4-acl" is enough to describe the identity. > Same with the identity ipv6-acl. > > I find it is very confusing to have the recursive reference of identity (all > of them are simply the description). > I fail to see anything confusing here. Did you read the relevant sections of RFC 6020? What is unclear about identities and how they work? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/> ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Can you remove the "Identity acl-base" defined in draft-ietf-netmod-acl-model-07
Juergen,
If "acl-base" has some content more than the comment (i.e. the description),
then it makes sense.
The comments in the "identity ipv4-acl" is enough to describe the identity.
Same with the identity ipv6-acl.
I find it is very confusing to have the recursive reference of identity (all of
them are simply the description).
My two cents,
Linda
-Original Message-
From: Juergen Schoenwaelder [mailto:j.schoenwael...@jacobs-university.de]
Sent: Monday, May 09, 2016 11:24 PM
To: Linda Dunbar
Cc: draft-ietf-netmod-acl-mo...@ietf.org; 'netmod@ietf.org'; Thomas D. Nadeau
Subject: Re: Can you remove the "Identity acl-base" defined in
draft-ietf-netmod-acl-model-07
Linda,
the identityref type in YANG can be scoped to a base identity. This allows to
restrict an indentityref to a certain set of identities.
See 6020 section 7.16.3 and section 9.10.5 for an example.
The ACL draft follows the model described in RFC 6020 and defines
typedef acl-type {
type identityref {
base acl-base;
}
}
which restricts acl-type to any identity directly or indirectly derived from
acl-base. If you remove acl-base, then acl-type could refer to any identity,
which includes identities that have nothing to do with ACLs.
/js
On Tue, May 10, 2016 at 03:43:38AM +, Linda Dunbar wrote:
> Dear Authors:
>
> The "acl-base" identity defined in your draft is empty (i.e. only with a
> description) . Then you define "ipv4-acl" to be "acl-base". So basically you
> inherited the comments twice.
>
> identity acl-base {
> description
> "Base Access Control List type for all Access Control List type
> identifiers."; } identity ipv4-acl { base acl:acl-base; description
> "ACL that primarily matches on fields from the IPv4 header (e.g. IPv4
> destination address) and layer 4 headers (e.g. TCP destination port).
> An acl of type ipv4-acl does not contain matches on fields in the
> ethernet header or the IPv6 header."; } identity ipv6-acl { base
> acl:acl-base; description "ACL that primarily matches on fields from
> the IPv6 header (e.g. IPv6 destination address) and layer 4 headers
> (e.g. TCP destination port). An acl of type ipv6-acl does not contain
> matches on fields in the ethernet header or the IPv4 header."; }
>
>
> You really don't need to define the "acl-base". What is the impact if
> defining the "ipv4-acl" and "ipv6-acl" as follows?
>
> identity ipv4-acl {
>description
>"ACL that primarily matches on fields from the IPv4 header
>(e.g. IPv4 destination address) and layer 4 headers (e.g. TCP
>destination port). An acl of type ipv4-acl does not contain
>matches on fields in the ethernet header or the IPv6 header."; }
> identity ipv6-acl {
>description
>"ACL that primarily matches on fields from the IPv6 header
>(e.g. IPv6 destination address) and layer 4 headers (e.g. TCP
>destination port). An acl of type ipv6-acl does not contain
>matches on fields in the ethernet header or the IPv4 header."; }
>
>
> Thanks, Linda Dunbar
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax: +49 421 200 3103 <http://www.jacobs-university.de/>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
[netmod] Can you remove the "Identity acl-base" defined in draft-ietf-netmod-acl-model-07
Dear Authors:
The "acl-base" identity defined in your draft is empty (i.e. only with a
description) . Then you define "ipv4-acl" to be "acl-base". So basically you
inherited the comments twice.
identity acl-base {
description
"Base Access Control List type for all Access Control List type
identifiers.";
}
identity ipv4-acl {
base acl:acl-base;
description
"ACL that primarily matches on fields from the IPv4 header
(e.g. IPv4 destination address) and layer 4 headers (e.g. TCP
destination port). An acl of type ipv4-acl does not contain
matches on fields in the ethernet header or the IPv6 header.";
}
identity ipv6-acl {
base acl:acl-base;
description
"ACL that primarily matches on fields from the IPv6 header
(e.g. IPv6 destination address) and layer 4 headers (e.g. TCP
destination port). An acl of type ipv6-acl does not contain
matches on fields in the ethernet header or the IPv4 header.";
}
You really don't need to define the "acl-base". What is the impact if defining
the "ipv4-acl" and "ipv6-acl" as follows?
identity ipv4-acl {
description
"ACL that primarily matches on fields from the IPv4 header
(e.g. IPv4 destination address) and layer 4 headers (e.g. TCP
destination port). An acl of type ipv4-acl does not contain
matches on fields in the ethernet header or the IPv6 header.";
}
identity ipv6-acl {
description
"ACL that primarily matches on fields from the IPv6 header
(e.g. IPv6 destination address) and layer 4 headers (e.g. TCP
destination port). An acl of type ipv6-acl does not contain
matches on fields in the ethernet header or the IPv4 header.";
}
Thanks, Linda Dunbar
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
[netmod] Is there any common module (like library module) for matching all IPv4 or IPv6 header fields?
Dear YANG Model experts: Draft-ietf-netmod-acl-model-07 has matching criteria for Destination Address and Source for IPv4 and IPv6 respectively, like: [cid:image001.png@01D1A720.430CA7F0] IDR FlowSpec also has defined YANG model for matching criteria for IPv6/ IPv4-prefix plus other header fields. I2RS Filter Based RIB also define various header matching. Is there a common library module that can be called when any IP header fields need to be used as matching criteria? Thanks, Linda Dunbar ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
[netmod] more Questions about draft-ietf-netmod-acl-model-03
Dean, et al,
I have a few questions about the draft:
1. Does the following statement in the Section 7 IANA Consideration make
"ietf-acl" equivalent to the long name
"urn:ietf:params:xml:ns:yang:ietf-access-control-list"?
urn:ietf:params:xml:ns:yang:ietf-access-control-list prefix: ietf-acl
If the answer is YES, can the example in Section 4.3 can use "ietf-acl"
directly instead of the long name?
i.e.
Does the "1" in ":1.0" above mean "yang-version 1" defined in the "module
ietf-access-control-list"? what about the "0" a?
2. The beginning of the module has "prefix acl". Does it mean that "acl"
is equivalent to "ietf-access-control-list"?
file "ietf-access-control-l...@2015-05-03.yang"
module ietf-access-control-list {
yang-version 1;
namespace "urn:ietf:params:xml:ns:yang:ietf-access-control-list";
prefix acl;
3. With "prefix acl" listed right after the "namespace", does the acl in
"ietf-acl:acl" (in Appendix A.1) actually mean the whole name space?
Thanks, Linda
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
[netmod] Question about draft-ietf-netmod-acl-model-03
Dean, et al, Does the following statement in the Section 7 IANA Consideration make "ietf-acl" equivalent to the long name "urn:ietf:params:xml:ns:yang:ietf-access-control-list"? urn:ietf:params:xml:ns:yang:ietf-access-control-list prefix: ietf-acl If the answer is YES, can the example in Section 4.3 can use "ietf-acl" directly instead of the long name? i.e. What does the ":1.0" mean in the example? Thanks, Linda ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] [I2nsf] Further Narrowing the I2NSF scope: the new charter for IETF 93
Thanks Dan, Myo, Diego, Xiao Jun, Frank and Zing's suggestions. p.s. I had to check dictionary for "bespoke" too. Synonyms<http://en.wikipedia.org/wiki/Synonym> are "custom-made", "made to order", and "made to measure<http://en.wikipedia.org/wiki/Made_to_measure>", which is a very accurate description. I will update the charter per your suggestions, Linda From: I2nsf [mailto:i2nsf-boun...@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: Monday, May 11, 2015 3:44 AM To: Zarny, Myo; Linda Dunbar; 'i2...@ietf.org'; 'Kathleen Moriarty' Cc: 'i...@ietf.org'; 'd...@ietf.org'; 'netmod@ietf.org' Subject: Re: [I2nsf] Further Narrowing the I2NSF scope: the new charter for IETF 93 I am fine with the editing proposed by Myo as it makes the scope more clear. Maybe the only thing I would suggest is to use 'non-standard' rather than 'bespoke' which may puzzle the non-native English speakers. I had to go to the dictionary to see what it exactly means (but it may be only me!). Mentioning another SDO in the charter is actually fine as long as it points to the fact that we are aiming to work in cooperation with other SDOs and avoid duplicating work. In this case we say at the end that we plan to cooperate with ETSI, so keeping explicit mentioning out of the introduction is fine. Thanks and Regards, Dan From: I2nsf [mailto:i2nsf-boun...@ietf.org] On Behalf Of Zarny, Myo Sent: Saturday, May 09, 2015 6:55 PM To: 'Linda Dunbar'; 'i2...@ietf.org'; 'Kathleen Moriarty' Cc: 'i...@ietf.org'; 'd...@ietf.org'; 'netmod@ietf.org' Subject: Re: [I2nsf] Further Narrowing the I2NSF scope: the new charter for IETF 93 Hi Linda, Thanks very much for putting this together. I agree that the scope needs to be tightened if it is to be meaningful. I'm fine with the suggested deliverables, milestones, etc. BUT we should tweak the first two paragraphs related to the goal of the WG. I2NSF shouldn't take a position on where the security functions are hosted or if the caller and the security service function belong to the same or different domains. Also, not sure if we should bring in another organization's name (ETSI) into an IETF charter. I've taken a stab at rewording the first few paragraphs... Network security functions (NSFs) are increasingly provided and consumed in increasingly diverse environments. Users of NSFs could consume network security services hosted by one or more providers, which may be their own enterprise, service providers, or a combination of both. Likewise, service providers may offer their customers network security services that consist of multiple security products from different vendors. Yet because no widely accepted industry standard security interfaces exist today, management of NSFs (device and policy provisioning, monitoring, etc.) tends to be bespoke, essentially as offered by product vendors. As a result, automation of such services, if it exists at all, is also bespoke. The primary goal of I2NSF is to define a set of interfaces and data models for policy provisioning and management aspects of NSFs. Other aspects of NSFs such as device or network provisioning are out of scope. The scope of I2NSF can be further divided into two layers: * I2NSF Capabilities Layer * I2NSF Services Layer ... I've made a few comments inline below as well. I'm not familiar with how detailed a charter needs to be, so I'll leave it others to comment on whether the level of detail here is sufficient, too much or too light. Myo From: I2nsf [mailto:i2nsf-boun...@ietf.org] On Behalf Of Linda Dunbar Sent: 7 May 2015 11:53 AM To: i2...@ietf.org<mailto:i2...@ietf.org>; Kathleen Moriarty Cc: i...@ietf.org<mailto:i...@ietf.org>; d...@ietf.org<mailto:d...@ietf.org>; netmod@ietf.org<mailto:netmod@ietf.org> Subject: [I2nsf] Further Narrowing the I2NSF scope: the new charter for IETF 93 Thanks to I2NSF contributors for the good progresses made since IETF92 side meetings. Among the two I2NSF interfaces, i.e. the client facing Service Interface and the NSF facing Capability Interface, the work to be done at the Capability Interface becomes very clear and concrete. But the Service Interface is still a little vague. The feedback from last IETF side meetings was "the scope is too big for one IETF WG". Therefore, we are leaning towards narrowing the I2NSF scope to the Capability Interface. The thinking logic is: Once the Capability Interface is completed, we will see more clearly the work for Service interface. Even if Capability layer alone is standardized, it is a giant leap forward in building blocks for Service Provider to automate their Security Controller that can utilize NSF by multiple vendors Here is the narrower sco
[netmod] secure communication channel to exchange security policy and monitor execution status for I2NSF (was RE: [I2nsf] Further Narrowing the I2NSF scope: the new charter for IETF 93
Da Cheng, You stated that the bullet for “The proper secure communication channels to carry the security policies between Controller and NSFs” is trivial. But SACM is considering using XMPP to exchange data among end devices (instead of NETCONF): see https://datatracker.ietf.org/doc/draft-salowey-sacm-xmpp-grid/ So there might be more than simple NETCONF, may be TLS +xxx have to be considered. Linda From: Dacheng Zhang [mailto:dacheng@alibaba-inc.com] Sent: Tuesday, May 12, 2015 10:55 PM To: Linda Dunbar; i2...@ietf.org; Kathleen Moriarty Cc: i...@ietf.org; d...@ietf.org; netmod@ietf.org Subject: Re: [I2nsf] Further Narrowing the I2NSF scope: the new charter for IETF 93 Hi，Linda: I like the current version of charter, which clarifies a reasonable scope of this work. Some tiny comments. The concrete work at the L2NSF Capability Layer includes - The informational & data models for each category to be represented to virtual or physical network security functions, - The capability registry (IANA) of policy provisioning capability to flow based security function, and - The proper secure communication channels to carry the security policies between Controller and NSFs. >>Dacheng: the third bullet is quite trival compared with the first two >>bullets, since we will try to re-use the work of I2RS,Netconf where the >>generation of security channels have already considered. So, maybe we could >>remove it. The capability registry is to make it feasible to categorize network security functions provided by different vendors based on security policy provisioning capability without any need to standardize security functions themselves. Standard provisioning capability interface is an essential building block for Security Service Provider to automate their Security Controllers that can utilize NSF by multiple vendors. This layer will leverage the existing protocols and data models defined by I2RS, Netconf, and NETMOD. >>Dacheng: I suggest to change the last sentence to “In this layer, we will >>leverage the existing protocols and data models defined by I2RS, Netconf, and >>NETMOD as much as possible.” Similar to I2RS focusing on the interface to RIB/FIB even though most routers provide far more functions than RIB/FIB, the I2NSF focused functions can be a portion of features supported by vendors’ specific devices. >>Dacheng: the first part of this sentence is redundant. We don’t have to imply >>that “we work in this way because I2RS used to do similar things. So if you >>want to challenge us, please challenge I2RS first”. Maybe we could remove it. 发件人: Linda Dunbar mailto:linda.dun...@huawei.com>> 日期: 2015年5月7日 星期四 下午11:53 至: "i2...@ietf.org<mailto:i2...@ietf.org>" mailto:i2...@ietf.org>>, Kathleen Moriarty mailto:kathleen.moriarty.i...@gmail.com>> 抄送: "i...@ietf.org<mailto:i...@ietf.org>" mailto:i...@ietf.org>>, "d...@ietf.org<mailto:d...@ietf.org>" mailto:d...@ietf.org>>, "netmod@ietf.org<mailto:netmod@ietf.org>" mailto:netmod@ietf.org>> 主题: [I2nsf] Further Narrowing the I2NSF scope: the new charter for IETF 93 Thanks to I2NSF contributors for the good progresses made since IETF92 side meetings. Among the two I2NSF interfaces, i.e. the client facing Service Interface and the NSF facing Capability Interface, the work to be done at the Capability Interface becomes very clear and concrete. But the Service Interface is still a little vague. The feedback from last IETF side meetings was "the scope is too big for one IETF WG". Therefore, we are leaning towards narrowing the I2NSF scope to the Capability Interface. The thinking logic is: Once the Capability Interface is completed, we will see more clearly the work for Service interface. Even if Capability layer alone is standardized, it is a giant leap forward in building blocks for Service Provider to automate their Security Controller that can utilize NSF by multiple vendors Here is the narrower scoped I2NSF charter. Your comments and suggestions are greatly appreciated. CC’ed to DOTS, I2RS, and Netmod groups for wider review. Enterprises, residential, and mobile customers are increasingly consuming network functions, especially network security related functions that are not running on their premises. In addition, the European Telecommunications Standards Institute (ETSI) Network Function Virtualization (NFV) initiative creates new management challenges for security policies to be enforced by distributed, virtual, network security functions (vNSF). Without standard interface to express, monitor, and manage security policies to security functions deployed at different premises, it becomes virtually impossible for security service providers to automate the service offering utilizing secur
