draft-ietf-i2nsf-nsf-facing-interface-dm-07.txt		draft-ietf-i2nsf-nsf-facing-interface-dm-08.txt
	I2NSF Working Group J. Kim		I2NSF Working Group J. Kim
	Internet-Draft J. Jeong		Internet-Draft J. Jeong
	Intended status: Standards Track Sungkyunkwan University		Intended status: Standards Track Sungkyunkwan University
	Expires: January 26, 2020 J. Park		Expires: May 7, 2020 J. Park
	ETRI		ETRI
	S. Hares		S. Hares
	Q. Lin		Q. Lin
	Huawei		Huawei
	July 25, 2019		November 4, 2019
	I2NSF Network Security Function-Facing Interface YANG Data Model		I2NSF Network Security Function-Facing Interface YANG Data Model
	draft-ietf-i2nsf-nsf-facing-interface-dm-07		draft-ietf-i2nsf-nsf-facing-interface-dm-08
	Abstract		Abstract
	This document defines a YANG data model for configuring security		This document defines a YANG data model for configuring security
	policy rules on Network Security Functions (NSF) in the Interface to		policy rules on Network Security Functions (NSF) in the Interface to
	Network Security Functions (I2NSF) framework. The YANG data model in		Network Security Functions (I2NSF) framework. The YANG data model in
	this document corresponds to the information model for NSF-Facing		this document corresponds to the information model for NSF-Facing
	Interface in the I2NSF framework.		Interface in the I2NSF framework.
	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 January 26, 2020.		This Internet-Draft will expire on May 7, 2020.
	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 24 ¶		skipping to change at page 2, line 24 ¶
	3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3.1. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 4		3.1. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 4
	4. YANG Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 4		4. YANG Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 4
	4.1. General I2NSF Security Policy Rule . . . . . . . . . . . 4		4.1. General I2NSF Security Policy Rule . . . . . . . . . . . 4
	4.2. Event Clause . . . . . . . . . . . . . . . . . . . . . . 6		4.2. Event Clause . . . . . . . . . . . . . . . . . . . . . . 6
	4.3. Condition Clause . . . . . . . . . . . . . . . . . . . . 7		4.3. Condition Clause . . . . . . . . . . . . . . . . . . . . 7
	4.4. Action Clause . . . . . . . . . . . . . . . . . . . . . . 14		4.4. Action Clause . . . . . . . . . . . . . . . . . . . . . . 14
	4.5. I2NSF Internet Key Exchange . . . . . . . . . . . . . . . 15		4.5. I2NSF Internet Key Exchange . . . . . . . . . . . . . . . 15
	5. YANG Data Module . . . . . . . . . . . . . . . . . . . . . . 15		5. YANG Data Module . . . . . . . . . . . . . . . . . . . . . . 15
	5.1. I2NSF NSF-Facing Interface YANG Data Module . . . . . . . 15		5.1. I2NSF NSF-Facing Interface YANG Data Module . . . . . . . 15
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 87		6. XML Configuration Examples of Low-Level Security Policy Rules 86
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 87		6.1. Security Requirement 1: Block SNS Access during Business
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 88		Hours . . . . . . . . . . . . . . . . . . . . . . . . . . 86
	8.1. Normative References . . . . . . . . . . . . . . . . . . 88		6.2. Security Requirement 2: Block Malicious VoIP/VoLTE
	8.2. Informative References . . . . . . . . . . . . . . . . . 90		Packets Coming to a Company . . . . . . . . . . . . . . . 89
	Appendix A. Configuration Examples . . . . . . . . . . . . . . . 91		6.3. Security Requirement 3: Mitigate HTTP and HTTPS Flood
	A.1. Security Requirement 1: Block SNS Access during Business		Attacks on a Company Web Server . . . . . . . . . . . . . 92
	Hours . . . . . . . . . . . . . . . . . . . . . . . . . . 91		7. Security Considerations . . . . . . . . . . . . . . . . . . . 95
	A.2. Security Requirement 2: Block Malicious VoIP/VoLTE		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 96
	Packets Coming to the Company . . . . . . . . . . . . . . 94		9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 96
	A.3. Security Requirement 3: Mitigate HTTP and HTTPS Flood		10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 96
	Attacks on a Company Web Server . . . . . . . . . . . . . 97		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 97
	Appendix B. Changes from draft-ietf-i2nsf-nsf-facing-interface-		11.1. Normative References . . . . . . . . . . . . . . . . . . 97
	dm-06 . . . . . . . . . . . . . . . . . . . . . . . 100		11.2. Informative References . . . . . . . . . . . . . . . . . 99
	Appendix C. Acknowledgments . . . . . . . . . . . . . . . . . . 100		Appendix A. Changes from draft-ietf-i2nsf-nsf-facing-interface-
	Appendix D. Contributors . . . . . . . . . . . . . . . . . . . . 100		dm-07 . . . . . . . . . . . . . . . . . . . . . . . 100
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 101		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 100
	1. Introduction		1. Introduction
	This document defines a YANG [RFC6020][RFC7950] data model for		This document defines a YANG [RFC6020][RFC7950] data model for
	security policy rule configuration of Network Security Functions		security policy rule configuration of Network Security Functions
	(NSF). The YANG data model corresponds to the information model		(NSF). The YANG data model corresponds to the information model
	[draft-ietf-i2nsf-capability] for NSF-Facing Interface in Interface		[draft-ietf-i2nsf-capability] for NSF-Facing Interface in Interface
	to Network Security Functions (I2NSF). The YANG data model in this		to Network Security Functions (I2NSF). The YANG data model in this
	document focuses on security policy configuration for generic network		document focuses on security policy configuration for generic network
	security functions. Note that security policy configuration for		security functions. Note that security policy configuration for
	skipping to change at page 5, line 19 ¶		skipping to change at page 5, line 19 ¶
	| +--rw priority-usage? identityref		| +--rw priority-usage? identityref
	| +--rw resolution-strategy? identityref		| +--rw resolution-strategy? identityref
	| +--rw default-action? identityref		| +--rw default-action? identityref
	| +--rw rules* [rule-name]		| +--rw rules* [rule-name]
	| | +--rw rule-name string		| | +--rw rule-name string
	| | +--rw rule-description? string		| | +--rw rule-description? string
	| | +--rw rule-priority? uint8		| | +--rw rule-priority? uint8
	| | +--rw rule-enable? boolean		| | +--rw rule-enable? boolean
	| | +--rw rule-session-aging-time? uint16		| | +--rw rule-session-aging-time? uint16
	| | +--rw rule-long-connection		| | +--rw rule-long-connection
	| | | +--rw enable? boolean		| | | +--rw enable? boolean
	| | | +--rw during? uint16		| | | +--rw duration? uint16
	| | +--rw time-intervals		| | +--rw time-intervals
	| | | +--rw absolute-time-interval		| | | +--rw absolute-time-interval
	| | | | +--rw start-time? start-time-type		| | | | +--rw start-time? start-time-type
	| | | | +--rw end-time? end-time-type		| | | | +--rw end-time? end-time-type
	| | | +--rw periodic-time-interval		| | | +--rw periodic-time-interval
	| | | +--rw day		| | | +--rw day
	| | | | +--rw every-day? boolean		| | | | +--rw every-day? boolean
	| | | | +--rw specific-day* day-type		| | | | +--rw specific-day* day-type
	| | | +--rw month		| | | +--rw month
	| | | +--rw every-month? boolean		| | | +--rw every-month? boolean
	skipping to change at page 13, line 15 ¶		skipping to change at page 13, line 15 ¶
	| | | | | +--:(tenant)		| | | | | +--:(tenant)
	| | | | | | +--rw tenant uint8		| | | | | | +--rw tenant uint8
	| | | | | +--:(vn-id)		| | | | | +--:(vn-id)
	| | | | | +--rw vn-id uint8		| | | | | +--rw vn-id uint8
	| | | | +--rw group		| | | | +--rw group
	| | | | | +--rw (group-name)?		| | | | | +--rw (group-name)?
	| | | | | +--:(tenant)		| | | | | +--:(tenant)
	| | | | | | +--rw tenant uint8		| | | | | | +--rw tenant uint8
	| | | | | +--:(vn-id)		| | | | | +--:(vn-id)
	| | | | | +--rw vn-id uint8		| | | | | +--rw vn-id uint8
	| | | | +--rw security-grup string		| | | | +--rw security-group string
	| | | +--rw gen-context-condition		| | | +--rw gen-context-condition
	| | | +--rw gen-context-description? string		| | | +--rw gen-context-description? string
	| | | +--rw geographic-location		| | | +--rw geographic-location
	| | | +--rw src-geographic-location* uint32		| | | +--rw src-geographic-location* uint32
	| | | +--rw dest-geographic-location* uint32		| | | +--rw dest-geographic-location* uint32
	| | +--rw action-clause-container		| | +--rw action-clause-container
	| | ...		| | ...
	| +--rw rule-group		| +--rw rule-group
	| ...		| ...
	+--rw i2nsf-ipsec? identityref		+--rw i2nsf-ipsec? identityref
	skipping to change at page 15, line 44 ¶		skipping to change at page 15, line 44 ¶
	Refer to [draft-ietf-i2nsf-sdn-ipsec-flow-protection] for the		Refer to [draft-ietf-i2nsf-sdn-ipsec-flow-protection] for the
	detailed description of the I2NSF IPsec.		detailed description of the I2NSF IPsec.
	5. YANG Data Module		5. YANG Data Module
	5.1. I2NSF NSF-Facing Interface YANG Data Module		5.1. I2NSF NSF-Facing Interface YANG Data Module
	This section contains a YANG data module for configuration of		This section contains a YANG data module for configuration of
	security policy rules on network security functions.		security policy rules on network security functions.
	<CODE BEGINS> file "ietf-i2nsf-policy-rule-for-nsf@2019-07-25.yang"		<CODE BEGINS> file "ietf-i2nsf-policy-rule-for-nsf@2019-11-04.yang"
	module ietf-i2nsf-policy-rule-for-nsf {		module ietf-i2nsf-policy-rule-for-nsf {
	yang-version 1.1;		yang-version 1.1;
	namespace		namespace
	"urn:ietf:params:xml:ns:yang:ietf-i2nsf-policy-rule-for-nsf";		"urn:ietf:params:xml:ns:yang:ietf-i2nsf-policy-rule-for-nsf";
	prefix		prefix
	nsfintf;		nsfintf;
	import ietf-inet-types{		import ietf-inet-types{
	prefix inet;		prefix inet;
	reference "RFC 6991";		reference "RFC 6991";
	}		}
	import ietf-yang-types{		import ietf-yang-types{
	prefix yang;		prefix yang;
	reference "RFC 6991";		reference "RFC 6991";
	}		}
			import ietf-key-chain{
			prefix key-chain;
			reference "RFC 8177";
			}
	organization		organization
	"IETF I2NSF (Interface to Network Security Functions)		"IETF I2NSF (Interface to Network Security Functions)
	Working Group";		Working Group";
	contact		contact
	"WG Web: <http://tools.ietf.org/wg/i2nsf>		"WG Web: <http://tools.ietf.org/wg/i2nsf>
	WG List: <mailto:i2nsf@ietf.org>		WG List: <mailto:i2nsf@ietf.org>
	WG Chair: Linda Dunbar		WG Chair: Linda Dunbar
	skipping to change at page 16, line 42 ¶		skipping to change at page 16, line 46 ¶
	Editor: Jaehoon Paul Jeong		Editor: Jaehoon Paul Jeong
	<mailto:pauljeong@skku.edu>		<mailto:pauljeong@skku.edu>
	Editor: Susan Hares		Editor: Susan Hares
	<mailto:shares@ndzh.com>";		<mailto:shares@ndzh.com>";
	description		description
	"This module defines a YANG data module for the Network Security		"This module defines a YANG data module for the Network Security
	Functions (NSF) facing interface.		Functions (NSF) facing interface.
	Copyright (c) 2018 IETF Trust and the persons		Copyright (c) 2019 IETF Trust and the persons
	identified as authors of the code. All rights reserved.		identified as authors of the code. All rights reserved.
	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 8341; 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-07-25"{		revision "2019-11-04"{
	description "Initial revision.";		description "The latest revision.";
	reference		reference
	"RFC XXXX: I2NSF Network Security Function-Facing Interface		"RFC XXXX: I2NSF Network Security Function-Facing Interface
	YANG Data Model";		YANG Data Model";
	}		}
	/*		/*
	* Identities		* Identities
	*/		*/
	identity priority-usage-type {		identity priority-usage-type {
	skipping to change at page 17, line 39 ¶		skipping to change at page 17, line 43 ¶
	identity priority-by-number {		identity priority-by-number {
	base priority-usage-type;		base priority-usage-type;
	description		description
	"Identity for priority by number";		"Identity for priority by number";
	}		}
	identity event {		identity event {
	description		description
	"Base identity for policy events";		"Base identity for policy events";
	reference		reference
	"draft-ietf-i2nsf-nsf-monitoring-data-model-01		"draft-ietf-i2nsf-nsf-monitoring-data-model-02
	- Event";		- Event";
	}		}
	identity system-event {		identity system-event {
	base event;		base event;
	description		description
	"Identity for system events";		"Identity for system events";
	reference		reference
	"draft-ietf-i2nsf-nsf-monitoring-data-model-01		"draft-ietf-i2nsf-nsf-monitoring-data-model-02
	- System event";		- System event";
	}		}
	identity system-alarm {		identity system-alarm {
	base event;		base event;
	description		description
	"Identity for system alarms";		"Identity for system alarms";
	reference		reference
	"draft-ietf-i2nsf-nsf-monitoring-data-model-01		"draft-ietf-i2nsf-nsf-monitoring-data-model-02
	- System alarm";		- System alarm";
	}		}
	identity access-violation {		identity access-violation {
	base system-event;		base system-event;
	description		description
	"Identity for access violation		"Identity for access violation
	system events";		system events";
	reference		reference
	"draft-ietf-i2nsf-nsf-monitoring-data-model-01		"draft-ietf-i2nsf-nsf-monitoring-data-model-02
	- System event";		- System event";
	}		}
	identity configuration-change {		identity configuration-change {
	base system-event;		base system-event;
	description		description
	"Identity for configuration change		"Identity for configuration change
	system events";		system events";
	reference		reference
	"draft-ietf-i2nsf-nsf-monitoring-data-model-01		"draft-ietf-i2nsf-nsf-monitoring-data-model-02
	- System event";		- System event";
	}		}
	identity memory-alarm {		identity memory-alarm {
	base system-alarm;		base system-alarm;
	description		description
	"Identity for memory alarm		"Identity for memory alarm
	system alarms";		system alarms";
	reference		reference
	"draft-ietf-i2nsf-nsf-monitoring-data-model-01		"draft-ietf-i2nsf-nsf-monitoring-data-model-02
	- System alarm";		- System alarm";
	}		}
	identity cpu-alarm {		identity cpu-alarm {
	base system-alarm;		base system-alarm;
	description		description
	"Identity for CPU alarm		"Identity for CPU alarm
	system alarms";		system alarms";
	reference		reference
	"draft-ietf-i2nsf-nsf-monitoring-data-model-01		"draft-ietf-i2nsf-nsf-monitoring-data-model-02
	- System alarm";		- System alarm";
	}		}
	identity disk-alarm {		identity disk-alarm {
	base system-alarm;		base system-alarm;
	description		description
	"Identity for disk alarm		"Identity for disk alarm
	system alarms";		system alarms";
	reference		reference
	"draft-ietf-i2nsf-nsf-monitoring-data-model-01		"draft-ietf-i2nsf-nsf-monitoring-data-model-02
	- System alarm";		- System alarm";
	}		}
	identity hardware-alarm {		identity hardware-alarm {
	base system-alarm;		base system-alarm;
	description		description
	"Identity for hardware alarm		"Identity for hardware alarm
	system alarms";		system alarms";
	reference		reference
	"draft-ietf-i2nsf-nsf-monitoring-data-model-01		"draft-ietf-i2nsf-nsf-monitoring-data-model-02
	- System alarm";		- System alarm";
	}		}
	identity interface-alarm {		identity interface-alarm {
	base system-alarm;		base system-alarm;
	description		description
	"Identity for interface alarm		"Identity for interface alarm
	system alarms";		system alarms";
	reference		reference
	"draft-ietf-i2nsf-nsf-monitoring-data-model-01		"draft-ietf-i2nsf-nsf-monitoring-data-model-02
	- System alarm";		- System alarm";
	}		}
	identity type-of-service {		identity type-of-service {
	description		description
	"Base identity for type of service of IPv4";		"Base identity for type of service of IPv4";
	reference		reference
	"RFC 791: Internet Protocol - Type of Service";		"RFC 791: Internet Protocol - Type of Service";
	}		}
	skipping to change at page 22, line 11 ¶		skipping to change at page 22, line 16 ¶
	description		description
	"Identity for reserved flags";		"Identity for reserved flags";
	reference		reference
	"RFC 791: Internet Protocol - Fragmentation Flags";		"RFC 791: Internet Protocol - Fragmentation Flags";
	}		}
	identity protocol {		identity protocol {
	description		description
	"Base identity for protocol of IPv4";		"Base identity for protocol of IPv4";
	reference		reference
	"RFC 790: Assigned numbers - Assigned Internet		"RFC 3232: Assigned Numbers: RFC 1700 is Replaced by an
	Protocol Number		On-line Database
	RFC 791: Internet Protocol - Protocol";		RFC 791: Internet Protocol - Protocol";
	}		}
	identity next-header {		identity next-header {
	description		description
	"Base identity for IPv6 next header";		"Base identity for IPv6 next header";
	reference		reference
	"RFC 8200: Internet Protocol, Version 6 (IPv6)		"RFC 8200: Internet Protocol, Version 6 (IPv6)
	Specification - Next Header";		Specification - Next Header";
	}		}
	identity icmp {		identity icmp {
	base protocol;		base protocol;
	base next-header;		base next-header;
	description		description
	"Identity for ICMP IPv4 protocol and		"Identity for ICMP IPv4 protocol and
	IPv6 nett header";		IPv6 nett header";
	reference		reference
	"RFC 790: - Assigned numbers - Assigned Internet		"RFC 3232: Assigned Numbers: RFC 1700 is Replaced by an
	Protocol Number		On-line Database
	RFC 791: Internet Protocol - Protocol		RFC 791: Internet Protocol - Protocol
	RFC 8200: Internet Protocol, Version 6 (IPv6)		RFC 8200: Internet Protocol, Version 6 (IPv6)
	Specification - Next Header";		Specification - Next Header";
	}		}
	identity igmp {		identity igmp {
	base protocol;		base protocol;
	base next-header;		base next-header;
	description		description
	"Identity for IGMP IPv4 protocol and		"Identity for IGMP IPv4 protocol and
	IPv6 next header";		IPv6 next header";
	reference		reference
	"RFC 790: - Assigned numbers - Assigned Internet		"RFC 3232: Assigned Numbers: RFC 1700 is Replaced by an
	Protocol Number		On-line Database
	RFC 791: Internet Protocol - Protocol		RFC 791: Internet Protocol - Protocol
	RFC 8200: Internet Protocol, Version 6 (IPv6)		RFC 8200: Internet Protocol, Version 6 (IPv6)
	Specification - Next Header";		Specification - Next Header";
	}		}
	identity tcp {		identity tcp {
	base protocol;		base protocol;
	base next-header;		base next-header;
	description		description
	"Identity for TCP protocol";		"Identity for TCP protocol";
	reference		reference
	"RFC 790: - Assigned numbers - Assigned Internet		"RFC 3232: Assigned Numbers: RFC 1700 is Replaced by an
	Protocol Number		On-line Database
	RFC 791: Internet Protocol - Protocol		RFC 791: Internet Protocol - Protocol
	RFC 8200: Internet Protocol, Version 6 (IPv6)		RFC 8200: Internet Protocol, Version 6 (IPv6)
	Specification - Next Header";		Specification - Next Header";
	}		}
	identity igrp {		identity igrp {
	base protocol;		base protocol;
	base next-header;		base next-header;
	description		description
	"Identity for IGRP IPv4 protocol		"Identity for IGRP IPv4 protocol
	and IPv6 next header";		and IPv6 next header";
	reference		reference
	"RFC 790: - Assigned numbers - Assigned Internet		"RFC 3232: Assigned Numbers: RFC 1700 is Replaced by an
	Protocol Number		On-line Database
	RFC 791: Internet Protocol - Protocol		RFC 791: Internet Protocol - Protocol
	RFC 8200: Internet Protocol, Version 6 (IPv6)		RFC 8200: Internet Protocol, Version 6 (IPv6)
	Specification - Next Header";		Specification - Next Header";
	}		}
	identity udp {		identity udp {
	base protocol;		base protocol;
	base next-header;		base next-header;
	description		description
	"Identity for UDP IPv4 protocol		"Identity for UDP IPv4 protocol
	and IPv6 next header";		and IPv6 next header";
	reference		reference
	"RFC 790: - Assigned numbers - Assigned Internet		"RFC 3232: Assigned Numbers: RFC 1700 is Replaced by an
	Protocol Number		On-line Database
	RFC 791: Internet Protocol - Protocol		RFC 791: Internet Protocol - Protocol
	RFC 8200: Internet Protocol, Version 6 (IPv6)		RFC 8200: Internet Protocol, Version 6 (IPv6)
	Specification - Next Header";		Specification - Next Header";
	}		}
	identity gre {		identity gre {
	base protocol;		base protocol;
	base next-header;		base next-header;
	description		description
	"Identity for GRE IPv4 protocol		"Identity for GRE IPv4 protocol
	and IPv6 next header";		and IPv6 next header";
	reference		reference
	"RFC 790: - Assigned numbers - Assigned Internet		"RFC 3232: Assigned Numbers: RFC 1700 is Replaced by an
	Protocol Number		On-line Database
	RFC 791: Internet Protocol - Protocol		RFC 791: Internet Protocol - Protocol
	RFC 8200: Internet Protocol, Version 6 (IPv6)		RFC 8200: Internet Protocol, Version 6 (IPv6)
	Specification - Next Header";		Specification - Next Header";
	}		}
	identity esp {		identity esp {
	base protocol;		base protocol;
	base next-header;		base next-header;
	description		description
	"Identity for ESP IPv4 protocol		"Identity for ESP IPv4 protocol
	and IPv6 next header";		and IPv6 next header";
	reference		reference
	"RFC 790: - Assigned numbers - Assigned Internet		"RFC 3232: Assigned Numbers: RFC 1700 is Replaced by an
	Protocol Number		On-line Database
	RFC 791: Internet Protocol - Protocol		RFC 791: Internet Protocol - Protocol
	RFC 8200: Internet Protocol, Version 6 (IPv6)		RFC 8200: Internet Protocol, Version 6 (IPv6)
	Specification - Next Header";		Specification - Next Header";
	}		}
	identity ah {		identity ah {
	base protocol;		base protocol;
	base next-header;		base next-header;
	description		description
	"Identity for AH IPv4 protocol		"Identity for AH IPv4 protocol
	and IPv6 next header";		and IPv6 next header";
	reference		reference
	"RFC 790: - Assigned numbers - Assigned Internet		"RFC 3232: Assigned Numbers: RFC 1700 is Replaced by an
	Protocol Number		On-line Database
	RFC 791: Internet Protocol - Protocol		RFC 791: Internet Protocol - Protocol
	RFC 8200: Internet Protocol, Version 6 (IPv6)		RFC 8200: Internet Protocol, Version 6 (IPv6)
	Specification - Next Header";		Specification - Next Header";
	}		}
	identity mobile {		identity mobile {
	base protocol;		base protocol;
	base next-header;		base next-header;
	description		description
	"Identity for mobile IPv4 protocol		"Identity for mobile IPv4 protocol
	and IPv6 next header";		and IPv6 next header";
	reference		reference
	"RFC 790: - Assigned numbers - Assigned Internet		"RFC 3232: Assigned Numbers: RFC 1700 is Replaced by an
	Protocol Number		On-line Database
	RFC 791: Internet Protocol - Protocol		RFC 791: Internet Protocol - Protocol
	RFC 8200: Internet Protocol, Version 6 (IPv6)		RFC 8200: Internet Protocol, Version 6 (IPv6)
	Specification - Next Header";		Specification - Next Header";
	}		}
	identity tlsp {		identity tlsp {
	base protocol;		base protocol;
	base next-header;		base next-header;
	description		description
	"Identity for TLSP IPv4 protocol		"Identity for TLSP IPv4 protocol
	and IPv6 next header";		and IPv6 next header";
	reference		reference
	"RFC 790: - Assigned numbers - Assigned Internet		"RFC 3232: Assigned Numbers: RFC 1700 is Replaced by an
	Protocol Number		On-line Database
	RFC 791: Internet Protocol - Protocol		RFC 791: Internet Protocol - Protocol
	RFC 8200: Internet Protocol, Version 6 (IPv6)		RFC 8200: Internet Protocol, Version 6 (IPv6)
	Specification - Next Header";		Specification - Next Header";
	}		}
	identity skip {		identity skip {
	base protocol;		base protocol;
	base next-header;		base next-header;
	description		description
	"Identity for skip IPv4 protocol		"Identity for skip IPv4 protocol
	and IPv6 next header";		and IPv6 next header";
	reference		reference
	"RFC 790: - Assigned numbers - Assigned Internet		"RFC 3232: Assigned Numbers: RFC 1700 is Replaced by an
	Protocol Number		On-line Database
	RFC 791: Internet Protocol - Protocol		RFC 791: Internet Protocol - Protocol
	RFC 8200: Internet Protocol, Version 6 (IPv6)		RFC 8200: Internet Protocol, Version 6 (IPv6)
	Specification - Next Header";		Specification - Next Header";
	}		}
	identity ipv6-icmp {		identity ipv6-icmp {
	base protocol;		base protocol;
	base next-header;		base next-header;
	description		description
	"Identity for IPv6 ICMP next header";		"Identity for IPv6 ICMP next header";
	reference		reference
	"RFC 790: - Assigned numbers - Assigned Internet		"RFC 3232: Assigned Numbers: RFC 1700 is Replaced by an
	Protocol Number		On-line Database
	RFC 8200: Internet Protocol, Version 6 (IPv6)		RFC 4443: Internet Control Message Protocol (ICMPv6)
			for the Internet Protocol Version 6 (IPv6) Specification
			RFC 8200: Internet Protocol, Version 6 (IPv6)
	Specification - Next Header";		Specification - Next Header";
	}		}
	identity eigrp {		identity eigrp {
	base protocol;		base protocol;
	base next-header;		base next-header;
	description		description
	"Identity for EIGRP IPv4 protocol		"Identity for EIGRP IPv4 protocol
	and IPv6 next header";		and IPv6 next header";
	reference		reference
	"RFC 790: - Assigned numbers - Assigned Internet		"RFC 3232: Assigned Numbers: RFC 1700 is Replaced by an
	Protocol Number		On-line Database
	RFC 791: Internet Protocol - Protocol		RFC 791: Internet Protocol - Protocol
	RFC 8200: Internet Protocol, Version 6 (IPv6)		RFC 8200: Internet Protocol, Version 6 (IPv6)
	Specification - Next Header";		Specification - Next Header";
	}		}
	identity ospf {		identity ospf {
	base protocol;		base protocol;
	base next-header;		base next-header;
	description		description
	"Identity for OSPF IPv4 protocol		"Identity for OSPF IPv4 protocol
	and IPv6 next header";		and IPv6 next header";
	reference		reference
	"RFC 790: - Assigned numbers - Assigned Internet		"RFC 3232: Assigned Numbers: RFC 1700 is Replaced by an
	Protocol Number		On-line Database
	RFC 791: Internet Protocol - Protocol		RFC 791: Internet Protocol - Protocol
	RFC 8200: Internet Protocol, Version 6 (IPv6)		RFC 8200: Internet Protocol, Version 6 (IPv6)
	Specification - Next Header";		Specification - Next Header";
	}		}
	identity l2tp {		identity l2tp {
	base protocol;		base protocol;
	base next-header;		base next-header;
	description		description
	"Identity for L2TP IPv4 protocol		"Identity for L2TP IPv4 protocol
	and IPv6 next header";		and IPv6 next header";
	reference		reference
	"RFC 790: - Assigned numbers - Assigned Internet		"RFC 3232: Assigned Numbers: RFC 1700 is Replaced by an
	Protocol Number		On-line Database
	RFC 791: Internet Protocol - Protocol		RFC 791: Internet Protocol - Protocol
	RFC 8200: Internet Protocol, Version 6 (IPv6)		RFC 8200: Internet Protocol, Version 6 (IPv6)
	Specification - Next Header";		Specification - Next Header";
	}		}
	identity ipopts {		identity ipopts {
	description		description
	"Base identity for IP options";		"Base identity for IP options";
	reference		reference
	"RFC 791: Internet Protocol - Options";		"RFC 791: Internet Protocol - Options";
	skipping to change at page 37, line 49 ¶		skipping to change at page 38, line 10 ¶
	description		description
	"Identity for bad length		"Identity for bad length
	in parameter problem types";		in parameter problem types";
	reference		reference
	"RFC 792: Internet Control Message Protocol";		"RFC 792: Internet Control Message Protocol";
	}		}
	identity bad-spi {		identity bad-spi {
	base icmp-type;		base icmp-type;
	description		description
	"Identity for bad spi		"Identity for bad spi";
	in photuris types";
	reference		reference
	"RFC 792: Internet Control Message Protocol";		"RFC 792: Internet Control Message Protocol";
	}		}
	identity authentication-failed {		identity authentication-failed {
	base icmp-type;		base icmp-type;
	description		description
	"Identity for authentication failed		"Identity for authentication failed";
	in photuris types";
	reference		reference
	"RFC 792: Internet Control Message Protocol";		"RFC 792: Internet Control Message Protocol";
	}		}
	identity decompression-failed {		identity decompression-failed {
	base icmp-type;		base icmp-type;
	description		description
	"Identity for decompression failed		"Identity for decompression failed";
	in photuris types";
	reference		reference
	"RFC 792: Internet Control Message Protocol";		"RFC 792: Internet Control Message Protocol";
	}		}
	identity decryption-failed {		identity decryption-failed {
	base icmp-type;		base icmp-type;
	description		description
	"Identity for decryption failed		"Identity for decryption failed";
	in photuris types";
	reference		reference
	"RFC 792: Internet Control Message Protocol";		"RFC 792: Internet Control Message Protocol";
	}		}
	identity need-authentication {		identity need-authentication {
	base icmp-type;		base icmp-type;
	description		description
	"Identity for need authentication		"Identity for need authentication";
	in photuris types";
	reference		reference
	"RFC 792: Internet Control Message Protocol";		"RFC 792: Internet Control Message Protocol";
	}		}
	identity need-authorization {		identity need-authorization {
	base icmp-type;		base icmp-type;
	description		description
	"Identity for need authorization		"Identity for need authorization";
	in photuris types";
	reference		reference
	"RFC 792: Internet Control Message Protocol";		"RFC 792: Internet Control Message Protocol";
	}		}
	identity req-no-error {		identity req-no-error {
	base icmp-type;		base icmp-type;
	description		description
	"Identity for request with no error		"Identity for request with no error
	in extended echo request types";		in extended echo request types";
	reference		reference
	"RFC 792: Internet Control Message Protocol		"RFC 792: Internet Control Message Protocol
	RFC 8335: PROBE: A Utility for Probing Interfaces";		RFC 8335: PROBE: A Utility for Probing Interfaces";
	}		}
	skipping to change at page 49, line 11 ¶		skipping to change at page 49, line 15 ¶
	"IKEless case: IPsec without IKEv2 in the NSF";		"IKEless case: IPsec without IKEv2 in the NSF";
	reference		reference
	"draft-ietf-i2nsf-sdn-ipsec-flow-protection-04		"draft-ietf-i2nsf-sdn-ipsec-flow-protection-04
	- ikeless";		- ikeless";
	}		}
	/*		/*
	* Typedefs		* Typedefs
	*/		*/
	typedef start-time-type {
	type union {
	type yang:date-and-time;
	type enumeration {
	enum right-away {
	description
	"Immediate rule execution
	in the system.";
	}
	}
	}
	description
	"Start time when the rules are applied.";
	}
	typedef end-time-type {
	type union {
	type yang:date-and-time;
	type enumeration {
	enum infinitely {
	description
	"Infinite rule execution
	in the system.";
	}
	}
	}
	description
	"End time when the rules are applied.";
	}
	typedef day-type {		typedef day-type {
	type enumeration {		type enumeration {
	enum sunday {		enum sunday {
	description		description
	"Sunday for periodic day";		"Sunday for periodic day";
	}		}
	enum monday {		enum monday {
	description		description
	"Monday for periodic day";		"Monday for periodic day";
	}		}
	skipping to change at page 58, line 15 ¶		skipping to change at page 57, line 35 ¶
	description		description
	"This is long-connection";		"This is long-connection";
	leaf enable {		leaf enable {
	type boolean;		type boolean;
	description		description
	"True is enable.		"True is enable.
	False is not enbale.";		False is not enbale.";
	}		}
	leaf during {		leaf duration {
	type uint16;		type uint16;
	description		description
	"This has long-connection during a time.";		"This is the duration of the long-connection.";
	}		}
	}		}
	container time-intervals {		container time-intervals {
	description		description
	"Time zone when the rules are applied";		"Time zone when the rules are applied";
	container absolute-time-interval {		container absolute-time-interval {
	description		description
	"Rule execution according to absolute time.		"Rule execution according to the absolute time.
	The absolute time intervals mean the exact time to		The absolute time interval means the exact time to
	start or end.";		start or end.";
	leaf start-time {		container start-time {
	type start-time-type;		uses "key-chain:lifetime";
	default right-away;
	description		description
	"Start time when the rules are applied";		"Start time when the rules are applied";
			reference
			"RFC 8177: YANG Data Model for Key Chains
			- lifetime";
	}		}
	leaf end-time {		container end-time {
	type end-time-type;		uses "key-chain:lifetime";
	default infinitely;
	description		description
	"End time when the rules are applied";		"End time when the rules are applied";
			reference
			"RFC 8177: YANG Data Model for Key Chains
			- lifetime";
	}		}
	}		}
	container periodic-time-interval {		container periodic-time-interval {
	description		description
	"Rule execution according to periodic time.		"Rule execution according to the periodic time.
	The periodic time intervals mean repeated time like		The periodic time interval means the repeated time
	day, week, or month.";		such as a day, week, or month.";
	container day {		container day {
	description		description
	"Rule execution according to day.";		"Rule execution according to day.";
	leaf every-day {		leaf every-day {
	type boolean;		type boolean;
	default true;		default true;
	description		description
	"Rule execution every day";		"Rule execution every day";
	}		}
	skipping to change at page 60, line 14 ¶		skipping to change at page 59, line 37 ¶
	or not. Examples of an I2NSF event include time and		or not. Examples of an I2NSF event include time and
	user actions (e.g., logon, logoff, and actions that		user actions (e.g., logon, logoff, and actions that
	violate any ACL.).";		violate any ACL.).";
	reference		reference
	"RFC 8329: Framework for Interface to Network Security		"RFC 8329: Framework for Interface to Network Security
	Functions - I2NSF Flow Security Policy Structure		Functions - I2NSF Flow Security Policy Structure
	draft-ietf-i2nsf-capability-05: Information Model		draft-ietf-i2nsf-capability-05: Information Model
	of NSFs Capabilities - Design Principles and ECA		of NSFs Capabilities - Design Principles and ECA
	Policy Model Overview		Policy Model Overview
	draft-ietf-i2nsf-nsf-monitoring-data-model-01: A YANG		draft-ietf-i2nsf-nsf-monitoring-data-model-02: I2NSF
	Data Model for Monitoring I2NSF Network Security		NSF Monitoring YANG Data Model - Alarms, Events, Logs,
	Functions - System Alarm and System Events";		and Counters";
	leaf event-clause-description {		leaf event-clause-description {
	type string;		type string;
	description		description
	"Description for an event clause";		"Description for an event clause";
	}		}
	container event-clauses {		container event-clauses {
	description		description
	"System Event Clause - either a system event or		"System Event Clause - either a system event or
	system alarm";		system alarm";
	reference		reference
	"RFC 8329: Framework for Interface to Network Security		"RFC 8329: Framework for Interface to Network Security
	Functions - I2NSF Flow Security Policy Structure		Functions - I2NSF Flow Security Policy Structure
	draft-ietf-i2nsf-capability-05: Information Model		draft-ietf-i2nsf-capability-05: Information Model
	of NSFs Capabilities - Design Principles and ECA Policy		of NSFs Capabilities - Design Principles and ECA Policy
	Model Overview		Model Overview
	draft-ietf-i2nsf-nsf-monitoring-data-model-01: A YANG		draft-ietf-i2nsf-nsf-monitoring-data-model-02: I2NSF
	Data Model for Monitoring I2NSF Network Security		NSF Monitoring YANG Data Model - Alarms, Events, Logs,
	Functions - System Alarm and System Events";		and Counters";
	leaf-list system-event {		leaf-list system-event {
	type identityref {		type identityref {
	base system-event;		base system-event;
	}		}
	description		description
	"The security policy rule according to		"The security policy rule according to
	system events.";		system events.";
	}		}
	skipping to change at page 87, line 5 ¶		skipping to change at page 86, line 29 ¶
	reference		reference
	"draft-ietf-i2nsf-sdn-ipsec-flow-protection-04		"draft-ietf-i2nsf-sdn-ipsec-flow-protection-04
	- i2nsf-ipsec";		- i2nsf-ipsec";
	}		}
	}		}
	<CODE ENDS>		<CODE ENDS>
	Figure 6: YANG Data Module of I2NSF NSF-Facing-Interface		Figure 6: YANG Data Module of I2NSF NSF-Facing-Interface
	6. IANA Considerations		6. XML Configuration Examples of Low-Level Security Policy Rules
	This document requests IANA to register the following URI in the
	"IETF XML Registry" [RFC3688]:
	URI: urn:ietf:params:xml:ns:yang:ietf-i2nsf-policy-rule-for-nsf
	Registrant Contact: The IESG.
	XML: N/A; the requested URI is an XML namespace.
	This document requests IANA to register the following YANG module in
	the "YANG Module Names" registry [RFC7950].
	name: ietf-i2nsf-policy-rule-for-nsf
	namespace: urn:ietf:params:xml:ns:yang:ietf-i2nsf-policy-rule-for-
	nsf
	prefix: nsfintf
	reference: RFC XXXX
	7. Security Considerations
	The YANG module specified in this document defines a data schema
	designed to be accessed through network management protocols such as
	NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is
	the secure transport layer, and the required 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.
	There are a number of data nodes defined in this YANG module that are
	writable/creatable/deletable (i.e., config true, which is the
	default). These data nodes may be considered sensitive or vulnerable
	in some network environments. Write operations (e.g., edit-config)
	to these data nodes without proper protection can have a negative
	effect on network operations. These are the subtrees and data nodes
	and their sensitivity/vulnerability:
	o ietf-i2nsf-policy-rule-for-nsf: The attacker may provide incorrect
	policy information of any target NSFs by illegally modifying this.
	Some of the readable data nodes in this YANG module may be considered
	sensitive or vulnerable in some network environments. It is thus
	important to control read access (e.g., via get, get-config, or
	notification) to these data nodes. These are the subtrees and data
	nodes and their sensitivity/vulnerability:
	o ietf-i2nsf-policy-rule-for-nsf: The attacker may gather the
	security policy information of any target NSFs and misuse the
	security policy information for subsequent attacks.
	8. References
	8.1. Normative References
	[RFC1394] Robinson, P., "Relationship of Telex Answerback Codes to
	Internet Domains", RFC 1394, DOI 10.17487/RFC1394, January
	1993, <https://www.rfc-editor.org/info/rfc1394>.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.
	[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
	A., Peterson, J., Sparks, R., Handley, M., and E.
	Schooler, "SIP: Session Initiation Protocol", RFC 3261,
	DOI 10.17487/RFC3261, June 2002,
	<https://www.rfc-editor.org/info/rfc3261>.
	[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
	the Network Configuration Protocol (NETCONF)", RFC 6020,
	DOI 10.17487/RFC6020, October 2010,
	<https://www.rfc-editor.org/info/rfc6020>.
	[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
	and A. Bierman, Ed., "Network Configuration Protocol
	(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
	<https://www.rfc-editor.org/info/rfc6241>.
	[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
	Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
	<https://www.rfc-editor.org/info/rfc6242>.
	[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
	RFC 6991, DOI 10.17487/RFC6991, July 2013,
	<https://www.rfc-editor.org/info/rfc6991>.
	[RFC768] Postel, J., "User Datagram Protocol", RFC 768, August
	1980.
	[RFC790] Postel, J., "Assigned Numbers", RFC 790, September 1981.
	[RFC791] Postel, J., "Internet Protocol", RFC 791, September 1981.
	[RFC792] Postel, J., "Internet Control Message Protocol", RFC 792,
	September 1981.
	[RFC793] Postel, J., "Transmission Control Protocol", RFC 793,
	September 1981.
	[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>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
	(IPv6) Specification", STD 86, RFC 8200,
	DOI 10.17487/RFC8200, July 2017,
	<https://www.rfc-editor.org/info/rfc8200>.
	[RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R.
	Kumar, "Framework for Interface to Network Security
	Functions", RFC 8329, DOI 10.17487/RFC8329, February 2018,
	<https://www.rfc-editor.org/info/rfc8329>.
	[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
	BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
	<https://www.rfc-editor.org/info/rfc8340>.
	[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
	Access Control Model", STD 91, RFC 8341,
	DOI 10.17487/RFC8341, March 2018,
	<https://www.rfc-editor.org/info/rfc8341>.
	[RFC8431] Wang, L., Chen, M., Dass, A., Ananthakrishnan, H., Kini,
	S., and N. Bahadur, "A YANG Data Model for the Routing
	Information Base (RIB)", RFC 8431, DOI 10.17487/RFC8431,
	September 2018, <https://www.rfc-editor.org/info/rfc8431>.
	[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>.
	8.2. Informative References
	[draft-dong-i2nsf-asf-config]
	Pan, W. and L. Xia, "Configuration of Advanced Security
	Functions with I2NSF Security Controller", draft-dong-
	i2nsf-asf-config-01 (work in progress), October 2018.
	[draft-ietf-i2nsf-capability]
	Xia, L., Strassner, J., Basile, C., and D. Lopez,
	"Information Model of NSFs Capabilities", draft-ietf-
	i2nsf-capability-05 (work in progress), April 2019.
	[draft-ietf-i2nsf-capability-data-model]
	Hares, S., Jeong, J., Kim, J., Moskowitz, R., and Q. Lin,
	"I2NSF Capability YANG Data Model", draft-ietf-i2nsf-
	capability-data-model-05 (work in progress), July 2019.
	[draft-ietf-i2nsf-sdn-ipsec-flow-protection]
	Marin-Lopez, R., Lopez-Millan, G., and F. Pereniguez-
	Garcia, "Software-Defined Networking (SDN)-based IPsec
	Flow Protection", draft-ietf-i2nsf-sdn-ipsec-flow-
	protection-05 (work in progress), July 2019.
	[draft-ietf-supa-generic-policy-info-model]
	Strassner, J., Halpern, J., and S. Meer, "Generic Policy
	Information Model for Simplified Use of Policy
	Abstractions (SUPA)", draft-ietf-supa-generic-policy-info-
	model-03 (work in progress), May 2017.
	Appendix A. Configuration Examples
	This section shows configuration examples of "ietf-i2nsf-policy-rule-		This section shows XML configuration examples of low-level security
	for-nsf" module for security policy rules of network security		policy rules that are delivered from the Security Controller to NSFs
	devices. For security requirements, we assume that the NSFs (i.e.,		over the NSF-Facing Interface. For security requirements, we assume
	General firewall, Time based firewall, URL filter, VoIP/VoLTE filter,		that the NSFs (i.e., General firewall, Time-based firewall, URL
	and http and https flood mitigation ) described in Appendix A.		filter, VoIP/VoLTE filter, and http and https flood mitigation )
	Configuration Examples of [draft-ietf-i2nsf-capability-data-model]		described in Appendix A. Configuration Examples of
	are registered in I2NSF framework. With the registed NSFs, we show		[draft-ietf-i2nsf-capability-data-model] are registered in I2NSF
	configuration examples for security policy rules of network security		framework. With the registed NSFs, we show configuration examples
	functions according to the following three security requirements: (i)		for security policy rules of network security functions according to
	Block SNS access during business hours, (ii) Block malicious VoIP/		the following three security requirements: (i) Block SNS access
	VoLTE packets coming to the company, and (iii) Mitigate http and		during business hours, (ii) Block malicious VoIP/VoLTE packets coming
	https flood attacks on company web server.		to the company, and (iii) Mitigate http and https flood attacks on
			company web server.
	A.1. Security Requirement 1: Block SNS Access during Business Hours		6.1. Security Requirement 1: Block SNS Access during Business Hours
	This section shows a configuration example for blocking SNS access		This section shows a configuration example for blocking SNS access
	during business hours.		during business hours.
	<i2nsf-security-policy		<i2nsf-security-policy
	xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-policy-rule-for-nsf">		xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-policy-rule-for-nsf">
	<system-policy>		<system-policy>
	<system-policy-name>sns_access</system-policy-name>		<system-policy-name>sns_access</system-policy-name>
	<rules>		<rules>
	<rule-name>block_sns_access_during_operation_time</rule-name>		<rule-name>block_sns_access_during_operation_time</rule-name>
	<time-intervals>		<time-intervals>
	<absolute-time-interval>		<absolute-time-interval>
	<start-time>09:00:00Z</start-time>		<start-date-time>2019-08-01T09:00:00Z</start-date-time>
	<end-time>18:00:00Z</end-time>		<end-date-time>2019-12-31T18:00:00Z</end-date-time>
	</absolute-time-interval>		</absolute-time-interval>
	</time-intervals>		</time-intervals>
	<condition-clause-container>		<condition-clause-container>
	<packet-security-ipv4-condition>		<packet-security-ipv4-condition>
	<pkt-sec-ipv4-src>		<pkt-sec-ipv4-src>
	<range-ipv4-address>		<range-ipv4-address>
	<start-ipv4-address>221.159.112.1</start-ipv4-address>		<start-ipv4-address>221.159.112.1</start-ipv4-address>
	<end-ipv4-address>221.159.112.90</end-ipv4-address>		<end-ipv4-address>221.159.112.90</end-ipv4-address>
	</range-ipv4-address>		</range-ipv4-address>
	</pkt-sec-ipv4-src>		</pkt-sec-ipv4-src>
	skipping to change at page 92, line 36 ¶		skipping to change at page 87, line 36 ¶
	</condition-clause-container>		</condition-clause-container>
	<action-clause-container>		<action-clause-container>
	<advanced-action>		<advanced-action>
	<content-security-control>url-filtering</content-security-control>		<content-security-control>url-filtering</content-security-control>
	</advanced-action>		</advanced-action>
	</action-clause-container>		</action-clause-container>
	</rules>		</rules>
	</system-policy>		</system-policy>
	</i2nsf-security-policy>		</i2nsf-security-policy>
	Figure 7: Configuration XML for Time based Firewall to Block SNS		Figure 7: Configuration XML for Time-based Firewall to Block SNS
	Access during Business Hours		Access during Business Hours
	<i2nsf-security-policy		<i2nsf-security-policy
	xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-policy-rule-for-nsf">		xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-policy-rule-for-nsf">
	<system-policy>		<system-policy>
	<system-policy-name>sns_access</system-policy-name>		<system-policy-name>sns_access</system-policy-name>
	<rules>		<rules>
	<rule-name>block_sns_access_during_operation_time</rule-name>		<rule-name>block_sns_access_during_operation_time</rule-name>
	<condition-clause-container>		<condition-clause-container>
	<packet-security-url-category-condition>		<packet-security-url-category-condition>
	skipping to change at page 93, line 29 ¶		skipping to change at page 88, line 29 ¶
	<egress-action>drop</egress-action>		<egress-action>drop</egress-action>
	</packet-action>		</packet-action>
	</action-clause-container>		</action-clause-container>
	</rules>		</rules>
	</system-policy>		</system-policy>
	</i2nsf-security-policy>		</i2nsf-security-policy>
	Figure 8: Configuration XML for Web Filter to Block SNS Access during		Figure 8: Configuration XML for Web Filter to Block SNS Access during
	Business Hours		Business Hours
	Figure 7 and Figure 8 show the configuration XML documents for time		Figure 7 and Figure 8 show the configuration XML documents for time-
	based firewall and web filter to block SNS access during business		based firewall and web filter to block SNS access during business
	hours. For the security requirement, two NSFs (i.e., a time based		hours. For the security requirement, two NSFs (i.e., a time-based
	firewall and a web filter) were used because one NSF can not meet the		firewall and a web filter) were used because one NSF cannot meet the
	security requirement. The instances of XML documents for the time		security requirement. The instances of XML documents for the time-
	based firewall and the web filter are as follows: Note that a		based firewall and the web filter are as follows: Note that a
	detailed data model for the configuration of the advanced network		detailed data model for the configuration of the advanced network
	security function (i.e., web filter) is described in		security function (i.e., web filter) is described in
	[draft-dong-i2nsf-asf-config].		[draft-dong-i2nsf-asf-config].
	Time based Firewall		Time-based Firewall is as follows:
	1. The name of the system policy is sns_access.		1. The name of the system policy is sns_access.
	2. The name of the rule is block_sns_access_during_operation_time.		2. The name of the rule is block_sns_access_during_operation_time.
	3. The rule is operated during the business hours (i.e., from 9 a.m.		3. The rule is operated during the business hours (i.e., from 9 a.m.
	to 6 p.m.).		to 6 p.m.).
	4. The rule inspects a source IPv4 address (i.e., from 221.159.112.1		4. The rule inspects a source IPv4 address (i.e., from 221.159.112.1
	to 221.159.112.90) to inspect the outgoing packets of employees.		to 221.159.112.90) to inspect the outgoing packets of employees.
	5. If the outgoing packets match the rules above, the time based		5. If the outgoing packets match the rules above, the time-based
	firewall sends the packets to url filtering for additional		firewall sends the packets to url filtering for additional
	inspection because the time based firewall can not inspect		inspection because the time-based firewall can not inspect
	contents of the packets for the SNS URL.		contents of the packets for the SNS URL.
	Web Filter		Web Filter is as follows:
	1. The name of the system policy is sns_access.		1. The name of the system policy is sns_access.
	2. The name of the rule is block_facebook_and_instagram.		2. The name of the rule is block_facebook_and_instagram.
	3. The rule inspects URL address to block the access packets to the		3. The rule inspects URL address to block the access packets to the
	facebook or the instagram.		facebook or the instagram.
	4. If the outgoing packets match the rules above, the packets are		4. If the outgoing packets match the rules above, the packets are
	blocked.		blocked.
	A.2. Security Requirement 2: Block Malicious VoIP/VoLTE Packets Coming		6.2. Security Requirement 2: Block Malicious VoIP/VoLTE Packets Coming
	to the Company		to a Company
	This section shows a configuration example for blocking malicious		This section shows a configuration example for blocking malicious
	VoIP/VoLTE packets coming to the company.		VoIP/VoLTE packets coming to a company.
	<i2nsf-security-policy		<i2nsf-security-policy
	xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-policy-rule-for-nsf">		xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-policy-rule-for-nsf">
	<system-policy>		<system-policy>
	<system-policy-name>voip_volte_inspection</system-policy-name>		<system-policy-name>voip_volte_inspection</system-policy-name>
	<rules>		<rules>
	<rule-name>block_malicious_voice_id</rule-name>		<rule-name>block_malicious_voice_id</rule-name>
	<condition-clause-container>		<condition-clause-container>
	<packet-security-ipv4-condition>		<packet-security-ipv4-condition>
	<pkt-sec-ipv4-dest>		<pkt-sec-ipv4-dest>
	skipping to change at page 95, line 37 ¶		skipping to change at page 90, line 37 ¶
	<action-clause-container>		<action-clause-container>
	<advanced-action>		<advanced-action>
	<content-security-control>voip-volte</content-security-control>		<content-security-control>voip-volte</content-security-control>
	</advanced-action>		</advanced-action>
	</action-clause-container>		</action-clause-container>
	</rules>		</rules>
	</system-policy>		</system-policy>
	</i2nsf-security-policy>		</i2nsf-security-policy>
	Figure 9: Configuration XML for General Firewall to Block Malicious		Figure 9: Configuration XML for General Firewall to Block Malicious
	VoIP/VoLTE Packets Coming to the Company		VoIP/VoLTE Packets Coming to a Company
	<i2nsf-security-policy		<i2nsf-security-policy
	xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-policy-rule-for-nsf">		xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-policy-rule-for-nsf">
	<system-policy>		<system-policy>
	<system-policy-name>voip_volte_inspection</system-policy-name>		<system-policy-name>voip_volte_inspection</system-policy-name>
	<rules>		<rules>
	<rule-name>block_malicious_voice_id</rule-name>		<rule-name>block_malicious_voice_id</rule-name>
	<condition-clause-container>		<condition-clause-container>
	<packet-security-voice-condition>		<packet-security-voice-condition>
	<pkt-sec-src-voice-id>11111@voip.black.com</pkt-sec-src-voice-id>		<pkt-sec-src-voice-id>11111@voip.black.com</pkt-sec-src-voice-id>
	skipping to change at page 96, line 27 ¶		skipping to change at page 91, line 27 ¶
	<action-clause-container>		<action-clause-container>
	<packet-action>		<packet-action>
	<ingress-action>drop</ingress-action>		<ingress-action>drop</ingress-action>
	</packet-action>		</packet-action>
	</action-clause-container>		</action-clause-container>
	</rules>		</rules>
	</system-policy>		</system-policy>
	</i2nsf-security-policy>		</i2nsf-security-policy>
	Figure 10: Configuration XML for VoIP/VoLTE Filter to Block Malicious		Figure 10: Configuration XML for VoIP/VoLTE Filter to Block Malicious
	VoIP/VoLTE Packets Coming to the Company		VoIP/VoLTE Packets Coming to a Company
	Figure 9 and Figure 10 show the configuration XML documents for		Figure 9 and Figure 10 show the configuration XML documents for
	general firewall and VoIP/VoLTE filter to block malicious VoIP/VoLTE		general firewall and VoIP/VoLTE filter to block malicious VoIP/VoLTE
	packets coming to the company. For the security requirement, two		packets coming to a company. For the security requirement, two NSFs
	NSFs (i.e., a general firewall and a VoIP/VoLTE filter) were used		(i.e., a general firewall and a VoIP/VoLTE filter) were used because
	because one NSF can not meet the security requirement. The instances		one NSF can not meet the security requirement. The instances of XML
	of XML documents for the general firewall and the VoIP/VoLTE filter		documents for the general firewall and the VoIP/VoLTE filter are as
	are as follows: Note that a detailed data model for the configuration		follows: Note that a detailed data model for the configuration of the
	of the advanced network security function (i.e., VoIP/VoLTE filter)		advanced network security function (i.e., VoIP/VoLTE filter) is
	is described in [draft-dong-i2nsf-asf-config].		described in [draft-dong-i2nsf-asf-config].
	General Firewall		General Firewall is as follows:
	1. The name of the system policy is voip_volte_inspection.		1. The name of the system policy is voip_volte_inspection.
	2. The name of the rule is block_malicious_voip_volte_packets.		2. The name of the rule is block_malicious_voip_volte_packets.
	3. The rule inspects a destination IPv4 address (i.e., from		3. The rule inspects a destination IPv4 address (i.e., from
	221.159.112.1 to 221.159.112.90) to inspect the packets coming		221.159.112.1 to 221.159.112.90) to inspect the packets coming
	into the company.		into the company.
	4. The rule inspects a port number (i.e., 5060 and 5061) to inspect		4. The rule inspects a port number (i.e., 5060 and 5061) to inspect
	VoIP/VoLTE packet.		VoIP/VoLTE packet.
	5. If the incoming packets match the rules above, the general		5. If the incoming packets match the rules above, the general
	firewall sends the packets to VoIP/VoLTE filter for additional		firewall sends the packets to VoIP/VoLTE filter for additional
	inspection because the general firewall can not inspect contents		inspection because the general firewall can not inspect contents
	of the VoIP/VoLTE packets.		of the VoIP/VoLTE packets.
	VoIP/VoLTE Filter		VoIP/VoLTE Filter is as follows:
	1. The name of the system policy is malicious_voice_id.		1. The name of the system policy is malicious_voice_id.
	2. The name of the rule is block_malicious_voice_id.		2. The name of the rule is block_malicious_voice_id.
	3. The rule inspects the voice id of the VoIP/VoLTE packets to block		3. The rule inspects the voice id of the VoIP/VoLTE packets to block
	the malicious VoIP/VoLTE packets (i.e., 11111@voip.black.com and		the malicious VoIP/VoLTE packets (i.e., 11111@voip.black.com and
	22222@voip.black.com).		22222@voip.black.com).
	4. If the incoming packets match the rules above, the packets are		4. If the incoming packets match the rules above, the packets are
	blocked.		blocked.
	A.3. Security Requirement 3: Mitigate HTTP and HTTPS Flood Attacks on a		6.3. Security Requirement 3: Mitigate HTTP and HTTPS Flood Attacks on a
	Company Web Server		Company Web Server
	This section shows a configuration example for mitigating http and		This section shows a configuration example for mitigating http and
	https flood attacks on a company web server.		https flood attacks on a company web server.
	<i2nsf-security-policy		<i2nsf-security-policy
	xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-policy-rule-for-nsf">		xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-policy-rule-for-nsf">
	<system-policy>		<system-policy>
	<system-policy-name>flood_attack_mitigation</system-policy-name>		<system-policy-name>flood_attack_mitigation</system-policy-name>
	<rules>		<rules>
	skipping to change at page 99, line 40 ¶		skipping to change at page 94, line 40 ¶
	general firewall and http and https flood attack mitigation to		general firewall and http and https flood attack mitigation to
	mitigate http and https flood attacks on a company web server. For		mitigate http and https flood attacks on a company web server. For
	the security requirement, two NSFs (i.e., a general firewall and a		the security requirement, two NSFs (i.e., a general firewall and a
	http and https flood attack mitigation) were used because one NSF can		http and https flood attack mitigation) were used because one NSF can
	not meet the security requirement. The instances of XML documents		not meet the security requirement. The instances of XML documents
	for the general firewall and http and https flood attack mitigation		for the general firewall and http and https flood attack mitigation
	are as follows: Note that a detailed data model for the configuration		are as follows: Note that a detailed data model for the configuration
	of the advanced network security function (i.e., http and https flood		of the advanced network security function (i.e., http and https flood
	attack mitigation) is described in [draft-dong-i2nsf-asf-config].		attack mitigation) is described in [draft-dong-i2nsf-asf-config].
	General Firewall		General Firewall is as follows:
	1. The name of the system policy is flood_attack_mitigation.		1. The name of the system policy is flood_attack_mitigation.
	2. The name of the rule is mitigate_http_and_https_flood_attack.		2. The name of the rule is mitigate_http_and_https_flood_attack.
	3. The rule inspects a destination IPv4 address (i.e.,		3. The rule inspects a destination IPv4 address (i.e.,
	221.159.112.95) to inspect the access packets coming into the		221.159.112.95) to inspect the access packets coming into the
	company web server.		company web server.
	4. The rule inspects a port number (i.e., 80 and 443) to inspect		4. The rule inspects a port number (i.e., 80 and 443) to inspect
	http and https packet.		http and https packet.
	5. If the packets match the rules above, the general firewall sends		5. If the packets match the rules above, the general firewall sends
	the packets to http and https flood attack mitigation for		the packets to http and https flood attack mitigation for
	additional inspection because the general firewall can not contrl		additional inspection because the general firewall can not contrl
	the amount of packets for http and https packets.		the amount of packets for http and https packets.
	HTTP and HTTPS Flood Attack Mitigation		HTTP and HTTPS Flood Attack Mitigation is as follows:
	1. The name of the system policy is		1. The name of the system policy is
	http_and_https_flood_attack_mitigation.		http_and_https_flood_attack_mitigation.
	2. The name of the rule is 100_per_second.		2. The name of the rule is 100_per_second.
	3. The rule controls the http and https packets according to the		3. The rule controls the http and https packets according to the
	amount of incoming packets.		amount of incoming packets.
	4. If the incoming packets match the rules above, the packets are		4. If the incoming packets match the rules above, the packets are
	blocked.		blocked.
	Appendix B. Changes from draft-ietf-i2nsf-nsf-facing-interface-dm-06		7. Security Considerations
	The following changes are made from draft-ietf-i2nsf-nsf-facing-		The YANG module specified in this document defines a data schema
	interface-dm-06:		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].
	o The version is revised according to the comments from Acee Lindem		The NETCONF access control model [RFC8341] provides a means of
	who is a YANG doctor for review.		restricting access to specific NETCONF or RESTCONF users to a
			preconfigured subset of all available NETCONF or RESTCONF protocol
			operations and content.
	Appendix C. Acknowledgments		There are a number of data nodes defined in this YANG module that are
			writable/creatable/deletable (i.e., config true, which is the
			default). These data nodes may be considered sensitive or vulnerable
			in some network environments. Write operations (e.g., edit-config)
			to these data nodes without proper protection can have a negative
			effect on network operations. These are the subtrees and data nodes
			and their sensitivity/vulnerability:
			o ietf-i2nsf-policy-rule-for-nsf: The attacker may provide incorrect
			policy information of any target NSFs by illegally modifying this.
			Some of the readable data nodes in this YANG module may be considered
			sensitive or vulnerable in some network environments. It is thus
			important to control read access (e.g., via get, get-config, or
			notification) to these data nodes. These are the subtrees and data
			nodes and their sensitivity/vulnerability:
			o ietf-i2nsf-policy-rule-for-nsf: The attacker may gather the
			security policy information of any target NSFs and misuse the
			security policy information for subsequent attacks.
			8. IANA Considerations
			This document requests IANA to register the following URI in the
			"IETF XML Registry" [RFC3688]:
			URI: urn:ietf:params:xml:ns:yang:ietf-i2nsf-policy-rule-for-nsf
			Registrant Contact: The IESG.
			XML: N/A; the requested URI is an XML namespace.
			This document requests IANA to register the following YANG module in
			the "YANG Module Names" registry [RFC7950].
			name: ietf-i2nsf-policy-rule-for-nsf
			namespace: urn:ietf:params:xml:ns:yang:ietf-i2nsf-policy-rule-for-
			nsf
			prefix: nsfintf
			reference: RFC XXXX
			9. 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).		Security Service Provisioning).
	Appendix D. Contributors		10. Contributors
	This document is made by the group effort of I2NSF working group.		This document is made by the group effort of I2NSF working group.
	Many people actively contributed to this document. The following are		Many people actively contributed to this document. The following are
	considered co-authors:		considered co-authors:
	o Hyoungshick Kim (Sungkyunkwan University)		o Hyoungshick Kim (Sungkyunkwan University)
	o Daeyoung Hyun (Sungkyunkwan University)		o Daeyoung Hyun (Sungkyunkwan University)
	o Dongjin Hong (Sungkyunkwan University)		o Dongjin Hong (Sungkyunkwan University)
	o Liang Xia (Huawei)		o Liang Xia (Huawei)
	o Tae-Jin Ahn (Korea Telecom)		o Tae-Jin Ahn (Korea Telecom)
	o Se-Hui Lee (Korea Telecom)		o Se-Hui Lee (Korea Telecom)
			11. References
			11.1. Normative References
			[RFC1394] Robinson, P., "Relationship of Telex Answerback Codes to
			Internet Domains", RFC 1394, DOI 10.17487/RFC1394, January
			1993, <https://www.rfc-editor.org/info/rfc1394>.
			[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
			Requirement Levels", BCP 14, RFC 2119,
			DOI 10.17487/RFC2119, March 1997,
			<https://www.rfc-editor.org/info/rfc2119>.
			[RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by
			an On-line Database", RFC 3232, January 2002.
			[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
			A., Peterson, J., Sparks, R., Handley, M., and E.
			Schooler, "SIP: Session Initiation Protocol", RFC 3261,
			DOI 10.17487/RFC3261, June 2002,
			<https://www.rfc-editor.org/info/rfc3261>.
			[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
			the Network Configuration Protocol (NETCONF)", RFC 6020,
			DOI 10.17487/RFC6020, October 2010,
			<https://www.rfc-editor.org/info/rfc6020>.
			[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
			and A. Bierman, Ed., "Network Configuration Protocol
			(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
			<https://www.rfc-editor.org/info/rfc6241>.
			[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
			Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
			<https://www.rfc-editor.org/info/rfc6242>.
			[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
			RFC 6991, DOI 10.17487/RFC6991, July 2013,
			<https://www.rfc-editor.org/info/rfc6991>.
			[RFC768] Postel, J., "User Datagram Protocol", RFC 768, August
			1980.
			[RFC791] Postel, J., "Internet Protocol", RFC 791, September 1981.
			[RFC792] Postel, J., "Internet Control Message Protocol", RFC 792,
			September 1981.
			[RFC793] Postel, J., "Transmission Control Protocol", RFC 793,
			September 1981.
			[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>.
			[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
			2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
			May 2017, <https://www.rfc-editor.org/info/rfc8174>.
			[RFC8177] Lindem, A., Ed., Qu, Y., Yeung, D., Chen, I., and J.
			Zhang, "YANG Data Model for Key Chains", RFC 8177,
			DOI 10.17487/RFC8177, June 2017,
			<https://www.rfc-editor.org/info/rfc8177>.
			[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
			(IPv6) Specification", STD 86, RFC 8200,
			DOI 10.17487/RFC8200, July 2017,
			<https://www.rfc-editor.org/info/rfc8200>.
			[RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R.
			Kumar, "Framework for Interface to Network Security
			Functions", RFC 8329, DOI 10.17487/RFC8329, February 2018,
			<https://www.rfc-editor.org/info/rfc8329>.
			[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
			BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
			<https://www.rfc-editor.org/info/rfc8340>.
			[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
			Access Control Model", STD 91, RFC 8341,
			DOI 10.17487/RFC8341, March 2018,
			<https://www.rfc-editor.org/info/rfc8341>.
			[RFC8431] Wang, L., Chen, M., Dass, A., Ananthakrishnan, H., Kini,
			S., and N. Bahadur, "A YANG Data Model for the Routing
			Information Base (RIB)", RFC 8431, DOI 10.17487/RFC8431,
			September 2018, <https://www.rfc-editor.org/info/rfc8431>.
			[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>.
			11.2. Informative References
			[draft-dong-i2nsf-asf-config]
			Pan, W. and L. Xia, "Configuration of Advanced Security
			Functions with I2NSF Security Controller", draft-dong-
			i2nsf-asf-config-01 (work in progress), October 2018.
			[draft-ietf-i2nsf-capability]
			Xia, L., Strassner, J., Basile, C., and D. Lopez,
			"Information Model of NSFs Capabilities", draft-ietf-
			i2nsf-capability-05 (work in progress), April 2019.
			[draft-ietf-i2nsf-capability-data-model]
			Hares, S., Jeong, J., Kim, J., Moskowitz, R., and Q. Lin,
			"I2NSF Capability YANG Data Model", draft-ietf-i2nsf-
			capability-data-model-05 (work in progress), July 2019.
			[draft-ietf-i2nsf-sdn-ipsec-flow-protection]
			Marin-Lopez, R., Lopez-Millan, G., and F. Pereniguez-
			Garcia, "Software-Defined Networking (SDN)-based IPsec
			Flow Protection", draft-ietf-i2nsf-sdn-ipsec-flow-
			protection-07 (work in progress), August 2019.
			[draft-ietf-supa-generic-policy-info-model]
			Strassner, J., Halpern, J., and S. Meer, "Generic Policy
			Information Model for Simplified Use of Policy
			Abstractions (SUPA)", draft-ietf-supa-generic-policy-info-
			model-03 (work in progress), May 2017.
			Appendix A. Changes from draft-ietf-i2nsf-nsf-facing-interface-dm-07
			The following changes are made from draft-ietf-i2nsf-nsf-facing-
			interface-dm-07:
			o The version is revised according to the comments from Acee Lindem
			who is a YANG doctor for review.
	Authors' Addresses		Authors' Addresses
	Jinyong Tim Kim		Jinyong Tim Kim
	Department of Electronic, Electrical and 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 10 8273 0930		Phone: +82 10 8273 0930
End of changes. 89 change blocks.
	363 lines changed or deleted		348 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/