draft-ietf-i2nsf-registration-interface-dm-03.txt		draft-ietf-i2nsf-registration-interface-dm-04.txt
	I2NSF Working Group S. Hyun		I2NSF Working Group S. Hyun
	Internet-Draft Chosun University		Internet-Draft Chosun University
	Intended status: Standards Track J. Jeong		Intended status: Standards Track J. Jeong
	Expires: September 29, 2019 T. Roh		Expires: December 14, 2019 T. Roh
	S. Wi		S. Wi
	Sungkyunkwan University		Sungkyunkwan University
	J. Park		J. Park
	ETRI		ETRI
	March 28, 2019		June 12, 2019
	I2NSF Registration Interface YANG Data Model		I2NSF Registration Interface YANG Data Model
	draft-ietf-i2nsf-registration-interface-dm-03		draft-ietf-i2nsf-registration-interface-dm-04
	Abstract		Abstract
	This document defines an information model and a YANG data model for		This document defines an information model and a YANG data model for
	Interface to Network Security Functions (I2NSF) Registration		Registration Interface between Security Controller and Developer's
	Interface between Security Controller and Developer's Management		Management System (DMS) in the Interface to Network Security
	System (DMS). The objective of these information and data models is		Functions (I2NSF) framework to register Network Security Functions
	to support NSF capability registration and query via I2NSF		(NSF) of the DMS into the Security Controller. The objective of
	Registration Interface.		these information and data models is to support NSF capability
			registration and query via I2NSF Registration Interface.
	Editorial Note (To be removed by RFC Editor)		Editorial Note (To be removed by RFC Editor)
	Please update these statements within the document with the RFC		Please update these statements within the document with the RFC
	number to be assigned to this document:		number to be assigned to this document:
	"This version of this YANG module is part of RFC XXXX;"		"This version of this YANG module is part of RFC XXXX;"
	"RFC XXXX: I2NSF Registration Interface YANG Data Model"		"RFC XXXX: I2NSF Registration Interface YANG Data Model"
	skipping to change at page 2, line 7 ¶		skipping to change at page 2, line 10 ¶
	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 September 29, 2019.		This Internet-Draft will expire on December 14, 2019.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 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
	skipping to change at page 2, line 46 ¶		skipping to change at page 2, line 49 ¶
	6.1. YANG Tree Diagram . . . . . . . . . . . . . . . . . . . . 8		6.1. YANG Tree Diagram . . . . . . . . . . . . . . . . . . . . 8
	6.1.1. Definition of Symbols in Tree Diagrams . . . . . . . 9		6.1.1. Definition of Symbols in Tree Diagrams . . . . . . . 9
	6.1.2. I2NSF Registration Interface . . . . . . . . . . . . 9		6.1.2. I2NSF Registration Interface . . . . . . . . . . . . 9
	6.1.3. NSF Capability Information . . . . . . . . . . . . . 11		6.1.3. NSF Capability Information . . . . . . . . . . . . . 11
	6.1.4. NSF Access Information . . . . . . . . . . . . . . . 11		6.1.4. NSF Access Information . . . . . . . . . . . . . . . 11
	6.2. YANG Data Modules . . . . . . . . . . . . . . . . . . . . 12		6.2. YANG Data Modules . . . . . . . . . . . . . . . . . . . . 12
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 17		8. Security Considerations . . . . . . . . . . . . . . . . . . . 17
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
	9.1. Normative References . . . . . . . . . . . . . . . . . . 17		9.1. Normative References . . . . . . . . . . . . . . . . . . 17
	9.2. Informative References . . . . . . . . . . . . . . . . . 17		9.2. Informative References . . . . . . . . . . . . . . . . . 18
	Appendix A. XML Example of Registration Interface Data Model . . 19		Appendix A. XML Example of Registration Interface Data Model . . 20
	A.1. Example 1: Registration for Capabilities of General		A.1. Example 1: Registration for Capabilities of General
	Firewall . . . . . . . . . . . . . . . . . . . . . . . . 19
	A.2. Example 2: Registration for Capabilities of Time based
	Firewall . . . . . . . . . . . . . . . . . . . . . . . . 20		Firewall . . . . . . . . . . . . . . . . . . . . . . . . 20
	A.3. Example 3: Registration for Capabilities of Web Filter . 22		A.2. Example 2: Registration for Capabilities of Time based
			Firewall . . . . . . . . . . . . . . . . . . . . . . . . 21
			A.3. Example 3: Registration for Capabilities of Web Filter . 23
	A.4. Example 4: Registration for Capabilities of VoIP/VoLTE		A.4. Example 4: Registration for Capabilities of VoIP/VoLTE
	Filter . . . . . . . . . . . . . . . . . . . . . . . . . 24		Filter . . . . . . . . . . . . . . . . . . . . . . . . . 25
	A.5. Example 5: Registration for Capabilities of HTTP and		A.5. Example 5: Registration for Capabilities of HTTP and
	HTTPS Flood Mitigation . . . . . . . . . . . . . . . . . 25		HTTPS Flood Mitigation . . . . . . . . . . . . . . . . . 26
	A.6. Example 6: Query for Capabilities of Time based Firewall 27		A.6. Example 6: Query for Capabilities of Time based Firewall 28
	Appendix B. NSF Lifecycle Managmenet in NFV Environments . . . . 29		Appendix B. NSF Lifecycle Managmenet in NFV Environments . . . . 30
	Appendix C. Changes from draft-ietf-i2nsf-registration-		Appendix C. Changes from draft-ietf-i2nsf-registration-
	interface-dm-02 . . . . . . . . . . . . . . . . . . 29		interface-dm-03 . . . . . . . . . . . . . . . . . . 30
	Appendix D. Acknowledgments . . . . . . . . . . . . . . . . . . 29		Appendix D. Acknowledgments . . . . . . . . . . . . . . . . . . 30
	Appendix E. Contributors . . . . . . . . . . . . . . . . . . . . 29		Appendix E. Contributors . . . . . . . . . . . . . . . . . . . . 30
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
	1. Introduction		1. Introduction
	A number of network security functions may exist in Interface to		A number of Network Security Functions (NSF) may exist in the
	Network Security Functions (I2NSF) framework [RFC8329]. Since these		Interface to Network Security Functions (I2NSF) framework [RFC8329].
	NSFs likely have different security capabilities, it is important to		Since each of these NSFs likely has different security capabilities
	register the security capabilities of each NSF into the security		from each other, it is important to register the security
	controller. In addition, it is required to search NSFs of some		capabilities of the NSF into the security controller. In addition,
	required security capabilities on demand. As an example, if		it is required to search NSFs of some required security capabilities
	additional security capabilities are required to serve some security		on demand. As an example, if additional security capabilities are
	service request(s) from an I2NSF user, the security controller should		required to serve some security service request(s) from an I2NSF
	be able to request the DMS for NSFs that have the required security		user, the security controller should be able to request the DMS for
	capabilities.		NSFs that have the required security capabilities.
	This document describes an information model (see Section 5) and a		This document describes an information model (see Section 5) and a
	YANG [RFC7950] data model (see Section 6) for the I2NSF Registration		YANG [RFC7950] data model (see Section 6) for the I2NSF Registration
	Interface [RFC8329] between the security controller and the		Interface [RFC8329] between the security controller and the
	developer's management system (DMS) to support NSF capability		developer's management system (DMS) to support NSF capability
	registration and query and NSF initiation request via the		registration and query via the registration interface. It also
	registration interface. It also describes the operations which		describes the operations which should be performed by the security
	should be performed by the security controller and the DMS via the		controller and the DMS via the Registration Interface using the
	Registration Interface using the defined model.		defined model.
	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].
	3. Terminology		3. Terminology
	This document uses the following terms defined in		This document uses the following terms defined in
	[i2nsf-terminology], [capability-im], [RFC8329],		[i2nsf-terminology], [capability-dm], [RFC8329],
	[nsf-triggered-steering], [supa-policy-data-model], and		[supa-policy-data-model], and [supa-policy-info-model]
	[supa-policy-info-model]
	o Network Security Function (NSF): A function that is responsible		o Network Security Function (NSF): A function that is responsible
	for specific treatment of received packets. A Network Security		for specific treatment of received packets. A Network Security
	Function can act at various layers of a protocol stack (e.g., at		Function can act at various layers of a protocol stack (e.g., at
	the network layer or other OSI layers). Sample Network Security		the network layer or other OSI layers). Sample Network Security
	Service Functions are as follows: Firewall, Intrusion Prevention/		Service Functions are as follows: Firewall, Intrusion Prevention/
	Detection System (IPS/IDS), Deep Packet Inspection (DPI),		Detection System (IPS/IDS), Deep Packet Inspection (DPI),
	Application Visibility and Control (AVC), network virus and		Application Visibility and Control (AVC), network virus and
	malware scanning, sandbox, Data Loss Prevention (DLP), Distributed		malware scanning, sandbox, Data Loss Prevention (DLP), Distributed
	Denial of Service (DDoS) mitigation and TLS proxy.		Denial of Service (DDoS) mitigation and TLS proxy.
	[nsf-triggered-steering]
	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
	repository, data definition language, query language,		repository, data definition language, query language,
	implementation language, and protocol. [supa-policy-info-model]		implementation language, and protocol. [supa-policy-info-model]
	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.
	skipping to change at page 5, line 25 ¶		skipping to change at page 5, line 23 ¶
	via the registration interface. DMS also uses the registration		via the registration interface. DMS also uses the registration
	interface to update the capabilities of the NSFs registered		interface to update the capabilities of the NSFs registered
	previously.		previously.
	2) In case that Security Controller fails to find any registered NSF		2) In case that Security Controller fails to find any registered NSF
	that can provide some required capabilities, Security Controller		that can provide some required capabilities, Security Controller
	queries DMS about NSF(s) having the required capabilities via the		queries DMS about NSF(s) having the required capabilities via the
	registration interface.		registration interface.
	Figure 1 shows the information model of the I2NSF registration		Figure 1 shows the information model of the I2NSF registration
	interface, which consists of three submodels: NSF capability		interface, which consists of two submodels: NSF capability
	registration, and NSF capability query. Each submodel is used for		registration and NSF capability query. Each submodel is used for the
	the operations listed above. The remainder of this section will		operations listed above. The remainder of this section will provide
	provide more in-depth explanations of each submodel.		in-depth explanations of each submodel.
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| I2NSF Registration Interface Information Model |		| I2NSF Registration Interface Information Model |
	| |		| |
	| +-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+ |		| +-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+ |
	| | NSF Capability | | NSF Capability | |		| | NSF Capability | | NSF Capability | |
	| | Registration | | Query | |		| | Registration | | Query | |
	| +-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+ |		| +-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+ |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 6, line 28 ¶		skipping to change at page 6, line 25 ¶
	| Name | | Information | | Information |		| Name | | Information | | Information |
	+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+		+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+
	Figure 2: NSF Capability Registration Sub-Model		Figure 2: NSF Capability Registration Sub-Model
	5.1.1. NSF Capability Information		5.1.1. NSF Capability Information
	NSF Capability Information basically describes the security		NSF Capability Information basically describes the security
	capabilities of an NSF. In Figure 3, we show capability objects of		capabilities of an NSF. In Figure 3, we show capability objects of
	an NSF. Following the information model of NSF capabilities defiend		an NSF. Following the information model of NSF capabilities defiend
	in [capability-im], we share the same security capabilities: Network		in [capability-dm], we share the same I2NSF security capabilities:
	Security Capabilities, Content Security Capabilities, and Attack		Time Capabilities, Event Capabilities, Condition Capabilities, Action
	Mitigation Capabilities. Also, NSF Capability Information		Capabilities, Resolution Strategy Capabilities, Default Action
			Capabilities, and IPsec Method. Also, NSF Capability Information
	additionally contains the performance capabilities of an NSF as shown		additionally contains the performance capabilities of an NSF as shown
	in Figure 3.		in Figure 3.
	+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+
	| NSF Capability |		| NSF Capability |
	| Information |		| Information |
	+-+-+-+-^-+-+-+-+-+		+-+-+-+-^-+-+-+-+-+
	|		|
	|		|
	+---------------+-------+--------------+		+----------------------+----------------------+
	| | |		| |
	| | |		| |
	+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+ |		+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
	|Network Security | |Content Security | |		| I2NSF | | Performance |
	| Capabilities | | Capabilities | |		| Capabilities | | Capabilities |
	+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+ |		+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
	|		|
	+-----------------------+--------------+		+--+-----------------+------------------+-----------------+-------+
	| |		| | | | |
	| |		+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ |
	+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+		| Time | | Event | | Condition | | Action | |
	| Performance | |Attack Mitigation|		| Capabilities| | Capabilities| | Capabilities| | Capabilities| |
	| Capabilities | | Capabilities |		+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ |
	+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+		|
			+----------------------+--------------------+-------+
			| | |
			+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ +-+-+-+-+-+-+
			| Resolution | | Default | | IPsec |
			| Strategy | | Action | | Method |
			| Capabilities| | Capabilities| +-+-+-+-+-+-+
			+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+
	Figure 3: NSF Capability Information		Figure 3: NSF Capability Information
	5.1.1.1. Performance Capabilities		5.1.1.1. Performance Capabilities
	This information represents the processing capability of an NSF.		This information represents the processing capability of an NSF.
	This information can be used to determine whether the NSF is in		This information can be used to determine whether the NSF is in
	congestion by comparing this with the workload that the NSF currently		congestion by comparing this with the workload that the NSF currently
	undergoes. Moreover, this information can specify an available		undergoes. Moreover, this information can specify an available
	amount of each type of resources such as processing power which are		amount of each type of resources such as processing power which are
	skipping to change at page 8, line 45 ¶		skipping to change at page 8, line 45 ¶
	registered NSFs has the required capabilities. In this case,		registered NSFs has the required capabilities. In this case,
	Security Controller makes a description of the required capabilities		Security Controller makes a description of the required capabilities
	by using the NSF capability information sub-model in Section 5.1.1,		by using the NSF capability information sub-model in Section 5.1.1,
	and sends DMS a query about which NSF(s) can provide these		and sends DMS a query about which NSF(s) can provide these
	capabilities.		capabilities.
	6. Data Model		6. Data Model
	6.1. YANG Tree Diagram		6.1. YANG Tree Diagram
	This section provides an overview of the YANG Tree diagram of the		This section provides the YANG Tree diagram of the I2NSF registration
	I2NSF registration interface.		interface.
	6.1.1. Definition of Symbols in Tree Diagrams		6.1.1. Definition of Symbols in 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 section. The meaning of the symbols used in the following		this section. The meaning of the symbols used in the following
	diagrams [RFC8431] is as follows:		diagrams [RFC8431] is as follows:
	Brackets "[" and "]" enclose list keys.		Brackets "[" and "]" enclose list keys.
	Abbreviations before data node names: "rw" means configuration		Abbreviations before data node names: "rw" means configuration
	skipping to change at page 10, line 45 ¶		skipping to change at page 10, line 45 ¶
	Figure 7: YANG tree of NSF Capability Query		Figure 7: YANG tree of NSF Capability Query
	Security Controller may require some additional capabilities to		Security Controller may require some additional capabilities to
	provide the security service requested by an I2NSF user, but none of		provide the security service requested by an I2NSF user, but none of
	the registered NSFs has the required capabilities. In this case,		the registered NSFs has the required capabilities. In this case,
	Security Controller makes a description of the required capabilities		Security Controller makes a description of the required capabilities
	using this module and then queries DMS about which NSF(s) can provide		using this module and then queries DMS about which NSF(s) can provide
	these capabilities. Use NETCONF RPCs to send a NSF capability query.		these capabilities. Use NETCONF RPCs to send a NSF capability query.
	Input data is query-i2nsf-capability-info and output data is nsf-		Input data is query-i2nsf-capability-info and output data is nsf-
	access-info. In Figure 7, the ietf-i2nsf-capability refers to the		access-info. In Figure 7, the ietf-i2nsf-capability refers to the
	module defined in [i2nsf-capability-dm].		module defined in [capability-dm].
	6.1.3. NSF Capability Information		6.1.3. NSF Capability Information
	This section expands the i2nsf-nsf-capability-info in Figure 6 and		This section expands the i2nsf-nsf-capability-info in Figure 6 and
	Figure 7.		Figure 7.
	NSF Capability Information		NSF Capability Information
	+--rw i2nsf-nsf-capability-info		+--rw i2nsf-nsf-capability-info
	+--rw i2nsf-capability		+--rw i2nsf-capability
	| uses ietf-i2nsf-capability		| uses ietf-i2nsf-capability
	+--rw nsf-performance-capability		+--rw nsf-performance-capability
	| uses i2nsf-nsf-performance-capability		| uses i2nsf-nsf-performance-capability
	Figure 8: YANG tree of I2NSF NSF Capability Information		Figure 8: YANG tree of I2NSF NSF Capability Information
	In Figure 8, the ietf-i2nsf-capability refers to the module defined		In Figure 8, the ietf-i2nsf-capability refers to the module defined
	in [i2nsf-capability-dm]. The i2nsf-nsf-performance-capability is		in [capability-dm]. The i2nsf-nsf-performance-capability is used to
	used to specify the performance capability of an NSF.		specify the performance capability of an NSF.
	6.1.3.1. NSF Performance Capability		6.1.3.1. NSF Performance Capability
	This section expands the i2nsf-nsf-performance-capability in		This section expands the i2nsf-nsf-performance-capability in
	Figure 8.		Figure 8.
	NSF Performance Capability		NSF Performance Capability
	+--rw i2nsf-nsf-performance-capability		+--rw i2nsf-nsf-performance-capability
	+--rw processing		+--rw processing
	| +--rw processing-average uint16		| +--rw processing-average uint16
	skipping to change at page 12, line 18 ¶		skipping to change at page 12, line 18 ¶
	+--rw nsf-address inet:ipv4-address		+--rw nsf-address inet:ipv4-address
	+--rw nsf-port-number inet:port-number		+--rw nsf-port-number inet:port-number
	Figure 10: YANG tree of I2NSF NSF Access Informantion		Figure 10: YANG tree of I2NSF NSF Access Informantion
	This module contains the network access information of an NSF that is		This module contains the network access information of an NSF that is
	required to enable network communications with the NSF.		required to enable network communications with the NSF.
	6.2. YANG Data Modules		6.2. YANG Data Modules
	This section introduces a YANG data module for the information model		This section provides YANG modules of the data model for the
	of the required data for the registration interface between Security		registration interface between Security Controller and Developer's
	Controller and Developer's Management System, as defined in		Management System, as defined in Section 5.
	Section 5.
	<CODE BEGINS> file "ietf-i2nsf-reg-interface@2019-03-28.yang"		<CODE BEGINS> file "ietf-i2nsf-reg-interface@2019-06-12.yang"
	module ietf-i2nsf-reg-interface{		module ietf-i2nsf-reg-interface{
	yang-version 1.1;		yang-version 1.1;
	namespace		namespace
	"urn:ietf:params:xml:ns:yang:ietf-i2nsf-reg-interface";		"urn:ietf:params:xml:ns:yang:ietf-i2nsf-reg-interface";
	prefix "iiregi";		prefix "iiregi";
	import ietf-inet-types{		import ietf-inet-types{
	prefix inet;		prefix inet;
	reference "RFC 6991";		reference "RFC 6991";
	skipping to change at page 13, line 34 ¶		skipping to change at page 13, line 32 ¶
	Redistribution and use in source and binary forms, with or		Redistribution and use in source and binary forms, with or
	without modification, is permitted pursuant to, and subject		without modification, is permitted pursuant to, and subject
	to the license terms contained in, the Simplified BSD License		to the license terms contained in, the Simplified BSD License
	set forth in Section 4.c of the IETF Trust's Legal Provisions		set forth in Section 4.c of the IETF Trust's Legal Provisions
	Relating to IETF Documents		Relating to IETF Documents
	(http://trustee.ietf.org/license-info).		(http://trustee.ietf.org/license-info).
	This version of this YANG module is part of RFC XXXX; see		This version of this YANG module is part of RFC XXXX; see
	the RFC itself for full legal notices.";		the RFC itself for full legal notices.";
	revision 2019-03-28 {		revision 2019-06-12 {
	description "The third revision";		description "The third revision";
	reference		reference
	"RFC XXXX: I2NSF Registration Interface YANG Data Model";		"RFC XXXX: I2NSF Registration Interface YANG Data Model";
	}		}
	rpc i2nsf-nsf-capability-query {		rpc i2nsf-nsf-capability-query {
	description		description
	"Capability information that the		"Capability information that the
	Security Controller		Security Controller
	sends to the DMS";		sends to the DMS";
	input{		input{
	skipping to change at page 17, line 12 ¶		skipping to change at page 17, line 12 ¶
	This document requests IANA to register the following YANG module in		This document requests IANA to register the following YANG module in
	the "YANG Module Names" registry [RFC7950].		the "YANG Module Names" registry [RFC7950].
	Name: ietf-i2nsf-reg-interface		Name: ietf-i2nsf-reg-interface
	Namespace: urn:ietf:params:xml:ns:yang:ietf-i2nsf-reg-interface		Namespace: urn:ietf:params:xml:ns:yang:ietf-i2nsf-reg-interface
	Prefix: iiregi		Prefix: iiregi
	Reference: RFC XXXX		Reference: RFC XXXX
	8. Security Considerations		8. Security Considerations
	This document introduces no additional security threats and SHOULD		The YANG module specified in this document defines a data schema
	follow the security requirements as stated in [RFC8329].		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 secure transport is
			Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS,
			and the required 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. References
	9.1. Normative References		9.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs toIndicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119,
			DOI 10.17487/RFC2119, March 1997,
			<https://www.rfc-editor.org/info/rfc2119>.
	[RFC3688] Mealling, M., "The IETF XML Registry", RFC 3688, January		[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
	2004.		DOI 10.17487/RFC3688, January 2004,
			<https://www.rfc-editor.org/info/rfc3688>.
	[RFC6087] Bierman, A., "Guidelines for Authors and Reviewers of YANG		[RFC6087] Bierman, A., "Guidelines for Authors and Reviewers of YANG
	Data Model Documents", RFC 6087, January 2011.		Data Model Documents", RFC 6087, DOI 10.17487/RFC6087,
			January 2011, <https://www.rfc-editor.org/info/rfc6087>.
	[RFC6991] Schoenwaelder, J., "Common YANG Data Types", RFC 6991,		[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
	July 2013.		and A. Bierman, Ed., "Network Configuration Protocol
			(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
			<https://www.rfc-editor.org/info/rfc6241>.
	[RFC7950] Bjorklund, M., "The YANG 1.1 Data Modeling Language",		[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
	RFC 7950, August 2016.		Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
			<https://www.rfc-editor.org/info/rfc6242>.
	[RFC8340] Bjorklund, M. and L. Berger, "YANG Tree Diagrams",		[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
	RFC 8340, March 2018.		RFC 6991, DOI 10.17487/RFC6991, July 2013,
			<https://www.rfc-editor.org/info/rfc6991>.
			[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
			RFC 7950, DOI 10.17487/RFC7950, August 2016,
			<https://www.rfc-editor.org/info/rfc7950>.
			[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>.
			[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>.
			[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		9.2. Informative References
	[capability-im]		[capability-dm]
	Xia, L., Strassner, J., Basile, C., and D. Lopez,		Hares, S., Jeong, J., Kim, J., Moskowitz, R., and Q. Lin,
	"Information Model of NSFs Capabilities", draft-i2nsf-		"I2NSF Capability YANG Data Model", draft-ietf-i2nsf-
	capability-04 (work in progress), October 2018.		capability-data-model-05 (work in progress), June 2019.
	[draft-ietf-nvo3-vxlan-gpe]		[draft-ietf-nvo3-vxlan-gpe]
	Maino, Ed., F., Kreeger, Ed., L., and U. Elzur, Ed.,		Maino, Ed., F., Kreeger, Ed., L., and U. Elzur, Ed.,
	"Generic Protocol Extension for VXLAN", draft-ietf-nvo3-		"Generic Protocol Extension for VXLAN", draft-ietf-nvo3-
	vxlan-gpe-06 (work in progress), April 2018.		vxlan-gpe-06 (work in progress), April 2018.
	[i2nsf-capability-dm]
	Hares, S., Jeong, J., Kim, J., Moskowitz, R., and Q. Lin,
	"I2NSF Capability YANG Data Model", draft-ietf-i2nsf-
	capability-data-model-02 (work in progress), November
	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-07 (work in		Terminology", draft-ietf-i2nsf-terminology-07 (work in
	progress), January 2019.		progress), January 2019.
	[nfv-framework]		[nfv-framework]
	"Network Functions Virtualisation (NFV); Architectureal		"Network Functions Virtualisation (NFV); Architectureal
	Framework", ETSI GS NFV 002 ETSI GS NFV 002 V1.1.1,		Framework", ETSI GS NFV 002 ETSI GS NFV 002 V1.1.1,
	October 2013.		October 2013.
	[nsf-triggered-steering]
	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.
	[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.
	[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 8431, September 2018.		Information Base (RIB)", RFC 8431, September 2018.
	[supa-policy-data-model]		[supa-policy-data-model]
	Halpern, J., Strassner, J., and S. van der Meer, "Generic		Halpern, J., Strassner, J., and S. van der Meer, "Generic
	skipping to change at page 19, line 8 ¶		skipping to change at page 20, line 8 ¶
	[supa-policy-info-model]		[supa-policy-info-model]
	Strassner, J., Halpern, J., and S. van der Meer, "Generic		Strassner, J., Halpern, J., and S. van der Meer, "Generic
	Policy Information Model for Simplified Use of Policy		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. XML Example of Registration Interface Data Model		Appendix A. XML Example of Registration Interface Data Model
	This section describes XML examples of the I2NSF Registration		This section describes XML examples of the I2NSF Registration
	Interface data model in five NSF Registration examples and one NSF		Interface data model under the assumption of registering several
	Capability Query example.		types of NSFs and querying NSF capability.
	A.1. Example 1: Registration for Capabilities of General Firewall		A.1. Example 1: Registration for Capabilities of General Firewall
	This section shows a configuration example for capabilities		This section shows an XML example for registering the capabilities of
	registration of general firewall.		general firewall.
	<i2nsf-nsf-registrations		<i2nsf-nsf-registrations
	xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-reg-interface"		xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-reg-interface"
	xmlns:capa="urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability">		xmlns:capa="urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability">
	<i2nsf-nsf-capability-registration>		<i2nsf-nsf-capability-registration>
	<nsf-name>general_firewall_capability</nsf-name>		<nsf-name>general_firewall_capability</nsf-name>
	<nsf-capability-info>		<nsf-capability-info>
	<i2nsf-capability>		<i2nsf-capability>
	<condition-capabilities>		<condition-capabilities>
	<generic-nsf-capabilities>		<generic-nsf-capabilities>
	skipping to change at page 19, line 40 ¶		skipping to change at page 20, line 40 ¶
	</generic-nsf-capabilities>		</generic-nsf-capabilities>
	</condition-capabilities>		</condition-capabilities>
	<action-capabilities>		<action-capabilities>
	<ingress-action-capa>capa:pass</ingress-action-capa>		<ingress-action-capa>capa:pass</ingress-action-capa>
	<ingress-action-capa>capa:drop</ingress-action-capa>		<ingress-action-capa>capa:drop</ingress-action-capa>
	<ingress-action-capa>capa:alert</ingress-action-capa>		<ingress-action-capa>capa:alert</ingress-action-capa>
	<egress-action-capa>capa:pass</egress-action-capa>		<egress-action-capa>capa:pass</egress-action-capa>
	<egress-action-capa>capa:drop</egress-action-capa>		<egress-action-capa>capa:drop</egress-action-capa>
	<egress-action-capa>capa:alert</egress-action-capa>		<egress-action-capa>capa:alert</egress-action-capa>
	</action-capabilities>		</action-capabilities>
	<ipsec-method>ikeless</ipsec-method>		<ipsec-method>capa:ikeless</ipsec-method>
	</i2nsf-capability>		</i2nsf-capability>
	<nsf-performance-capability>		<nsf-performance-capability>
	<processing>		<processing>
	<processing-average>1000</processing-average>		<processing-average>1000</processing-average>
	<processing-peak>5000</processing-peak>		<processing-peak>5000</processing-peak>
	</processing>		</processing>
	<bandwidth>		<bandwidth>
	<outbound>		<outbound>
	<outbound-average>1000</outbound-average>		<outbound-average>1000</outbound-average>
	<outbound-peak>5000</outbound-peak>		<outbound-peak>5000</outbound-peak>
	skipping to change at page 20, line 20 ¶		skipping to change at page 21, line 20 ¶
	<nsf-access-info>		<nsf-access-info>
	<nsf-instance-name>general_firewall</nsf-instance-name>		<nsf-instance-name>general_firewall</nsf-instance-name>
	<nsf-address>221.159.112.100</nsf-address>		<nsf-address>221.159.112.100</nsf-address>
	<nsf-port-address>3000</nsf-port-address>		<nsf-port-address>3000</nsf-port-address>
	</nsf-access-info>		</nsf-access-info>
	</i2nsf-nsf-capability-registration>		</i2nsf-nsf-capability-registration>
	</i2nsf-nsf-registrations>		</i2nsf-nsf-registrations>
	Figure 12: Configuration XML for Registration of General Firewall		Figure 12: Configuration XML for Registration of General Firewall
	Figure 12 shows the configuration XML for registration of general		Figure 12 shows the configuration XML for registering the general
	firewall and its capabilities are as follows.		firewall and its capabilities as follows.
	1. The instance name of the NSF is general_firewall.		1. The instance name of the NSF is general_firewall.
	2. The NSF can inspect protocol, exact IPv4 address, and range IPv4		2. The NSF can inspect protocol, exact IPv4 address, and range IPv4
	address for IPv4 packets.		address for IPv4 packets.
	3. The NSF can inspect exact port number and range port number for		3. The NSF can inspect exact port number and range port number for
	tcp packets.		tcp packets.
	4. The NSF can control whether the packets are allowed to pass,		4. The NSF can determine whether the packets are allowed to pass,
	drop, or alert.		drop, or alert.
	5. The NSF can support IPsec not through IKEv2, but through a		5. The NSF can support IPsec not through IKEv2, but through a
	Security Controller.		Security Controller.
	6. The NSF can have processing power and bandwidth.		6. The NSF can have processing power and bandwidth.
	7. The location of the NSF is 221.159.112.100.		7. The location of the NSF is 221.159.112.100.
	8. The port of the NSF is 3000.		8. The port of the NSF is 3000.
	A.2. Example 2: Registration for Capabilities of Time based Firewall		A.2. Example 2: Registration for Capabilities of Time based Firewall
	This section shows a configuration example for capabilities		This section shows an XML example for registering the capabilities of
	registration of time based firewall.		time-based firewall.
	<i2nsf-nsf-registrations		<i2nsf-nsf-registrations
	xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-reg-interface"		xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-reg-interface"
	xmlns:capa="urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability">		xmlns:capa="urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability">
	<i2nsf-nsf-capability-registration>		<i2nsf-nsf-capability-registration>
	<nsf-name>time_based_firewall_capability</nsf-name>		<nsf-name>time_based_firewall_capability</nsf-name>
	<nsf-capability-info>		<nsf-capability-info>
	<i2nsf-capability>		<i2nsf-capability>
	<time-capabilities>absolute-time</time-capabilities>		<time-capabilities>absolute-time</time-capabilities>
	<time-capabilities>periodic-time</time-capabilities>		<time-capabilities>periodic-time</time-capabilities>
	skipping to change at page 21, line 25 ¶		skipping to change at page 22, line 25 ¶
	</generic-nsf-capabilities>		</generic-nsf-capabilities>
	</condition-capabilities>		</condition-capabilities>
	<action-capabilities>		<action-capabilities>
	<ingress-action-capa>capa:pass</ingress-action-capa>		<ingress-action-capa>capa:pass</ingress-action-capa>
	<ingress-action-capa>capa:drop</ingress-action-capa>		<ingress-action-capa>capa:drop</ingress-action-capa>
	<ingress-action-capa>capa:alert</ingress-action-capa>		<ingress-action-capa>capa:alert</ingress-action-capa>
	<egress-action-capa>capa:pass</egress-action-capa>		<egress-action-capa>capa:pass</egress-action-capa>
	<egress-action-capa>capa:drop</egress-action-capa>		<egress-action-capa>capa:drop</egress-action-capa>
	<egress-action-capa>capa:alert</egress-action-capa>		<egress-action-capa>capa:alert</egress-action-capa>
	</action-capabilities>		</action-capabilities>
	<ipsec-method>ike</ipsec-method>		<ipsec-method>capa:ike</ipsec-method>
	</i2nsf-capability>		</i2nsf-capability>
	<nsf-performance-capability>		<nsf-performance-capability>
	<processing>		<processing>
	<processing-average>1000</processing-average>		<processing-average>1000</processing-average>
	<processing-peak>5000</processing-peak>		<processing-peak>5000</processing-peak>
	</processing>		</processing>
	<bandwidth>		<bandwidth>
	<outbound>		<outbound>
	<outbound-average>1000</outbound-average>		<outbound-average>1000</outbound-average>
	<outbound-peak>5000</outbound-peak>		<outbound-peak>5000</outbound-peak>
	skipping to change at page 22, line 7 ¶		skipping to change at page 23, line 7 ¶
	<nsf-access-info>		<nsf-access-info>
	<nsf-instance-name>time_based_firewall</nsf-instance-name>		<nsf-instance-name>time_based_firewall</nsf-instance-name>
	<nsf-address>221.159.112.110</nsf-address>		<nsf-address>221.159.112.110</nsf-address>
	<nsf-port-address>3000</nsf-port-address>		<nsf-port-address>3000</nsf-port-address>
	</nsf-access-info>		</nsf-access-info>
	</i2nsf-nsf-capability-registration>		</i2nsf-nsf-capability-registration>
	</i2nsf-nsf-registrations>		</i2nsf-nsf-registrations>
	Figure 13: Configuration XML for Registration of Time based Firewall		Figure 13: Configuration XML for Registration of Time based Firewall
	Figure 13 shows the configuration XML for registration of time based		Figure 13 shows the configuration XML for registering the time-based
	firewall and its capabilities are as follows.		firewall and its capabilities as follows.
	1. The instance name of the NSF is time_based_firewall.		1. The instance name of the NSF is time_based_firewall.
	2. The NSF can execute the security policy rule according to		2. The NSF can enforce the security policy rule according to
	absolute time and periodic time.		absolute time and periodic time.
	3. The NSF can inspect protocol, exact IPv4 address, and range IPv4		3. The NSF can inspect protocol, exact IPv4 address, and range IPv4
	address for IPv4 packets.		address for IPv4 packets.
	4. The NSF can control whether the packets are allowed to pass,		4. The NSF can determine whether the packets are allowed to pass,
	drop, or alert.		drop, or alert.
	5. The NSF can support IPsec through IKEv2.		5. The NSF can support IPsec through IKEv2.
	6. The NSF can have processing power and bandwidth.		6. The NSF can have processing power and bandwidth.
	7. The location of the NSF is 221.159.112.110.		7. The location of the NSF is 221.159.112.110.
	8. The port of the NSF is 3000.		8. The port of the NSF is 3000.
	A.3. Example 3: Registration for Capabilities of Web Filter		A.3. Example 3: Registration for Capabilities of Web Filter
	This section shows a configuration example for capabilities		This section shows an XML example for registering the capabilities of
	registration of web filter.		web filter.
	<i2nsf-nsf-registrations		<i2nsf-nsf-registrations
	xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-reg-interface"		xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-reg-interface"
	xmlns:capa="urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability">		xmlns:capa="urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability">
	<i2nsf-nsf-capability-registration>		<i2nsf-nsf-capability-registration>
	<nsf-name>web_filter_capability</nsf-name>		<nsf-name>web_filter_capability</nsf-name>
	<nsf-capability-info>		<nsf-capability-info>
	<i2nsf-capability>		<i2nsf-capability>
	<condition-capabilities>		<condition-capabilities>
	<advanced-nsf-capabilities>		<advanced-nsf-capabilities>
	skipping to change at page 23, line 6 ¶		skipping to change at page 24, line 6 ¶
	</condition-capabilities>		</condition-capabilities>
	<action-capabilities>		<action-capabilities>
	<ingress-action-capa>capa:pass</ingress-action-capa>		<ingress-action-capa>capa:pass</ingress-action-capa>
	<ingress-action-capa>capa:drop</ingress-action-capa>		<ingress-action-capa>capa:drop</ingress-action-capa>
	<ingress-action-capa>capa:alert</ingress-action-capa>		<ingress-action-capa>capa:alert</ingress-action-capa>
	<egress-action-capa>capa:pass</egress-action-capa>		<egress-action-capa>capa:pass</egress-action-capa>
	<egress-action-capa>capa:drop</egress-action-capa>		<egress-action-capa>capa:drop</egress-action-capa>
	<egress-action-capa>capa:alert</egress-action-capa>		<egress-action-capa>capa:alert</egress-action-capa>
	</action-capabilities>		</action-capabilities>
	<ipsec-method>ikeless</ipsec-method>		<ipsec-method>capa:ikeless</ipsec-method>
	</i2nsf-capability>		</i2nsf-capability>
	<nsf-performance-capability>		<nsf-performance-capability>
	<processing>		<processing>
	<processing-average>1000</processing-average>		<processing-average>1000</processing-average>
	<processing-peak>5000</processing-peak>		<processing-peak>5000</processing-peak>
	</processing>		</processing>
	<bandwidth>		<bandwidth>
	<outbound>		<outbound>
	<outbound-average>1000</outbound-average>		<outbound-average>1000</outbound-average>
	<outbound-peak>5000</outbound-peak>		<outbound-peak>5000</outbound-peak>
	skipping to change at page 23, line 35 ¶		skipping to change at page 24, line 35 ¶
	<nsf-access-info>		<nsf-access-info>
	<nsf-instance-name>web_filter</nsf-instance-name>		<nsf-instance-name>web_filter</nsf-instance-name>
	<nsf-address>221.159.112.120</nsf-address>		<nsf-address>221.159.112.120</nsf-address>
	<nsf-port-address>3000</nsf-port-address>		<nsf-port-address>3000</nsf-port-address>
	</nsf-access-info>		</nsf-access-info>
	</i2nsf-nsf-capability-registration>		</i2nsf-nsf-capability-registration>
	</i2nsf-nsf-registrations>		</i2nsf-nsf-registrations>
	Figure 14: Configuration XML for Registration of Web Filter		Figure 14: Configuration XML for Registration of Web Filter
	Figure 14 shows the configuration XML for registration of web filter		Figure 14 shows the configuration XML for registering the web filter,
	and its capabilities are as follows.		and its capabilities are as follows.
	1. The instance name of the NSF is web_filter.		1. The instance name of the NSF is web_filter.
	2. The NSF can inspect url for http and https packets.		2. The NSF can inspect url for http and https packets.
	3. The NSF can control whether the packets are allowed to pass,		3. The NSF can determine whether the packets are allowed to pass,
	drop, or alert.		drop, or alert.
	4. The NSF can support IPsec not through IKEv2, but through a		4. The NSF can support IPsec not through IKEv2, but through a
	Security Controller.		Security Controller.
	5. The NSF can have processing power and bandwidth.		5. The NSF can have processing power and bandwidth.
	6. The location of the NSF is 221.159.112.120.		6. The location of the NSF is 221.159.112.120.
	7. The port of the NSF is 3000.		7. The port of the NSF is 3000.
	A.4. Example 4: Registration for Capabilities of VoIP/VoLTE Filter		A.4. Example 4: Registration for Capabilities of VoIP/VoLTE Filter
	This section shows a configuration example for capabilities		This section shows an XML example for registering the capabilities of
	registration of VoIP/VoLTE filter.		VoIP/VoLTE filter.
	<i2nsf-nsf-registrations		<i2nsf-nsf-registrations
	xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-reg-interface"		xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-reg-interface"
	xmlns:capa="urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability">		xmlns:capa="urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability">
	<i2nsf-nsf-capability-registration>		<i2nsf-nsf-capability-registration>
	<nsf-name>voip_volte_filter_capability</nsf-name>		<nsf-name>voip_volte_filter_capability</nsf-name>
	<nsf-capability-info>		<nsf-capability-info>
	<i2nsf-capability>		<i2nsf-capability>
	<condition-capabilities>		<condition-capabilities>
	<advanced-nsf-capabilities>		<advanced-nsf-capabilities>
	skipping to change at page 24, line 32 ¶		skipping to change at page 25, line 32 ¶
	</advanced-nsf-capabilities>		</advanced-nsf-capabilities>
	</condition-capabilities>		</condition-capabilities>
	<action-capabilities>		<action-capabilities>
	<ingress-action-capa>capa:pass</ingress-action-capa>		<ingress-action-capa>capa:pass</ingress-action-capa>
	<ingress-action-capa>capa:drop</ingress-action-capa>		<ingress-action-capa>capa:drop</ingress-action-capa>
	<ingress-action-capa>capa:alert</ingress-action-capa>		<ingress-action-capa>capa:alert</ingress-action-capa>
	<egress-action-capa>capa:pass</egress-action-capa>		<egress-action-capa>capa:pass</egress-action-capa>
	<egress-action-capa>capa:drop</egress-action-capa>		<egress-action-capa>capa:drop</egress-action-capa>
	<egress-action-capa>capa:alert</egress-action-capa>		<egress-action-capa>capa:alert</egress-action-capa>
	</action-capabilities>		</action-capabilities>
	<ipsec-method>ikeless</ipsec-method>		<ipsec-method>capa:ikeless</ipsec-method>
	</i2nsf-capability>		</i2nsf-capability>
	<nsf-performance-capability>		<nsf-performance-capability>
	<processing>		<processing>
	<processing-average>1000</processing-average>		<processing-average>1000</processing-average>
	<processing-peak>5000</processing-peak>		<processing-peak>5000</processing-peak>
	</processing>		</processing>
	<bandwidth>		<bandwidth>
	<outbound>		<outbound>
	<outbound-average>1000</outbound-average>		<outbound-average>1000</outbound-average>
	<outbound-peak>5000</outbound-peak>		<outbound-peak>5000</outbound-peak>
	skipping to change at page 25, line 12 ¶		skipping to change at page 26, line 12 ¶
	<nsf-access-info>		<nsf-access-info>
	<nsf-instance-name>voip_volte_filter</nsf-instance-name>		<nsf-instance-name>voip_volte_filter</nsf-instance-name>
	<nsf-address>221.159.112.130</nsf-address>		<nsf-address>221.159.112.130</nsf-address>
	<nsf-port-address>3000</nsf-port-address>		<nsf-port-address>3000</nsf-port-address>
	</nsf-access-info>		</nsf-access-info>
	</i2nsf-nsf-capability-registration>		</i2nsf-nsf-capability-registration>
	</i2nsf-nsf-registrations>		</i2nsf-nsf-registrations>
	Figure 15: Configuration XML for Registration of VoIP/VoLTE Filter		Figure 15: Configuration XML for Registration of VoIP/VoLTE Filter
	Figure 15 shows the configuration XML for registration of VoIP/VoLTE		Figure 15 shows the configuration XML for registering VoIP/VoLTE
	filter and its capabilities are as follows.		filter, and its capabilities are as follows.
	1. The instance name of the NSF is voip_volte_filter.		1. The instance name of the NSF is voip_volte_filter.
	2. The NSF can inspect voice id for VoIP/VoLTE packets.		2. The NSF can inspect voice id for VoIP/VoLTE packets.
	3. The NSF can control whether the packets are allowed to pass,		3. The NSF can determine whether the packets are allowed to pass,
	drop, or alert.		drop, or alert.
	4. The NSF can support IPsec not through IKEv2, but through a		4. The NSF can support IPsec not through IKEv2, but through a
	Security Controller.		Security Controller.
	5. The NSF can have processing power and bandwidth.		5. The NSF can have processing power and bandwidth.
	6. The location of the NSF is 221.159.112.130.		6. The location of the NSF is 221.159.112.130.
	7. The port of the NSF is 3000.		7. The port of the NSF is 3000.
	A.5. Example 5: Registration for Capabilities of HTTP and HTTPS Flood		A.5. Example 5: Registration for Capabilities of HTTP and HTTPS Flood
	Mitigation		Mitigation
	This section shows a configuration example for capabilities		This section shows an XML example for registering the capabilities of
	registration of http and https flood mitigation.		http and https flood mitigation.
	<i2nsf-nsf-registrations		<i2nsf-nsf-registrations
	xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-reg-interface"		xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-reg-interface"
	xmlns:capa="urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability">		xmlns:capa="urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability">
	<i2nsf-nsf-capability-registration>		<i2nsf-nsf-capability-registration>
	<nsf-name>		<nsf-name>
	http_and_h ttps_flood_mitigation_capability		http_and_h ttps_flood_mitigation_capability
	</nsf-name>		</nsf-name>
	<nsf-capability-info>		<nsf-capability-info>
	<i2nsf-capability>		<i2nsf-capability>
	skipping to change at page 26, line 14 ¶		skipping to change at page 27, line 14 ¶
	</condition-capabilities>		</condition-capabilities>
	<action-capabilities>		<action-capabilities>
	<ingress-action-capa>capa:pass</ingress-action-capa>		<ingress-action-capa>capa:pass</ingress-action-capa>
	<ingress-action-capa>capa:drop</ingress-action-capa>		<ingress-action-capa>capa:drop</ingress-action-capa>
	<ingress-action-capa>capa:alert</ingress-action-capa>		<ingress-action-capa>capa:alert</ingress-action-capa>
	<egress-action-capa>capa:pass</egress-action-capa>		<egress-action-capa>capa:pass</egress-action-capa>
	<egress-action-capa>capa:drop</egress-action-capa>		<egress-action-capa>capa:drop</egress-action-capa>
	<egress-action-capa>capa:alert</egress-action-capa>		<egress-action-capa>capa:alert</egress-action-capa>
	</action-capabilities>		</action-capabilities>
	<ipsec-method>ike</ipsec-method>		<ipsec-method>capa:ike</ipsec-method>
	</i2nsf-capability>		</i2nsf-capability>
	<nsf-performance-capability>		<nsf-performance-capability>
	<processing>		<processing>
	<processing-average>1000</processing-average>		<processing-average>1000</processing-average>
	<processing-peak>5000</processing-peak>		<processing-peak>5000</processing-peak>
	</processing>		</processing>
	<bandwidth>		<bandwidth>
	<outbound>		<outbound>
	<outbound-average>1000</outbound-average>		<outbound-average>1000</outbound-average>
	<outbound-peak>5000</outbound-peak>		<outbound-peak>5000</outbound-peak>
	skipping to change at page 26, line 46 ¶		skipping to change at page 27, line 46 ¶
	</nsf-instance-name>		</nsf-instance-name>
	<nsf-address>221.159.112.140</nsf-address>		<nsf-address>221.159.112.140</nsf-address>
	<nsf-port-address>3000</nsf-port-address>		<nsf-port-address>3000</nsf-port-address>
	</nsf-access-info>		</nsf-access-info>
	</i2nsf-nsf-capability-registration>		</i2nsf-nsf-capability-registration>
	</i2nsf-nsf-registrations>		</i2nsf-nsf-registrations>
	Figure 16: Configuration XML for Registration of of HTTP and HTTPS		Figure 16: Configuration XML for Registration of of HTTP and HTTPS
	Flood Mitigation		Flood Mitigation
	Figure 16 shows the configuration XML for registration of VoIP/VoLTE		Figure 16 shows the configuration XML for registering the http and
	filter and its capabilities are as follows.		https flood mitigator, and its capabilities are as follows.
	1. The instance name of the NSF is http_and_https_flood_mitigation.		1. The instance name of the NSF is http_and_https_flood_mitigation.
	2. The NSF can control the amount of packets for http and https		2. The NSF can control the amount of packets for http and https
	packets.		packets.
	3. The NSF can control whether the packets are allowed to pass,		3. The NSF can determine whether the packets are allowed to pass,
	drop, or alert.		drop, or alert.
	4. The NSF can support IPsec through IKEv2.		4. The NSF can support IPsec through IKEv2.
	5. The NSF can have processing power and bandwidth.		5. The NSF can have processing power and bandwidth.
	6. The location of the NSF is 221.159.112.140.		6. The location of the NSF is 221.159.112.140.
	7. The port of the NSF is 3000.		7. The port of the NSF is 3000.
	A.6. Example 6: Query for Capabilities of Time based Firewall		A.6. Example 6: Query for Capabilities of Time based Firewall
	This section shows a configuration example for capabilities query of		This section shows an XML example for querying the capabilities of
	Time based Firewall.		time-based firewall.
	<rpc message-id="101"		<rpc message-id="101"
	xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">		xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
	<i2nsf-nsf-capability-query		<i2nsf-nsf-capability-query
	xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-reg-interface"		xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-reg-interface"
	xmlns:capa="urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability">		xmlns:capa="urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability">
	<query-i2nsf-capability-info>		<query-i2nsf-capability-info>
	<time-capabilities>absolute-time</time-capabilities>		<time-capabilities>absolute-time</time-capabilities>
	<time-capabilities>periodic-time</time-capabilities>		<time-capabilities>periodic-time</time-capabilities>
	<condition-capabilities>		<condition-capabilities>
	skipping to change at page 28, line 28 ¶		skipping to change at page 29, line 28 ¶
	</generic-nsf-capabilities>		</generic-nsf-capabilities>
	</condition-capabilities>		</condition-capabilities>
	<action-capabilities>		<action-capabilities>
	<ingress-action-capa>capa:pass</ingress-action-capa>		<ingress-action-capa>capa:pass</ingress-action-capa>
	<ingress-action-capa>capa:drop</ingress-action-capa>		<ingress-action-capa>capa:drop</ingress-action-capa>
	<ingress-action-capa>capa:alert</ingress-action-capa>		<ingress-action-capa>capa:alert</ingress-action-capa>
	<egress-action-capa>capa:pass</egress-action-capa>		<egress-action-capa>capa:pass</egress-action-capa>
	<egress-action-capa>capa:drop</egress-action-capa>		<egress-action-capa>capa:drop</egress-action-capa>
	<egress-action-capa>capa:alert</egress-action-capa>		<egress-action-capa>capa:alert</egress-action-capa>
	</action-capabilities>		</action-capabilities>
	<ipsec-method>ikeless</ipsec-method>		<ipsec-method>capa:ikeless</ipsec-method>
	</query-i2nsf-capability-info>		</query-i2nsf-capability-info>
	</i2nsf-nsf-capability-query>		</i2nsf-nsf-capability-query>
	</rpc>		</rpc>
	<rpc-reply message-id="101"		<rpc-reply message-id="101"
	xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">		xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
	<nsf-access-info		<nsf-access-info
	xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-reg-interface">		xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-reg-interface">
	<nsf-instance-name>time-based-firewall</nsf-instance-name>		<nsf-instance-name>time-based-firewall</nsf-instance-name>
	<nsf-address>221.159.223.250</nsf-address>		<nsf-address>221.159.223.250</nsf-address>
	<nsf-port-address>8080</nsf-port-address>		<nsf-port-address>8080</nsf-port-address>
	</nsf-access-info>		</nsf-access-info>
	</rpc-reply>		</rpc-reply>
	Figure 17: Configuration XML for Query of Time based Firewall		Figure 17: Configuration XML for Query of Time-based Firewall
	Figure 17 shows the configuration of input data and output data XML		Figure 17 shows the XML configuration for querying the capabilities
	for nsf capability query of time based firewall.		of the time-based firewall.
	Appendix B. NSF Lifecycle Managmenet in NFV Environments		Appendix B. NSF Lifecycle Managmenet in NFV Environments
	Network Functions Virtualization (NFV) can be used to implement I2NSF		Network Functions Virtualization (NFV) can be used to implement I2NSF
	framework. In NFV environments, NSFs are deployed as virtual network		framework. In NFV environments, NSFs are deployed as virtual network
	functions (VNFs). Security Controller can be implemented as an		functions (VNFs). Security Controller can be implemented as an
	Element Management (EM) of the NFV architecture, and is connected		Element Management (EM) of the NFV architecture, and is connected
	with the VNF Manager (VNFM) via the Ve-Vnfm interface		with the VNF Manager (VNFM) via the Ve-Vnfm interface
	[nfv-framework]. Security Controller can use this interface for the		[nfv-framework]. Security Controller can use this interface for the
	purpose of the lifecycle management of NSFs. If some NSFs need to be		purpose of the lifecycle management of NSFs. If some NSFs need to be
	instantiated to enforce security policies in the I2NSF framework,		instantiated to enforce security policies in the I2NSF framework,
	Security Controller could request the VNFM to instantiate them		Security Controller could request the VNFM to instantiate them
	through the Ve-Vnfm interface. Or if an NSF, running as a VNF, is		through the Ve-Vnfm interface. Or if an NSF, running as a VNF, is
	not used by any traffic flows for a time period, Security Controller		not used by any traffic flows for a time period, Security Controller
	may request deinstantiating it through the interface for efficient		may request deinstantiating it through the interface for efficient
	resource utilization.		resource utilization.
	Appendix C. Changes from draft-ietf-i2nsf-registration-interface-dm-02		Appendix C. Changes from draft-ietf-i2nsf-registration-interface-dm-03
	The following changes have been made from draft-ietf-i2nsf-		The following changes have been made from draft-ietf-i2nsf-
	registration-interface-dm-02:		registration-interface-dm-03:
	o Appendix A. added an IPsec field in the XML examples of the		o In Section 5.1.1, Figure 3 and sentences are revised to be
	registration interface data model for five NSF Registration		synchronized with the I2NSF Capability YANG Data Model, including
	examples and one NSF Capability Query example.		IPsec method support.
	Appendix D. Acknowledgments		Appendix D. 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(MSIP)		Technology Promotion (IITP) grant funded by the Korea government
	(No.R-20160222-002755, Cloud based Security Intelligence Technology		(MSIP)(No. R-20160222-002755, Cloud based Security Intelligence
	Development for the Customized Security Service Provisioning).		Technology Development for the Customized Security Service
			Provisioning).
	Appendix E. Contributors		Appendix E. 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 Jinyong Tim Kim (Sungkyunkwan University)		o Jinyong Tim Kim (Sungkyunkwan University)
			o Chaehong Chung (Sungkyunkwan University)
	o Susan Hares (Huawei)		o Susan Hares (Huawei)
	o Diego R. Lopez (Telefonica)		o Diego R. Lopez (Telefonica)
	o Chung, Chaehong (Sungkyunkwan University)
	Authors' Addresses		Authors' Addresses
	Sangwon Hyun		Sangwon Hyun
	Department of Computer Engineering		Department of Computer Engineering
	Chosun University		Chosun University
	309, Pilmun-daero, Dong-gu		309, Pilmun-daero, Dong-gu
	Gwangju, Jeollanam-do 61452		Gwangju, Jeollanam-do 61452
	Republic of Korea		Republic of Korea
	EMail: shyun@chosun.ac.kr		EMail: shyun@chosun.ac.kr
	Jaehoon Paul Jeong		Jaehoon Paul Jeong
	Department of Software		Department of Computer Science and Engineering
	Sungkyunkwan University		Sungkyunkwan University
	2066 Seobu-Ro, Jangan-Gu		2066 Seobu-Ro, Jangan-Gu
	Suwon, Gyeonggi-Do 16419		Suwon, Gyeonggi-Do 16419
	Republic of Korea		Republic of Korea
	Phone: +82 31 299 4957		Phone: +82 31 299 4957
	Fax: +82 31 290 7996		Fax: +82 31 290 7996
	EMail: pauljeong@skku.edu		EMail: pauljeong@skku.edu
	URI: http://iotlab.skku.edu/people-jaehoon-jeong.php		URI: http://iotlab.skku.edu/people-jaehoon-jeong.php
	Taekyun Roh		Taekyun Roh
	Electrical Computer Engineering		Department of Electronic, Electrical and Computer Engineering
	Sungkyunkwan University		Sungkyunkwan University
	2066 Seobu-Ro, Jangan-Gu		2066 Seobu-Ro, Jangan-Gu
	Suwon, Gyeonggi-Do 16419		Suwon, Gyeonggi-Do 16419
	Republic of Korea		Republic of Korea
	Phone: +82 31 290 7222		Phone: +82 31 290 7222
	Fax: +82 31 299 6673		Fax: +82 31 299 6673
	EMail: tkroh0198@skku.edu		EMail: tkroh0198@skku.edu
	Sarang Wi		Sarang Wi
	Electrical Computer Engineering		Department of Electronic, Electrical and Computer Engineering
	Sungkyunkwan University		Sungkyunkwan University
	2066 Seobu-Ro, Jangan-Gu		2066 Seobu-Ro, Jangan-Gu
	Suwon, Gyeonggi-Do 16419		Suwon, Gyeonggi-Do 16419
	Republic of Korea		Republic of Korea
	Phone: +82 31 290 7222		Phone: +82 31 290 7222
	Fax: +82 31 299 6673		Fax: +82 31 299 6673
	EMail: dnl9795@skku.edu		EMail: dnl9795@skku.edu
	Jung-Soo Park		Jung-Soo Park
	Electronics and Telecommunications Research Institute		Electronics and Telecommunications Research Institute
End of changes. 69 change blocks.
	159 lines changed or deleted		192 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/