< draft-hares-i2rs-bnp-info-model-00.txt		draft-hares-i2rs-bnp-info-model-01.txt >
	I2RS working group S. Hares		I2RS working group S. Hares
	Internet-Draft Q. Wu		Internet-Draft Q. Wu
	Intended status: Standards Track Huawei		Intended status: Standards Track Huawei
	Expires: March 30, 2015 September 26, 2014		Expires: April 30, 2015 October 27, 2014
	An Information Model for Basic Network Policy		An Information Model for Basic Network Policy
	draft-hares-i2rs-bnp-info-model-00		draft-hares-i2rs-bnp-info-model-01
	Abstract		Abstract
	This document contains three information Models: Basic Network Policy		This document contains the Basic Network Policy (BNP IM) Information
	(BNP IM). ACLs do not provide all the policy support required by		Model which an instantiation and extension of the PCIM work (RFC3060,
	BGP, Policy Based Routing (PBR), SFC Topology Information Model (SF-		RFC 3460, RFC 3644) that supports both the configuration models and
	Topo IM), Service Forwarding Chaing IM (SFC IM), and and flow		the I2RS ephemeral models. The PCIM work contains a Policy Core
	specification filtering. The BNP IM has the following top-down		Information Model (PCIM) (RFC3060) and the Quality of Service (QoS)
	levels of Policy Hierarchy: Policy Set, Policy Group, Policy Rule,		Policy Information Model (QPIM)(RFC3644) and policy based routing.
	and conditional actions within the policy rule (conditional match and		The PCIM work provided a framework to incorporate ACL filters, prefix
	Actions). These can be used in PBR-RIB or BGP to provide an ordered		filters, and more complex filters. This extension to PCIM model
	set of policy rules grouped with a Policy Group via operators (AND,		incorporate ACLs, Prefix-filtering, and complex policy (match, set,
	OR, etc.) and ordered by a combination of priority and precedence.		modify, set) into the PCIM framework. Complex policy is need by I2RS
	The Policy is an ordered set of Policy Groups.		programmatic interface to BGP, flow specification filtering, Policy
			Based Routing (PBR), MPLS topology management, and flow specification
	The BNP IM is based on the concept of an extensible information model		filtering.
	for representing policies. This concept is also found in the Policy
	Core Information Model (PCIM) (RFC3060) and the Quality of Service
	(QoS) Policy Information Model (QPIM)(RFC3644) and policy based
	routing.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on March 30, 2015.		This Internet-Draft will expire on April 30, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 IETF Trust and the persons identified as the		Copyright (c) 2014 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
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Definitions and Acronyms . . . . . . . . . . . . . . . . . . 5		2. Definitions and Acronyms . . . . . . . . . . . . . . . . . . 3
	3. Basic Network Policy Information Model (BNP IM) . . . . . . . 5		3. PCIM Overview . . . . . . . . . . . . . . . . . . . . . . . . 3
	3.1. BNP IM Overview . . . . . . . . . . . . . . . . . . . . . 5		4. Top-Down yang Diagram for PCIM . . . . . . . . . . . . . . . 5
	3.2. The Policy Set . . . . . . . . . . . . . . . . . . . . . 7		4.1. Policy Set Structures . . . . . . . . . . . . . . . . . . 5
	3.2.1. Policy Set Overview . . . . . . . . . . . . . . . . . 7		4.2. Policy Group Expansion for Basic Network Policy (BNP) . . 6
	3.2.2. Policy-Set RBNF . . . . . . . . . . . . . . . . . . . 8		5. Example of use in BGP . . . . . . . . . . . . . . . . . . . . 9
	3.3. The Policy Group . . . . . . . . . . . . . . . . . . . . 8		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
	3.3.1. Policy Group Overview . . . . . . . . . . . . . . . . 8		7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	3.3.2. Policy-Group RBNF . . . . . . . . . . . . . . . . . . 10		8. Informative References . . . . . . . . . . . . . . . . . . . 10
	3.4. The Policy Rule . . . . . . . . . . . . . . . . . . . . . 12		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
	3.4.1. Policy-Rule Overview . . . . . . . . . . . . . . . . 12
	3.4.2. Policy-Rule RBNF . . . . . . . . . . . . . . . . . . 13
	3.5. BNP IM Grammar . . . . . . . . . . . . . . . . . . . . . 18
	4. Extensions to the Policy IM . . . . . . . . . . . . . . . . . 18
	4.1. Extension to the RIB IM . . . . . . . . . . . . . . . . . 18
	4.2. Extension from the BGP IM . . . . . . . . . . . . . . . . 19
	4.3. Extension from SFC Topology IM . . . . . . . . . . . . . 19
	4.4. Extension from the SFC Traffic Filters . . . . . . . . . 19
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 19
	7. Informative References . . . . . . . . . . . . . . . . . . . 19
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
	1. Introduction		1. Introduction
	The Interface to the Routing System (I2RS) provides read and write		The Interface to the Routing System (I2RS) provides read and write
	access to the information and state within the routing process within		access to the information and state within the routing process within
	routing elements. The I2RS client interacts with one or more I2RS		routing elements. The I2RS client interacts with one or more I2RS
	agents to collect information from network routing systems.		agents to collect information from network routing systems. The
			processing of collecting information at the I2RS agent may require
	Processing of collected information at the I2RS agent may require the		the I2RS Agent to filter certain information, group pieces of
	I2RS Agent to filter certain information or group pieces of		information, or perform actions on the I2RS collected information
	information in order to reduce the data flow through the network to		based on specific I2RS policies.
	the I2RS client. Some applications that that utilize the services of
	I2RS client may also wish to require specific data in response to
	network events or conditions based on pre-established rules. This
	functionality is necessary to meet the requirements of i2rs enabled
	services which include service-layer routing improvements, and
	control of traffic flows and exit points.
	This document introduces a Basic Network Policy information model
	(BNP IM) to handle policies related to the network. This basic
	policy model can be easily extended beyond the basic functions. The
	[I-D.ietf-i2rs-architecture] suggests that associated with the I2RS
	RIB model there will be "Policy-based Routing (ACLs)" and RIB "policy
	controls". These basic policy functions can operate as part of this
	functional blocks providing the basic model for policy operators.
	This model can also be considered as the substance of the policy
	templates.
	The BNP IM is extensible allowing other extensions to make the BNP IM
	policy adaptable to specific I2RS protocol features. This policy
	model can be linked with other information models such as the
	following:
	o Policy Base Routing Information model (PBR-IM) (Model in section
	4),
	o I2RS RIB Informational Model (RIB IM) (see section 6)
	([I-D.ietf-i2rs-rib-info-model])
	o BGP Informational Model (BGP IM) (see section 6)
	([I-D.hares-i2rs-bgp-im])
	o Service Topology (see section 6)
	([I-D.hares-i2rs-info-model-service-topo])
	o Service Forwarding Chaining Filters Information Mode (SFC IM) (see		The generic policy work done in PCIM WG has been has been recast into
	section 6) (ietf-hares-dunbar-i2rs-sfc-policy-im-00.txt)		I2RS work. The PCIM work contains a Policy Core Information Model
			(PCIM) [RFC3060], Policy Core Informational Model Extensions
			[RFC3460] and the Quality of Service (QoS) Policy Information Model
			(QPIM) ([RFC3644]) The basic concept of PCIM is that there are policy
			rules which are combined into policy groups. If nesting and
			aggregation of policy groups is necessary, the PCIM work defines a
			policy set that operates under specific rules. Policy Groups can be
			used without using policy sets. This concept of a policy group as an
			entity that contains a set of policy rules is also reference utilized
			by the OpenDaylight group policy project.
	The BNP IM model is a product of the industry approach to I2RS that		In initial work for I2RS or netmod, the policy group that simply
	standardizes on a few basic network functions to obtain quick		combines and orders policies rules will be sufficient.
	deployment of initial I2RS RIB modules, and build on this success to
	create network functions. Additional I2RS modules add I2RS
	interfaces to policy-based routing, BGP, Service topology creation,
	Service Chaining functions, and policy templates.
	This information model leveraged previous work done on extensible		Policy rules may include specific filters such as ACL or prefix
	information model for representing policies. This work included the		filters by simple reference. The following drafts provide these more
	Policy Core Information Model (PCIM) [RFC3060] [RFC3060], and an		specific filters;
	extension to this model to address the need for QoS management,
	called the Quality of Service (QoS) Policy Information Model (QPIM)
	[RFC3644] [RFC3644].
	Most policy within routing and forwarding systems has become		o ACL policy [I-D.bogdanovic-netmod-acl-model]
	hierarchical with individual specific policies being grouped as a
	policy set. The hierarchical policy rule definition enhances policy
	readability and reusability. Groups of network policies have labels
	to aid operational use. Named groups of policy are easily identified
	and reused as blocks.
	The Basic Network Policy information model contains the following		o BGP Prefix filter policy [I-D.zhdankin-netmod-bgp-cfg]
	three components:
	Policy Group		2. Definitions and Acronyms
	Policy is described by a set of policy rules that may be grouped		BGP: Border Gateway Protocol
	into subsets. A Policy group is used to provide a hierarchical
	policy definition that provides the model context or scope for
	sub-rule actions. The model context includes identity, scope,
	role, precedence, priority and security model. In a policy group
	policy rules and policy groups can be nested within other policy
	rules.
	Policy Set		CLI: Command Line Interface
	A Policy Set is a set of Policy Groups identified by a Policy Set		IGP: Interior Gateway Protocol
	Name.
	Policy Rule		Information Model: An abstract model of a conceptual domain,
			independent of a specific implementations or data representation
	A Policy Rule is represented by the semantics "If Condition then		INSTANCE: Routing Code often has the ability to spin up multiple
	Action".		copies of itself into virtual machines. Each Routing code
			instance or each protocol instance is denoted as Foo_INSTANCE in
			the text below.
	This draft contains the Basic Network-Policy Information Model (BNP		NETCONF: The Network Configuration Protocol
	IM). BNP IM is a generic network policy model. It can be thought of
	as a coherent set of rules to administer, manage, and control access
	to network resources and defines a network policy at its most general
	level of abstraction. It models aspects such as actions and
	conditions that constitute a policy element relationship, as well as
	operators contained in the both condition and action that can either
	be used to overwrite an old value of the variable or imply match
	relationship.
	2. Definitions and Acronyms		PCIM - Policy Core Information Model
	IGP: Interior Gateway Protocol		RESTconf - http programmatic protocol to access yang modules
	Information Model: An abstract model of a conceptual domain,		3. PCIM Overview
	independent of a specific implementations or data representation
	CLI: Command Line Interface		The PCIM work created the concepts of Policy Set, Policy Group, and
			Policy Rule. This section reviews these concepts as background for
			the application of these concepts to current configuration and I2RS
			policy. In addition, this section suggests placement of policy rule
			concepts.
	SNMP: The Simple Network Management Protocol		The basic PCIM concepts are:
	NETCONF: The Network Configuration Protocol		Policy Set
	RBNF: Routing Backus-Naur Form		is a class which derived from Policy, and it is inserted into the
			inheritance hierarchy above both PolicyGroup and PolicyRule (as
			figure 1 shows). The Policy set is a coherent set of rules that
			has two properties of PolicyDecisionStrategy and PolicyRoles, and
			supports PolicySetComponent subclass. The PolicySetComponent is
			an aggregation class that allows aggregation of policy groups and
			under policy groups the a set of rules. The PolicySet contains
			rules for nesting policies that include matching strategies (all-
			matching or first-match), priorities between rules, and roles.
			One of the roles that must be conditionally matched is the models
			denotation of "read-only" or "read-write".
	INSTANCE: Routing Code often has the ability to spin up multiple		Policy Group
	copies of itself into virtual machines. Each Routing code
	instance or each protocol instance is denoted as Foo_INSTANCE in
	the text below.
	3. Basic Network Policy Information Model (BNP IM)		Policy is described by a set of policy rules that may be grouped
			into subsets. [RFC3060] defines policy groups as either a group
			of policy rules or group of policy groups - but not both. A
			policy group is used to provide a hierarchical policy definition
			that provides the model context or scope for sub-rule actions.
			The policy group is identified by a policy group name, and
			contains policy rules. Policy groups can be nested within other
			policy rules only within Policy sets.
	3.1. BNP IM Overview		Policy Rule
	I2RS needs its own implicit and explicit policy. This section		A Policy Rule is represented by the semantics "If Condition then
	provides an overview of the network policy model. The network policy		Action". A Policy Rule may have a priority assigned to it.
	model is defined by the following components, whose relationship is
	roughly depicted in the figure below.
	+-----------------------+		| "nests and aggregates policy-group"
	| Network-Policy |
	+-----------+-----------+
	^
	/|\
	| "extends"
	+-----------^-------------+		+-----------^-------------+
	| Policy Set |		| Policy Set |
	+--+-------------------+--+		+--+-------------------+--+
	^ ^		^ ^
	/|\ /|\		/|\ /|\
	+------------+ +--------------+		+------------+ +--------------+
	|Policy Group| | Policy Group |		|Policy Group| | Policy Group |
	+------------+ +--------------+		+------------+ +--------------+
	^ ^ +----------------+		^ ^ +------------------+
	| | ---|ACL Policy-Rule |		| | ---| ACL Policy-Rule |
	| | | | Additions |		| | | | Additions |
	| | | +----------------+		| | | +------------------+
	| "extends" | "extends" | +----------------+		| | | +------------------+
	+--------^-------+ +-------^-------+ |--|PBR Policy-Rule |		+--------^-------+ +-------^-------+ |--|Prefix Policy-Rule|
	| Policy Rule | | Policy Rule |<----| Additions |		| Policy Rule | | Policy Rule |<----| Additions |
	+----------------+ +---------------+ | +----------------+		+----------------+ +---------------+ | +------------------+
	: : | . . .		: : | . . .
	: : | +---------------+		: : | +------------------+
	......: :..... ---|RIB Policy-Rule|		......: :..... ---|Other Policy-Rule |
	: : | Additions |		: : | Additions |
	: : +---------------+		: : +------------------+
	: :		: :
	+---------V---------+ +-V-------------+		+---------V---------+ +-V-------------+
	| Policy Condition | | Policy Action |		| Policy Condition | | Policy Action |
	+-------------------+ +---------------+		+-------------------+ +---------------+
	: : : : : :		: : : : : :
	.....: . :..... .....: . :.....		.....: . :..... .....: . :.....
	: : : : : :		: : : : : :
	+----V---+ +---V----+ +--V---+ +-V------++--V-----++--V---+		+----V---+ +---V----+ +--V---+ +-V------++--V-----++--V---+
	| Match | |Policy | |Policy| | Set || Policy ||Policy|		| Match | |Policy | |Policy| | Set || Policy ||Policy|
	|Operator| |Variable| |Value | |Operator||Variable|| Value|		|Operator| |Variable| |Value | |Operator||Variable|| Value|
	+--------+ +--------+ +------+ +--------++--------++------+		+--------+ +--------+ +------+ +--------++--------++------+
	Figure 1: Overall model BNP IM structure		Figure 1: Overall model BNP IM structure
	Network-Policy - contains sets of policies.		4. Top-Down yang Diagram for PCIM
	Policy-Set: Provides an ordered list of Policy Groups according to
	the priority and precedence of the rules. rules. it is inserted into
	the inheritance hierarchy above both Policy-Group and Policy-Rule.
	Policy-Group: Defines the basic network policy Group model which
	combines the a list of Policy-Rules.
	Policy Rule: Represents the semantics of "If Condition then Action".
	o Condition models the elementary match operation "<variable> match
	<value>".
	o Action models the elementary set operation. "SET <variable> TO
	<value>".
	In the Condition model, the 'Match' operator is usually implied while
	in the action model, the 'Set' operator is explicitly used.
	Policy-Sets, Policy-Groups, and Policy-Rules have basic functionality
	(Policy-Basic IM) plus extensions defined by specific Information
	Models such as:
	The PBR Information Model (PBR IM) (contained in this document),
	The I2RS_Local_Policy Model (LP IM) (contained in this document),
	The RIB Information Model (RIB IM)
	([I-D.ietf-i2rs-rib-info-model]),
	The BGP Information Model (BGP-IM) ([I-D.hares-i2rs-bgp-im]),
	The Traffic Steering Information Model
	([I-D.hares-i2rs-info-model-service-topo]),
	The SFC Information Model (SFC IM) (ietf-hares-dunbar-i2rs-sfc-
	policy-im-00.txt)
	The MPLS LDP Information Model (MPLS LDP IM) (TBD) .
	I2RS Client-Agents Information Models MAY support only the Policy-
	Basic IM, or MAY support any additional specific information models.
	Each level of the Policy hierarchy (Policy-Set, Policy-Group, and
	Policy-Rules have both a read and write scope
	3.2. The Policy Set
	3.2.1. Policy Set Overview
	The Policy-Set structure has the following elements:
	o Policy-Set_Name - Unique Name for Policy Set
	o Policy-Set is introduced to provide an abstraction for a set of
	rules. It is derived from Policy, and it is inserted into the
	inheritance hierarchy above both PolicyGroup and PolicyRule. This
	reflects the additional structural flexibility and semantic
	capability of both subclasses.
	3.2.2. Policy-Set RBNF
	Figure 2 - Policy Set RBNF
	<Network_policy> ::= (<Policy_Set> ...)
	<Policy-Set> ::= <Policy-Set-Name> <Policy_Group_list>
	<PG_Priority< <PG_precedence>
	<Policy-Group_list> ::= (<Policy-Group> ...)
	3.3. The Policy Group
	3.3.1. Policy Group Overview
	In order to provide hierarchical policy definition and associate
	policy rule with other constraint, the basic policy group model needs
	to be defined. The corresponding extensions are introduced in a
	component, whose structure is informally depicted in the following
	diagram.
	Figure 2 - Policy Group
	+---------------------------------------+ (optional)
	| Policy Group |....
	+---------------------------------------+ :
	* * * * ^ :
	| | | :....:
	| | | | |
	| | | | |
	| | | | |
	+--------+ +----+ +-----------+ +------------------+
	|Identity| |Role| |Group order| | Policy Rule |
	+--------+ +----+ +---+--+---+| +------------------+
	* * * * * *
	| | | | |
	+--+ | - +---------+ +-------+ | +-+-------+
	| | | |priority | |policy | | |mandatory|
	| | +---------+ |order | | +---------+
	+----+---+ ++----+ |-+----------+ +-------+ | +-------+
	|Resource| |Scope| |-|precedence| | ----+-+ Name +
	+--------+ +-----+ | +----------+ | +--------+ | +-------+
	* * | +----------+ |-|priority| | +-------+
	| | |-|preference| | +--------+ +-|enabled|
	| | | +----------+ | +----------+ +-------+
	| | | +----------+ |-|precedence|
	| | |-| combine | | +----------+
	| | | +----------+ | +----------+
	| | | +----------+ |-|preference|
	| | |-|refcnt | | +----------+
	| | +----------+ | +----------+
	+-----++-----+ +-| combine |
	| Read||Write| | +----------+
	|Scope||Scope| | +----------+
	+-----++-----+ |-| refcnt |
	+----------+
	The basic information model works as follows: Within the policy group
	information model, hierarchy is used to model context or scope for
	the sub-rule actions. A policy group contains Identity, role, and
	group ordering information. The ordering is the variables priority,
	precedence, preference, combination operators (AND plus OR), and
	reference count (refcnt) for the policy group. The same ordering
	information is kept at the rule level.
	The elements of the Policy Group information model are as follows:
	o An identity contains the name of the Policy group
	o A role which identifies a resource (E.g. PBR-RIB, or BGP
	Neighbor) and a read/write scope. A policy group may have read
	scope, write scope, or both.
	o A policy group has ordering that includes priority, precedence,
	preference (within global route table) and combinational ordering
	(combine). A group can have only one priority, precedence, and
	preference. The default mechanism for establishing order to order
	first on priority, and if matched to use precedence to order, and
	if precedence ties, to use preference. Other priorities may be
	used and the signalling of these is not covered at this revision.
	The policy group reference count is a read-only variable on the
	number of times this policy-group has been associated with an I2RS
	interface to a protocol or a RIB (RIB or PBR RIB)
	o A policy rule has policy condition for matching, actions, and the
	same ordering values as the policy group which include: priority,
	precedence, preference, and combination ordering. Policy rules
	can be ordered within a RIB such as the PBR-RIB or within the a
	rules set associated with a protocol. Please note that ACLS wit
	their condition for matching, the DENY/ACCEPT action, and the
	preference setting form one type of policy group.
	o The mandatory flag indicates that this rule is mandatory to be
	satisfied for this policy group. (This feature is still under
	discussion within the group of authors.)
	o The enabled flag indicates that this rule is enabled. The lack of
	the flag allows rules to be inserted into a policy set without
	being enabled.
	o A policy rule can inherit scope and ordering from the policy group
	or use its own values. A policy rule also can have its own
	properties, e.g., enabled, mandatory, usage. Rules
	o The policy rule policy group elements can be extended with policy-
	specific components (policy-extensions, policy-group-extension
	respectively). One such extension is the inheritance of the ACL
	specific rule as policy rules.
	3.3.2. Policy-Group RBNF
	A more formal depiction in RBNF format follows below
	Figure 4 - Policy-Group RBNF
	<Policy-Group> ::= <Policy-Group_Identity>
	<Policy-Group_Roles>
	<Policy-Group_order>
	(<Policy-Rule* list>)
	[<Supporting-Policy-Group_list>]
	[<Policy-Group-Extension>]
	<Policy-Group-Roles> ::= (<Policy-Group-Role> ...)
	<Policy-Group-Role> ::=<Node-RESOURCES> | <Policy-Group-Scope>
	<Node-RESOURCES> ::= [<I2RS_AGENT_RESOURCE>]
	<Policy-Group-Scope> ::= (<READ_SCOPE> <Policy-Group_Read_Scope>)
	| (<WRITE_SCOPE> <Policy-Group_Write_Scope>)
	<Policy-Group_Identity> ::= STRING;
	<Policy-Group-Order> ::= <Policy-Group-Priority>
	<Policy-Group_precedence>
	<Policy-Group_preference>
	<Policy-Group_combine>
	<Policy-Group_refcnt>
	<Policy-Group-priority> ::= <PRIORITY>
	<Policy-Group-precedence> ::= <PRECEDENCE>
	<Policy-Group-preference> ::= <PREFERENCE>
	<Policy-Group_Combine> ::= <COMBO-OPERATORS>
	<Policy-Group-refcnt> ::= <REFCNT>
	<PRIORITY> :: = INTEGER;		The top down architecture has policy sets, policy groups, and policy
	<PRECEDENCE> :: = INTEGER:		rules. It is not necessary to have policy sets to have policy rules.
	<PREFERENCE> ::= INTEGER;
	<COMBO-OPERATORS> :: = [AND] | OR| NULL;
	<REFCNT> :: = INTEGER;
	<Policy-Rule-list> ::= <Policy-Rule>*
	[Xpath in Yang may or may not be able to replace the definitions below ]		4.1. Policy Set Structures
	<Policy-Group_Read_Scope> ::= <Policy-Group_Read_Scope_Type>		Per PCIM, the PolicySet contains rules for nesting policies that
	[<RIB-IM_READ_list>]		include matching strategies (all-matching or first-match), priorities
	[<BGP-IM-READ_list>]		between rules, and roles. The Yang diagram is below.
	<Policy-Group_Read_Scope_Type> ::= <RIB-IM_READ_SCOPE_TYPE>		Figure 2 - Policy Set Yang
	| <BGP-IM_READ_SCOPE_TYPE>
	<Policy-Group_Write_Scope> ::= <Policy-Group_Write_Scope_Type>		module: ietf-pcim
	[<RIB-IM_WRITE_list>]		+--rw policy-set [policy-set-name]
	[<BGP-IM-WRITE_list>]		| +--rw policy-set-name string
			| +--rw matching-strategy enumeration
			| +--rw policy-roles enumeration
			| +--rw default-rule-priority uint16
			| +--rw policy-group* [policy-group-name]
	<Policy-Group_Write_Scope_Type> ::= <RIB-IM_WRITE_SCOPE_TYPE>		Figure 2 - PSET Yang level
	| <BGP-IM_WRITE_SCOPE_TYPE>
	<Supporting-Policy-Group> ::= <SUPPORT-POLICY-GROUP> (		4.2. Policy Group Expansion for Basic Network Policy (BNP)
	<Policy-Group> ...)
	<Policy-Group-Extension> ::= ... /* Vendor Specific Policy */		Policy groups within the PCIM work have a name that identifies the
			grouping of policy rules. In PCIM, the policy rule has a name,
			status, priority, match condition with an action. The status for the
			policy rule is enabled or disabled. The priority is the priority
			within the policy rule order. This expansion of the PCIM policy rule
			adds a policy-rule order field, a reference count (pr-refcnt). It
			expands the PCIM match/condition methods to include a reference to
			other match-action fields.
	3.4. The Policy Rule		I2RS which requires that a read/write scope be tied to a particular
			portion of the ephemeral tree. This requirement is instantiated as
			the I2RS-role at the policy group level. However, it is anticipated
			this will be replaced by an expansion of [I-D.ietf-netconf-restconf]
			functionality surrounding the xpath feature. This element is left in
			this model to until these restconf xpath additions have been
			finalized.
	3.4.1. Policy-Rule Overview		The logical structure is below in figure 3 with an expansion of the
			pcim match-action-operation in figure 4.
	The following diagram contains an informal graphical depiction of the		Figure 3 - Policy Group
	main elements of the information model:		+-------------------------------------+ (optional)
			| Policy Group |....
			+--------------------------------------+ :
			* * * ^ :
			| | :....:
			| | | |
			| | | |
			| | | |
			+------+ +----+ +-----------------------+
			| Name | |I2RS| | Policy Rule |
			| | |Role| | |
			+------+ +----+ +-----------------------+
			* * *
			| | |
			+--+ | | +----------+
			| | |-| Name |
			| | | +----------+
			+----+---+ ++----+ | +----------+
			| | |I2RS | | + Policy |
			|Resource| |Scope| | +rule order|
			+--------+ +-----+ |-+----------+
			* * | +----------+
			+------+ | | |-| Status |
			|read |--| | | +----------+
			|scope | | | | +----------+
			+------+ | | |-| priority |
			+------+ | | +----------+
			|write |------| | +----------+
			|scope | |-| refcnt |
			+------+ | +----------+
			| +--------------+
			|-| PCIM |
			| | match/action |
			| +--------------+
			| +--------------+
			|-| ACL |
			| | match/action |
			| +--------------+
			|-+--------------+
			| Prefix-list |
			| match/action |
			+--------------+
	Figure 5 - Policy Rule		Figure 5 - Policy Rule's match-condition
	+----------------+		+----------------+
	| Policy Rule |		| PCIM |
			| Policy Rule |
	+----------------+		+----------------+
	* *		* *
	| |		| |
	| |		| |
	+---------+ +--------+		+---------+ +--------+
	...>|Condition|<.......| Action |<...		...>|Condition|<.......| Action |<...
	: +---------+<.......+--------+ :		: +---------+<.......+--------+ :
	: : * * : :		: : * * : :
	:..... | : :... :		:..... | : :... :
	| :		| :
	+--------+...........:		+--------+...........:
	|Operator|		|Operator|
	+--------+		+--------+
	Roughly speaking, the basic information model works as follows: A		The basic yang high-level structure for the policy group is included
	policy rule must identity, match conditions and actions; and it may		below in figure 6.
	contain policy rule ordering and status information. A operator
	connects variable and value in the action or condition. Condition
	can map onto and be supported by other condition, while action can
	map onto and be supported by other actions.
	The elements of the Policy Rule information model are as follows:
	o A policy can in turn be part of a hierarchy of policies Each
	policy is distinguished via a policy-identity.
	o Policy rule inherit scope from policy group. A policy role has a
	certain scope(read/write). This scope is intended to capture the
	unique I2RS read or write functionality of the role. This is a
	place-holder for this function of the I2RS ROLE. Hopefully,
	policy scope can be deleted.
	o Furthermore, a policy rule contains conditions and actions, each
	captured in their own list. The logic presented is a compromise
	between the simple logical AND and the complicated negation.
	o A condition contains a variable and a value and use a match
	operator, to connect variable with value. Also condition may be
	specific to a particular Info-Module like BGP IM. The list
	Policy-Rule_Condition_Extensions specifies these conditions which
	are unique to the protocol.
	o An action contains a variable and a value. An action uses the Set
	operator to connect a variable with a value. An action may be
	specific to a particular Info-Module like BGP IM. The list
	Policy-Rule_Action_Extensions specifies these conditions which are
	unique to the protocol. This is captured in list Policy-
	Rule_Action_Extensions
	o The policy, condition, action and operator elements can be
	extended with policy-specific components (policy-extensions,
	condition-extension, action-extension and operator-extension
	respectively) that are specific to other informational models.
	o Resources below indicates the amount of space that the policy
	might take in the routing instance. The issue is to try to
	differentiate between the 50 ACL policy group and the 300,000 ACL
	group.
	o Policy Rule scope maps to ROLE Read/Write Concept. This concept
	is under revision (see i2rs-security-draft) It is intended to
	restrict even policy to a portion of the Routing tree. Whether
	this makes policy simpler or more complex is the question.
	o RIB-IM-Tree-Match - indicates a match stored as a tree form with
	the longest match.
	3.4.2. Policy-Rule RBNF
	The information model for the Network-policy component is more
	formally shown in RBNF below:
	Figure 6 Policy Rule RBNF
	<Policy-Rule> ::= [<Policy-Rule-identity>]
	[<Policy-Rule-Order>]
	[<Policy-Rule-Scope]
	[<Policy-Rule-Status>]
	<Policy-Match>
	<Policy-Condition>
	[<Policy-Rule_rule_extensions>]
	<Policy-Rule-Order> ::= <Policy-Group-Priority>
	<Policy-Group_precedence>
	<Policy-Group_preference>
	<Policy-Group_combine>
	<Policy-Group_refcnt>
	<Policy-Rule-Status> ::= [<Policy-Rule-Enable>]
	[<Policy-Rule-Mandatory>]
	<Policy-Rule-identity> ::= string;
	<Policy-Rule-Priority> ::= <PRIORITY>
	<Policy-Rule-precedence> ::= <PRECEDENCE>
	<Policy-Rule-preference> ::= <PREFERENCE>
	<Policy-Rule-Combine> ::= <COMBO_OPERATORS>
	<Policy-Rule-refcnt> ::=<REFCNT>
	<Policy-Enable> ::= Boolean;
	<Policy-Mandatory> ::=Boolean;
	<Policy-Rule_Condition> ::= <Policy-Rule_Match_node>
	(<Policy-Rule_Match_value> ...)
	[<Policy-Rule_mode>]
	[<Policy-Rule_Match_Operator>]
	[<Policy-Rule_Condition_extension>]
	<Policy-Rule_Match_node> ::= [<Policy-Rule_Match_Node_BNP-IM>]
	| [<Policy-Rule_Match_node_external]
	<Policy-Rule_Match_value> ::= [<Policy-Rule_Match_Value_BNP-IM>]
	| [<Policy-Rule_Match_Value_external]
	<Policy-Rule_mode> ::= PERMIT | DENY ;
	<Policy-Rule_Match_operator_external> ::=
	[<Policy-Rule_Match_Operator_BNP-IM>]
	| [<Policy-Rule_Match_Operator_external]
	<Policy-Rule-action> ::= <Policy-Rule_Action_variable>
	<Policy-Rule_Action_value>
	<Policy-Rule_Set-Operator>
	[<Policy-Rule_action-extension> ]
	<Policy-Rule_Security-Model> ::= <First-Matching>
	|<All-Matching>]
	<Policy-Rule_rule_extension> ::=
	<I2RS-LC-policy_rule_extensions>
	<Policy-Rule-action> ::= <Policy-Rule_Action_variable>
	<Policy-Rule_Action_value>
	<Policy-Rule_Set-Operator>
	[<Policy-Rule_action-extension> ]
	<Policy-Rule_Action_variable> ::= <Policy-Rule_Action_var>
	(<Policy-Rule_Action_value> ...)
	[<Policy-Rule_Set_Operator>]
	[<Policy-Rule_Action_extension>]
	<Policy-Rule_Action_var> ::= [<Policy-Rule_Action_Vars_BNP-IM>]
	| [<Policy-Rule_Action_external>]
	<Policy-Rule_Action_value> ::= [<Policy-Rule_Action_Vars_BNP-IM>]
	| [<Policy-Rule_Action_external>]
	<Policy-Rule_Set_Operator> ::= [<Policy-Rule_Set_Operator_BNP-IM>]
	| [<Policy-Rule_Set_Operator_external>]
	<Policy-Rule-action-extension> ::=
	[<Policy-Rule_act_ext_BNP-IM>]
	| [<Policy-Rule_act_ext_external>]
	<Policy-Rule-Match-Operator-Policy-IM> ::= <IS-SET-MEMBER'>
	|<IN-INTEGER-RANGE>
	|<IP-ADDRESS-AS-RESOLVED-BY-DNS>
	|<Policy_IM-Match-Operator-extension>
	<Policy-Rule_condition_extension> ::=
	<Policy_Rule_condition_ext-BNP-IM>
	[<Policy-Rule_Condition_ext_external>]
	! Policy Rule scope maps to ROLE Read/Write Concept
	! This concept is under revision (see i2rs-security-draft)
	! It is intended to restrict even policy to a portion of the
	! Routing tree. Whether this makes policy simpler or more
	! complex is the question.
	<Policy-Rule_Scope> ::= (<READ_SCOPE>
	<Policy-Rule_Read_scope>)
	| (<WRITE_SCOPE>
	<Policy-Rule_Write_scope>)
	<Policy-Rule_Read_scope> ::= ((<BNP_READ_SCOPE_TYPE>
	<BNP_READ_SCOPE_list>) ...)
	| [<Policy-Rule_Read_Scope_External>]
	<Policy-Rule_Write_scope> ::= ((<BNP_WRITE_SCOPE_TYPE>
	<BNP_WRITE_SCOPE_list>)...)
	[<Policy-Rule_Write_Scope_External>]
	/* these scopes besides RIB IM are defined in each IM */
	<PR_Read_Scope_RIB_IM> ::=<RIB-IM_READ_SCOPE_TYPE>
	<RIB-IM_READ_list>
	<PR_Read_Scope_RIB_IM> ::=<RIB-IM_READ_SCOPE_TYPE>
	<RIB-IM_READ_list>
	<RIB-IM_READ_list> ::= [<RIB-IM-Tree-Match> ...]
	<RIB-IM_WRITE_list> ::= [<RIB-IM-Tree-Match> ...]
	<RIB-IM-Tree-Match> ::= <RIB-IM-Match-routing-instance>
	<RIB-IM-Match-interface-list>
	<RIM-IM-Match-rib_list>
	<RIB-IM-match-route-list>
	/* extensions to other IM */
	/* External Read and Write Scope */
	<Policy-Rule_Read_Scope_External> ::=
	[<PR_Read_Scope_RIB_IM>]
	[<PR_Read_Scope_BGP_IM>]
	[<PR_Read_Scope_PBR_IM>]
	[<PR_Read_Scope_I2RSLC_IM>]
	[<PR_Read_Scope_STopo_IM>]
	[<PR_Read_Scope_SFC-Policy_IM>]
	<Policy-Rule_Write_Scope_External> ::=
	[<PR_Write_Scope_RIB_IM>]
	[<PR_Write_Scope_BGP_IM>]
	[<PR_WriteScope_PBR_IM>]
	[<PR_Read_Scope_I2RSLC_IM>]
	[<PR_Read_Scope_STopo_IM>]
	[<PR_Read_Scope_SFC-PolicyIM>]
	/* External Rule Conditionals */
	<Policy-Rule_Match_node_external> ::=
	[<Policy-Rule_Match_Node_RIB-IM>]
	| [<Policy-Rule_Match_Node_PBR-IM>]
	| [<Policy-Rule_match_Node_I2RSLC-IM>]
	| [<Policy-Rule_Match_Node_BGP-IM>]
	| [<Policy-Rule_Match_Node_STopo-IM>]
	| [<Policy-Rule_Match_Node_SFC-Policy-IM>]
	<Policy-Rule_Match_Value_external> ::=
	[<Policy-Rule_Match_Value_RIB-IM>]
	| [<Policy-Rule_Match_Value_PBR-IM>]
	| [<Policy-Rule_Match_Value_I2RSLC-IM>]
	| [<Policy-Rule_Match_Value_BGP-IM>]
	| [<Policy-Rule_Match_Value_STopo-IM>]
	| [<Policy-Rule_Match_Value_SFC-Policy-IM>]
	<Policy-Rule_Match_operator_external> ::=
	[<Policy-Rule_Match_Operator_RIB-IM>]
	| [<Policy-Rule_Match_Operator_PBR-IM>]
	| [<Policy-Rule_Match_Operator_I2RSLC-IM>]
	| [<Policy-Rule_Match_Operator_BGP-IM>]
	| [<Policy-Rule_Match_Operator_STopo-IM>]
	| [<Policy-Rule_Match_Operator_SFC-Policy-IM>]
	<Policy-Rule_Action_value_external> ::=
	[<Policy-Rule_Action_Values_RIB-IM>]
	| [<Policy-Rule_Action_Values_PBR-IM>]
	| [<Policy-Rule_Match_Operator_I2RSLC-IM>]
	| [<Policy-Rule_Action_Values_BGP-IM>]
	| [<Policy-Rule_Set_Operator_STopo-IM>]
	| [<Policy-Rule_Set_Operator_SFC-Policy-IM>]
	<Policy-Rule_Set_Operator_external> ::=
	[<Policy-Rule_Set_Operator_RIB-IM>]
	| [<Policy-Rule_Set_Operator_PBR-IM>]
	| [<Policy-Rule_Match_Operator_I2RSLC-IM>]
	| [<Policy-Rule_Set_Operator_RIB-IM>]
	| [<Policy-Rule_Set_Operator_BGP-IM>]
	| [<Policy-Rule_Set_Operator_STopo-IM>]
	| [<Policy-Rule_Set_Operator_SFC-Policy-IM>]
	<Policy-Rule_act_ext_external> ::=
	[<Policy-Rule_extension_RIB-IM>]
	| [<Policy-Rule_act_ext_PBR-IM>]
	| [<Policy-Rule_act_ext_I2RSLC-IM>]
	| [<Policy-Rule_act_ext_RIB-IM>]
	| [<Policy-Rule_act_ext_BGP-IM>]
	| [<Policy-Rule_act_ext_STopo-IM>]
	| [<Policy-Rule_act_ext_SFC-Policy-IM>]
	| [<I2RS_Vendor-Rule_act_ext>]/* other I2RS IM */
	3.5. BNP IM Grammar
	This section specifies the network policy information model in
	Routing Backus-Naur Form (RBNF, [RFC5511]). It also provides
	diagrams of the main entities of which the information model is
	comprised.
	<basic-network_policy_in> ::= (<policy-set> ...)
	<basic-network_policy_out> ::= (<policy-set> ...)
	<network-policy_rules_list> ::= (<policy-rule>...)
	4. Extensions to the Policy IM
	4.1. Extension to the RIB IM
	Figure 11 - RIB Information Model Extensions
	<RIB-IM_READ_list> ::= [<RIB-IM-Tree-Match ...]
	<RIB-IM_WRITE_list> ::= [<RIB-IM-Tree-Match ...]
	<RIB-IM-Tree-Match> ::= <RIB-IM-Match-routing-instance>
	<RIB-IM-Match-interface-list>
	<RIM-IM-Match-rib_list>
	<RIB-IM-match-route-list;
	/* BGP Info Module Tree Match */
	<BGP-IM_READ_list> ::= [<BGP-IM-Tree-Match ...]
	<BGP-IM_WRITE_list> ::= [<BGP-IM-Tree-Match ...]
	<BGP-IM-Tree-Match> ::= <BGP-IM-Tree-Match-protocol-instance>
	<BGP-IM-Match-Protocol-instance> ::= (<BGP_protocol> ...)
	<pbr_rib> ::= <bgp_route_list>
	<bgp_route_list> ::= (<bgp_route> ...)
	<bgp_route> ::= <BGP_ROUTE_TYPE>
	<bgp_route_prefix>
	<bgp_attribute_list>
	<bgp_route_create>
	<bgp_rt_state_info>
	<basic-network_policy_in> ::= (<policy-set> ...)
	<basic-network_policy_out> ::= (<policy-set> ...)
	<network-policy_rules_list> ::= (<policy-rule>...)
	4.2. Extension from the BGP IM
	Figure 12 - BGP Information Model Extensions
	<BGP-IM_READ_list> ::= [<BGP-IM-Tree-Match ...]
	<BGP-IM_WRITE_list> ::= [<BGP-IM-Tree-Match ...]
	<BGP-IM-Tree-Match> ::= <BGP-IM-Tree-Match-protocol-instance>
	<BGP-IM-Match-Protocol-instance> ::= (<BGP_protocol> ...)
	4.3. Extension from SFC Topology IM
	Figure 13 - SFC Topology Information Model Extensions
	/* what part of the STopo Model can access */		Figure 6
	<STopo-IM_READ_list> ::= [<STopo-IM-Tree-Match ...]		module: ietf-pcim
	<STopo-IM_WRITE_list> ::= [<STopo-IM-Tree-Match ...]		+--rw policy-set [policy-set-name]
	<STopo-IM-Tree-Match> ::= <STopo-IM-Tree-Match-protocol-instance>		| ....
	<STopo-IM-Match-Protocol-instance> ::= (<STopo_protocol> ...)		| +--rw policy-group* [policy-group-name]
			| | +--rw policy-group-name
			| | +--rw i2rs-scope
			| | | +--tree-xpath
			| | | +--access enumeration
			| | +--rw policy-rule* [policy-rule-name]
			| | | +--rw pr-name string
			| | | +--rw pr-order unit16
			| | | +--rw pr-status enumeration
			| | | +--rw pr-priority unit16
			| | | +--rw pr-refcnt unit16
			| | | +--rw pr-match-act
			| | | | +--rw pr-match-act-type
			| | | | +case: pcim match-act ref-cnt
			| | | | +case: acl acl-ref
			| | | | +case: Prefix-list prefix-list-ref
			| | | + +case: pbr-pcim-match-act pbr-pcim-match-act-ref
	4.4. Extension from the SFC Traffic Filters		5. Example of use in BGP
	Figure 14 - Traffic Steering Information Model Extensions		The PCIM suggests a patch structure of match-field, operator for
			match, action (send packet), and set value. The following is an
			example is an example structure for the pcim of the match-condition
			applied to BGP.
	/* what part of the STopo Model can access */		figure 7
	<SFC-Policy-IM_READ_list> ::= [<SF-Policy-IM-Tree-Match ...]		+--rw bnp-match-act
	<SFC-Policy-IM_WRITE_list> ::= [<SF-Policy-IM-Tree-Match ...]		| +--rw bnp-match-act-bgp-i2rs
	<SFC-Policy-IM-Tree-Match> ::= <SF-Policy-IM-Tree-Match-protocol-instance>		| | +--rw bgp-match-field
	<SFC-Policy-IM-Match-Protocol-instance> ::= <SF_instance_list>		| | | +--rw bgp-afi
			| | | +--rw bgp-local-rib
			| | | +--rw bgp-peer
			| | | +--rw bgp-rib-in
			| | | | +--bgp-rib-in-policy-type
			| | | | +--bgp-rib-in-policy
			| | | | +--case: policy-set pcim-policy-set-name
			| | | | +--case: policy-group pcim-policy-group-name
			| | | +--rw bgp-rib-out
			| | | | +--bgp-rib-out-policy-type
			| | | | +--bgp-rib-out-policy
			| | | | +--case: policy-set pcim-policy-set-name
			| | | | +--case: policy-group pcim-policy-group-name
			| | | +--rw bgp-route-prefix
			| | | | .. prefix or prefix-range
			| | | +--rw bgp-attribute-list
			| | | | ... bgp attributes
			| | | +--rw bgp-state-info
			| | | | ... bgp state
			| | +--rw bgp-match-operator
			| | | +--rw operator-type enumeration
			| | | +--rw bgp-prefix-range-operator
			| | | +--rw bgp-attribute-operator
			| | | +--rw bgp-state-operator
			| | +--rw bgp-action
			| | | +--bgp-act enumeration
			| | | +--bgp-act value
			| | +--rw bgp-set
			| | | +--bgp-set enumeration
			| | | +--bgp-set value
	5. IANA Considerations		6. IANA Considerations
	This draft includes no request to IANA.		This draft includes no request to IANA.
	6. Security Considerations		7. Security Considerations
	TBD		TBD
	7. Informative References		8. Informative References
			[I-D.bogdanovic-netmod-acl-model]
			Bogdanovic, D., Sreenivasa, K., Huang, L., and D. Blair,
			"Network Access Control List (ACL) YANG Data Model",
			draft-bogdanovic-netmod-acl-model-02 (work in progress),
			October 2014.
	[I-D.hares-i2rs-bgp-im]		[I-D.hares-i2rs-bgp-im]
	Hares, S., Wang, L., and S. Zhuang, "An I2RS BGP		Hares, S., Wang, L., and S. Zhuang, "An I2RS BGP
	Information Model", draft-hares-i2rs-bgp-im-00 (work in		Information Model", draft-hares-i2rs-bgp-im-01 (work in
	progress), July 2014.		progress), October 2014.
	[I-D.hares-i2rs-info-model-service-topo]
	Hares, S., Wu, W., and X. Guan, "An Information model for
	service topology", draft-hares-i2rs-info-model-service-
	topo-01 (work in progress), July 2014.
	[I-D.hares-i2rs-usecase-reqs-summary]		[I-D.hares-i2rs-usecase-reqs-summary]
	Hares, S., "Summary of I2RS Use Case Requirements", draft-		Hares, S., "Summary of I2RS Use Case Requirements", draft-
	hares-i2rs-usecase-reqs-summary-00 (work in progress),		hares-i2rs-usecase-reqs-summary-00 (work in progress),
	July 2014.		July 2014.
	[I-D.ietf-i2rs-architecture]		[I-D.ietf-i2rs-architecture]
	Atlas, A., Halpern, J., Hares, S., Ward, D., and T.		Atlas, A., Halpern, J., Hares, S., Ward, D., and T.
	Nadeau, "An Architecture for the Interface to the Routing		Nadeau, "An Architecture for the Interface to the Routing
	System", draft-ietf-i2rs-architecture-05 (work in		System", draft-ietf-i2rs-architecture-05 (work in
	progress), July 2014.		progress), July 2014.
	[I-D.ietf-i2rs-rib-info-model]		[I-D.ietf-i2rs-rib-info-model]
	Bahadur, N., Folkes, R., Kini, S., and J. Medved, "Routing		Bahadur, N., Folkes, R., Kini, S., and J. Medved, "Routing
	Information Base Info Model", draft-ietf-i2rs-rib-info-		Information Base Info Model", draft-ietf-i2rs-rib-info-
	model-03 (work in progress), May 2014.		model-03 (work in progress), May 2014.
			[I-D.ietf-netconf-restconf]
			Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
			Protocol", draft-ietf-netconf-restconf-02 (work in
			progress), October 2014.
			[I-D.zhdankin-netmod-bgp-cfg]
			Alex, A., Patel, K., and A. Clemm, "Yang Data Model for
			BGP Protocol", draft-zhdankin-netmod-bgp-cfg-01 (work in
			progress), October 2014.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC3060] Moore, B., Ellesson, E., Strassner, J., and A. Westerinen,		[RFC3060] Moore, B., Ellesson, E., Strassner, J., and A. Westerinen,
	"Policy Core Information Model -- Version 1		"Policy Core Information Model -- Version 1
	Specification", RFC 3060, February 2001.		Specification", RFC 3060, February 2001.
			[RFC3460] Moore, B., "Policy Core Information Model (PCIM)
			Extensions", RFC 3460, January 2003.
	[RFC3644] Snir, Y., Ramberg, Y., Strassner, J., Cohen, R., and B.		[RFC3644] Snir, Y., Ramberg, Y., Strassner, J., Cohen, R., and B.
	Moore, "Policy Quality of Service (QoS) Information		Moore, "Policy Quality of Service (QoS) Information
	Model", RFC 3644, November 2003.		Model", RFC 3644, November 2003.
	[RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash,
	"Policy-Enabled Path Computation Framework", RFC 5394,
	December 2008.
	[RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax		[RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax
	Used to Form Encoding Rules in Various Routing Protocol		Used to Form Encoding Rules in Various Routing Protocol
	Specifications", RFC 5511, April 2009.		Specifications", RFC 5511, April 2009.
	Authors' Addresses		Authors' Addresses
	Susan Hares		Susan Hares
	Huawei		Huawei
	7453 Hickory Hill		7453 Hickory Hill
	Saline, MI 48176		Saline, MI 48176
	USA		USA
	Email: shares@ndzh.com		Email: shares@ndzh.com
	Qin Wu		Qin Wu
	Huawei		Huawei
	101 Software Avenue, Yuhua District		101 Software Avenue, Yuhua District
	Nanjing, Jiangsu 210012		Nanjing, Jiangsu 210012
	China		China
	Email: bill.wu@huawei.com@huawei.com		Email: bill.wu@huawei.com
End of changes. 62 change blocks.
	718 lines changed or deleted		273 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/