draft-ietf-i2nsf-capability-data-model-02.txt		draft-ietf-i2nsf-capability-data-model-03.txt
	I2NSF Working Group S. Hares		I2NSF Working Group S. Hares
	Internet-Draft Huawei		Internet-Draft Huawei
	Intended status: Standards Track J. Jeong		Intended status: Standards Track J. Jeong
	Expires: May 8, 2019 J. Kim		Expires: September 12, 2019 J. Kim
	Sungkyunkwan University		Sungkyunkwan University
	R. Moskowitz		R. Moskowitz
	HTT Consulting		HTT Consulting
	Q. Lin		Q. Lin
	Huawei		Huawei
	November 4, 2018		March 11, 2019
	I2NSF Capability YANG Data Model		I2NSF Capability YANG Data Model
	draft-ietf-i2nsf-capability-data-model-02		draft-ietf-i2nsf-capability-data-model-03
	Abstract		Abstract
	This document defines a YANG data model for capabilities that enable		This document defines a YANG data model for capabilities of various
	a user to control various Network Security Functions (NSFs) in the		Network Security Functions (NSFs) in Interface to Network Security
	framework for Interface to Network Security Functions (I2NSF).		Functions (I2NSF) framework to cetrally manage capabilities of varios
			NSFs.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on May 8, 2019.		This Internet-Draft will expire on September 12, 2019.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 IETF Trust and the persons identified as the		Copyright (c) 2019 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4		2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
	3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3.1. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 4		3.1. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 4
	4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5		4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
	5. The Structure and Objective of NSF Capabilities . . . . . . . 6		5. YANG Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 6
	5.1. Generic Network Security Function Identification . . . . 6		5.1. Capabilities of Network Security Function . . . . . . . . 6
	5.2. Event Capabilities . . . . . . . . . . . . . . . . . . . 6		6. YANG Data Modules . . . . . . . . . . . . . . . . . . . . . . 8
	5.3. Condition Capabilities . . . . . . . . . . . . . . . . . 7		6.1. I2NSF Capability YANG Data Module . . . . . . . . . . . . 9
	5.4. Action Capabilities . . . . . . . . . . . . . . . . . . . 7		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
	5.5. Resolution Strategy Capabilities . . . . . . . . . . . . 7		8. Security Considerations . . . . . . . . . . . . . . . . . . . 37
	5.6. Default Action Capabilities . . . . . . . . . . . . . . . 8		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 37
	5.7. RPC for Acquiring Appropriate Network Security Function . 8		9.1. Normative References . . . . . . . . . . . . . . . . . . 37
	6. Data Model Structure . . . . . . . . . . . . . . . . . . . . 8		9.2. Informative References . . . . . . . . . . . . . . . . . 39
	6.1. Network Security Function Identification . . . . . . . . 8		Appendix A. Changes from draft-ietf-i2nsf-capability-data-
	6.2. Capabilities of Generic Network Security Function . . . . 9		model-02 . . . . . . . . . . . . . . . . . . . . . . 40
	6.2.1. Event Capabilities . . . . . . . . . . . . . . . . . 10		Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 40
	6.2.2. Condition Capabilities . . . . . . . . . . . . . . . 12		Appendix C. Contributors . . . . . . . . . . . . . . . . . . . . 40
	6.2.3. Action Capabilities . . . . . . . . . . . . . . . . . 14		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41
	6.2.4. Resolution Strategy Capabilities . . . . . . . . . . 16
	6.2.5. Capabilities of Advanced Network Security Function . 16
	6.2.6. Content Security Capabilities . . . . . . . . . . . . 17
	6.2.7. Attack Mitigation Capabilities . . . . . . . . . . . 18
	6.2.8. RPC for Acquiring Appropriate Network Security
	Function . . . . . . . . . . . . . . . . . . . . . . 19
	7. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 20
	7.1. I2NSF Capability YANG Data Module . . . . . . . . . . . . 20
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 57
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 57
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 57
	10.1. Normative References . . . . . . . . . . . . . . . . . . 57
	10.2. Informative References . . . . . . . . . . . . . . . . . 57
	Appendix A. Example: Extended VoIP-VoLTE Security Function
	Capabilities Module . . . . . . . . . . . . . . . . 59
	Appendix B. Example: Configuration XML of Capability Module . . 60
	B.1. Example: Configuration XML of Generic Network Security
	Function Capabilities . . . . . . . . . . . . . . . . . . 60
	B.2. Example: Configuration XML of Extended VoIP/VoLTE
	Security Function Capabilities Module . . . . . . . . . . 62
	Appendix C. Changes from draft-ietf-i2nsf-capability-data-
	model-01 . . . . . . . . . . . . . . . . . . . . . . 63
	Appendix D. Acknowledgments . . . . . . . . . . . . . . . . . . 64
	Appendix E. Contributors . . . . . . . . . . . . . . . . . . . . 64
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 64
	1. Introduction		1. Introduction
	As the industry becomes more sophisticated and network devices (e.g.,		As the industry becomes more sophisticated and network devices (e.g.,
	Internet of Things, Self-driving vehicles, and VoIP/VoLTE		Internet of Things, Self-driving vehicles, and VoIP/VoLTE
	smartphones), service providers have a lot of problems mentioned in		smartphones), service providers have a lot of problems mentioned in
	[RFC8192]. To resolve these problems, [i2nsf-nsf-cap-im] specifies		[RFC8192]. To resolve these problems, [i2nsf-nsf-cap-im] specifies
	the information model of the capabilities of Network Security		the information model of the capabilities of Network Security
	Functions (NSFs).		Functions (NSFs).
	This document provides a data model using YANG [RFC6020][RFC7950]		This document provides a data model using YANG [RFC6020][RFC7950]
	that defines the capabilities of NSFs to express capabilities of		that defines the capabilities of NSFs to centrally manage
	those security devices. This YANG data model is based on the		capabilities of those security devices. The security devices can
	information model for I2NSF NSF capabilities [i2nsf-nsf-cap-im]. The		register their own capabilities into Network Operator Management
	security devices can register their own capabilities into Network		(Mgmt) System (i.e., Security Controller) with this YANG data model
	Operator Management (Mgmt) System (i.e., Security Controller) with		through the registration interface [RFC8329]. With the capabilities
	this YANG data model through the registration interface [RFC8329].		of those security devices registered centrally, those security
	After the capabilities of the NSFs are registered, this YANG data		devices can be easily managed [RFC8329]. This YANG data model is
	model can be used by the IN2SF user or Service Function Forwarder		based on the information model for I2NSF NSF capabilities
	(SFF) [i2nsf-sfc] to acquire appropriate NSFs that can be controlled		[i2nsf-nsf-cap-im].
	by the Network Operator Mgmt System.
	The "Event-Condition-Action" (ECA) policy model is used as the basis		This YANG data model uses an "Event-Condition-Action" (ECA) policy
	for the design of I2NSF Policy Rules. The "ietf-i2nsf-capability"		model that is used as the basis for the design of I2NSF Policy
	YANG module defined in this document provides the following features:		described in [RFC8329] and [i2nsf-nsf-cap-im]. Rules. The "ietf-
			i2nsf-capability" YANG module defined in this document provides the
			following features:
	o Configuration of identification for generic network security		o Definition for general capabilities of network security functions.
	function policy
	o Configuration of event capabilities for generic network security		o Definition for event capabilities of generic network security
	function policy		function.
	o Configuration of condition capabilities for generic network		o Definition for condition capabilities of generic network security
	security function policy		function.
	o Configuration of action capabilities for generic network security		o Definition for condition capabilities of advanced network security
	function policy		function.
	o Configuration of strategy capabilities for generic network		o Definition for action capabilities of generic network security
	security function policy		function.
	o Configuration of default action capabilities for generic network		o Definition for resolution strategy capabilities of generic network
	security function policy		security function.
	o RPC for acquiring appropriate network security function according		o Definition for default action capabilities of generic network
	to type of NSF and/or target devices.		security function.
	2. Requirements Language		2. Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119][RFC8174].
	3. Terminology		3. Terminology
	This document uses the terminology described in		This document uses the terminology described in
	[i2nsf-terminology][i2nsf-nsf-cap-im]		[i2nsf-terminology][i2nsf-nsf-cap-im]
	[RFC8431][supa-policy-info-model]. Especially, the following terms		[RFC8431][supa-policy-info-model]. Especially, the following terms
	are from [supa-policy-info-model]:		are from [supa-policy-info-model]:
	o Data Model: A data model is a representation of concepts of		o Data Model: A data model is a representation of concepts of
	interest to an environment in a form that is dependent on data		interest to an environment in a form that is dependent on data
	skipping to change at page 4, line 35 ¶		skipping to change at page 4, line 9 ¶
	o Information Model: An information model is a representation of		o Information Model: An information model is a representation of
	concepts of interest to an environment in a form that is		concepts of interest to an environment in a form that is
	independent of data repository, data definition language, query		independent of data repository, data definition language, query
	language, implementation language, and protocol.		language, implementation language, and protocol.
	3.1. Tree Diagrams		3.1. Tree Diagrams
	A simplified graphical representation of the data model is used in		A simplified graphical representation of the data model is used in
	this document. The meaning of the symbols in these diagrams		this document. The meaning of the symbols in these diagrams
	[RFC8431] is as follows:		[RFC8340] is as follows:
	o Brackets "[" and "]" enclose list keys.		o Brackets "[" and "]" enclose list keys.
	o Abbreviations before data node names: "rw" means configuration		o Abbreviations before data node names: "rw" means configuration
	(read-write) and "ro" state data (read-only).		(read-write) and "ro" state data (read-only).
	o Symbols after data node names: "?" means an optional node and "*"		o Symbols after data node names: "?" means an optional node and "*"
	denotes a "list" and "leaf-list".		denotes a "list" and "leaf-list".
	o Parentheses enclose choice and case nodes, and case nodes are also		o Parentheses enclose choice and case nodes, and case nodes are also
	marked with a colon (":").		marked with a colon (":").
	o Ellipsis ("...") stands for contents of subtrees that are not		o Ellipsis ("...") stands for contents of subtrees that are not
	shown.		shown.
	4. Overview		4. Overview
	This section explains overview how the YANG data model can be used by		This section explains overview how the YANG data model can be used in
	I2NSF User, Developer's Mgmt System, and SFF. Figure 1 shows		I2NSF framework described in [RFC8329]. Figure 1 shows capabilities
	capabilities of NSFs in I2NSF Framework. As shown in this figure,		of NSFs in I2NSF Framework. As shown in this figure, Developer's
	Developer's Mgmt System can register NSFs with capabilities that the		Mgmt System can register NSFs with capabilities that the network
	device can support. To register NSFs in this way, the Developer's		security device can support. To register NSFs in this way, the
	Mgmt System utilizes this standardized capabilities YANG data model		Developer's Mgmt System utilizes this standardized capabilities YANG
	through registration interface. Through this registration of		data model through registration interface. With the capabilities of
	capabilities, the a lot of problems [RFC8192] can be resolved. The		those network security devices registered centrally, those security
	following shows use cases.		devices can be easily managed, which can resolve the a lot of
			problems described in [RFC8192]. The following shows use cases.
	Note [i2nsf-nsf-yang] is used to configure rules of NSFs in I2NSF		Note [i2nsf-nsf-yang] is used to configure security policy rules of
	Framework.		generic network security functions and [i2nsf-advanced-nsf-dm] is
			used to configure security policy rules of advanced network security
			functions according to the capabilities of network security devices
			registed in I2NSF Framework.
	+-------------------------------------------------------+		+-------------------------------------------------------+
	| I2NSF User (e.g., Overlay Network Mgmt, Enterprise |		| I2NSF User (e.g., Overlay Network Mgmt, Enterprise |
	| Network Mgmt, another network domain's mgmt, etc.) |		| Network Mgmt, another network domain's mgmt, etc.) |
	+--------------------+----------------------------------+		+--------------------+----------------------------------+
	|		|
	Consumer-Facing Interface |		Consumer-Facing Interface |
	|		|
	| I2NSF		| I2NSF
	+-----------------+------------+ Registration +-------------+		+-----------------+------------+ Registration +-------------+
	skipping to change at page 5, line 51 ¶		skipping to change at page 5, line 36 ¶
	+-------+ +-------+ +-------+ +-------+		+-------+ +-------+ +-------+ +-------+
	NSF-1 NSF-m NSF-1 NSF-n		NSF-1 NSF-m NSF-1 NSF-n
	E = {} E = {user} E = {dev} E = {time}		E = {} E = {user} E = {dev} E = {time}
	C = {IPv4} C = {IPv6} C = {IPv4, IPv6} C = {IPv4}		C = {IPv4} C = {IPv6} C = {IPv4, IPv6} C = {IPv4}
	A = {Allow, Deny} A = {Allow, Deny} A = {Allow, Deny} A = {Allow, Deny}		A = {Allow, Deny} A = {Allow, Deny} A = {Allow, Deny} A = {Allow, Deny}
	Developer Mgmt System A Developer Mgmt System B		Developer Mgmt System A Developer Mgmt System B
	Figure 1: Capabilities of NSFs in I2NSF Framework		Figure 1: Capabilities of NSFs in I2NSF Framework
	o If I2NSF User wants to apply rules about blocking malicious users,		o If network manager wants to apply security policy rules about
	it is a tremendous burden to apply all of these rules to NSFs one		blocking malicious users, it is a tremendous burden to apply all
	by one. This problem can be resolved by standardizing the		of these rules to NSFs one by one. This problem can be resolved
	capabilities of NSFs. If I2NSF User wants to block malicious		by managing the capabilities of NSFs. If network manager wants to
	users with IPv6, I2NSF User sends the rules about blocking the		block malicious users with IPv6, network manager sends the
	users to Network Operator Mgmt System. When the Network Operator		security policy rules about blocking the users to Network Operator
	Mgmt System receives the rules, it sends that rules to appropriate		Mgmt System using I2NSF user (i.e., a web browser or a software).
	NSFs (i.e., NSF-m in Developer Mgmt System A and NSF-1 in		When the Network Operator Mgmt System receives the security policy
	Developer Mgmt System B) which can support the capabilities (i.e.,		rules, it automatically sends that security policy rules to
	IPv6). Therefore, I2NSF User need not consider NSFs where to		appropriate NSFs (i.e., NSF-m in Developer Mgmt System A and NSF-1
	apply the rules.		in Developer Mgmt System B) which can support the capabilities
			(i.e., IPv6). Therefore, I2NSF User need not consider NSFs where
			to apply the rules.
	o If NSFs find the malicious packets, it is a tremendous burden for		o If NSFs find the malicious packets, it is a tremendous burden for
	I2NSF User to apply the rule about blocking the malicious packets		network manager to apply the rule about blocking the malicious
	to NSFs one by one. This problem can be resolved by standardizing		packets to NSFs one by one. This problem can be resolved by
	the capabilities of NSFs. If NSFs find the malicious packets with		managing the capabilities of NSFs. If NSFs find the suspicious
	IPv4, they can ask the Network Operator Mgmt System to alter		packets with IPv4, they can ask the Network Operator Mgmt System
			for information about the suspicious packets with IPv4. to alter
	specific rules and/or configurations. When the Network Operator		specific rules and/or configurations. When the Network Operator
	Mgmt System receives the rules for malicious packets, it inspects		Mgmt System receives information, it inspects the information
	whether the rules are reasonable and sends the rules to		about the suspicious packets with IPv4. If the suspicious packets
	appropriate NSFs (i.e., NSF-1 in Developer Mgmt System A and NSF-1		are determined to be malicious packets, the Network Operator Mgmt
	and NSF-n in Developer Mgmt System B) which can support the		System creates and sends the security policy rule against
	capabilities (i.e., IPv4). Therefore, the new rules can be		malicious packets to appropriate NSFs (i.e., NSF-1 in Developer
	applied to appropriate NSFs without control of I2NSF USer.		Mgmt System A and NSF-1 and NSF-n in Developer Mgmt System B)
			which can support the capabilities (i.e., IPv4). Therefore, the
	o If NSFs of Service Function Chaining (SFC) [i2nsf-sfc] fail, it is		new security policy rule against malicious packets can be applied
	a tremendous burden for I2NSF User to reconfigure the policy of		to appropriate NSFs without intervention of humans.
	SFC immediately. This problem can be resolved by periodically
	acquiring information of appropriate NSFs of SFC. If SFF needs
	information of Web Application Firewall for SFC, it can ask the
	Network Operator Mgmt System to acquire the location information
	of appropriate Web Application Firewall. When the Network
	Operator Mgmt System receives requested information from SFF, it
	sends location information of Web Application Firewall to the SFF.
	Therefore, the policy about the NSFs of SFC can be periodically
	updated without control of I2NSF USer.
	5. The Structure and Objective of NSF Capabilities
	5.1. Generic Network Security Function Identification
	This shows a identification for generic network security functions.
	These objects are defined as location information and target device
	information.
	5.2. Event Capabilities
	This shows a event capabilities for generic network security
	functions policy. This is used to specify capabilities about any
	important occurrence in time of a change in the system being managed,
	and/or in the environment of the system being managed. When used in
	the context of I2NSF Policy Rules, it is used to determine whether
	the Condition clause of the I2NSF Policy Rule can be evaluated or
	not. These object of event capabilities is defined as user security
	event capabilities, device security event capabilities, system
	security event capabilities, and time security event capabilities.
	These object of event capabilities can be extended according to
	specific vendor event features.
	5.3. Condition Capabilities
	This shows a condition capabilities for generic network security
	functions policy. This is used to specify capabilities about a set
	of attributes, features, and/or values that are to be compared with a
	set of known attributes, features, and/or values in order to
	determine whether or not the set of Actions in that (imperative)
	I2NSF Policy Rule can be executed or not. These object of condition
	capabilities is defined as packet security condition capabilities,
	packet payload security condition capabilities, target security
	condition capabilities, user security condition capabilities, context
	condition capabilities, and generic context condition capabilities.
	These object of condition capabilities can be extended according to
	specific vendor condition features.
	5.4. Action Capabilities
	This shows a action capabilities for generic network security
	functions policy. This is used to specify capabilities to control
	and monitor aspects of flow-based NSFs when the event and condition
	clauses are satisfied. NSFs provide security functions by executing
	various Actions. These object of action capabilities is defined as
	ingress action capabilities, egress action capabilities, and apply
	profile action capabilities. These object of action capabilities can
	be extended according to specific vendor action features.
	5.5. Resolution Strategy Capabilities
	This shows a resolution strategy capabilities for generic network
	security functions policy. This can be used to specify capabilities
	how to resolve conflicts that occur between the actions of the same
	or different policy rules that are matched and contained in this
	particular NSF. These objects are defined as first-matching-rule
	capability and last-matching-rule capability. These objects can be
	extended according to specific vendor resolution strategy features.
	5.6. Default Action Capabilities
	This shows a default action policy for generic network security
	functions. This can be used to specify capabilities about a
	predefined action when no other alternative action was matched by the
	currently executing I2NSF Policy Rule.
	5.7. RPC for Acquiring Appropriate Network Security Function
	This shows a RPC for acquiring an appropriate network security
	function according to type of NSF and/or target devices. If the SFF
	[i2nsf-sfc]does not have the location information of network security
	functions that it should send in own cache table, this can be used to
	acquire the information. These objects are defined as input data
	(i.e., NSF type and target devices) and output data (i.e., location
	information of NSF).
	6. Data Model Structure		5. YANG Tree Diagram
	This section shows an overview of a structure tree of capabilities		This section shows an YANG tree diagram of capabilities for network
	for generic network security functions, as defined in the		security functions, as defined in the [i2nsf-nsf-cap-im].
	[i2nsf-nsf-cap-im].
	6.1. Network Security Function Identification		5.1. Capabilities of Network Security Function
	The data model for network security function identification has the		This section shows YANG tree diagram for capabilities of network
	following structure:		security functions.
	module: ietf-i2nsf-capability		module: ietf-i2nsf-capability
	+--rw nsf* [nsf-name]		+--rw nsf
	+--rw nsf-name string		+--rw time-capabilities* enumeration
	+--rw nsf-type? nsf-type		+--rw event-capabilities
	+--rw nsf-address		| +--rw system-event-capa* identityref
	| +--rw (nsf-address-type)?		| +--rw system-alarm-capa* identityref
	| +--:(ipv4-address)		+--rw condition-capabilities
	| | +--rw ipv4-address inet:ipv4-address		| +--rw generic-nsf-capabilities
	| +--:(ipv6-address)		| | +--rw ipv4-capa* identityref
	| +--rw ipv6-address inet:ipv6-address		| | +--rw ipv6-capa* identityref
	+--rw target-device		| | +--rw tcp-capa* identityref
	| +--rw pc? boolean		| | +--rw udp-capa* identityref
	| +--rw mobile-phone? boolean		| | +--rw icmp-capa* identityref
	| +--rw voip-volte-phone? boolean		| +--rw advanced-nsf-capabilities
	| +--rw tablet? boolean		| +--rw antivirus-capa* identityref
	| +--rw iot? boolean		| +--rw antiddos-capa* identityref
	| +--rw vehicle? boolean		| +--rw ips-capa* identityref
	+--rw generic-nsf-capabilities		| +--rw http-capa* identityref
	| +--rw net-sec-capabilities		| +--rw voip-volte-capa* identityref
	| uses net-sec-caps		+--rw action-capabilities
	+--rw advanced-nsf-capabilities		| +--rw ingress-action-capa* identityref
	| +--rw advaneced-sec-capabilities		| +--rw egress-action-capa* identityref
	| uses advaneced-sec-caps		| +--rw log-action-capa* identityref
	+--rw complete-nsf-capabilities		+--rw resolution-strategy-capabilities* identityref
	+--rw con-sec-control-capabilities		+--rw default-action-capabilities* identityref
	| uses i2nsf-con-sec-control-caps
	+--rw attack-mitigation-capabilities
	uses i2nsf-attack-mitigation-control-caps
	Figure 2: Data Model Structure for NSF-Identification
	This document also utilizes a formal model for policy reconciliation
	proposed by Basile et al. [Policy-Reconciliation], which handles
	conflict resolution, the use of external data, and target device.
	The nsf-type object can be used for configuration about type of a
	NSF. The types of NSF consists of Network Firewall, Web Application
	Firewall, Anti-Virus, IDS, IPS, and DDoS Mitigator. The nsf-address
	object can be used for configuration about location of a NSF. The
	target-device object can be used for configuration about target
	devices. We will add additional type of a NSF for more generic
	network security functions.
	6.2. Capabilities of Generic Network Security Function
	The data model for Generic NSF capabilities has the following
	structure:
	+--rw generic-nsf-capabilities
	+--rw net-sec-capabilities
	uses i2nsf-net-sec-caps
	Figure 3: Data Model Structure for Capabilities of Network Security
	Function
	6.2.1. Event Capabilities
	The data model for event capabilities has the following structure:
	+--rw i2nsf-net-sec-caps
	+--rw net-sec-capabilities
	+--rw time
	| +--rw time-zone
	| | +--rw time-zone-offset? boolean
	| +--rw time-inteval
	| +--rw absolute-time-inteval
	| | +--rw start-time? boolean
	| | +--rw end-time? boolean
	| +--rw periodic-time-inteval
	| +--rw day? boolean
	| +--rw month? boolean
	+--rw event
	| +--rw usr-event
	| | +--rw usr-sec-event-content? boolean
	| | +--rw usr-sec-event-format
	| | | +--rw unknown? boolean
	| | | +--rw guid? boolean
	| | | +--rw uuid? boolean
	| | | +--rw uri? boolean
	| | | +--rw fqdn? boolean
	| | | +--rw fqpn? boolean
	| | +--rw usr-sec-event-type
	| | +--rw unknown? boolean
	| | +--rw user-created? boolean
	| | +--rw user-grp-created? boolean
	| | +--rw user-deleted? boolean
	| | +--rw user-grp-deleted? boolean
	| | +--rw user-logon? boolean
	| | +--rw user-logoff? boolean
	| | +--rw user-access-request? boolean
	| | +--rw user-access-granted? boolean
	| | +--rw user-access-violation? boolean
	| +--rw dev-event
	| | +--rw dev-sec-event-content boolean
	| | +--rw dev-sec-event-format
	| | | +--rw unknown? boolean
	| | | +--rw guid? boolean
	| | | +--rw uuid? boolean
	| | | +--rw uri? boolean
	| | | +--rw fqdn? boolean
	| | | +--rw fqpn? boolean
	| | +--rw dev-sec-event-type
	| | | +--rw unknown? boolean
	| | | +--rw comm-alarm? boolean
	| | | +--rw quality-of-service-alarm? boolean
	| | | +--rw process-err-alarm? boolean
	| | | +--rw equipment-err-alarm? boolean
	| | | +--rw environmental-err-alarm? boolean
	| | +--rw dev-sec-event-type-severity
	| | +--rw unknown? boolean
	| | +--rw cleared? boolean
	| | +--rw indeterminate? boolean
	| | +--rw critical? boolean
	| | +--rw major? boolean
	| | +--rw minor? boolean
	| | +--rw warning? boolean
	| +--rw sys-event
	| | +--rw sys-sec-event-content? boolean
	| | +--rw sys-sec-event-format
	| | | +--rw unknown? boolean
	| | | +--rw guid? boolean
	| | | +--rw uuid? boolean
	| | | +--rw uri? boolean
	| | | +--rw fqdn? boolean
	| | | +--rw fqpn? boolean
	| | +--rw sys-sec-event-type
	| | +--rw unknown? boolean
	| | +--rw audit-log-written-to? boolean
	| | +--rw audit-log-cleared? boolean
	| | +--rw policy-created? boolean
	| | +--rw policy-edited? boolean
	| | +--rw policy-deleted? boolean
	| | +--rw policy-executed? boolean
	| +--rw time-event
	| +--rw time-sec-event-begin? boolean
	| +--rw time-sec-event-end? boolean
	| +--rw time-sec-event-time-zone? boolean
	+--rw condition
	| ...
	+--rw action
	| ...
	+--rw resolution-strategy
	...
	Figure 4: Data Model Structure for Event Capabilities of Network
	Security Function
	These objects are defined as capabilities of user security event,
	device security event, system security event, and time security
	event. These objects can be extended according to specific vendor
	event features. We will add additional event objects for more
	generic network security functions.
	6.2.2. Condition Capabilities
	The data model for condition capabilities has the following
	structure:
	+--rw i2nsf-net-sec-caps
	+--rw net-sec-capabilities
	+--rw time
	| +--rw time-zone
	| | +--rw time-zone-offset? boolean
	| +--rw time-inteval
	| +--rw absolute-time-inteval
	| | +--rw start-time? boolean
	| | +--rw end-time? boolean
	| +--rw periodic-time-inteval
	| +--rw day? boolean
	| +--rw month? boolean
	+--rw event
	| ...
	+--rw condition
	| +--rw packet-security-condition
	| | +--rw packet-security-mac-condition
	| | | +--rw pkt-sec-cond-mac-dest? boolean
	| | | +--rw pkt-sec-cond-mac-src? boolean
	| | | +--rw pkt-sec-cond-mac-8021q? boolean
	| | | +--rw pkt-sec-cond-mac-ether-type? boolean
	| | | +--rw pkt-sec-cond-mac-tci? string
	| | +--rw packet-security-ipv4-condition
	| | | +--rw pkt-sec-cond-ipv4-header-length? boolean
	| | | +--rw pkt-sec-cond-ipv4-tos? boolean
	| | | +--rw pkt-sec-cond-ipv4-total-length? boolean
	| | | +--rw pkt-sec-cond-ipv4-id? boolean
	| | | +--rw pkt-sec-cond-ipv4-fragment? boolean
	| | | +--rw pkt-sec-cond-ipv4-fragment-offset? boolean
	| | | +--rw pkt-sec-cond-ipv4-ttl? boolean
	| | | +--rw pkt-sec-cond-ipv4-protocol? boolean
	| | | +--rw pkt-sec-cond-ipv4-src? boolean
	| | | +--rw pkt-sec-cond-ipv4-dest? boolean
	| | | +--rw pkt-sec-cond-ipv4-ipopts? boolean
	| | | +--rw pkt-sec-cond-ipv4-sameip? boolean
	| | | +--rw pkt-sec-cond-ipv4-geoip? boolean
	| | +--rw packet-security-ipv6-condition
	| | | +--rw pkt-sec-cond-ipv6-dscp? boolean
	| | | +--rw pkt-sec-cond-ipv6-ecn? boolean
	| | | +--rw pkt-sec-cond-ipv6-traffic-class? boolean
	| | | +--rw pkt-sec-cond-ipv6-flow-label? boolean
	| | | +--rw pkt-sec-cond-ipv6-payload-length? boolean
	| | | +--rw pkt-sec-cond-ipv6-next-header? boolean
	| | | +--rw pkt-sec-cond-ipv6-hop-limit? boolean
	| | | +--rw pkt-sec-cond-ipv6-src? boolean
	| | | +--rw pkt-sec-cond-ipv6-dest? boolean
	| | +--rw packet-security-tcp-condition
	| | | +--rw pkt-sec-cond-tcp-src-port? boolean
	| | | +--rw pkt-sec-cond-tcp-dest-port? boolean
	| | | +--rw pkt-sec-cond-tcp-seq-num? boolean
	| | | +--rw pkt-sec-cond-tcp-ack-num? boolean
	| | | +--rw pkt-sec-cond-tcp-window-size? boolean
	| | | +--rw pkt-sec-cond-tcp-flags? boolean
	| | +--rw packet-security-udp-condition
	| | | +--rw pkt-sec-cond-udp-src-port? boolean
	| | | +--rw pkt-sec-cond-udp-dest-port? boolean
	| | | +--rw pkt-sec-cond-udp-length? boolean
	| | +--rw packet-security-icmp-condition
	| | +--rw pkt-sec-cond-icmp-type? boolean
	| | +--rw pkt-sec-cond-icmp-code? boolean
	| | +--rw pkt-sec-cond-icmp-seg-num? boolean
	| +--rw packet-payload-condition
	| | +--rw pkt-payload-content? boolean
	| +--rw acl-number? boolean
	| +--rw application-condition
	| | +--rw application-object? boolean
	| | +--rw application-group? boolean
	| | +--rw application-label? boolean
	| | +--rw category
	| | +--rw application-category? boolean
	| +--rw target-condition
	| | +--rw device-sec-context-cond? boolean
	| +--rw users-condition
	| | +--rw user
	| | | +--rw (user-name)?
	| | | +--:(tenant)
	| | | | +--rw tenant? boolean
	| | | +--:(vn-id)
	| | | +--rw vn-id? boolean
	| | +--rw group
	| | +--rw (group-name)?
	| | | +--:(tenant)
	| | | | +--rw tenant? boolean
	| | | +--:(vn-id)
	| | | +--rw vn-id? boolean
	| | +--rw security-grup boolean
	| +--rw url-category-condition
	| | +--rw pre-defined-category? boolean
	| | +--rw user-defined-category? boolean
	| +--rw context-condition
	| | +--rw temp? string
	| +--rw gen-context-condition
	| +--rw geographic-location
	| +--rw src-geographic-location? boolean
	| +--rw dest-geographic-location? boolean
	+--rw action
	| ...
	+--rw resolution-strategy
	...
	Figure 5: Data Model Structure for Condition Capabilities of Network
	Security Function
	These objects are defined as capabilities of packet security
	condition, packet payload security condition, target security
	condition, user security condition, context condition, and generic
	context condition. These objects can be extended according to
	specific vendor condition features. We will add additional condition
	objects for more generic network security functions.
	6.2.3. Action Capabilities
	The data model for action capabilities has the following structure:
	+--rw i2nsf-net-sec-caps
	+--rw net-sec-capabilities
	+--rw time
	| +--rw time-zone
	| | +--rw time-zone-offset? boolean
	| +--rw time-inteval
	| +--rw absolute-time-inteval
	| | +--rw start-time? boolean
	| | +--rw end-time? boolean
	| +--rw periodic-time-inteval
	| +--rw day? boolean
	| +--rw month? boolean
	+--rw event
	| ...
	+--rw condition
	| ...
	+--rw action
	| +--rw rule-log? boolean
	| +--rw session-log? boolean
	| +--rw ingress-action
	| | +--rw ingress-action-type
	| | +--rw pass? boolean
	| | +--rw drop? boolean
	| | +--rw reject? boolean
	| | +--rw alert? boolean
	| | +--rw mirror? boolean
	| +--rw egress-action
	| +--rw egress-action-type
	| +--rw invoke-signaling? boolean
	| +--rw tunnel-encapsulation? boolean
	| +--rw forwarding? boolean
	| +--rw redirection? boolean
	+--rw resolution-strategy
	...
	Figure 6: Data Model Structure for Action Capabilities of Network
	Security Function
	These objects are defined capabilities as ingress action, egress
	action, and apply profile action. These objects can be extended
	according to specific vendor action feature. We will add additional
	action objects for more generic network security functions.
	6.2.4. Resolution Strategy Capabilities
	The data model for resolution strategy capabilities has the following
	structure:
	+--rw i2nsf-net-sec-caps
	+--rw net-sec-capabilities
	+--rw time
	| +--rw time-zone
	| | +--rw time-zone-offset? boolean
	| +--rw time-inteval
	| +--rw absolute-time-inteval
	| | +--rw start-time? boolean
	| | +--rw end-time? boolean
	| +--rw periodic-time-inteval
	| +--rw day? boolean
	| +--rw month? boolean
	+--rw event
	| ...
	+--rw condition
	| ...
	+--rw action
	| ...
	+--rw resolution-strategy
	+--rw first-matching-rule? boolean
	+--rw last-matching-rule? boolean
	Figure 7: Data Model Structure for Resolution Strategy Capabilities		Figure 2: YANG Tree Diagram for Capabilities of Network Security
	of Network Security Function		Functions
	These objects are defined capabilities as first-matching-rule and		This YANG tree diagram shows capabilities of network security
	last-matching-rule. These objects can be extended according to
	specific vendor resolution strategy features. We will add additional
	resolution strategy objects for more generic network security
	functions.		functions.
	6.2.5. Capabilities of Advanced Network Security Function		The NSF includes NSF capabilities. The NSF capabilities include time
			capabilities, event capabilities, condition capabilities, action
	The data model for advanced NSF capabilities has the following		capabilities, resolution strategy capabilities, and default action
	structure:		capabilities.
	+--rw advanced-nsf-capabilities
	| +--rw advanced-sec-capabilities
	| +--rw antivirus
	| | +--rw detect? boolean
	| | +--rw exception-application? boolean
	| | +--rw exception-signature? boolean
	| | +--rw whitelists? boolean
	| +--rw antiddos
	| | +--rw syn-flood-action? boolean
	| | +--rw udp-flood-action? boolean
	| | +--rw http-flood-action? boolean
	| | +--rw https-flood-action? boolean
	| | +--rw dns-request-flood-action? boolean
	| | +--rw dns-reply-flood-action? boolean
	| | +--rw icmp-flood-action? boolean
	| | +--rw sip-flood-action? boolean
	| | +--rw detect-mode? boolean
	| | +--rw baseline-learn? boolean
	| +--rw ips
	| +--rw signature-set? boolean
	| +--rw exception-signature? boolean
	...
	Figure 8: Data Model Structure for Capabilities of Advanced Network
	Security Function
	These objects are defined capabilities of advanced network security
	functions such as antivirus, antiddos, and ips. A detailed data
	model for the configuration of the advanced network security
	functions is described in [i2nsf-advanced-nsf-dm].
	6.2.6. Content Security Capabilities
	The data model for content security capabilities has the following
	structure:
	+--rw complete-nsf-capabilities
	+--rw con-sec-control-capabilities
	| +--rw anti-virus? boolean
	| +--rw ips? boolean
	| +--rw ids? boolean
	| +--rw url-filter? boolean
	| +--rw data-filter? boolean
	| +--rw mail-filter? boolean
	| +--rw sql-filter? boolean
	| +--rw file-blocking? boolean
	| +--rw file-isolate? boolean
	| +--rw pkt-capture? boolean
	| +--rw application-behavior? boolean
	| +--rw voip-volte? boolean
	+--rw attack-mitigation-capabilities
	...
	Figure 9: Data Model Structure for Content Security Capabilities of
	Network Security Function
	Content security is composed of a number of distinct security		Time capabilities are used to specify capabilities when to execute
	Capabilities; each such Capability protects against a specific type		the I2NSF policy rule. The time capabilities are defined as absolute
	of threat in the application layer. Content security is a type of		time and periodic time.
	Generic Network Security Function (GNSF), which summarizes a well-
	defined set of security Capabilities.
	6.2.7. Attack Mitigation Capabilities		Event capabilities are used to specify capabilities how to trigger
			the evaluation of the condition clause of the I2NSF Policy Rule. The
			event capabilities are defined as system event and system alarm. The
			event capability can be extended according to specific vendor
			condition features. The event capability is described in detail in
			[i2nsf-nsf-cap-im].
	The data model for attack mitigation capabilities has the following		Condition capabilities are used to specify capabilities of a set of
	structure:		attributes, features, and/or values that are to be compared with a
			set of known attributes, features, and/or values in order to
			determine whether or not the set of actions in that (imperative)
			I2NSF policy rule can be executed or not. The condition capability
			is classified as condition capabilities of generic network security
			functions and advanced network security functions. The condition
			capabilities of generic network security functions are defined as
			IPv4 capability, IPv6 capability, tcp capability, udp capability, and
			icmp capability. The condition capabilities of advanced network
			security functions are defined as antivirus capability, antiddos
			capability, ips capability, http capability, and VoIP/VoLTE
			capability. The condition capability can be extended according to
			specific vendor condition features. The condition capability is
			described in detail in [i2nsf-nsf-cap-im].
	+--rw complete-nsf-capabilities		Action capabilities is used to specify capabilities how to control
	...		and monitor aspects of flow-based NSFs when the event and condition
	+--rw attack-mitigation-capabilities		clauses are satisfied. The action capabilities are defined as
	+--rw (attack-mitigation-control-type)?		ingress action capability, egress action capability, and log action
	+--:(ddos-attack)		capability. The action capability can be extended according to
	| +--rw (ddos-attack-type)?		specific vendor action features. The action capability is described
	| +--:(network-layer-ddos-attack)		in detail in [i2nsf-nsf-cap-im].
	| | +--rw network-layer-ddos-attack-types
	| | +--rw syn-flood-attack? boolean
	| | +--rw udp-flood-attack? boolean
	| | +--rw icmp-flood-attack? boolean
	| | +--rw ip-fragment-flood-attack? boolean
	| | +--rw ipv6-related-attack? boolean
	| +--:(app-layer-ddos-attack)
	| +--rw app-layer-ddos-attack-types
	| +--rw http-flood-attack? boolean
	| +--rw https-flood-attack? boolean
	| +--rw dns-flood-attack? boolean
	| +--rw dns-amp-flood-attack? boolean
	| +--rw ssl-flood-attack? boolean
	+--:(single-packet-attack)
	+--rw (single-packet-attack-type)?
	+--:(scan-and-sniff-attack)
	| +--rw ip-sweep-attack? boolean
	| +--rw port-scanning-attack? boolean
	+--:(malformed-packet-attack)
	| +--rw ping-of-death-attack? boolean
	| +--rw teardrop-attack? boolean
	+--:(special-packet-attack)
	+--rw oversized-icmp-attack? boolean
	+--rw tracert-attack? boolean
	Figure 10: Data Model Structure for Attack Mitigation Capabilities of		Resolution strategy capabilities are used to specify capabilities how
	Network Security Function		to resolve conflicts that occur between the actions of the same or
			different policy rules that are matched and contained in this
			particular NSF. The resolution strategy capabilities are defined as
			First Matching Rule (FMR), Last Matching Rule (LMR), Prioritized
			Matching Rule (PMR) with Errors (PMRE), and Prioritized Matching Rule
			with No Errors (PMRN). The resolution strategy capability can be
			extended according to specific vendor action features. The
			resolution strategy capability is described in detail in
			[i2nsf-nsf-cap-im].
	Attack mitigation is composed of a number of GNSFs; each one protects		Default action capabilities are used to specify capabilities how to
	against a specific type of network attack. Attack Mitigation		execute I2NSF policy rule when no rule matches a packet. The default
	security is a type of GNSF, which summarizes a well-defined set of		action capabilities are defined as pass, drop, reject, alert, and
	security Capabilities.		mirror. The default action capability can be extended according to
			specific vendor action features. The default action capability is
			described in detail in [i2nsf-nsf-cap-im].
	6.2.8. RPC for Acquiring Appropriate Network Security Function		6. YANG Data Modules
			6.1. I2NSF Capability YANG Data Module
	The data model for RPC for Acquiring Appropriate Network Security		This section introduces an YANG data module for capabilities of
	Function has the following structure:		network security functions, as defined in the [i2nsf-nsf-cap-im].
	rpcs:		<CODE BEGINS> file "ietf-i2nsf-capability@2019-03-11.yang"
	+---x call-appropriate-nsf
	+---w input
	| +---w nsf-type nsf-type
	| +---w target-device
	| +---w pc? boolean
	| +---w mobile-phone? boolean
	| +---w voip-volte-phone? boolean
	| +---w tablet? boolean
	| +---w iot? boolean
	| +---w vehicle? boolean
	+--ro output
	+--ro nsf-address
	+--ro (nsf-address-type)?
	+--:(ipv4-address)
	| +--ro ipv4-address inet:ipv4-address
	+--:(ipv6-address)
	+--ro ipv6-address inet:ipv6-address
	Figure 11: RPC for Acquiring Appropriate Network Security Function		module ietf-i2nsf-capability {
			yang-version 1.1;
			namespace
			"urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability";
			prefix
			iicapa;
	This shows a RPC for acquiring an appropriate network security		organization
	function according to type of NSF and/or target devices. If the SFF		"IETF I2NSF (Interface to Network Security Functions)
	[i2nsf-sfc]does not have the location information of network security		Working Group";
	functions that it should send in own cache table, this can be used to
	acquire the information. These objects are defined as input data
	(i.e., NSF type and target devices) and output data (i.e., location
	information of NSF).
	7. YANG Modules		contact
			"WG Web: <http://tools.ietf.org/wg/i2nsf>
			WG List: <mailto:i2nsf@ietf.org>
	7.1. I2NSF Capability YANG Data Module		WG Chair: Adrian Farrel
			<mailto:Adrain@olddog.co.uk>
	This section introduces a YANG module for the information model of		WG Chair: Linda Dunbar
	network security functions, as defined in the [i2nsf-nsf-cap-im].		<mailto:Linda.duhbar@huawei.com>
	<CODE BEGINS> file "ietf-i2nsf-capability@2018-11-04.yang"		Editor: Susan Hares
			<mailto:shares@ndzh.com>
	module ietf-i2nsf-capability {		Editor: Jaehoon Paul Jeong
	namespace		<mailto:pauljeong@skku.edu>
	"urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability";
	prefix
	i2nsf-capability;
	import ietf-inet-types{		Editor: Jinyong Tim Kim
	prefix inet;		<mailto:timkim@skku.edu>";
	}
	organization
	"IETF I2NSF (Interface to Network Security Functions)
	Working Group";
	contact		description
	"WG Web: <http://tools.ietf.org/wg/i2nsf>		"This module describes a capability model
	WG List: <mailto:i2nsf@ietf.org>		for I2NSF devices.
	WG Chair: Adrian Farrel		Copyright (c) 2018 IETF Trust and the persons
	<mailto:Adrain@olddog.co.uk>		identified as authors of the code. All rights reserved.
	WG Chair: Linda Dunbar		Redistribution and use in source and binary forms, with or
	<mailto:Linda.duhbar@huawei.com>		without modification, is permitted pursuant to, and subject
			to the license terms contained in, the Simplified BSD License
			set forth in Section 4.c of the IETF Trust's Legal Provisions
			Relating to IETF Documents
			(http://trustee.ietf.org/license-info).
	Editor: Susan Hares		This version of this YANG module is part of RFC 8341; see
	<mailto:shares@ndzh.com>		the RFC itself for full legal notices.";
	Editor: Jaehoon Paul Jeong		revision "2019-03-11"{
	<mailto:pauljeong@skku.edu>		description "Initial revision.";
			reference
			"RFC XXXX: I2NSF Capability YANG Data Model";
			}
	Editor: Jinyong Tim Kim		/*
	<mailto:timkim@skku.edu>";		* Identities
			*/
			identity event {
	description		description
	"This module describes a capability model		"Base identity for event of policy.";
	for I2NSF devices.";		reference
			"draft-hong-i2nsf-nsf-monitoring-data-model-06
	revision "2018-11-04"{		- Event";
	description "The fifth revision";		}
	reference
	"draft-ietf-i2nsf-capability-04";
	}
	grouping i2nsf-nsf-location {
	description
	"This provides a location for capabilities.";
	container nsf-address {
	description
	"This is location information for capabilities.";
	choice nsf-address-type {
	description
	"nsf address type: ipv4 and ipv4";
	case ipv4-address {
	description
	"ipv4 case";
	leaf ipv4-address {
	type inet:ipv4-address;
	mandatory true;
	description
	"nsf address type is ipv4";
	}
	}
	case ipv6-address {
	description
	"ipv6 case";
	leaf ipv6-address {
	type inet:ipv6-address;
	mandatory true;
	description
	"nsf address type is ipv6";
	}
	}
	}
	}
	}
	typedef nsf-type {		identity system-event-capa {
	type enumeration {		base event;
	enum network-firewall {		description
	description		"Identity for system event";
	"If type of a NSF is Network Firewall.";		reference
	}		"draft-hong-i2nsf-nsf-monitoring-data-model-06
			- System alarm";
			}
	enum web-app-firewall {		identity system-alarm-capa {
	description		base event;
	"If type of a NSF is Web Application		description
	Firewall.";		"Identity for system alarm";
	}		reference
			"draft-hong-i2nsf-nsf-monitoring-data-model-06
			- System alarm";
			}
	enum anti-virus {		identity access-violation {
	description		base system-event-capa;
	"If type of a NSF is Anti-Virus";		description
	}		"Identity for access violation
			among system events";
	enum ids {		reference
	description		"draft-hong-i2nsf-nsf-monitoring-data-model-06
	"If type of a NSF is IDS.";		- System event";
	}		}
	enum ips {		identity configuration-change {
	description		base system-event-capa;
	"If type of a NSF is IPS.";		description
	}		"Identity for configuration change
	enum ddos-mitigator {		among system events";
	description		reference
	"If type of a NSF is DDoS Mitigator.";		"draft-hong-i2nsf-nsf-monitoring-data-model-06
	}		- System event";
	}		}
	description
	"This is used for type of NSF.";
	}
	grouping i2nsf-it-resources {		identity memory-alarm {
	description		base system-alarm-capa;
	"This provides a link between capabilities		description
	and IT resources. This has a list of IT resources		"Identity for memory alarm
	by name.";		among system alarms";
	container target-device {		reference
	description		"draft-hong-i2nsf-nsf-monitoring-data-model-06
	"it-resources";		- System alarm";
			}
	leaf pc {		identity cpu-alarm {
	type boolean;		base system-alarm-capa;
	description		description
	"If type of a device is PC.";		"Identity for cpu alarm
	}		among system alarms";
			reference
			"draft-hong-i2nsf-nsf-monitoring-data-model-06
			- System alarm";
			}
	leaf mobile-phone {		identity disk-alarm {
	type boolean;		base system-alarm-capa;
	description		description
	"If type of a device is mobile-phone.";		"Identity for disk alarm
	}		among system alarms";
			reference
			"draft-hong-i2nsf-nsf-monitoring-data-model-06
			- System alarm";
			}
	leaf voip-volte-phone {		identity hardware-alarm {
	type boolean;		base system-alarm-capa;
	description		description
	"If type of a device is voip-volte-phone.";		"Identity for hardware alarm
	}		among system alarms";
			reference
			"draft-hong-i2nsf-nsf-monitoring-data-model-06
			- System alarm";
			}
	leaf tablet {		identity interface-alarm {
	type boolean;		base system-alarm-capa;
	description		description
	"If type of a device is tablet.";		"Identity for interface alarm
	}		among system alarms";
			reference
			"draft-hong-i2nsf-nsf-monitoring-data-model-06
			- System alarm";
			}
	leaf iot {		identity condition {
	type boolean;		description
	description		"Base identity for conditions of policy";
	"If type of a device is Internet of Things.";		}
	}
	leaf vehicle {
	type boolean;
	description
	"If type of a device is vehicle.";
	}
	}		identity ipv4-capa {
	}		base condition;
			description
			"Identity for capabilities of IPv4 condition";
			reference
			"RFC 791: Internet Protocol";
			}
	grouping capabilities-information {		identity exact-ipv4-header-length {
	description		base ipv4-capa;
	"This includes information of capabilities.";		description
			"Identity for exact header length capability
			of IPv4 condition";
			reference
			"RFC 791: Internet Protocol - Header Length";
			}
	leaf nsf-type {		identity range-ipv4-header-length {
	type nsf-type;		base ipv4-capa;
	description		description
	"This is type of NSF.";		"Identity for range header length capability
	}		of IPv4 condition";
	uses i2nsf-nsf-location;		reference
	uses i2nsf-it-resources;		"RFC 791: Internet Protocol - Header Length";
	}		}
			identity ipv4-tos {
			base ipv4-capa;
			description
			"Identity for type of service capability
			of IPv4 condition";
			reference
			"RFC 791: Internet Protocol - Type of Service";
			}
	grouping i2nsf-net-sec-caps {		identity exact-ipv4-total-length {
	description		base ipv4-capa;
	"i2nsf-net-sec-caps";		description
	container net-sec-capabilities {		"Identity for exact total length capability
	description		of IPv4 condition";
	"net-sec-capabilities";		reference
			"RFC 791: Internet Protocol - Total Length";
			}
	container time {		identity range-ipv4-total-length {
	description		base ipv4-capa;
	"This is capabilities for time";		description
	container time-zone {		"Identity for range total length capability
	description		of IPv4 condition";
	"This can be used to apply rules		reference
	according to time zone";		"RFC 791: Internet Protocol - Total Length";
			}
	leaf time-zone-offset {		identity ipv4-id {
	type boolean;		base ipv4-capa;
	description		description
	"This is offset for UTC time zone";		"Identity for identification capability
	}		of IPv4 condition";
			reference
			"RFC 791: Internet Protocol - Identification";
			}
	}		identity ipv4-fragment-flags {
			base ipv4-capa;
			description
			"Identity for fragment flags capability
			of IPv4 condition";
			reference
			"RFC 791: Internet Protocol - Fragmentation Flags";
			}
	container time-inteval {		identity exact-ipv4-fragment-offset {
	description		base ipv4-capa;
	"This can be used to apply rules		description
	according to time inteval";		"Identity for exact fragment offset capability
	container absolute-time-inteval {		of IPv4 condition";
	description		reference
	"This can be used to apply rules according to		"RFC 791: Internet Protocol - Fragmentation Offset";
	absolute time inteval";		}
	leaf start-time {
	type boolean;
	description
	"This is start time for absolute time inteval";
	}
	leaf end-time {
	type boolean;
	description
	"This is end time for absolute time inteval";
	}
	}
	container periodic-time-inteval {
	description
	"This can be used to apply rules according to
	periodic time inteval";
	leaf day {
	type boolean;
	description
	"This is day for periodic time inteval";
	}
	leaf month {
	type boolean;
	description
	"This is month for periodic time inteval";
	}
	}
	}
	}
	container event {		identity range-ipv4-fragment-offset {
	description		base ipv4-capa;
	" This is abstract. An event is defined as any important		description
	occurrence in time of a change in the system being		"Identity for range fragment offset capability
	managed, and/or in the environment of the system being		of IPv4 condition";
	managed. When used in the context of policy rules for		reference
	a flow-based NSF, it is used to determine whether the		"RFC 791: Internet Protocol - Fragmentation Offset";
	Condition clause of the Policy Rule can be evaluated		}
	or not. Examples of an I2NSF event include time and
	user actions (e.g., logon, logoff, and actions that
	violate any ACL.).";
	container usr-event {		identity exact-ipv4-ttl {
	description "TBD";		base ipv4-capa;
	leaf usr-sec-event-content {		description
	type boolean;		"Identity for exact time to live capability
	description		of IPv4 condition";
	"This is a mandatory string that contains the content		reference
	of the UserSecurityEvent. The format of the content		"RFC 791: Internet Protocol - Time To Live (TTL)";
	is specified in the usrSecEventFormat class		}
	attribute, and the type of event is defined in the
	usrSecEventType class attribute. An example of the
	usrSecEventContent attribute is a string hrAdmin,
	with the usrSecEventFormat set to 1 (GUID) and the
	usrSecEventType attribute set to 5 (new logon).";
	}
	container usr-sec-event-format {		identity range-ipv4-ttl {
	description		base ipv4-capa;
	"This is a mandatory uint 8 enumerated integer, which		description
	is used to specify the data type of the		"Identity for range time to live capability
	usrSecEventContent attribute. The content is		of IPv4 condition";
	specified in the usrSecEventContent class attribute,		reference
	and the type of event is defined in the		"RFC 791: Internet Protocol - Time To Live (TTL)";
	usrSecEventType class attribute. An example of the		}
	usrSecEventContent attribute is string hrAdmin,
	with the usrSecEventFormat attribute set to 1 (GUID)
	and the usrSecEventType attribute set to 5
	(new logon).";
	leaf unknown {
	type boolean;
	description
	"If SecEventFormat is unknown";
	}
	leaf guid {
	type boolean;
	description
	"If SecEventFormat is GUID
	(Generic Unique IDentifier)";
	}
	leaf uuid {
	type boolean;
	description
	"If SecEventFormat is UUID
	(Universal Unique IDentifier)";
	}
	leaf uri {
	type boolean;
	description
	"If SecEventFormat is URI
	(Uniform Resource Identifier)";
	}
	leaf fqdn {
	type boolean;
	description
	"If SecEventFormat is FQDN
	(Fully Qualified Domain Name)";
	}
	leaf fqpn {
	type boolean;
	description
	"If SecEventFormat is FQPN
	(Fully Qualified Path Name)";
	}
	}
	container usr-sec-event-type {		identity ipv4-protocol {
	leaf unknown {		base ipv4-capa;
	type boolean;		description
	description		"Identity for protocol capability
	"If usrSecEventType is unknown";		of IPv4 condition";
	}		reference
	leaf user-created {		"RFC 790: Assigned numbers - Assigned Internet
	type boolean;		Protocol Number
	description		RFC 791: Internet Protocol - Protocol";
	"If usrSecEventType is new user		}
	created";
	}
	leaf user-grp-created {
	type boolean;
	description
	"If usrSecEventType is new user
	group created";
	}
	leaf user-deleted {
	type boolean;
	description
	"If usrSecEventType is user
	deleted";
	}
	leaf user-grp-deleted {
	type boolean;
	description
	"If usrSecEventType is user
	group deleted";
	}
	leaf user-logon {
	type boolean;
	description
	"If usrSecEventType is user
	logon";
	}
	leaf user-logoff {
	type boolean;
	description
	"If usrSecEventType is user
	logoff";
	}
	leaf user-access-request {
	type boolean;
	description
	"If usrSecEventType is user
	access request";
	}
	leaf user-access-granted {
	type boolean;
	description
	"If usrSecEventType is user
	granted";
	}
	leaf user-access-violation {
	type boolean;
	description
	"If usrSecEventType is user
	violation";
	}
	description
	"This is a mandatory uint 8 enumerated integer, which
	is used to specify the type of event that involves
	this user. The content and format are specified in
	the usrSecEventContent and usrSecEventFormat class
	attributes, respectively. An example of the
	usrSecEventContent attribute is string hrAdmin,
	with the usrSecEventFormat attribute set to 1 (GUID)
	and the usrSecEventType attribute set to 5
	(new logon).";
	}
	}		identity exact-ipv4-address {
	container dev-event {		base ipv4-capa;
	description "TBD";		description
			"Identity for exact address capability
			of IPv4 condition";
			reference
			"RFC 791: Internet Protocol - Address";
			}
	leaf dev-sec-event-content {		identity range-ipv4-address {
	type boolean;		base ipv4-capa;
	mandatory true;		description
	description		"Identity for range-address capability
	"This is a mandatory string that contains the content		of IPv4 condition";
	of the DeviceSecurityEvent. The format of the		reference
	content is specified in the devSecEventFormat class		"RFC 791: Internet Protocol - Address";
	attribute, and the type of event is defined in the		}
	devSecEventType class attribute. An example of the
	devSecEventContent attribute is alarm, with the
	devSecEventFormat attribute set to 1 (GUID), the
	devSecEventType attribute set to 5 (new logon).";
	}
	container dev-sec-event-format {		identity ipv4-ipopts {
	description		base ipv4-capa;
	"This is a mandatory uint 8 enumerated integer,		description
	which is used to specify the data type of the		"Identity for option capability
	devSecEventContent attribute.";		of IPv4 condition";
			reference
			"RFC 791: Internet Protocol - Options";
			}
	leaf unknown {		identity ipv4-sameip {
	type boolean;		base ipv4-capa;
	description		description
	"If SecEventFormat is unknown";		"Identity for sameIP capability
	}		of IPv4 condition";
	leaf guid {		}
	type boolean;
	description
	"If SecEventFormat is GUID
	(Generic Unique IDentifier)";
	}
	leaf uuid {
	type boolean;
	description
	"If SecEventFormat is UUID
	(Universal Unique IDentifier)";
	}
	leaf uri {
	type boolean;
	description
	"If SecEventFormat is URI
	(Uniform Resource Identifier)";
	}
	leaf fqdn {
	type boolean;
	description
	"If SecEventFormat is FQDN
	(Fully Qualified Domain Name)";
	}
	leaf fqpn {
	type boolean;
	description
	"If SecEventFormat is FQPN
	(Fully Qualified Path Name)";
	}
	}
	container dev-sec-event-type {		identity ipv4-geoip {
	description		base ipv4-capa;
	"This is a mandatory uint 8 enumerated integer,		description
	which is used to specify the type of event		"Identity for geography capability
	that was generated by this device.";		of IPv4 condition";
			}
	leaf unknown {		identity ipv6-capa {
	type boolean;		base condition;
	description		description
	"If devSecEventType is unknown";		"Identity for capabilities of IPv6 condition";
	}		reference
	leaf comm-alarm {		"RFC 2460: Internet Protocol, Version 6 (IPv6)
	type boolean;		Specification";
	description		}
	"If devSecEventType is communications
	alarm";
	}
	leaf quality-of-service-alarm {
	type boolean;
	description
	"If devSecEventType is quality of service
	alarm";
	}
	leaf process-err-alarm {
	type boolean;
	description
	"If devSecEventType is processing error
	alarm";
	}
	leaf equipment-err-alarm {
	type boolean;
	description
	"If devSecEventType is equipment error
	alarm";
	}
	leaf environmental-err-alarm {
	type boolean;
	description
	"If devSecEventType is environmental error
	alarm";
	}
	}		identity ipv6-traffic-class {
	container dev-sec-event-type-severity {		base ipv6-capa;
	description		description
	"This is a mandatory uint 8 enumerated integer,		"Identity for traffic class capability
	which is used to specify the perceived		of IPv6 condition";
	severity of the event generated by this		reference
	Device.";		"RFC 2460: Internet Protocol, Version 6 (IPv6)
			Specification - Traffic Class";
			}
	leaf unknown {		identity exact-ipv6-flow-label {
	type boolean;		base ipv6-capa;
	description		description
	"If devSecEventType is unknown";		"Identity for exact flow label capability
	}		of IPv6 condition";
	leaf cleared {		reference
	type boolean;		"RFC 2460: Internet Protocol, Version 6 (IPv6)
	description		Specification - Flow Label";
	"If devSecEventTypeSeverity is cleared";		}
	}
	leaf indeterminate {
	type boolean;
	description
	"If devSecEventTypeSeverity is
	indeterminate";
	}
	leaf critical {
	type boolean;
	description
	"If devSecEventTypeSeverity is critical";
	}
	leaf major{
	type boolean;
	description
	"If devSecEventTypeSeverity is major";
	}
	leaf minor {
	type boolean;
	description
	"If devSecEventTypeSeverity is minor";
	}
	leaf warning {
	type boolean;
	description
	"If devSecEventTypeSeverity is warning";
	}
	}
	}
	container sys-event {
	description "TBD";
	leaf sys-sec-event-content {
	type boolean;
	description
	"This is a mandatory string that contains a content
	of the SystemSecurityEvent. The format of a content
	is specified in a sysSecEventFormat class attribute,
	and the type of event is defined in the
	sysSecEventType class attribute. An example of the
	sysSecEventContent attribute is string sysadmin3,
	with the sysSecEventFormat attribute set to 1(GUID),
	and the sysSecEventType attribute set to 2
	(audit log cleared).";
	}
	container sys-sec-event-format {		identity range-ipv6-flow-label {
	description		base ipv6-capa;
	"This is a mandatory uint 8 enumerated integer, which		description
	is used to specify the data type of the		"Identity for range flow label capability
	sysSecEventContent attribute.";		of IPv6 condition";
			reference
			"RFC 2460: Internet Protocol, Version 6 (IPv6)
			Specification - Flow Label";
			}
	leaf unknown {		identity exact-ipv6-payload-length {
	type boolean;		base ipv6-capa;
	description		description
	"If SecEventFormat is unknown";		"Identity for exact payload length capability
	}		of IPv6 condition";
	leaf guid {		reference
	type boolean;		"RFC 2460: Internet Protocol, Version 6 (IPv6)
	description		Specification - Payload Length";
	"If SecEventFormat is GUID		}
	(Generic Unique IDentifier)";
	}
	leaf uuid {
	type boolean;
	description
	"If SecEventFormat is UUID
	(Universal Unique IDentifier)";
	}
	leaf uri {
	type boolean;
	description
	"If SecEventFormat is URI
	(Uniform Resource Identifier)";
	}
	leaf fqdn {
	type boolean;
	description
	"If SecEventFormat is FQDN
	(Fully Qualified Domain Name)";
	}		identity range-ipv6-payload-length {
	leaf fqpn {		base ipv6-capa;
	type boolean;		description
	description		"Identity for range payload length capability
	"If SecEventFormat is FQPN		of IPv6 condition";
	(Fully Qualified Path Name)";		reference
	}		"RFC 2460: Internet Protocol, Version 6 (IPv6)
	}		Specification - Payload Length";
			}
			identity ipv6-next-header {
			base ipv6-capa;
			description
			"Identity for next header capability
			of IPv6 condition";
			reference
			"RFC 2460: Internet Protocol, Version 6 (IPv6)
			Specification - Next Header";
			}
	container sys-sec-event-type {		identity exact-ipv6-hop-limit {
	description		base ipv6-capa;
	"This is a mandatory uint 8 enumerated integer, which		description
	is used to specify the type of event that involves		"Identity for exact hop limit capability
	this device.";		of IPv6 condition";
			reference
			"RFC 2460: Internet Protocol, Version 6 (IPv6)
			Specification - Hop Limit";
			}
	leaf unknown {		identity range-ipv6-hop-limit {
	type boolean;		base ipv6-capa;
	description		description
	"If sysSecEventType is unknown";		"Identity for range hop limit capability
	}		of IPv6 condition";
	leaf audit-log-written-to {		reference
	type boolean;		"RFC 2460: Internet Protocol, Version 6 (IPv6)
	description		Specification - Hop Limit";
	"If sysSecEventTypeSeverity		}
	is that audit log is written to";
	}
	leaf audit-log-cleared {
	type boolean;
	description
	"If sysSecEventTypeSeverity
	is that audit log is cleared";
	}
	leaf policy-created {
	type boolean;
	description
	"If sysSecEventTypeSeverity
	is that policy is created";
	}
	leaf policy-edited{
	type boolean;
	description
	"If sysSecEventTypeSeverity
	is that policy is edited";
	}
	leaf policy-deleted{
	type boolean;
	description
	"If sysSecEventTypeSeverity
	is that policy is deleted";
	}
	leaf policy-executed{
	type boolean;
	description
	"If sysSecEventTypeSeverity
	is that policy is executed";
	}
	}
	}
	container time-event {
	description "TBD";
	leaf time-sec-event-begin {		identity exact-ipv6-address {
	type boolean;		base ipv6-capa;
	description		description
	"This is a mandatory DateTime attribute, and		"Identity for exact address capability
	represents the beginning of a time period.		of IPv6 condition";
	It has a value that has a date and/or a time		reference
	component (as in the Java or Python libraries).";		"RFC 2460: Internet Protocol, Version 6 (IPv6)
	}		Specification - Address";
			}
	leaf time-sec-event-end {		identity range-ipv6-address {
	type boolean;		base ipv6-capa;
	description		description
	"This is a mandatory DateTime attribute, and		"Identity for range address capability
	represents the end of a time period. It has		of IPv6 condition";
	a value that has a date and/or a time component		reference
	(as in the Java or Python libraries). If this is		"RFC 2460: Internet Protocol, Version 6 (IPv6)
	a single event occurrence, and not a time period		Specification - Address";
	when the event can occur, then the
	timeSecEventPeriodEnd attribute may be ignored.";
	}
	leaf time-sec-event-time-zone {		}
	type boolean;
	description
	"This is a mandatory string attribute, and defines a
	time zone that this event occurred in using the
	format specified in ISO8601.";
	}
	}
	}		identity tcp-capa {
			base condition;
			description
			"Identity for capabilities of tcp condition";
			reference
			"RFC 793: Transmission Control Protocol";
			}
	container condition {		identity exact-tcp-port-num {
	description		base tcp-capa;
	" This is abstract. A condition is defined as a set		description
	of attributes, features, and/or values that are to be		"Identity for exact port number capability
	compared with a set of known attributes, features,		of tcp condition";
	and/or values in order to determine whether or not the		reference
	set of Actions in that (imperative) I2NSF Policy Rule		"RFC 793: Transmission Control Protocol - Port Number";
	can be executed or not. Examples of I2NSF Conditions		}
	include matching attributes of a packet or flow, and
	comparing the internal state of an NSF to a desired state.";
	container packet-security-condition {		identity range-tcp-port-num {
	description "TBD";		base tcp-capa;
			description
			"Identity for range port number capability
			of tcp condition";
			reference
			"RFC 793: Transmission Control Protocol - Port Number";
			}
	container packet-security-mac-condition {		identity exact-tcp-seq-num {
	description		base tcp-capa;
	"The purpose of this Class is to represent packet MAC		description
	packet header information that can be used as part of		"Identity for exact sequence number capability
	a test to determine if the set of Policy Actions in		of tcp condition";
	this ECA Policy Rule should be execute or not.";		reference
			"RFC 793: Transmission Control Protocol - Sequence Number";
			}
	leaf pkt-sec-cond-mac-dest {		identity range-tcp-seq-num {
	type boolean;		base tcp-capa;
	description		description
	"The MAC destination address (6 octets long).";		"Identity for range sequence number capability
	}		of tcp condition";
			reference
			"RFC 793: Transmission Control Protocol - Sequence Number";
			}
	leaf pkt-sec-cond-mac-src {		identity exact-tcp-ack-num {
	type boolean;		base tcp-capa;
	description		description
	"The MAC source address (6 octets long).";		"Identity for exact acknowledgement number capability
	}		of tcp condition";
			reference
			"RFC 793: Transmission Control Protocol - Acknowledgement Number";
			}
	leaf pkt-sec-cond-mac-8021q {		identity range-tcp-ack-num {
	type boolean;		base tcp-capa;
	description		description
	"This is an optional string attribute, and defines		"Identity for range acknowledgement number capability
	The 802.1Q tab value (2 octets long).";		of tcp condition";
	}		reference
			"RFC 793: Transmission Control Protocol - Acknowledgement Number";
			}
	leaf pkt-sec-cond-mac-ether-type {		identity exact-tcp-window-size {
	type boolean;		base tcp-capa;
	description		description
	"The EtherType field (2 octets long). Values up to		"Identity for exact window size capability
	and including 1500 indicate the size of the payload		of tcp condition";
	in octets; values of 1536 and above define which		reference
	protocol is encapsulated in the payload of the		"RFC 793: Transmission Control Protocol - Window Size";
	frame.";		}
	}
	leaf pkt-sec-cond-mac-tci {
	type string;
	description
	"This is an optional string attribute, and defines
	the Tag Control Information. This consists of a 3
	bit user priority field, a drop eligible indicator
	(1 bit), and a VLAN identifier (12 bits).";
	}
	}
	container packet-security-ipv4-condition {		identity range-tcp-window-size {
	description		base tcp-capa;
	"The purpose of this Class is to represent packet IPv4		description
	packet header information that can be used as part of		"Identity for range window size capability
	a test to determine if the set of Policy Actions in		of tcp condition";
	this ECA Policy Rule should be executed or not.";		reference
			"RFC 793: Transmission Control Protocol - Window Size";
			}
	leaf pkt-sec-cond-ipv4-header-length {		identity tcp-flags {
	type boolean;		base tcp-capa;
	description		description
	"The IPv4 packet header consists of 14 fields,		"Identity for flags capability
	of which 13 are required.";		of tcp condition";
	}		reference
			"RFC 793: Transmission Control Protocol - Flags";
			}
	leaf pkt-sec-cond-ipv4-tos {		identity udp-capa {
	type boolean;		base condition;
	description		description
	"The ToS field could specify a datagram's priority		"Identity for capabilities of udp condition";
	and request a route for low-delay, high-throughput,		reference
	or highly-reliable service..";		"RFC 768: User Datagram Protocol";
	}		}
	leaf pkt-sec-cond-ipv4-total-length {		identity exact-udp-port-num {
	type boolean;		base udp-capa;
	description		description
	"This 16-bit field defines the entire packet size,		"Identity for exact port number capability
	including header and data, in bytes.";		of udp condition";
	}		reference
			"RFC 768: User Datagram Protocol - Port Number";
			}
	leaf pkt-sec-cond-ipv4-id {		identity range-udp-port-num {
	type boolean;		base udp-capa;
	description		description
	"This field is an identification field and is		"Identity for range port number capability
	primarily used for uniquely identifying		of udp condition";
	the group of fragments of a single IP datagram.";		reference
	}		"RFC 768: User Datagram Protocol - Port Number";
			}
	leaf pkt-sec-cond-ipv4-fragment {		identity exact-udp-total-length {
	type boolean;		base udp-capa;
	description		description
	"IP fragmentation is an Internet Protocol (IP)		"Identity for exact total-length capability
	process that breaks datagrams into smaller pieces		of udp condition";
	(fragments), so that packets may be formed that		reference
	can pass through a link with a smaller maximum		"RFC 768: User Datagram Protocol - Total Length";
	transmission unit (MTU) than the original		}
	datagram size.";
	}
	leaf pkt-sec-cond-ipv4-fragment-offset {		identity range-udp-total-length {
	type boolean;		base udp-capa;
	description		description
	"Fragment offset field along with Don't Fragment		"Identity for range total-length capability
	and More Fragment flags in the IP protocol		of udp condition";
	header are used for fragmentation and reassembly		reference
	of IP datagrams.";		"RFC 768: User Datagram Protocol - Total Length";
	}		}
	leaf pkt-sec-cond-ipv4-ttl {		identity icmp-capa {
	type boolean;		base condition;
	description		description
	"The ttl keyword is used to check for a specific		"Identity for capabilities of icmp condition";
	IP time-to-live value in the header of		reference
	a packet.";		"RFC 792: Internet Control Message Protocol";
	}		}
	leaf pkt-sec-cond-ipv4-protocol {		identity icmp-type {
	type boolean;		base icmp-capa;
	description		description
	"Internet Protocol version 4(IPv4) is the fourth		"Identity for icmp type capability
	version of the Internet Protocol (IP).";		of icmp condition";
	}		reference
			"RFC 792: Internet Control Message Protocol";
			}
	leaf pkt-sec-cond-ipv4-src {		identity http-capa {
	type boolean;		base condition;
	description		description
	"Defines the IPv4 Source Address.";		"Identity for capabilities of http condition";
	}		}
	leaf pkt-sec-cond-ipv4-dest {		identity uri {
	type boolean;		base http-capa;
	description		description
	"Defines the IPv4 Destination Address.";		"Identity for uri capabilities of
	}		http condition";
			}
	leaf pkt-sec-cond-ipv4-ipopts {		identity url {
	type boolean;		base http-capa;
	description		description
	"With the ipopts keyword you can check if		"Identity for url capabilities of
	a specific ip option is set. Ipopts has		http condition";
	to be used at the beginning of a rule.";		}
	}
	leaf pkt-sec-cond-ipv4-sameip {		identity log-action-capa {
	type boolean;		description
	description		"Identity for capabilities of log action";
	"Every packet has a source IP-address and		}
	a destination IP-address. It can be that
	the source IP is the same as
	the destination IP.";
	}
	leaf pkt-sec-cond-ipv4-geoip {		identity rule-log {
	type boolean;		base log-action-capa;
	description		description
	"The geoip keyword enables you to match on		"Identity for rule log capability
	the source, destination or source and destination		of log action";
	IP addresses of network traffic and to see to		}
	which country it belongs. To do this, Suricata
	uses GeoIP API with MaxMind database format.";
	}
	}
	container packet-security-ipv6-condition {		identity session-log {
	description		base log-action-capa;
	"The purpose of this Class is to represent packet		description
	IPv6 packet header information that can be used as		"Identity for session log capability
	part of a test to determine if the set of Policy		of log action";
	Actions in this ECA Policy Rule should be executed		}
	or not.";
	leaf pkt-sec-cond-ipv6-dscp {		identity ingress-action-capa {
	type boolean;		description
	description		"Identity for capabilities of ingress action";
	"Differentiated Services Code Point (DSCP)		reference
	of ipv6.";		"draft-ietf-i2nsf-capability-04: Information Model
	}		of NSFs Capabilities - Action";
			}
	leaf pkt-sec-cond-ipv6-ecn {		identity egress-action-capa {
	type boolean;		description
	description		"Base identity for egress action";
	"ECN allows end-to-end notification of network		}
	congestion without dropping packets.";
	}
	leaf pkt-sec-cond-ipv6-traffic-class {
	type boolean;
	description
	"The bits of this field hold two values. The 6
	most-significant bits are used for
	differentiated services, which is used to
	classify packets.";
	}
	leaf pkt-sec-cond-ipv6-flow-label {		identity default-action-capa {
	type boolean;		description
	description		"Identity for capabilities of default action";
	"The flow label when set to a non-zero value		reference
	serves as a hint to routers and switches		"draft-ietf-i2nsf-capability-04: Information Model
	with multiple outbound paths that these		of NSFs Capabilities - Default action";
	packets should stay on the same path so that		}
	they will not be reordered.";
	}
	leaf pkt-sec-cond-ipv6-payload-length {		identity pass {
	type boolean;		base ingress-action-capa;
	description		base egress-action-capa;
	"The size of the payload in octets,		base default-action-capa;
	including any extension headers.";		description
	}		"Identity for pass";
			reference
			"draft-ietf-i2nsf-capability-04: Information Model
			of NSFs Capabilities - Actions and
			default action";
			}
	leaf pkt-sec-cond-ipv6-next-header {		identity drop {
	type boolean;		base ingress-action-capa;
	description		base egress-action-capa;
	"Specifies the type of the next header.		base default-action-capa;
	This field usually specifies the transport		description
	layer protocol used by a packet's payload.";		"Identity for drop";
	}		reference
			"draft-ietf-i2nsf-capability-04: Information Model
			of NSFs Capabilities - Actions and
			default action";
			}
	leaf pkt-sec-cond-ipv6-hop-limit {		identity reject {
	type boolean;		base ingress-action-capa;
	description		base egress-action-capa;
	"Replaces the time to live field of IPv4.";		base default-action-capa;
	}		description
			"Identity for reject";
			reference
			"draft-ietf-i2nsf-capability-04: Information Model
			of NSFs Capabilities - Actions and
			default action";
			}
	leaf pkt-sec-cond-ipv6-src {		identity alert {
	type boolean;		base ingress-action-capa;
	description		base egress-action-capa;
	"The IPv6 address of the sending node.";		base default-action-capa;
	}		description
			"Identity for alert";
			reference
			"draft-ietf-i2nsf-capability-04: Information Model
			of NSFs Capabilities - Actions and
			default action";
			}
	leaf pkt-sec-cond-ipv6-dest {		identity mirror {
	type boolean;		base ingress-action-capa;
	description		base egress-action-capa;
	"The IPv6 address of the destination node(s).";		base default-action-capa;
	}		description
	}		"Identity for mirror";
			reference
			"draft-ietf-i2nsf-capability-04: Information Model
			of NSFs Capabilities - Actions and
			default action";
			}
	container packet-security-tcp-condition {		identity invoke-signaling {
	description		base egress-action-capa;
	"The purpose of this Class is to represent packet		description
	TCP packet header information that can be used as		"Identity for invoke signaling";
	part of a test to determine if the set of Policy		}
	Actions in this ECA Policy Rule should be executed
	or not.";
	leaf pkt-sec-cond-tcp-src-port {		identity tunnel-encapsulation {
	type boolean;		base egress-action-capa;
	description		description
	"This is a mandatory string attribute, and		"Identity for tunnel encapsulation";
	defines the Source Port number (16 bits).";		}
	}
	leaf pkt-sec-cond-tcp-dest-port {		identity forwarding {
	type boolean;		base egress-action-capa;
	description		description
	"This is a mandatory string attribute, and		"Identity for forwarding";
	defines the Destination Port number (16 bits).";
	}
	leaf pkt-sec-cond-tcp-seq-num {		}
	type boolean;
	description
	"If the SYN flag is set (1), then this is the
	initial sequence number.";
	}
	leaf pkt-sec-cond-tcp-ack-num {		identity redirection {
	type boolean;		base egress-action-capa;
	description		description
	"If the ACK flag is set then the value of this		"Identity for redirection";
	field is the next sequence number that the sender		}
	is expecting.";
	}
	leaf pkt-sec-cond-tcp-window-size {		identity resolution-strategy-capa {
	type boolean;		description
	description		"Base identity for resolution strategy";
	"The size of the receive window, which specifies		reference
	the number of windows size units (by default,bytes)		"draft-ietf-i2nsf-capability-04: Information Model
	(beyond the segment identified by the sequence		of NSFs Capabilities - Resolution Strategy";
	number in the acknowledgment field) that the sender		}
	of this segment is currently willing to recive.";
	}
	leaf pkt-sec-cond-tcp-flags {		identity fmr {
	type boolean;		base resolution-strategy-capa;
	description		description
	"This is a mandatory string attribute, and defines		"Identity for First Matching Rule (FMR)";
	the nine Control bit flags (9 bits).";		reference
	}		"draft-ietf-i2nsf-capability-04: Information Model
	}		of NSFs Capabilities - Resolution Strategy";
			}
	container packet-security-udp-condition {		identity lmr {
	description		base resolution-strategy-capa;
	"The purpose of this Class is to represent packet UDP		description
	packet header information that can be used as part		"Identity for Last Matching Rule (LMR)";
	of a test to determine if the set of Policy Actions		reference
	in this ECA Policy Rule should be executed or not.";		"draft-ietf-i2nsf-capability-04: Information Model
			of NSFs Capabilities - Resolution Strategy";
			}
	leaf pkt-sec-cond-udp-src-port {		identity pmr {
	type boolean;		base resolution-strategy-capa;
	description		description
	"This is a mandatory string attribute, and		"Identity for Prioritized Matching Rule (PMR)";
	defines the UDP Source Port number (16 bits).";		reference
	}		"draft-ietf-i2nsf-capability-04: Information Model
			of NSFs Capabilities - Resolution Strategy";
			}
	leaf pkt-sec-cond-udp-dest-port {		identity pmre {
	type boolean;		base resolution-strategy-capa;
	description		description
	"This is a mandatory string attribute, and		"Identity for Prioritized Matching Rule
	defines the UDP Destination Port number (16 bits).";		with Errors (PMRE)";
	}
	leaf pkt-sec-cond-udp-length {		reference
	type boolean;		"draft-ietf-i2nsf-capability-04: Information Model
	description		of NSFs Capabilities - Resolution Strategy";
	"This is a mandatory string attribute, and defines		}
	the length in bytes of the UDP header and data
	(16 bits).";
	}
	}
	container packet-security-icmp-condition {		identity pmrn {
	description		base resolution-strategy-capa;
	"The internet control message protocol condition.";		description
			"Identity for Prioritized Matching Rule
			with No Errors (PMRN)";
			reference
			"draft-ietf-i2nsf-capability-04: Information Model
			of NSFs Capabilities - Resolution Strategy";
			}
	leaf pkt-sec-cond-icmp-type {		identity advanced-nsf-capa {
	type boolean;		description
	description		"Base identity for advanced
	"ICMP type, see Control messages.";		network security function capabilities";
	}		reference
			"RFC 8329: Framework for Interface to Network Security
			Functions - Differences from ACL Data Models
			draft-dong-i2nsf-asf-config-01: Configuration of
			Advanced Security Functions with I2NSF Security
			Controller";
			}
	leaf pkt-sec-cond-icmp-code {		identity antivirus-capa {
	type boolean;		base advanced-nsf-capa;
	description		description
	"ICMP subtype, see Control messages.";		"Identity for antivirus capabilities";
	}		reference
			"RFC 8329: Framework for Interface to Network Security
			Functions - Differences from ACL Data Models
			draft-dong-i2nsf-asf-config-01: Configuration of
			Advanced Security Functions with I2NSF Security
			Controller - Antivirus";
			}
	leaf pkt-sec-cond-icmp-seg-num {		identity antiddos-capa {
	type boolean;		base advanced-nsf-capa;
	description		description
	"The icmp Sequence Number.";		"Identity for antiddos capabilities";
	}		reference
	}		"RFC 8329: Framework for Interface to Network Security
	}		Functions - Differences from ACL Data Models
			draft-dong-i2nsf-asf-config-01: Configuration of
			Advanced Security Functions with I2NSF Security
			Controller - Antiddos";
			}
	container packet-payload-condition {		identity ips-capa {
	description "TBD";		base advanced-nsf-capa;
	leaf pkt-payload-content {		description
	type boolean;		"Identity for IPS capabilities";
	description		reference
	"The content keyword is very important in		"RFC 8329: Framework for Interface to Network Security
	signatures. Between the quotation marks you		Functions - Differences from ACL Data Models
	can write on what you would like the		draft-dong-i2nsf-asf-config-01: Configuration of
	signature to match.";		Advanced Security Functions with I2NSF Security
	}		Controller - Intrusion Prevention System";
	}		}
	leaf acl-number {
	type boolean;
	description
	"This is acl-number.";
	}
	container application-condition {		identity voip-volte-capa {
	description		base advanced-nsf-capa;
	"TBD";		description
			"Identity for VoIP/VoLTE capabilities";
			reference
			"RFC 3261: SIP: Session Initiation Protocol
			RFC 8329: Framework for Interface to Network Security
			Functions - Differences from ACL Data Models
			draft-dong-i2nsf-asf-config-01: Configuration of
			Advanced Security Functions with I2NSF Security
			Controller";
			}
	leaf application-object {		identity detect {
	type boolean;		base antivirus-capa;
	description		description
	"This is application object.";		"Identity for detect capabilities
	}		of antivirus";
	leaf application-group {		reference
	type boolean;		"draft-dong-i2nsf-asf-config-01: Configuration of
	description		Advanced Security Functions with I2NSF Security
	"This is application group.";		Controller - Antivirus";
			}
	}		identity exception-application {
	leaf application-label {		base antivirus-capa;
	type boolean;		description
	description		"Identity for exception application capabilities
	"This is application label.";		of antivirus";
	}		reference
	container category {		"draft-dong-i2nsf-asf-config-01: Configuration of
	description		Advanced Security Functions with I2NSF Security
	"TBD";		Controller - Antivirus";
	leaf application-category {
	type boolean;
	description
	"TBD";
	}		}
	}
	}
	container target-condition {		identity exception-signature {
	description "TBD";		base antivirus-capa;
			description
			"Identity for exception signature capabilities
			of antivirus";
			reference
			"draft-dong-i2nsf-asf-config-01: Configuration of
			Advanced Security Functions with I2NSF Security
			Controller - Antivirus";
			}
	leaf device-sec-context-cond {		identity whitelists {
	type boolean;		base antivirus-capa;
	description		description
	"The device attribute that can identify a device,		"Identity for whitelists capabilities
	including the device type (i.e., router, switch,		of antivirus";
	pc, ios, or android) and the device's owner as		reference
	well.";		"draft-dong-i2nsf-asf-config-01: Configuration of
	}		Advanced Security Functions with I2NSF Security
	}		Controller - Antivirus";
	container users-condition {		}
	description "TBD";
	container user{		identity syn-flood-action {
	description		base antiddos-capa;
	"The user (or user group) information with which		description
	network flow is associated: The user has many		"Identity for syn flood action capabilities
	attributes such as name, id, password, type,		of antiddos";
	authentication mode and so on. Name/id is often		reference
	used in the security policy to identify the user.		"draft-dong-i2nsf-asf-config-01: Configuration of
	Besides, NSF is aware of the IP address of the		Advanced Security Functions with I2NSF Security
	user provided by a unified user management system		Controller - Antiddos";
	via network. Based on name-address association,		}
	NSF is able to enforce the security functions
	over the given user (or user group)";
	choice user-name {		identity udp-flood-action {
	description		base antiddos-capa;
	"The name of the user.		description
	This must be unique.";		"Identity for udp flood action capabilities
			of antiddos";
			reference
			"draft-dong-i2nsf-asf-config-01: Configuration of
			Advanced Security Functions with I2NSF Security
			Controller - Antiddos";
			}
	case tenant {		identity http-flood-action {
	description		base antiddos-capa;
	"Tenant information.";		description
			"Identity for http flood action capabilities
			of antiddos";
			reference
			"draft-dong-i2nsf-asf-config-01: Configuration of
			Advanced Security Functions with I2NSF Security
			Controller - Antiddos";
			}
	leaf tenant {		identity https-flood-action {
	type boolean;		base antiddos-capa;
	description		description
	"User's tenant information.";		"Identity for https flood action capabilities
	}		of antiddos";
	}		reference
			"draft-dong-i2nsf-asf-config-01: Configuration of
			Advanced Security Functions with I2NSF Security
			Controller - Antiddos";
			}
	case vn-id {		identity dns-request-flood-action {
	description		base antiddos-capa;
	"VN-ID information.";		description
			"Identity for dns request flood action capabilities
			of antiddos";
			reference
			"draft-dong-i2nsf-asf-config-01: Configuration of
			Advanced Security Functions with I2NSF Security
			Controller - Antiddos";
			}
	leaf vn-id {		identity dns-reply-flood-action {
	type boolean;		base antiddos-capa;
	description		description
	"User's VN-ID information.";		"Identity for dns reply flood action capabilities
	}		of antiddos";
	}		reference
	}		"draft-dong-i2nsf-asf-config-01: Configuration of
	}		Advanced Security Functions with I2NSF Security
	container group {		Controller - Antiddos";
	description		}
	"The user (or user group) information with which
	network flow is associated: The user has many
	attributes such as name, id, password, type,
	authentication mode and so on. Name/id is often
	used in the security policy to identify the user.
	Besides, NSF is aware of the IP address of the
	user provided by a unified user management system
	via network. Based on name-address association,
	NSF is able to enforce the security functions
	over the given user (or user group)";
	choice group-name {		identity icmp-flood-action {
	description		base antiddos-capa;
	"The name of the user.		description
	This must be unique.";		"Identity for icmp flood action capabilities
			of antiddos";
			reference
			"draft-dong-i2nsf-asf-config-01: Configuration of
			Advanced Security Functions with I2NSF Security
			Controller - Antiddos";
			}
	case tenant {		identity sip-flood-action {
	description		base antiddos-capa;
	"Tenant information.";		description
			"Identity for sip flood action capabilities
			of antiddos";
			reference
			"draft-dong-i2nsf-asf-config-01: Configuration of
			Advanced Security Functions with I2NSF Security
			Controller - Antiddos";
			}
	leaf tenant {		identity detect-mode {
	type boolean;		base antiddos-capa;
	description		description
	"User's tenant information.";		"Identity for detect mode capabilities
	}		of antiddos";
	}		reference
			"draft-dong-i2nsf-asf-config-01: Configuration of
			Advanced Security Functions with I2NSF Security
			Controller - Antiddos";
			}
	case vn-id {		identity baseline-learn {
	description		base antiddos-capa;
	"VN-ID information.";		description
			"Identity for baseline learn capabilities
			of antiddos";
			reference
			"draft-dong-i2nsf-asf-config-01: Configuration of
			Advanced Security Functions with I2NSF Security
			Controller - Antiddos";
			}
	leaf vn-id {		identity signature-set {
	type boolean;		base ips-capa;
	description		description
	"User's VN-ID information.";		"Identity for signature set capabilities
	}		of IPS";
	}		reference
	}		"draft-dong-i2nsf-asf-config-01: Configuration of
	leaf security-grup {		Advanced Security Functions with I2NSF Security
	type boolean;		Controller - Intrusion Prevention System";
	mandatory true;		}
	description		identity ips-exception-signature {
	"security-grup.";		base ips-capa;
	}		description
	}		"Identity for ips exception signature capabilities
	}		of IPS";
			reference
			"draft-dong-i2nsf-asf-config-01: Configuration of
			Advanced Security Functions with I2NSF Security
			Controller - Intrusion Prevention System";
			}
	container url-category-condition {		identity voice-id {
	description		base voip-volte-capa;
	"TBD";		description
	leaf pre-defined-category {		"Identity for voice-id capabilities
	type boolean;		of VoIP/VoLTE";
	description		reference
	"This is pre-defined-category.";		"RFC 3261: SIP: Session Initiation Protocol";
	}		}
	leaf user-defined-category {
	type boolean;
	description
	"This user-defined-category.";
	}
	}
	container context-condition {		identity user-agent {
	description "TBD";		base voip-volte-capa;
	leaf temp {		description
	type string;		"Identity for user agent capabilities
	description		of VoIP/VoLTE";
	"This is temp for context condition.";		reference
			"RFC 3261: SIP: Session Initiation Protocol";
			}
	}		/*
	}		* Grouping
	container gen-context-condition {		*/
	description "TBD";
	container geographic-location {		grouping nsf-capabilities {
	description		description
	"The location where network traffic is associated		"Capabilities of network security funtion";
	with. The region can be the geographic location		reference
	such as country, province, and city,		"RFC 8329: Framework for Interface to Network Security
	as well as the logical network location such as		Functions - I2NSF Flow Security Policy Structure
	IP address, network section, and network domain.";		draft-ietf-i2nsf-capability-04: Information Model
			of NSFs Capabilities - Capability Information Model Design";
	leaf src-geographic-location {		leaf-list time-capabilities {
	type boolean;		type enumeration {
	description		enum absolute-time {
	"This is mapped to ip address. We can acquire
	source region through ip address stored the
	database.";
	}
	leaf dest-geographic-location {
	type boolean;
	description
	"This is mapped to ip address. We can acquire
	destination region through ip address stored
	the database.";
	}
	}
	}
	}
	container action {
	description		description
	"An action is used to control and monitor aspects of		"Capabilities of absolute time.
	flow-based NSFs when the event and condition clauses		If network security function has the absolute time
	are satisfied. NSFs provide security functions by		capability, the network security function
	executing various Actions. Examples of I2NSF Actions		supports rule execution according to absolute time.";
	include providing intrusion detection and/or protection,
	web and flow filtering, and deep packet inspection
	for packets and flows.";
	leaf rule-log {
	type boolean;
	description
	"rule-log";
	}
	leaf session-log {
	type boolean;
	description
	"session-log";
	}
	container ingress-action {
	description "TBD";
	container ingress-action-type {
	description
	"Ingress action type: permit, deny, and mirror.";
	leaf pass {
	type boolean;
	description
	"If ingress action is pass";
	}
	leaf drop {
	type boolean;
	description
	"If ingress action is drop";
	}
	leaf reject {
	type boolean;
	description
	"If ingress action is reject";
	}
	leaf alert {
	type boolean;
	description
	"If ingress action is alert";
	}
	leaf mirror {
	type boolean;
	description
	"If ingress action is mirror";
	}
	}
	}
	container egress-action {
	description "TBD";
	container egress-action-type {
	description
	"Egress-action-type: invoke-signaling,
	tunnel-encapsulation, and forwarding.";
	leaf invoke-signaling {
	type boolean;
	description
	"If egress action is invoke signaling";
	}
	leaf tunnel-encapsulation {
	type boolean;
	description
	"If egress action is tunnel encapsulation";
	}
	leaf forwarding {
	type boolean;
	description
	"If egress action is forwarding";
	}
	leaf redirection {
	type boolean;
	description
	"If egress action is redirection";
	}
	}
	}
	}		}
	container resolution-strategy {		enum periodic-time {
	description		description
	"The resolution strategies can be used to		"Capabilities of periodic time.
	specify how to resolve conflicts that occur between		If network security function has the periodic time
	the actions of the same or different policy rules that		capability, the network security function
	are matched and contained in this particular NSF";		supports rule execution according to periodic time.";
	leaf first-matching-rule {
	type boolean;
	description
	"If the resolution strategy is first matching rule";
	}
	leaf last-matching-rule {
	type boolean;
	description
	"If the resolution strategy is last matching rule";
	}
	}		}
	}		}
			description
			"This is capabilities for time";
	}		}
	grouping i2nsf-advanced-sec-caps {		container event-capabilities {
	description		description
	"i2nsf-advanced-sec-caps";		"Capabilities of events.
	container advanced-sec-capabilities {		If network security function has
	description		the event capabilities, the network security functions
	"net-sec-capabilities";		supports rule execution according to system event
			and system alarm.";
	container antivirus {
	description
	"antivirus";
	leaf detect {
	type boolean;
	description
	"detect capability";
	}
	leaf exception-application {
	type boolean;
	description
	"exception-application capability";
	}
	leaf exception-signature {
	type boolean;
	description
	"exception-signature capability";
	}
	leaf whitelists {
	type boolean;
	description
	"exception-signature capability";
	}
	}
	container antiddos {		reference
	description		"RFC 8329: Framework for Interface to Network Security
	"antiddos";		Functions - I2NSF Flow Security Policy Structure
			draft-ietf-i2nsf-capability-04: Information Model
			of NSFs Capabilities - Design Principles and ECA
			Policy Model Overview
			draft-hong-i2nsf-nsf-monitoring-data-model-06: A YANG
			Data Model for Monitoring I2NSF Network Security
			Functions - System Alarm and System Events";
	leaf syn-flood-action {		leaf-list system-event-capa {
	type boolean;		type identityref {
	description		base system-event-capa;
	"syn-flood-action capability";
	}
	leaf udp-flood-action {
	type boolean;
	description
	"udp-flood-action capability";
	}
	leaf http-flood-action {
	type boolean;
	description
	"http-flood-action capability";
	}
	leaf https-flood-action {
	type boolean;
	description
	"https-flood-action capability";
	}
	leaf dns-request-flood-action {
	type boolean;
	description
	"dns-request-flood-action capability";
	}
	leaf dns-reply-flood-action {
	type boolean;
	description
	"dns-reply-flood-action capability";
	}
	leaf icmp-flood-action {
	type boolean;
	description
	"icmp-flood-action capability";
	}
	leaf sip-flood-action {
	type boolean;
	description
	"sip-flood-action capability";
	}
	leaf detect-mode {
	type boolean;
	description
	"detect mode capability";
	}
	leaf baseline-learn {
	type boolean;
	description
	"baseline-learn capability";
	}
	}		}
			description
			"Capabilities for a system event";
			}
	container ips {		leaf-list system-alarm-capa {
	description		type identityref {
	"ips";		base system-alarm-capa;
	leaf signature-set {
	type boolean;
	description
	"signature-set capability";
	}
	leaf exception-signature {
	type boolean;
	description
	"exception-signature capability";
	}
	}		}
			description
			"Capabilities for a system alarm";
	}		}
	}		}
	grouping i2nsf-con-sec-control-caps {		container condition-capabilities {
	description		description
	"i2nsf-con-sec-control-caps";		"Capabilities of conditions.";
	container con-sec-control-capabilities {		container generic-nsf-capabilities {
	description		description
	"content-security-control-capabilities";		"Capabilities of conditions.
			If a network security function has
			the condition capabilities, the network security function
			supports rule execution according to conditions of IPv4,
			IPv6, foruth layer, ICMP, and payload.";
			reference
			"RFC 791: Internet Protocol
			RFC 792: Internet Control Message Protocol
			RFC 793: Transmission Control Protocol
			RFC 2460: Internet Protocol, Version 6 (IPv6)
			Specification - Next Header
			RFC 8329: Framework for Interface to Network Security
			Functions - I2NSF Flow Security Policy Structure
			draft-ietf-i2nsf-capability-04: Information Model
			of NSFs Capabilities - Design Principles and ECA Policy
			Model Overview";
	leaf anti-virus {		leaf-list ipv4-capa {
	type boolean;		type identityref {
	description		base ipv4-capa;
	"antivirus";		}
	}
	leaf ips {
	type boolean;
	description		description
	"ips";		"Capabilities for an IPv4 packet";
			reference
			"RFC 791: Internet Protocol";
	}		}
	leaf ids {		leaf-list ipv6-capa {
	type boolean;		type identityref {
			base ipv6-capa;
			}
	description		description
	"ids";		"Capabilities for an IPv6 packet";
			reference
			"RFC 2460: Internet Protocol, Version 6 (IPv6)
			Specification - Next Header";
	}		}
	leaf url-filter {		leaf-list tcp-capa {
	type boolean;		type identityref {
	description		base tcp-capa;
	"url-filter";		}
	}
	leaf data-filter {
	type boolean;
	description		description
	"data-filter";		"Capabilities for a tcp packet";
			reference
			"RFC 793: Transmission Control Protocol";
	}		}
	leaf mail-filter {
	type boolean;		leaf-list udp-capa {
			type identityref {
			base udp-capa;
			}
	description		description
	"mail-filter";		"Capabilities for an udp packet";
			reference
			"RFC 768: User Datagram Protocol";
	}		}
	leaf sql-filter {
	type boolean;		leaf-list icmp-capa {
			type identityref {
			base icmp-capa;
			}
	description		description
	"sql-filter";		"Capabilities for an ICMP packet";
			reference
			"RFC 2460: Internet Protocol, Version 6 (IPv6) ";
	}		}
	leaf file-blocking {		}
	type boolean;
			container advanced-nsf-capabilities {
			description
			"Capabilities of advanced network security functions,
			such as anti virus, anti DDoS, IPS, and VoIP/VoLTE.";
			reference
			"RFC 8329: Framework for Interface to Network Security
			Functions - Differences from ACL Data Models
			draft-dong-i2nsf-asf-config-01: Configuration of
			Advanced Security Functions with I2NSF Security
			Controller";
			leaf-list antivirus-capa {
			type identityref {
			base antivirus-capa;
			}
	description		description
	"file-blocking";		"Capabilities for an antivirus";
			reference
			"draft-dong-i2nsf-asf-config-01: Configuration of
			Advanced Security Functions with I2NSF Security
			Controller";
	}		}
	leaf file-isolate {
	type boolean;		leaf-list antiddos-capa {
			type identityref {
			base antiddos-capa;
			}
	description		description
	"file-isolate";		"Capabilities for an antiddos";
			reference
			"draft-dong-i2nsf-asf-config-01: Configuration of
			Advanced Security Functions with I2NSF Security
			Controller";
	}		}
	leaf pkt-capture {
	type boolean;		leaf-list ips-capa {
			type identityref {
			base ips-capa;
			}
	description		description
	"pkt-capture";		"Capabilities for an ips";
			reference
			"draft-dong-i2nsf-asf-config-01: Configuration of
			Advanced Security Functions with I2NSF Security
			Controller";
	}		}
	leaf application-behavior {
	type boolean;		leaf-list http-capa {
			type identityref {
			base http-capa;
			}
	description		description
	"application-behavior";		"Capabilities for a http";
			reference
			"draft-dong-i2nsf-asf-config-01: Configuration of
			Advanced Security Functions with I2NSF Security
			Controller";
	}		}
	leaf voip-volte {
	type boolean;		leaf-list voip-volte-capa {
			type identityref {
			base voip-volte-capa;
			}
	description		description
	"voip-volte";		"Capabilities for a voip and volte";
			reference
			"draft-dong-i2nsf-asf-config-01: Configuration of
			Advanced Security Functions with I2NSF Security
			Controller";
	}		}
	}		}
	}		}
			container action-capabilities {
	grouping i2nsf-attack-mitigation-control-caps {
	description		description
	"i2nsf-attack-mitigation-control-caps";		"Capabilities of actions.
			If network security function has
	container attack-mitigation-capabilities {		the action capabilities, the network security function
	description		supports rule execution according to actions.";
	"attack-mitigation-capabilities";
	choice attack-mitigation-control-type {
	description
	"attack-mitigation-control-type";
	case ddos-attack {
	description
	"ddos-attack";
	choice ddos-attack-type {
	description
	"ddos-attack-type";
	case network-layer-ddos-attack {
	description
	"network-layer-ddos-attack";
	container network-layer-ddos-attack-types {
	description
	"network-layer-ddos-attack-type";
	leaf syn-flood-attack {
	type boolean;
	description
	"syn-flood-attack";
	}
	leaf udp-flood-attack {
	type boolean;
	description
	"udp-flood-attack";
	}
	leaf icmp-flood-attack {
	type boolean;
	description
	"icmp-flood-attack";
	}
	leaf ip-fragment-flood-attack {
	type boolean;
	description
	"ip-fragment-flood-attack";
	}
	leaf ipv6-related-attack {
	type boolean;
	description
	"ip-fragment-flood-attack";
	}
	}
	}
	case app-layer-ddos-attack {
	description
	"app-layer-ddos-attack";
	container app-layer-ddos-attack-types {
	description
	"app-layer-ddos-attack-types";
	leaf http-flood-attack {
	type boolean;
	description
	"http-flood-attack";
	}
	leaf https-flood-attack {
	type boolean;
	description
	"https-flood-attack";
	}
	leaf dns-flood-attack {
	type boolean;
	description
	"dns-flood-attack";
	}
	leaf dns-amp-flood-attack {
	type boolean;
	description
	"dns-amp-flood-attack";
	}
	leaf ssl-flood-attack {
	type boolean;
	description
	"ssl-flood-attack";
	}
	}
	}
	}
	}
	case single-packet-attack {		leaf-list ingress-action-capa {
	description		type identityref {
	"single-packet-attack";		base ingress-action-capa;
	choice single-packet-attack-type {
	description
	"single-packet-attack-type";
	case scan-and-sniff-attack {
	description
	"scan-and-sniff-attack";
	leaf ip-sweep-attack {
	type boolean;
	description
	"ip-sweep-attack";
	}
	leaf port-scanning-attack {
	type boolean;
	description
	"port-scanning-attack";
	}
	}
	case malformed-packet-attack {
	description
	"malformed-packet-attack";
	leaf ping-of-death-attack {
	type boolean;
	description
	"ping-of-death-attack";
	}
	leaf teardrop-attack {
	type boolean;
	description
	"teardrop-attack";
	}
	}
	case special-packet-attack {
	description
	"special-packet-attack";
	leaf oversized-icmp-attack {
	type boolean;
	description
	"oversized-icmp-attack";
	}
	leaf tracert-attack {
	type boolean;
	description
	"tracert-attack";
	}
	}
	}
	}
	}		}
	}
	}
	list nsf {
	key "nsf-name";
	description
	"nsf-name";
	leaf nsf-name {
	type string;
	mandatory true;
	description		description
	"nsf-name";		"Capabilities for an action";
	}		}
	uses capabilities-information;		leaf-list egress-action-capa {
			type identityref {
	container generic-nsf-capabilities {		base egress-action-capa;
	description		}
	"generic-nsf-capabilities";
	uses i2nsf-net-sec-caps;
	}
	container advanced-nsf-capabilities {
	description		description
	"advanced-nsf-capabilities";		"Capabilities for an egress action";
	uses i2nsf-advanced-sec-caps;
	}		}
	container complete-nsf-capabilities {		leaf-list log-action-capa {
			type identityref {
			base log-action-capa;
			}
	description		description
	"generic-nsf-capabilities";		"Capabilities for a log action";
	uses i2nsf-con-sec-control-caps;
	uses i2nsf-attack-mitigation-control-caps;
	}		}
	}		}
	rpc call-appropriate-nsf {		leaf-list resolution-strategy-capabilities {
			type identityref {
			base resolution-strategy-capa;
			}
	description		description
	"We can acquire appropriate NSF that we want		"Capabilities for a resolution strategy.
	If we give type of NSF that we want to use,		The resolution strategies can be used to
	we acquire the location information of NSF";		specify how to resolve conflicts that occur between
			the actions of the same or different policy rules that
			are matched and contained in this particular NSF";
			reference
			"draft-ietf-i2nsf-capability-04: Information Model
			of NSFs Capabilities - Resolution strategy";
			}
	input {		leaf-list default-action-capabilities {
	leaf nsf-type {		type identityref {
	type nsf-type;		base default-action-capa;
	mandatory true;
	description
	"This is used to acquire NSF
	This is mandatory";
	}
	uses i2nsf-it-resources;
	}
	output {
	uses i2nsf-nsf-location;
	}		}
	}		description
			"Capabilities for a default action.
			A default action is used to execute I2NSF policy rule
			when no rule matches a packet. The default action is
			defined as pass, drop, reject, alert, and mirror.";
			reference
			"draft-ietf-i2nsf-capability-04: Information Model
			of NSFs Capabilities - Default action";
			}
	}		}
	<CODE ENDS>		/*
			* Data nodes
			*/
	Figure 12: YANG Data Module of I2NSF Capability		container nsf {
			description
			"The list of capabilities of
			network security function";
			uses nsf-capabilities;
			}
			}
	8. IANA Considerations		<CODE ENDS>
	No IANA considerations exist for this document at this time. URL		Figure 3: YANG Data Module of I2NSF Capability
	will be added.
	9. Security Considerations		7. IANA Considerations
	This document introduces no additional security threats and SHOULD		This document requests IANA to register the following URI in the
	follow the security requirements as stated in [RFC8329].		"IETF XML Registry" [RFC3688]:
	10. References		URI: urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability
	10.1. Normative References		Registrant Contact: The IESG.
			XML: N/A; the requested URI is an XML namespace.
			This document requests IANA to register the following YANG module in
			the "YANG Module Names" registry [RFC7950].
			name: ietf-i2nsf-capability
			namespace: urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability
			prefix: iicapa
			reference: RFC XXXX
			8. Security Considerations
			The YANG module specified in this document defines a data schema
			designed to be accessed through network management protocols such as
			NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is
			the secure transport layer, and the required transport secure
			transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer
			is HTTPS, and the required transport secure transport is TLS
			[RFC8446].
			The NETCONF access control model [RFC8341] provides a means of
			restricting access to specific NETCONF or RESTCONF users to a
			preconfigured subset of all available NETCONF or RESTCONF protocol
			operations and content.
			9. References
			9.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the		[RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the
	Network Configuration Protocol (NETCONF)", RFC 6020,		Network Configuration Protocol (NETCONF)", RFC 6020,
	October 2010.		October 2010.
			[RFC6087] Bierman, A., "Guidelines for Authors and Reviewers of YANG
			Data Model Documents", RFC 6087, DOI 10.17487/RFC6087,
			January 2011, <https://www.rfc-editor.org/info/rfc6087>.
			[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
			and A. Bierman, Ed., "Network Configuration Protocol
			(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
			<https://www.rfc-editor.org/info/rfc6241>.
			[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
			Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
			<https://www.rfc-editor.org/info/rfc6242>.
			[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
			RFC 6991, DOI 10.17487/RFC6991, July 2013,
			<https://www.rfc-editor.org/info/rfc6991>.
	[RFC7950] Bjorklund, M., "The YANG 1.1 Data Modeling Language",		[RFC7950] Bjorklund, M., "The YANG 1.1 Data Modeling Language",
	RFC 7950, August 2016.		RFC 7950, August 2016.
			[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
			Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
			<https://www.rfc-editor.org/info/rfc8040>.
			[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
			2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
			May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	[RFC8192] Hares, S., Lopez, D., Zarny, M., Jacquenet, C., Kumar, R.,		[RFC8192] Hares, S., Lopez, D., Zarny, M., Jacquenet, C., Kumar, R.,
	and J. Jeong, "Interface to Network Security Functions		and J. Jeong, "Interface to Network Security Functions
	(I2NSF): Problem Statement and Use Cases", RFC 8192, July		(I2NSF): Problem Statement and Use Cases", RFC 8192, July
	2017.		2017.
	[RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R.		[RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R.
	Kumar, "Framework for Interface to Network Security		Kumar, "Framework for Interface to Network Security
	Functions", RFC 8329, February 2018.		Functions", RFC 8329, February 2018.
			[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
			BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
			<https://www.rfc-editor.org/info/rfc8340>.
			[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
			Access Control Model", STD 91, RFC 8341,
			DOI 10.17487/RFC8341, March 2018,
			<https://www.rfc-editor.org/info/rfc8341>.
	[RFC8431] Wang, L., Chen, M., Dass, A., Ananthakrishnan, H., Kini,		[RFC8431] Wang, L., Chen, M., Dass, A., Ananthakrishnan, H., Kini,
	S., and N. Bahadur, "A YANG Data Model for Routing		S., and N. Bahadur, "A YANG Data Model for Routing
	Information Base (RIB)", RFC RFC8431, September 2018.		Information Base (RIB)", RFC RFC8431, September 2018.
	10.2. Informative References		[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
			Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
			<https://www.rfc-editor.org/info/rfc8446>.
			9.2. Informative References
	[i2nsf-advanced-nsf-dm]		[i2nsf-advanced-nsf-dm]
	Pan, W. and L. Xia, "Configuration of Advanced Security		Pan, W. and L. Xia, "Configuration of Advanced Security
	Functions with I2NSF Security Controller", draft-dong-		Functions with I2NSF Security Controller", draft-dong-
	i2nsf-asf-config-01 (work in progress), October 2018.		i2nsf-asf-config-01 (work in progress), October 2018.
	[i2nsf-nsf-cap-im]		[i2nsf-nsf-cap-im]
	Xia, L., Strassner, J., Basile, C., and D. Lopez,		Xia, L., Strassner, J., Basile, C., and D. Lopez,
	"Information Model of NSFs Capabilities", draft-ietf-		"Information Model of NSFs Capabilities", draft-ietf-
	i2nsf-capability-04 (work in progress), October 2018.		i2nsf-capability-04 (work in progress), October 2018.
	[i2nsf-nsf-yang]		[i2nsf-nsf-yang]
	Kim, J., Jeong, J., Park, J., Hares, S., and Q. Lin,		Kim, J., Jeong, J., Park, J., Hares, S., and Q. Lin,
	"I2NSF Network Security Function-Facing Interface YANG		"I2NSF Network Security Function-Facing Interface YANG
	Data Model", draft-ietf-i2nsf-nsf-facing-interface-dm-01		Data Model", draft-ietf-i2nsf-nsf-facing-interface-dm-01
	(work in progress), July 2018.		(work in progress), July 2018.
	[i2nsf-sfc]
	Hyun, S., Jeong, J., Park, J., and S. Hares, "Service
	Function Chaining-Enabled I2NSF Architecture", draft-hyun-
	i2nsf-nsf-triggered-steering-06 (work in progress), July
	2018.
	[i2nsf-terminology]		[i2nsf-terminology]
	Hares, S., Strassner, J., Lopez, D., Xia, L., and H.		Hares, S., Strassner, J., Lopez, D., Xia, L., and H.
	Birkholz, "Interface to Network Security Functions (I2NSF)		Birkholz, "Interface to Network Security Functions (I2NSF)
	Terminology", draft-ietf-i2nsf-terminology-06 (work in		Terminology", draft-ietf-i2nsf-terminology-07 (work in
	progress), July 2018.		progress), January 2019.
	[Policy-Reconciliation]
	Basile, C., Lioy, A., Pitscheider, C., and S. Zhao, "A
	Formal Model of Policy Reconciliation",
	Euromicro Euromicro International Conference on Parallel,
	Distributed and Network-Based Processing (PDP), March
	2015.
	[supa-policy-info-model]		[supa-policy-info-model]
	Strassner, J., Halpern, J., and S. Meer, "Generic Policy		Strassner, J., Halpern, J., and S. Meer, "Generic Policy
	Information Model for Simplified Use of Policy		Information Model for Simplified Use of Policy
	Abstractions (SUPA)", draft-ietf-supa-generic-policy-info-		Abstractions (SUPA)", draft-ietf-supa-generic-policy-info-
	model-03 (work in progress), May 2017.		model-03 (work in progress), May 2017.
	Appendix A. Example: Extended VoIP-VoLTE Security Function Capabilities		Appendix A. Changes from draft-ietf-i2nsf-capability-data-model-02
	Module
	This section gives a simple example of how VoIP-VoLTE Security
	Function Capabilities module could be extended.
	module
	ex-voip-volte-capa {
	namespace "http://example.com/voip-volte-capa";
	prefix "voip-volte-capa";
	import ietf-i2nsf-capability {
	prefix capa;
	}
	augment "/capa:nsf/capa:generic-nsf-capabilities/"
	+ "capa:net-sec-control-capabilities/"
	+ "capa:condition/capa:condition-type" {
	case voice-condition {
	leaf sip-header-method {
	type boolean;
	description
	"SIP header method.";
	}
	leaf sip-header-uri {
	type boolean;
	description
	"SIP header URI.";
	}
	leaf sip-header-from {
	type boolean;
	description
	"SIP header From.";
	}
	leaf sip-header-to {
	type boolean;
	description
	"SIP header To.";
	}
	leaf sip-header-expire-time {
	type boolean;
	description
	"SIP header expire time.";
	}
	leaf sip-header-user-agent {
	type boolean;
	description
	"SIP header user agent.";
	}
	}
	}
	}
	Figure 13: Example: Extended VoIP-VoLTE Security Function
	Capabilities Module
	Appendix B. Example: Configuration XML of Capability Module
	This section gives a xml examples for a configuration of Capability
	module according to a requirement.
	B.1. Example: Configuration XML of Generic Network Security Function
	Capabilities
	This section gives a xml example for generic network security
	function capability configuration according to a requirement.
	Requirement: Register packet filter according to requirements.
	1. The location of the NSF is 221.159.112.150.
	2. The NSF can obtain the best effect if the packet was generated by
	PC or IoT.
	3. The NSF can apply policies according to time.
	4. The NSF should be able to block the source packets or destination
	packets with IPv4 address.
	5. The NSF should be able to pass, reject, or alert packets.
	6. Here is XML example for the generic network security function
	capability configuration:
	<?xml version="1.0" encoding="UTF-8"?>
	<rpc message-id="1" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
	<edit-config>
	<target>
	<running />
	</target>
	<config>
	<nsf xmlns="urn:ietf:params:xml:ns:yang:" +
	"ietf-i2nsf-capability">
	<nsf-name>Huawei-Firewall</nsf-name>
	<nsf-address>
	<ipv4-address>221.159.112.150</ipv4-address>
	</nsf-address>
	<target-device>
	<pc>true</pc>
	</target-device>
	<target-device>
	<iot>true</iot>
	</target-device>
	<generic-nsf-capabilities>
	<net-sec-control-capabilities>
	<nsc-capabilities-name>ipv4-packet-filter<nsc-capabilities-name>
	<time-zone>
	<start-time>true</start-time>
	<end-time>true</end-time>
	</time-zone>
	<condition>
	<packet-security-ipv4-condition>
	<pkt-sec-cond-ipv4-src>true</pkt-sec-cond-ipv4-src>
	<pkt-sec-cond-ipv4-dest>true</pkt-sec-cond-ipv4-dest>
	</packet-security-ipv4-condition>
	</condition>
	<action>
	<ingress-action-type>
	<pass>true</pass>
	<reject>true</reject>
	<alert>true</alert>
	</ingress-action-type>
	</action>
	</net-sec-control-capabilities>
	</generic-nsf-capabilities>
	</nsf>
	</config>
	</edit-config>
	</rpc>
	Figure 14: Example: Configuration XML for Generic Network Security
	Function Capability
	B.2. Example: Configuration XML of Extended VoIP/VoLTE Security
	Function Capabilities Module
	This section gives a xml example for extended VoIP-VoLTE security
	function capabilities (See Figure 13) configuration according to a
	requirement.
	Requirement: Register VoIP/VoLTe security function according to
	requirements.
	1. The location of the NSF is 221.159.112.151.
	2. The NSF can obtain the best effect if the packet was generated by
	VoIP-VoLTE phone.
	3. The NSF should be able to block the malicious sip packets with
	user agent.
	4. The NSF should be able to pass, reject, or alert packets.		The following changes are made from draft-ietf-i2nsf-capability-data-
			model-03:
	Here is XML example for the VoIP-VoLTE security function capabilities		o We revised this YANG data module according to guidelines for
	configuration:		authors and reviewers of YANG data model documents [RFC6087].
	<?xml version="1.0" encoding="UTF-8"?>		o We changed the structure of the overall YANG data module.
	<rpc message-id="1" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
	<edit-config>
	<target>
	<running />
	</target>
	<config>
	<nsf xmlns="urn:ietf:params:xml:ns:yang:" +
	"ietf-i2nsf-capability">
	<nsf-name>Cisco-VoIP-VoLTE</nsf-name>
	<nsf-address>
	<ipv4-address>221.159.112.151</ipv4-address>
	</nsf-address>
	<generic-nsf-capabilities>
	<net-sec-control-capabilities>
	<nsc-capabilities-name>sip-packet-filter<nsc-capabilities-name>
	<condition>
	<sip-header-user-agent>true</sip-header-user-agent>
	</condition>
	<action>
	<ingress-action-type>
	<pass>true</pass>
	<reject>true</reject>
	<alert>true</alert>
	</ingress-action-type>
	</action>
	</net-sec-control-capabilities>
	</generic-nsf-capabilities>
	</nsf>
	</config>
	</edit-config>
	</rpc>
	Figure 15: Example: Configuration XML for Extended VoIP/VoLTE		o We changed enumeration type to identity type for scalable
	Security Function Capabilities		components.
	Appendix C. Changes from draft-ietf-i2nsf-capability-data-model-01		o We added a description for the YANG tree diagram of the YANG data
			module.
	The following changes are made from draft-ietf-i2nsf-capability-data-		o We revised overall sentences of this YANG data model document.
	model-01:
	o We added capabilities of advanced network security functions such		o We added configuration examples to make it easier for reviewers to
	as anti-virus, anti-ddos, and IPS.		understand.
	Appendix D. Acknowledgments		Appendix B. Acknowledgments
	This work was supported by Institute for Information & communications		This work was supported by Institute for Information & communications
	Technology Promotion (IITP) grant funded by the Korea government		Technology Promotion (IITP) grant funded by the Korea government
	(MSIP) (No.R-20160222-002755, Cloud based Security Intelligence		(MSIP) (No.R-20160222-002755, Cloud based Security Intelligence
	Technology Development for the Customized Security Service		Technology Development for the Customized Security Service
	Provisioning).		Provisioning).
	Appendix E. Contributors		Appendix C. Contributors
	This document is made by the group effort of I2NSF working group.		This document is made by the group effort of I2NSF working group.
	Many people actively contributed to this document. The following are		Many people actively contributed to this document. The following are
	considered co-authors:		considered co-authors:
	o Hyoungshick Kim (Sungkyunkwan University)		o Hyoungshick Kim (Sungkyunkwan University)
	o Daeyoung Hyun (Sungkyunkwan University)		o Daeyoung Hyun (Sungkyunkwan University)
	o Dongjin Hong (Sungkyunkwan University)		o Dongjin Hong (Sungkyunkwan University)
End of changes. 240 change blocks.
	2454 lines changed or deleted		1418 lines changed or added
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/