draft-ietf-i2nsf-capability-data-model-09.txt		draft-ietf-i2nsf-capability-data-model-10.txt
	I2NSF Working Group S. Hares, Ed.		I2NSF Working Group S. Hares, Ed.
	Internet-Draft Huawei		Internet-Draft Huawei
	Intended status: Standards Track J. Jeong, Ed.		Intended status: Standards Track J. Jeong, Ed.
	Expires: March 1, 2021 J. Kim		Expires: March 10, 2021 J. Kim
	Sungkyunkwan University		Sungkyunkwan University
	R. Moskowitz		R. Moskowitz
	HTT Consulting		HTT Consulting
	Q. Lin		Q. Lin
	Huawei		Huawei
	August 28, 2020		September 6, 2020
	I2NSF Capability YANG Data Model		I2NSF Capability YANG Data Model
	draft-ietf-i2nsf-capability-data-model-09		draft-ietf-i2nsf-capability-data-model-10
	Abstract		Abstract
	This document defines a YANG data model for the capabilities of		This document defines a YANG data model for the capabilities of
	various Network Security Functions (NSFs) in the Interface to Network		various Network Security Functions (NSFs) in the Interface to Network
	Security Functions (I2NSF) framework to centrally manage the		Security Functions (I2NSF) framework to centrally manage the
	capabilities of the various NSFs.		capabilities of the various NSFs.
	Status of This Memo		Status of This Memo
	skipping to change at page 1, line 39 ¶		skipping to change at page 1, line 39 ¶
	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 March 1, 2021.		This Internet-Draft will expire on March 10, 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2020 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 . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3
	4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4		4. YANG Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 6
	5. YANG Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 6		4.1. Network Security Function (NSF) Capabilities . . . . . . 6
	5.1. Network Security Function (NSF) Capabilities . . . . . . 6		5. YANG Data Model of I2NSF NSF Capability . . . . . . . . . . . 9
	6. YANG Data Model of I2NSF NSF Capability . . . . . . . . . . . 9		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40		7. Security Considerations . . . . . . . . . . . . . . . . . . . 40
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 40		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 41
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 41		8.1. Normative References . . . . . . . . . . . . . . . . . . 41
	9.1. Normative References . . . . . . . . . . . . . . . . . . 41		8.2. Informative References . . . . . . . . . . . . . . . . . 44
	9.2. Informative References . . . . . . . . . . . . . . . . . 44
	Appendix A. Configuration Examples . . . . . . . . . . . . . . . 45		Appendix A. Configuration Examples . . . . . . . . . . . . . . . 45
	A.1. Example 1: Registration for the Capabilities of a General		A.1. Example 1: Registration for the Capabilities of a General
	Firewall . . . . . . . . . . . . . . . . . . . . . . . . 45		Firewall . . . . . . . . . . . . . . . . . . . . . . . . 45
	A.2. Example 2: Registration for the Capabilities of a Time-		A.2. Example 2: Registration for the Capabilities of a Time-
	based Firewall . . . . . . . . . . . . . . . . . . . . . 47		based Firewall . . . . . . . . . . . . . . . . . . . . . 47
	A.3. Example 3: Registration for the Capabilities of a Web		A.3. Example 3: Registration for the Capabilities of a Web
	Filter . . . . . . . . . . . . . . . . . . . . . . . . . 48		Filter . . . . . . . . . . . . . . . . . . . . . . . . . 48
	A.4. Example 4: Registration for the Capabilities of a		A.4. Example 4: Registration for the Capabilities of a
	VoIP/VoLTE Filter . . . . . . . . . . . . . . . . . . . . 49		VoIP/VoLTE Filter . . . . . . . . . . . . . . . . . . . . 49
	A.5. Example 5: Registration for the Capabilities of a HTTP		A.5. Example 5: Registration for the Capabilities of a HTTP
	skipping to change at page 3, line 38 ¶		skipping to change at page 3, line 37 ¶
	o Definition for action capabilities of generic network security		o Definition for action capabilities of generic network security
	functions.		functions.
	o Definition for resolution strategy capabilities of generic network		o Definition for resolution strategy capabilities of generic network
	security functions.		security functions.
	o Definition for default action capabilities of generic network		o Definition for default action capabilities of generic network
	security functions.		security functions.
	2. Requirements Language		2. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].
	3. Terminology
	This document uses the terminology described in [RFC8329].		This document uses the terminology described in [RFC8329].
	This document follows the guidelines of [RFC8407], uses the common		This document follows the guidelines of [RFC8407], uses the common
	YANG types defined in [RFC6991], and adopts the Network Management		YANG types defined in [RFC6991], and adopts the Network Management
	Datastore Architecture (NMDA). The meaning of the symbols in tree		Datastore Architecture (NMDA). The meaning of the symbols in tree
	diagrams is defined in [RFC8340].		diagrams is defined in [RFC8340].
	4. Overview		3. Overview
	This section provides as overview of how the YANG data model can be		This section provides as overview of how the YANG data model can be
	used in the I2NSF framework described in [RFC8329]. Figure 1 shows		used in the I2NSF framework described in [RFC8329]. Figure 1 shows
	the capabilities (e.g., firewall and web filter) of NSFs in the I2NSF		the capabilities (e.g., firewall and web filter) of NSFs in the I2NSF
	Framework. As shown in this figure, an NSF Developer's Management		Framework. As shown in this figure, an NSF Developer's Management
	System can register NSFs and the capabilities that the network		System can register NSFs and the capabilities that the network
	security device can support. To register NSFs in this way, the		security device can support. To register NSFs in this way, the
	Developer's Management System utilizes this standardized capability		Developer's Management System utilizes this standardized capability
	YANG data model through the I2NSF Registration Interface [RFC8329].		YANG data model through the I2NSF Registration Interface [RFC8329].
	That is, this Registration Interface uses the YANG module described		That is, this Registration Interface uses the YANG module described
	skipping to change at page 6, line 18 ¶		skipping to change at page 6, line 18 ¶
	and NSF-1 in Developer's Management System B) which can support		and NSF-1 in Developer's Management System B) which can support
	the capabilities (i.e., IPv6). This lets an I2NSF User not		the capabilities (i.e., IPv6). This lets an I2NSF User not
	consider NSFs where the rule is applied.		consider NSFs where the rule is applied.
	o If NSFs encounter the suspicious IPv6 packets of malicious users,		o If NSFs encounter the suspicious IPv6 packets of malicious users,
	they can filter the packets out according to the configured		they can filter the packets out according to the configured
	security policy rule. Therefore, the security policy rule against		security policy rule. Therefore, the security policy rule against
	the malicious users' packets can be automatically applied to		the malicious users' packets can be automatically applied to
	appropriate NSFs without human intervention.		appropriate NSFs without human intervention.
	5. YANG Tree Diagram		4. YANG Tree Diagram
	This section shows a YANG tree diagram of capabilities of network		This section shows a YANG tree diagram of capabilities of network
	security functions, as defined in the [I-D.ietf-i2nsf-capability].		security functions, as defined in the [I-D.ietf-i2nsf-capability].
	5.1. Network Security Function (NSF) Capabilities		4.1. Network Security Function (NSF) Capabilities
	This section explains a YANG tree diagram of NSF capabilities and its		This section explains a YANG tree diagram of NSF capabilities and its
	features. Figure 2 shows a YANG tree diagram of NSF capabilities.		features. Figure 2 shows a YANG tree diagram of NSF capabilities.
	The NSF capabilities in the tree include time capabilities, event		The NSF capabilities in the tree include time capabilities, event
	capabilities, condition capabilities, action capabilities, resolution		capabilities, condition capabilities, action capabilities, resolution
	strategy capabilities, and default action capabilities. Those		strategy capabilities, and default action capabilities. Those
	capabilities can be tailored or extended according to a vendor's		capabilities can be tailored or extended according to a vendor's
	specific requirements. Refer to the NSF capabilities information		specific requirements. Refer to the NSF capabilities information
	model for detailed discussion [I-D.ietf-i2nsf-capability].		model for detailed discussion [I-D.ietf-i2nsf-capability].
	skipping to change at page 9, line 14 ¶		skipping to change at page 9, line 14 ¶
	alert, and mirror. See Section 3.4.2 (Conflict, Resolution Strategy		alert, and mirror. See Section 3.4.2 (Conflict, Resolution Strategy
	and Default Action) in [I-D.ietf-i2nsf-capability] for more		and Default Action) in [I-D.ietf-i2nsf-capability] for more
	information about the default action.		information about the default action.
	IPsec method capabilities are used to specify capabilities of how to		IPsec method capabilities are used to specify capabilities of how to
	support an Internet Key Exchange (IKE) for the security		support an Internet Key Exchange (IKE) for the security
	communication. The default action capabilities are defined as IKE or		communication. The default action capabilities are defined as IKE or
	IKE-less. See [I-D.ietf-i2nsf-sdn-ipsec-flow-protection] for more		IKE-less. See [I-D.ietf-i2nsf-sdn-ipsec-flow-protection] for more
	information about the SDN-based IPsec flow protection in I2NSF.		information about the SDN-based IPsec flow protection in I2NSF.
	6. YANG Data Model of I2NSF NSF Capability		5. YANG Data Model of I2NSF NSF Capability
	This section introduces a YANG module for NSFs' capabilities, as		This section introduces a YANG module for NSFs' capabilities, as
	defined in the [I-D.ietf-i2nsf-capability].		defined in the [I-D.ietf-i2nsf-capability].
	This YANG module imports from [RFC6991]. It makes references to [RFC		This YANG module imports from [RFC6991]. It makes references to [RFC
	0768][RFC0790][RFC0791][RFC0792][RFC0793][RFC3261][RFC4443][RFC8200][		0768][IANA-Protocol-Numbers][RFC0791][RFC0792][RFC0793][RFC3261][RFC4
	RFC8329][I-D.ietf-i2nsf-capability][I-D.ietf-i2nsf-nsf-monitoring-dat		443][RFC8200][RFC8329][I-D.ietf-i2nsf-capability][I-D.ietf-i2nsf-nsf-
	a-model][I-D.ietf-i2nsf-sdn-ipsec-flow-protection].		monitoring-data-model][I-D.ietf-i2nsf-sdn-ipsec-flow-protection].
	<CODE BEGINS> file "ietf-i2nsf-capability@2020-08-28.yang"		<CODE BEGINS> file "ietf-i2nsf-capability@2020-09-06.yang"
	module ietf-i2nsf-capability {		module ietf-i2nsf-capability {
	yang-version 1.1;		yang-version 1.1;
	namespace		namespace
	"urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability";		"urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability";
	prefix		prefix
	nsfcap;		nsfcap;
	organization		organization
	"IETF I2NSF (Interface to Network Security Functions)		"IETF I2NSF (Interface to Network Security Functions)
	skipping to change at page 10, line 20 ¶		skipping to change at page 10, line 20 ¶
	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 "2020-08-28"{		// RFC Ed.: replace XXXX with an actual RFC number and remove
			// this note.
			revision "2020-09-06"{
	description "Initial revision.";		description "Initial revision.";
	reference		reference
	"RFC XXXX: I2NSF Capability YANG Data Model";		"RFC XXXX: I2NSF Capability YANG Data Model";
			// RFC Ed.: replace XXXX with an actual RFC number and remove
			// this note.
	}		}
	/*		/*
	* Identities		* Identities
	*/		*/
	identity event {		identity event {
	description		description
	"Base identity for I2NSF policy events.";		"Base identity for I2NSF policy events.";
	reference		reference
	skipping to change at page 15, line 39 ¶		skipping to change at page 15, line 42 ¶
	condition capability";		condition capability";
	reference		reference
	"RFC 791: Internet Protocol - Time To Live (TTL)";		"RFC 791: Internet Protocol - Time To Live (TTL)";
	}		}
	identity ipv4-protocol {		identity ipv4-protocol {
	base ipv4-capability;		base ipv4-capability;
	description		description
	"Identity for IPv4 protocol condition capability";		"Identity for IPv4 protocol condition capability";
	reference		reference
	"RFC 790: Assigned numbers - Assigned Internet		"IANA Website: Assigned Internet Protocol Numbers
	Protocol Number		- Protocol Number for IPv4
	RFC 791: Internet Protocol - Protocol";		RFC 791: Internet Protocol - Protocol";
	}		}
	identity exact-ipv4-address {		identity exact-ipv4-address {
	base ipv4-capability;		base ipv4-capability;
	description		description
	"Identity for exact-match IPv4 address		"Identity for exact-match IPv4 address
	condition capability";		condition capability";
	reference		reference
	"RFC 791: Internet Protocol - Address";		"RFC 791: Internet Protocol - Address";
	}		}
	identity range-ipv4-address {		identity range-ipv4-address {
	base ipv4-capability;		base ipv4-capability;
	description		description
	"Identity for range-match IPv4 address condition		"Identity for range-match IPv4 address condition
	capability";		capability";
	reference		reference
	"RFC 791: Internet Protocol - Address";		"RFC 791: Internet Protocol - Address";
	}		}
	identity ipv4-ip-opts {		identity ipv4-ip-opts {
	skipping to change at page 18, line 22 ¶		skipping to change at page 18, line 24 ¶
	identity range-ipv6-hop-limit {		identity range-ipv6-hop-limit {
	base ipv6-capability;		base ipv6-capability;
	description		description
	"Identity for range-match IPv6 hop limit condition		"Identity for range-match IPv6 hop limit condition
	capability";		capability";
	reference		reference
	"RFC 8200: Internet Protocol, Version 6 (IPv6)		"RFC 8200: Internet Protocol, Version 6 (IPv6)
	Specification - Hop Limit";		Specification - Hop Limit";
	}		}
			identity ipv6-protocol {
			base ipv6-capability;
			description
			"Identity for IPv6 protocol condition capability";
			reference
			"IANA Website: Assigned Internet Protocol Numbers
			- Protocol Number for IPv6
			RFC 8200: Internet Protocol, Version 6 (IPv6)
			Specification - Protocol";
			}
	identity exact-ipv6-address {		identity exact-ipv6-address {
	base ipv6-capability;		base ipv6-capability;
	description		description
	"Identity for exact-match IPv6 address condition		"Identity for exact-match IPv6 address condition
	capability";		capability";
	reference		reference
	"RFC 8200: Internet Protocol, Version 6 (IPv6)		"RFC 8200: Internet Protocol, Version 6 (IPv6)
	Specification - Address";		Specification - Address";
	}		}
	skipping to change at page 40, line 5 ¶		skipping to change at page 40, line 14 ¶
	description		description
	"The name of Network Security Function (NSF)";		"The name of Network Security Function (NSF)";
	}		}
	}		}
	}		}
	<CODE ENDS>		<CODE ENDS>
	Figure 3: YANG Data Module of I2NSF Capability		Figure 3: YANG Data Module of I2NSF Capability
	7. IANA Considerations		6. IANA Considerations
	This document requests IANA to register the following URI in the		This document requests IANA to register the following URI in the
	"IETF XML Registry" [RFC3688]:		"IETF XML Registry" [RFC3688]:
	URI: urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability		URI: urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability
	Registrant Contact: The IESG.		Registrant Contact: The IESG.
	XML: N/A; the requested URI is an XML namespace.		XML: N/A; the requested URI is an XML namespace.
	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][RFC8525]:		the "YANG Module Names" registry [RFC7950][RFC8525]:
	name: ietf-i2nsf-capability		name: ietf-i2nsf-capability
	namespace: urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability		namespace: urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability
	prefix: nsfcap		prefix: nsfcap
	reference: RFC XXXX		reference: RFC XXXX
	8. Security Considerations		// RFC Ed.: replace XXXX with an actual RFC number and remove
			// this note.
			7. Security Considerations
	The YANG module specified in this document defines a data schema		The YANG module specified in this document defines a data schema
	designed to be accessed through network management protocols such as		designed to be accessed through network management protocols such as
	NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is		NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is
	the secure transport layer, and the required transport secure		the secure transport layer, and the required transport secure
	transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer		transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer
	is HTTPS, and the required transport secure transport is TLS		is HTTPS, and the required transport secure transport is TLS
	[RFC8446].		[RFC8446].
	The NETCONF access control model [RFC8341] provides a means of		The NETCONF access control model [RFC8341] provides a means of
	skipping to change at page 41, line 11 ¶		skipping to change at page 41, line 25 ¶
	Some of the readable data nodes in this YANG module may be considered		Some of the readable data nodes in this YANG module may be considered
	sensitive or vulnerable in some network environments. It is thus		sensitive or vulnerable in some network environments. It is thus
	important to control read access (e.g., via get, get-config, or		important to control read access (e.g., via get, get-config, or
	notification) to these data nodes. These are the subtrees and data		notification) to these data nodes. These are the subtrees and data
	nodes and their sensitivity/vulnerability:		nodes and their sensitivity/vulnerability:
	o ietf-i2nsf-capability: An attacker could gather the security		o ietf-i2nsf-capability: An attacker could gather the security
	capability information of any NSF and use this information to		capability information of any NSF and use this information to
	evade detection or filtering.		evade detection or filtering.
	9. References		8. References
	9.1. Normative References		8.1. Normative References
	[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,		[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
	DOI 10.17487/RFC0768, August 1980,		DOI 10.17487/RFC0768, August 1980,
	<https://www.rfc-editor.org/info/rfc768>.		<https://www.rfc-editor.org/info/rfc768>.
	[RFC0790] Postel, J., "Assigned numbers", RFC 790,
	DOI 10.17487/RFC0790, September 1981,
	<https://www.rfc-editor.org/info/rfc790>.
	[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,		[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
	DOI 10.17487/RFC0791, September 1981,		DOI 10.17487/RFC0791, September 1981,
	<https://www.rfc-editor.org/info/rfc791>.		<https://www.rfc-editor.org/info/rfc791>.
	[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,		[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,
	RFC 792, DOI 10.17487/RFC0792, September 1981,		RFC 792, DOI 10.17487/RFC0792, September 1981,
	<https://www.rfc-editor.org/info/rfc792>.		<https://www.rfc-editor.org/info/rfc792>.
	[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,		[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
	RFC 793, DOI 10.17487/RFC0793, September 1981,		RFC 793, DOI 10.17487/RFC0793, September 1981,
	skipping to change at page 44, line 5 ¶		skipping to change at page 44, line 10 ¶
	[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol		[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
	Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,		Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
	<https://www.rfc-editor.org/info/rfc8446>.		<https://www.rfc-editor.org/info/rfc8446>.
	[RFC8525] Bierman, A., Bjorklund, M., Schoenwaelder, J., Watsen, K.,		[RFC8525] Bierman, A., Bjorklund, M., Schoenwaelder, J., Watsen, K.,
	and R. Wilton, "YANG Library", RFC 8525,		and R. Wilton, "YANG Library", RFC 8525,
	DOI 10.17487/RFC8525, March 2019,		DOI 10.17487/RFC8525, March 2019,
	<https://www.rfc-editor.org/info/rfc8525>.		<https://www.rfc-editor.org/info/rfc8525>.
	9.2. Informative References		8.2. Informative References
	[I-D.ietf-i2nsf-capability]		[I-D.ietf-i2nsf-capability]
	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-05 (work in progress), April 2019.		i2nsf-capability-05 (work in progress), April 2019.
	[I-D.ietf-i2nsf-nsf-monitoring-data-model]		[I-D.ietf-i2nsf-nsf-monitoring-data-model]
	Jeong, J., Chung, C., Hares, S., Xia, L., and H. Birkholz,		Jeong, J., Chung, C., Hares, S., Xia, L., and H. Birkholz,
	"I2NSF NSF Monitoring YANG Data Model", draft-ietf-i2nsf-		"I2NSF NSF Monitoring YANG Data Model", draft-ietf-i2nsf-
	nsf-monitoring-data-model-03 (work in progress), May 2020.		nsf-monitoring-data-model-03 (work in progress), May 2020.
	[I-D.ietf-i2nsf-sdn-ipsec-flow-protection]		[I-D.ietf-i2nsf-sdn-ipsec-flow-protection]
	Lopez, R., Lopez-Millan, G., and F. Pereniguez-Garcia,		Lopez, R., Lopez-Millan, G., and F. Pereniguez-Garcia,
	"Software-Defined Networking (SDN)-based IPsec Flow		"Software-Defined Networking (SDN)-based IPsec Flow
	Protection", draft-ietf-i2nsf-sdn-ipsec-flow-protection-08		Protection", draft-ietf-i2nsf-sdn-ipsec-flow-protection-08
	(work in progress), June 2020.		(work in progress), June 2020.
			[IANA-Protocol-Numbers]
			"Assigned Internet Protocol Numbers", Available:
			https://www.iana.org/assignments/protocol-
			numbers/protocol-numbers.xhtml, September 2020.
	Appendix A. Configuration Examples		Appendix A. Configuration Examples
	This section shows configuration examples of "ietf-i2nsf-capability"		This section shows configuration examples of "ietf-i2nsf-capability"
	module for capabilities registration of general firewall.		module for capabilities registration of general firewall.
	A.1. Example 1: Registration for the Capabilities of a General Firewall		A.1. Example 1: Registration for the Capabilities of a General Firewall
	This section shows a configuration example for the capabilities		This section shows a configuration example for the capabilities
	registration of a general firewall in either an IPv4 network or an		registration of a general firewall in either an IPv4 network or an
	IPv6 network.		IPv6 network.
	skipping to change at page 51, line 49 ¶		skipping to change at page 51, line 49 ¶
	4. The NSF can control whether the packets are allowed to pass,		4. The NSF can control whether the packets are allowed to pass,
	drop, or alert.		drop, or alert.
	Appendix B. Acknowledgments		Appendix B. Acknowledgments
	This work was supported by Institute of Information & Communications		This work was supported by Institute of Information & Communications
	Technology Planning & Evaluation (IITP) grant funded by the Korea		Technology Planning & Evaluation (IITP) grant funded by the Korea
	MSIT (Ministry of Science and ICT) (R-20160222-002755, Cloud based		MSIT (Ministry of Science and ICT) (R-20160222-002755, Cloud based
	Security Intelligence Technology Development for the Customized		Security Intelligence Technology Development for the Customized
	Security Service Provisioning). This work was supported in part by		Security Service Provisioning).
	the IITP (2020-0-00395, Standard Development of Blockchain based
	Network Management Automation Technology).
	Appendix C. 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, such as Acee		Many people actively contributed to this document, such as Acee
	Lindem, Roman Danyliw, and Tom Petch. The authors sincerely		Lindem, Roman Danyliw, and Tom Petch. The authors sincerely
	appreciate their contributions.		appreciate their contributions.
	The following are co-authors of this document:		The following are co-authors of this document:
End of changes. 26 change blocks.
	45 lines changed or deleted		59 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/