draft-ietf-i2nsf-consumer-facing-interface-dm-00.txt		draft-ietf-i2nsf-consumer-facing-interface-dm-01.txt
	Network Working Group J. Jeong		Network Working Group J. Jeong
	Internet-Draft E. Kim		Internet-Draft E. Kim
	Intended status: Standards Track Sungkyunkwan University		Intended status: Standards Track Sungkyunkwan University
	Expires: September 6, 2018 T. Ahn		Expires: January 3, 2019 T. Ahn
	Korea Telecom		Korea Telecom
	R. Kumar		R. Kumar
	Juniper Networks		Juniper Networks
	S. Hares		S. Hares
	Huawei		Huawei
	March 5, 2018		July 2, 2018
	I2NSF Consumer-Facing Interface YANG Data Model		I2NSF Consumer-Facing Interface YANG Data Model
	draft-ietf-i2nsf-consumer-facing-interface-dm-00		draft-ietf-i2nsf-consumer-facing-interface-dm-01
	Abstract		Abstract
	This document describes a YANG data model for the Consumer-Facing		This document describes a YANG data model for the Consumer-Facing
	Interface between an Interface to Network Security Functions (I2NSF)		Interface between an Interface to Network Security Functions (I2NSF)
	User and Security Controller in an I2NSF system in a Network		User and Security Controller in an I2NSF system in a Network
	Functions Virtualization (NFV) environment. The data model is		Functions Virtualization (NFV) environment. The data model is
	required for enabling different users of a given I2NSF system to		required for enabling different users of a given I2NSF system to
	define, manage, and monitor security policies for specific flows		define, manage, and monitor security policies for specific flows
	within an administrative domain.		within an administrative domain.
	skipping to change at page 1, line 42 ¶		skipping to change at page 1, line 42 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on September 6, 2018.		This Internet-Draft will expire on January 3, 2019.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 IETF Trust and the persons identified as the		Copyright (c) 2018 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 ¶
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3		2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
	3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	4. Data Modeling for Security Policies for Consumer-Facing		4. Data Modeling for Security Policies for Consumer-Facing
	Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 3		Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 3
	5. YANG Data Model for Security Policies for Consumer-Facing		5. YANG Data Model for Security Policies for Consumer-Facing
	Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 8		Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 8
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 36		6. Security Considerations . . . . . . . . . . . . . . . . . . . 37
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36		7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 37
	8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 36		8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 37
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 36		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 37
	9.1. Normative References . . . . . . . . . . . . . . . . . . 36		9.1. Normative References . . . . . . . . . . . . . . . . . . 37
	9.2. Informative References . . . . . . . . . . . . . . . . . 36		9.2. Informative References . . . . . . . . . . . . . . . . . 37
	Appendix A. Changes from draft-jeong-i2nsf-consumer-facing-		Appendix A. Changes from draft-ietf-i2nsf-consumer-facing-
	interface-dm-05 . . . . . . . . . . . . . . . . . . 38		interface-dm-00 . . . . . . . . . . . . . . . . . . 39
	Appendix B. Use Case: Policy Instance Example for VoIP/VoLTE		Appendix B. Use Case: Policy Instance Example for VoIP/VoLTE
	Security Services . . . . . . . . . . . . . . . . . 38		Security Services . . . . . . . . . . . . . . . . . 39
	Appendix C. Policy Instance YANG Example for VoIP/VoLTE Security		Appendix C. Policy Instance YANG Example for VoIP/VoLTE Security
	Services . . . . . . . . . . . . . . . . . . . . . . 40		Services . . . . . . . . . . . . . . . . . . . . . . 41
	Appendix D. Example XML output for VoIP service . . . . . . . . 50		Appendix D. Example XML output for VoIP service . . . . . . . . 51
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52
	1. Introduction		1. Introduction
	This document provides a YANG [RFC6020] data model that defines the		This document provides a YANG [RFC6020] data model that defines the
	required data for the Consumer-Facing Interface between an Interface		required data for the Consumer-Facing Interface between an Interface
	to Network Security Functions (I2NSF) User and Security Controller in		to Network Security Functions (I2NSF) User and Security Controller in
	an I2NSF system [i2nsf-framework] in a Network Functions		an I2NSF system [i2nsf-framework] in a Network Functions
	Virtualization (NFV) environment. The data model is required for		Virtualization (NFV) environment. The data model is required for
	enabling different users of a given I2NSF system to define, manage		enabling different users of a given I2NSF system to define, manage
	skipping to change at page 4, line 7 ¶		skipping to change at page 4, line 7 ¶
	facilitate the efficient delivery of the control or management		facilitate the efficient delivery of the control or management
	messages.		messages.
	This data model is designed to support the I2NSF framework that can		This data model is designed to support the I2NSF framework that can
	be extended according to the security needs. In other words, the		be extended according to the security needs. In other words, the
	model design is independent of the content and meaning of specific		model design is independent of the content and meaning of specific
	policies as well as the implementation approach. This document		policies as well as the implementation approach. This document
	suggests a VoIP/VoLTE security service as a use case for policy rule		suggests a VoIP/VoLTE security service as a use case for policy rule
	generation.		generation.
			+-----------------+ +-----------------+
			| | | |
			| Consumer Facing +------>+ Consumer Facing |
			| Interface | | Interface |
			|Information Model| | Data Model |
			+--------+--------+ +-----------------+
			^
			|
			|
			+-------------+-------------+
			| |
			| Policy-general |
			| |
			+-------------+-------------+
			^
			|
			+------------+-------------+------------+--------------+
			| | | | |
			+-----+----+ +----+-----+ +----+----+ +----+----+ +------+-----+
			| | | | | | | | | |
			| Multi | | Endpoint | | Policy | | Threat | | Telemetry |
			| tenancy | | groups | | | | feed | | data |
			+----------+ +----------+ +----+----+ +---------+ +------------+
			^
			|
			|
			+------+------+
			| |
			| Rule |
			| |
			+------+------+
			^
			|
			+----------------+----------------+
			| | |
			+------+------+ +------+------+ +------+------+
			| | | | | |
			| Event | | Condition | | Action |
			| | | | | |
			+-------------+ +-------------+ +-------------+
			Figure 1: High-level-abstraction for Consumer Facing Interface
	Multi-tenancy in this document enables multiple administrative		Multi-tenancy in this document enables multiple administrative
	domains in order to manage application resources. An Enterprise		domains in order to manage application resources. An Enterprise
	organization may have multiple tenants or departments such as HR,		organization may have multiple tenants or departments such as HR,
	finance, and legal. Thus, we need an object which defines a set of		finance, and legal. Thus, we need an object which defines a set of
	permissions assigned to a user in an organization that wants to		permissions assigned to a user in an organization that wants to
	manage its own Security Policies. You can think of it as a way to		manage its own Security Policies. You can think of it as a way to
	assign policy users to a job function or a set of permissions within		assign policy users to a job function or a set of permissions within
	the organization. The policy-role object SHALL have Name, Date and		the organization. The policy-role object SHALL have Name, Date and
	access-profile to grant or deny permissions for the perpose of		access-profile to grant or deny permissions for the perpose of
	security policy management.		security policy management.
	skipping to change at page 5, line 40 ¶		skipping to change at page 6, line 35 ¶
	| | +--rw role string		| | +--rw role string
	| +--rw policy-mgnt-auth-method* [policy-mgnt-auth-method-id]		| +--rw policy-mgnt-auth-method* [policy-mgnt-auth-method-id]
	| +--rw policy-mgnt-auth-method-id uint16		| +--rw policy-mgnt-auth-method-id uint16
	| +--rw name string		| +--rw name string
	| +--rw date yang:date-and-time		| +--rw date yang:date-and-time
	| +--rw authentication-method enumeration		| +--rw authentication-method enumeration
	| +--rw mutual-authentication boolean		| +--rw mutual-authentication boolean
	| +--rw token-server inet:ipv4-address		| +--rw token-server inet:ipv4-address
	| +--rw certificate-server inet:ipv4-address		| +--rw certificate-server inet:ipv4-address
	| +--rw single-sing-on-server inet:ipv4-address		| +--rw single-sing-on-server inet:ipv4-address
	+--rw end-group		+--rw endpoint-group
	| +--rw meta-data-source* [meta-data-source-id]		| +--rw meta-data-source* [meta-data-source-id]
	| | +--rw meta-data-source-id uint16		| | +--rw meta-data-source-id uint16
	| | +--rw name string		| | +--rw name string
	| | +--rw date yang:date-and-time		| | +--rw date yang:date-and-time
	| | +--rw tag-type? boolean		| | +--rw tag-type? boolean
	| | +--rw tag-server-information? inet:ipv4-address		| | +--rw tag-server-information? inet:ipv4-address
	| | +--rw tag-application-protocol? string		| | +--rw tag-application-protocol? string
	| | +--rw tag-server-credential? string		| | +--rw tag-server-credential? string
	| +--rw user-group* [user-group-id]		| +--rw user-group* [user-group-id]
	| | +--rw user-group-id uint16		| | +--rw user-group-id uint16
	skipping to change at page 7, line 44 ¶		skipping to change at page 8, line 39 ¶
	| +--rw qos-marking? uint16		| +--rw qos-marking? uint16
	+--rw telemetry-destination* [telemetry-destination-id]		+--rw telemetry-destination* [telemetry-destination-id]
	+--rw telemetry-destination-id uint16		+--rw telemetry-destination-id uint16
	+--rw name? string		+--rw name? string
	+--rw date? yang:date-and-time		+--rw date? yang:date-and-time
	+--rw collector-source? inet:ipv4-address		+--rw collector-source? inet:ipv4-address
	+--rw collector-credentials? string		+--rw collector-credentials? string
	+--rw data-encoding? string		+--rw data-encoding? string
	+--rw data-transport? enumeration		+--rw data-transport? enumeration
	Figure 1: Generic Data Model for Security Policies for cf Interface		Figure 2: Generic Data Model for Security Policies for cf Interface
	5. YANG Data Model for Security Policies for Consumer-Facing Interface		5. YANG Data Model for Security Policies for Consumer-Facing Interface
	This section describes a YANG data model for Consumer-Facing		This section describes a YANG data model for Consumer-Facing
	Interface, based on the information model of Consumer-Facing		Interface, based on the information model of Consumer-Facing
	Interface to security controller [client-facing-inf-im].		Interface to security controller [client-facing-inf-im].
	<CODE BEGINS> file "policy-general.yang"		<CODE BEGINS> file "policy-general.yang"
	module ietf-policy-general {		module ietf-policy-general {
	namespace		namespace
	skipping to change at page 8, line 47 ¶		skipping to change at page 9, line 37 ¶
	WG Chair: Linda Dunbar		WG Chair: Linda Dunbar
	<mailto:Linda.duhbar@huawei.com>		<mailto:Linda.duhbar@huawei.com>
	Editor: Jaehoon Paul Jeong		Editor: Jaehoon Paul Jeong
	<mailto:pauljeong@skku.edu>";		<mailto:pauljeong@skku.edu>";
	description		description
	"This module defines a YANG data module for consumer-facing		"This module defines a YANG data module for consumer-facing
	interface to security controller.";		interface to security controller.";
	revision "2018-03-05"{		revision "2018-07-02"{
	description "fourth revision";		description "fourth revision";
	reference		reference
	"draft-kumar-i2nsf-client-facing-interface-im-04";		"draft-kumar-i2nsf-client-facing-interface-im-04";
	}		}
	//Groupings		//Groupings
	container policy {		container policy {
	description		description
	"This object is a policy instance to have		"This object is a policy instance to have
	complete information such as where and when		complete information such as where and when
	a policy need to be applied.";		a policy need to be applied.";
	list rule {		list rule {
	key "rule-id";		key "rule-id";
	leaf rule-id {		leaf rule-id {
	skipping to change at page 19, line 10 ¶		skipping to change at page 20, line 4 ¶
	}		}
	leaf single-sing-on-server {		leaf single-sing-on-server {
	type inet:ipv4-address;		type inet:ipv4-address;
	mandatory true;		mandatory true;
	description		description
	"The single-sign-on-server information		"The single-sign-on-server information
	if the authentication method is		if the authentication method is
	single-sign-on-based";		single-sign-on-based";
	}		}
	}		}
	}		}
	container end-group {		container endpoint-group {
	description		description
	"A logical entity in their business		"A logical entity in their business
	environment, where a security policy		environment, where a security policy
	is to be applied.";		is to be applied.";
	list meta-data-source {		list meta-data-source {
	key "meta-data-source-id";		key "meta-data-source-id";
	leaf meta-data-source-id {		leaf meta-data-source-id {
	type uint16;		type uint16;
	mandatory true;		mandatory true;
	skipping to change at page 36, line 4 ¶		skipping to change at page 36, line 46 ¶
	}		}
	enum buffer-over-udp{		enum buffer-over-udp{
	description		description
	"telemetry data protocol is buffer over UDP.";		"telemetry data protocol is buffer over UDP.";
	}		}
	}		}
	description		description
	"This field contains streaming telemetry data		"This field contains streaming telemetry data
	protocols. This could be gRPC, protocol		protocols. This could be gRPC, protocol
	buffer over UDP, etc.";		buffer over UDP, etc.";
	}		}
	}		}
	}		}
	}		}
	<CODE ENDS>		<CODE ENDS>
			Figure 3: YANG for policy-general
	Figure 2: YANG for policy-general
	6. Security Considerations		6. Security Considerations
	The data model for the I2NSF Consumer-Facing Interface is derived		The data model for the I2NSF Consumer-Facing Interface is derived
	from the I2NSF Consumer-Facing Interface Information Model		from the I2NSF Consumer-Facing Interface Information Model
	[client-facing-inf-im], so the same security considerations with the		[client-facing-inf-im], so the same security considerations with the
	information model should be included in this document. The data		information model should be included in this document. The data
	model needs to support a mechanism to protect Consumer-Facing		model needs to support a mechanism to protect Consumer-Facing
	Interface to Security Controller.		Interface to Security Controller.
	7. Acknowledgements		7. Acknowledgments
	This work was supported by Institute for Information & communications		This work was supported by Institute for Information & communications
	Technology Promotion(IITP) grant funded by the Korea government(MSIP)		Technology Promotion(IITP) grant funded by the Korea government(MSIP)
	(No.R-20160222-002755, Cloud based Security Intelligence Technology		(No.R-20160222-002755, Cloud based Security Intelligence Technology
	Development for the Customized Security Service Provisioning).		Development for the Customized Security Service Provisioning).
	This document has greatly benefited from inputs by Hyoungshick Kim,		This document has greatly benefited from inputs by Hyoungshick Kim,
	Mahdi F. Dachmehchi, Seungjin Lee, Jinyong Tim Kim, and Daeyoung		Mahdi F. Dachmehchi, Seungjin Lee, Jinyong Tim Kim, and Daeyoung
	Hyun.		Hyun.
	skipping to change at page 38, line 5 ¶		skipping to change at page 39, line 5 ¶
	[i2nsf-terminology]		[i2nsf-terminology]
	Hares, S., Strassner, J., Lopez, D., Birkholz, H., and L.		Hares, S., Strassner, J., Lopez, D., Birkholz, H., and L.
	Xia, "Information model for Client-Facing Interface to		Xia, "Information model for Client-Facing Interface to
	Security Controller", draft-ietf-i2nsf-terminology-04		Security Controller", draft-ietf-i2nsf-terminology-04
	(work in progress), July 2017.		(work in progress), July 2017.
	[RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the		[RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the
	Network Configuration Protocol (NETCONF)", RFC 6020,		Network Configuration Protocol (NETCONF)", RFC 6020,
	October 2010.		October 2010.
	Appendix A. Changes from draft-jeong-i2nsf-consumer-facing-interface-		Appendix A. Changes from draft-ietf-i2nsf-consumer-facing-interface-
	dm-05		dm-00
	The following changes have been made from draft-jeong-i2nsf-consumer-		The following changes have been made from draft-jeong-i2nsf-consumer-
	facing-interface-dm-05:		facing-interface-dm-05:
	o In Section 4, the YANG has been modified to represent a policy		o In Section 3, the high-level abstraction of the consumer facing
	delivered over the consumer facing interface. More specifically,		interface has been added.
	the YANG model has been modified so that a policy-domain object
	can have multiple tenants, and as a result, the policy-tenant leaf
	in the tree is added to be the child of policy-domain object.
	This clarifies the relationship between a domain and tenants.
	o The overall organization of the YANG data model and its data types		o The overall organization of the YANG data model and its data types
	have also been reviewed and corrected, and produced the		have also been reviewed and corrected, and produced the
	corresponding data tree as shown in the Section 5. The reviewed		corresponding data tree as shown in the Section 5.
	data tree model and YANG fully adopted Event-Condition-Action
	(ECA) scheme as suggested in the most recent draft about the I2NSF
	Consumer-Facing Interface Information Model [client-facing-inf-im]
	and I2NSF Framework [i2nsf-framework].
	o The data tree model in Appendix B and Yang in Appendix C have also
	been modified for better adoption of ECA based policy generation.
	o A revised version of an example XML format output is as shown in
	Appendix D for VoIP service policy based on Yang in Appendix C.
	o Overall editorial errors have been corrected.		o Overall editorial errors have been corrected.
	Appendix B. Use Case: Policy Instance Example for VoIP/VoLTE Security		Appendix B. Use Case: Policy Instance Example for VoIP/VoLTE Security
	Services		Services
	A common scenario for VoIP/VoLTE policy enforcement could be that a		A common scenario for VoIP/VoLTE policy enforcement could be that a
	malicious call is made to a benign user of any telecommunication		malicious call is made to a benign user of any telecommunication
	company. For example, imagine a case wherea company "A" employs a		company. For example, imagine a case wherea company "A" employs a
	hacker with a malicious attempt to hack a user's phone with malware.		hacker with a malicious attempt to hack a user's phone with malware.
	skipping to change at page 40, line 23 ¶		skipping to change at page 41, line 9 ¶
	| +--rw signature-server? inet:ipv4-address		| +--rw signature-server? inet:ipv4-address
	| +--rw file-types? string		| +--rw file-types? string
	| +--rw malware-signatures? string		| +--rw malware-signatures? string
	+--rw event-map-group* [event-map-group-id]		+--rw event-map-group* [event-map-group-id]
	+--rw event-map-group-id uint16		+--rw event-map-group-id uint16
	+--rw name? string		+--rw name? string
	+--rw date? yang:date-and-time		+--rw date? yang:date-and-time
	+--rw security-events? string		+--rw security-events? string
	+--rw threat-map? string		+--rw threat-map? string
	Figure 3: Policy Instance Example for VoIP/VoLTE Security Services		Figure 4: Policy Instance Example for VoIP/VoLTE Security Services
	Appendix C. Policy Instance YANG Example for VoIP/VoLTE Security		Appendix C. Policy Instance YANG Example for VoIP/VoLTE Security
	Services		Services
	The following YANG data model is a policy instance for VoIP/VoLTE		The following YANG data model is a policy instance for VoIP/VoLTE
	security services. The policy-calendar can act as a scheduler to set		security services. The policy-calendar can act as a scheduler to set
	the start time and end time to block malicious calls which use		the start time and end time to block malicious calls which use
	suspicious IDs, or calls from other countries.		suspicious IDs, or calls from other countries.
	<CODE BEGINS> file "ietf-i2nsf-cf-interface-voip.yang"		<CODE BEGINS> file "ietf-i2nsf-cf-interface-voip.yang"
	skipping to change at page 41, line 23 ¶		skipping to change at page 42, line 9 ¶
	WG Chair: Linda Dunbar		WG Chair: Linda Dunbar
	<mailto:Linda.duhbar@huawei.com>		<mailto:Linda.duhbar@huawei.com>
	Editor: Jaehoon Paul Jeong		Editor: Jaehoon Paul Jeong
	<mailto:pauljeong@skku.edu>";		<mailto:pauljeong@skku.edu>";
	description		description
	"This module defines a YANG data module for consumer-facing		"This module defines a YANG data module for consumer-facing
	interface to security controller.";		interface to security controller.";
	revision "2018-03-05"{		revision "2018-07-02"{
	description "sixth revision";		description "sixth revision";
	reference		reference
	"draft-kumar-i2nsf-client-facing-interface-im-04";		"draft-kumar-i2nsf-client-facing-interface-im-04";
	}		}
	container policy-voip {		container policy-voip {
	description		description
	"This object is a policy instance to have		"This object is a policy instance to have
	complete information such as where and when		complete information such as where and when
	a policy need to be applied.";		a policy need to be applied.";
	skipping to change at page 50, line 33 ¶		skipping to change at page 51, line 19 ¶
	type string;		type string;
	description		description
	"This contains a list of threat levels.";		"This contains a list of threat levels.";
	}		}
	}		}
	}		}
	}		}
	<CODE ENDS>		<CODE ENDS>
	Figure 4: Policy Instance YANG Example for VoIP Security Services		Figure 5: Policy Instance YANG Example for VoIP Security Services
	Appendix D. Example XML output for VoIP service		Appendix D. Example XML output for VoIP service
	In this section, we present an XML example for VoIP service. Here,		In this section, we present an XML example for VoIP service. Here,
	we are going to drop calls commin from a country with an Ip from		we are going to drop calls commin from a country with an Ip from
	South Africa that is classified as malicious.		South Africa that is classified as malicious.
	<?xml version="1.1" encoding="UTF-8"?>		<?xml version="1.1" encoding="UTF-8"?>
	<rpc message-id="1" xmlns="urn:ietf:params:xml:ns:restconf:base:1.0">		<rpc message-id="1" xmlns="urn:ietf:params:xml:ns:restconf:base:1.0">
	<edit-config>		<edit-config>
	skipping to change at page 51, line 46 ¶		skipping to change at page 52, line 32 ¶
	<owner-id>01</owner-id>		<owner-id>01</owner-id>
	<name>i2nsf-admin</name>		<name>i2nsf-admin</name>
	</owner>		</owner>
	</rule-voip>		</rule-voip>
	</policy-voip>		</policy-voip>
	</i2nsf-cf-interface-voip-req>		</i2nsf-cf-interface-voip-req>
	</config>		</config>
	</edit-config>		</edit-config>
	</rpc>		</rpc>
	Figure 5: An XML example for VoIP service		Figure 6: An XML example for VoIP service
	Authors' Addresses		Authors' Addresses
	Jaehoon Paul Jeong		Jaehoon Paul Jeong
	Department of Software		Department of Software
	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
End of changes. 24 change blocks.
	46 lines changed or deleted		75 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/