Network Policy YANG Data Model
draft-wang-netmod-yang-policy-dm-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Zitao Wang , Linda Dunbar , Qin Wu | ||
| Last updated | 2015-01-26 | ||
| RFC stream | (None) | ||
| Formats | |||
| Additional resources | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-wang-netmod-yang-policy-dm-00
Network Working Group Z. Wang
Internet-Draft L. Dunbar
Intended status: Standards Track Q. Wu
Expires: July 30, 2015 Huawei
January 26, 2015
Network Policy YANG Data Model
draft-wang-netmod-yang-policy-dm-00
Abstract
This document describes a common core YANG data model for network
policies. The common core model can be augmented by additional YANG
modules defining data models for policy related protocols and
functions to support various different network applications (such as
Constraint based Routing, Network QoS, Traffic engineering, network
management etc). The core policy data model provides common building
blocks for such extensions - policy information bases, policy related
protocols.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 30, 2015.
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
Wang, et al. Expires July 30, 2015 [Page 1]
Internet-Draft Basic network policy January 2015
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Definitions and Acronyms . . . . . . . . . . . . . . . . . . 3
2.1. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 3
3. Design of Network Policy Modules . . . . . . . . . . . . . . 4
3.1. The Policy-set . . . . . . . . . . . . . . . . . . . . . 5
3.1.1. policy-role . . . . . . . . . . . . . . . . . . . . . 5
3.2. The Policy-group . . . . . . . . . . . . . . . . . . . . 6
3.3. Policy-rule . . . . . . . . . . . . . . . . . . . . . . . 7
4. IETF Network Policy data hierarchy . . . . . . . . . . . . . 9
5. Usage Examples . . . . . . . . . . . . . . . . . . . . . . . 10
5.1. Routing Policy . . . . . . . . . . . . . . . . . . . . . 10
5.2. QoS Policy . . . . . . . . . . . . . . . . . . . . . . . 11
6. IETF Network Policy YANG Module . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.1. Normative References . . . . . . . . . . . . . . . . . . 17
9.2. Informative References . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction
The policy-controlled network modeled the network as a state machine,
and use corresponding policy which may aggregate a set of policy
rules to control relevant devices at any given time RFC[3060].
The Policies can either be used in a stand-alone policy rule or
aggregated into policy groups functions RFC[3060]. And in order to
perform more elaborate functions, RFC[3460] defines a policy set to
aggregate the policy rule and policy group. And a set of conditions
associated with a policy rule specifies when the policy rule is
applicable. If such set of condition evaluates to TRUE, then
corresponding a set of actions will be executed.
This document describes a common core YANG data model for network
policies. The common core model can be augmented by additional YANG
modules defining data models for policy related protocols and
functions to support various different network applications (such as
Constraint Based Routing, Network QoS, Traffic Engineering, MPLS
management etc). The core policy data model provides common building
Wang, et al. Expires July 30, 2015 [Page 2]
Internet-Draft Basic network policy January 2015
blocks for such extensions - policy information bases, policy related
protocols.
2. Definitions and Acronyms
ACL: Access Control List
BNP: basic network policy
QoS: Quality of Service
YANG: A data definition language for NETCONF
2.1. Tree Diagrams
A simplified graphical representation of the data model is used in
this document. The meaning of the symbols in these diagrams is as
follows:
Each node is printed as:
<status> <flags> <name> <opts> <type>
<status> is one of:
+ for current
x for deprecated
o for obsolete
<flags> is one of:
rw for Read/Write
ro for ReadOnly
-x for rpcs (remote procedure calls)
-n for notifications
<name> is the name of the node
If the node is augmented into the tree from another module, its name
is printed as <prefix>:<name>.
Wang, et al. Expires July 30, 2015 [Page 3]
Internet-Draft Basic network policy January 2015
<opts> is one of:
? for an optional leaf or choice
! for a presence container
* for a leaf-list or list
[<keys>] for a list's keys
<type> is the name of the type for leafs and leaf-lists
3. Design of Network Policy Modules
Policies can either be used in a stand-alone fashion which are called
policy rules or aggregated into policy groups to perform more
elaborate functions [RFC3060]. And in accordance with [RFC3460],
policy set is inserted into the inheritance hierarchy above both
policy group and policy rule. In this document, we define common
core network policy yang module, and specific policies can inherit
and augment from it.
This section describes common core network policy yang model
structure and each separate elements:
Policy Set It is a set of Policies which is inserted into the
inheritance hierarchy above both Policy-group and Policy-Rule.
Policy Group A policy group is used to provide a hierarchical policy
definition that provides the model context or scope for each
policy rule. The policy group is identified by a policy group
name, and contains a set of policy rules. One Policy group can be
nested within other policy group.
Policy Rule A Policy Rule is represented by the semantics "If
Condition then Action". A Policy Rule may have a priority and a
precedence assigned to it. One Policy rule can be nested within
other policy rules.
The following figure shows the structure of ietf-policy yang model:
module: ietf-policy
rw policy-set!
| ....
+--rw policy-group* [group-name]
| ....
+--rw policy-rule* [rule-name]
| ....
Wang, et al. Expires July 30, 2015 [Page 4]
Internet-Draft Basic network policy January 2015
3.1. The Policy-set
A policy-set contain a policy-role leaf, a policy-decision-strategy
leaf, a list of policy-groups and a list of policy-rules. A policy
set is referred to a set of policies that can be applied to multiple
same role device in the network.
The following figure shows the snippet of policy-set list:
module: ietf-policy
+--rw policy-set!
| +--rw role role-type
| +--rw policy-decision-strategy enumeration
| +--rw policy-group* [policy-group-name]
| ......
| +--rw policy-rule*[rules-name]
......
Snippet of data hierarchy related to policy-set
o The policy-decision-strategy leaf is used to specify the decision
strategy for the policies. There are two matching strategy:
"First-Matching" and "All-Matching." "The First- Matching
strategy is used to cause the evaluation of the rules in a set
such that the only actions enforced on a given examination of the
Policy Set are those for the first rule that has its conditions
evaluate to TRUE. The All-Matching strategy is used to cause the
evaluation of all rules in a set; for all of the rules whose
conditions evaluate to TRUE, the actions are enforced. " [RFC3460]
o The policy-role is an administratively specified characteristic of
a managed element. As a selector for policies, it determines the
applicability of the policy to a particular managed element.
3.1.1. policy-role
In RFC[4011], the policy role is described as "A role is an
administratively specified characteristic of a managed element. As a
selector for policies, it determines the applicability of the policy
to a particular managed element. "
And some examples of policy role type has already defined in
RFC[4011], such as political, financial, legal, geographical, and
architectural characteristics. And in this document, the policy-role
is defined as an abstract property, Specific policies can specify
corresponding roles. For example, in MPLS management, one LSP can be
assigned with various roles including
"primary","secondary","backup","tunnel". The secondary LSP can be
Wang, et al. Expires July 30, 2015 [Page 5]
Internet-Draft Basic network policy January 2015
used to load primary LSP traffic so that network resource utilization
can be banlanced. When the primary LSP fails, the backup LSP can be
activiated so that network high availability can be achieved.
Tunneled LSP can be used by other LSPs to provide routing service or
support traffic enginneering.
3.2. The Policy-group
Policy group is a generalized aggregation list. And this list can
contain a set of policy rules that belong to the same group (e.g.,
having the same role for various policy rules). And a policy-group
list can also contains other policy-group, but are not allowed when
policy-groups contain both policy-groups and policy-rules RFC[3060].
The following figure shows the snippet of policy-rule list:
module: ietf-policy
+--rw policy-set!
|....
+--rw policy-group* [group-name]
+--rw group-name string
+--rw group-type bnp-group-type
+--rw role? role-type
+--rw oper-data!
| +--ro targets* string
+--rw policy-rule* [rule-name]
....
Snippet of data hierarchy related to policy-group
o The group-name is the identification of the policy-group.
Different policy-group list is distinguished via the leaf group-
name.
o The role in policy-group is an optional leaf. The role leaf have
already implicit inherited policy-set role, but sometimes we need
to defined a new role for a policy-group. For example, in policy-
set we defined the role is "Ethernet", and in some policy-rule it
may want to define another role characteristic such as "fast".
o The oper-info container contains a target leaf list. These
parameters can be used to present a set of targets which the
policy is applied. And the oper-date container also can be
augment by some specific policy to contain relevant topology
information.
Wang, et al. Expires July 30, 2015 [Page 6]
Internet-Draft Basic network policy January 2015
3.3. Policy-rule
Policies can either be used in a stand-alone policy rule or
aggregated into policy groups functions RFC[3060]. In this document
we define two separated policy-rule list:
1. The hierarchy of the policy-rule is under the policy-group list.
2. The hierarchy of the policy-rule is the same as the policy-group
list.
A Policy rule contains a policy-condition container and a policy-
action container. And a policy-condition contains a variable
container, a match container and a value container.
The following figure shows the snippet of policy-set:
module: ietf-policy
+--rw policy-set!
......
+--rw policy-group* [group-name]
| +--rw group-name string
| .....
+--rw policy-rule* [rule-name]
+--rw rule-name string
+--rw rule-type bnp-rule-type
+--rw role? role-type
+--rw priority uint32
+--rw sequenced-actions enumeration
+--rw execution-strategy enumeration
+--rw conditions!
| +--rw variable!
| +--rw match!
| +--rw value!
| +--rw policy-time-period!
| +--rw start? yang:date-and-time
| +--rw end? yang:date-and-time
| +--rw duration? uint32
+--rw action!
+--rw (policy-action)?
+--:(default-action)
+--rw action-null empty
Snippet of data hierarchy related to policy-rule
o The rule-name is the identification of the policy-rule. Different
policy-rule is distinguished via the leaf rule-name.
Wang, et al. Expires July 30, 2015 [Page 7]
Internet-Draft Basic network policy January 2015
o The priority leaf indicate the priority of the policy rule. And
it will be used when a single client is sending operations to
accomplish multiple tasks.
o The sequenced-actions leaf is an enumeration type which can
indicate the action ordering.
o The execution-strategy leaf defines the execution strategy to be
used upon the sequenced actions is this policy-rule.
o The condition container include a variable container, a match
container, a value container and a policy-time-period container.
o The variable container is a generalized aggregation container
which can be used to contain a set of condition variable. Note
that the variable may implicit in the model, and specific policies
(i.e. routing policy, Traffic Engineering, QoS policy etc.) can
augment this container.
augment /ietf-policy:policy-set/ietf-policy:policy-rule+
/ietf-policy:conditions/ietf-policy:variable
+--rw qos-variable!
+--rw qos-rsvp-variable!
o The match container is a generalized aggregation container which
can be used to contain a set of condition match parameters. Note
that the match may implicit in the model, and specific policies
(i.e. routing policy, Traffic Engineering related policy, QoS
policy etc.) can augment this container.
o The value container is a generalized aggregation container which
can be used to contain a set of condition value. Note that the
value may implicit in the model, and specific policies (i.e.
routing policy, Traffic Engineering related policy, QoS policy
etc.) can augment this container.
o The policy-time-period container include a start time leaf, an end
time leaf, and a duration optional leaf.
o The actions container include policy-action choice, and in this
basic policy yang model policy-action choice include a default
empty case, and it can be augmented by specific policy(i.e.
routing policy, Traffic Engineering related policy, QoS policy
etc.).
Wang, et al. Expires July 30, 2015 [Page 8]
Internet-Draft Basic network policy January 2015
augment /ietf-policy:policy-set/ietf-policy:policy-rule+
/ietf-policy:action/ietf-policy:policy-action:
+--:(qos-policy-action)
+--rw qos-action!
+--rw qos-simple-action!
+--rw qos-discard-action!
+--rw qos-admission-action!
+--rw qos-phb-action!
4. IETF Network Policy data hierarchy
The following figure provide the structure of basic network policy
yang
module: ietf-policy
+--rw policy-set!
| +--rw role role-type
| +--rw policy-decision-strategy enumeration
+--rw policy-rule* [rule-name]
| +--rw rule-name string
| +--rw rule-type bnp-rule-type
| +--rw role? role-type
| +--rw priority uint32
| +--rw sequenced-actions enumeration
| +--rw execution-strategy enumeration
| +--rw conditions!
| | +--rw variable!
| | +--rw match!
| | +--rw value!
| | +--rw policy-time-period!
| | +--rw start? yang:date-and-time
| | +--rw end? yang:date-and-time
| | +--rw duration? uint32
| +--rw action!
| +--rw (policy-action)?
| +--:(default-action)
| +--rw action-null empty
+--rw policy-group* [group-name]
+--rw group-name string
+--rw group-type bnp-group-type
+--rw role? role-type
+--rw oper-data!
| +--ro targets* string
+--rw policy-rule* [rule-name]
+--rw rule-name string
+--rw rule-type bnp-rule-type
+--rw role? role-type
+--rw priority uint32
Wang, et al. Expires July 30, 2015 [Page 9]
Internet-Draft Basic network policy January 2015
+--rw sequenced-actions enumeration
+--rw execution-strategy enumeration
+--rw conditions!
| +--rw variable!
| +--rw match!
| +--rw value!
| +--rw policy-time-period!
| +--rw start? yang:date-and-time
| +--rw end? yang:date-and-time
| +--rw duration? uint32
+--rw action!
+--rw (policy-action)?
+--:(default-action)
+--rw action-null empty
data hierarchy of Ietf Network Policy
5. Usage Examples
5.1. Routing Policy
The following figure provide an example of use in routing policy:
augment /ietf-policy:policy-set/ietf-policy:policy-rule/ietf-policy:conditions
+/ietf-policy:variable:
+--rw routing-variable!
+--rw prefix!
| +--rw address uint32
| +--rw masklength uint32
| +--rw masklengthrange uint32
+--rw neighbor!
+--rw address uint32
augment /ietf-policy:policy-set/ietf-policy:policy-rule/ietf-policy:conditions
+/ietf-policy:match:
+--rw routing-match!
+--rw match-prefix!
+--rw match-neighbor!
augment /ietf-policy:policy-set/ietf-policy:policy-rule/ietf-policy:action:
+--:(routing-policy-action)
+--rw routing-action!
+--rw accept uint32
+--rw reject uint32
o A condition contains a variable and a value and use a match
operator, to connect variable with value. And a simple condition
Wang, et al. Expires July 30, 2015 [Page 10]
Internet-Draft Basic network policy January 2015
models an elementary Boolean expression of the form "variable MATCH
value" RFC[3460].
o The prefix container containan address leaf, a masklength leaf and
a mask lengthrange leaf. The address leaf is used to indicate the
address variable, the masklength leaf is used to indicate the length
of mask, and the masklengthrange leaf is used to indicate the range
for the masklength.
o The neighbor container contain an address leaf. The address leaf
is used to indicate the address of neighbor.
o The match container contain a match-prefix container and a match-
neighbor container. If the prefix/neighbor variable and match-
prefix/mathc-prefix match success it may corresponding to a policy
value. And both match-prefix and match-neighbor are abstract
container that serves as the base container for all implicit match
operator.
o The routing-action container contains an access leaf and a reject
leaf.
5.2. QoS Policy
The following figure provide an example of use in QoS policy:
augment /ietf-policy:policy-set/ietf-policy:policy-rule/ietf-policy:conditions
+/ietf-policy:variable:
+--rw qos-variable!
+--rw qos-rsvp-variable!
augment /ietf-policy:policy-set/ietf-policy:policy-rule/ietf-policy:conditions
+/ietf-policy:match:
+--rw qos-match!
augment /ietf-policy:policy-set/ietf-policy:policy-rule/ietf-policy:conditions
+/ietf-policy:value:
+--rw qos-value!
+--rw qos-dn-value!
+--rw qos-attribute-value!
augment /ietf-policy:policy-set/ietf-policy:policy-rule/ietf-policy:action:
+--:(qos-policy-action)
+--rw qos-action!
+--rw qos-simple-action!
+--rw qos-discard-action!
+--rw qos-admission-action!
+--rw qos-phb-action!
Wang, et al. Expires July 30, 2015 [Page 11]
Internet-Draft Basic network policy January 2015
o The qos-variable container contains a qos-rsvp-variable container.
And the qos-rsvp-variable is an abstract container that serves as the
base container for all implicit variables that have to do with RSVP
conditioning RFC[3644].
o Sometimes the match operator is implicated, the formal notation of
the SimplePolicyCondition, together with its associations, models
only a pair, (<variable>, <value>) RFC[3460]. And in this example we
explicit defined an abstract qos-match container that serves as the
base container for all implicit match operator that have to do with
qos conditinon.
o The qos-value container contains a qos-dn-value container and a
qos-attribute-value container. The qos-dn-value container is used to
represent a set of Distinguished Name values. A Distinguished Name
can be used as a key to retrieve an object from a directory service.
And the qos-attribute-value container is used to represent a set of
property values for the "Value" term in a condition RFC[3644].
o The qos-policy-action case contains a qos-action container. And
the qos-action container contains a qos-simple-action container, a
qos-discard-action container, a qos-admission-action container and a
qos-phb-action container.
o The qos-simple-action container contains the elementary action.
And the qos-discard-action is used to specify that packets should be
discarded. The qos-admission-action container can be used to perform
admission decisions based on a comparison of a meter measuring the
temporal behavior of a set of flow with a traffic profile. And the
qos-phb-action is used to define the per-hop behavior that is to be
assigned to behavior aggregates RFC[3644].
6. IETF Network Policy YANG Module
<CODE BEGINS> file "ietf-policy.yang"
module ietf-policy{
yang-version 1;
namespace "urn:TBD:params:xml:ns:yang:ietf-policy";
prefix plc;
import ietf-yang-types { prefix yang;}
organization "IETF I2RS Working Group";
contact
"wangzitao@huawei.com";
description
"This module defines common core-network-policy yang data model";
Wang, et al. Expires July 30, 2015 [Page 12]
Internet-Draft Basic network policy January 2015
typedef bnp-group-type {
type string;
description "basic network group type";
}
typedef bnp-rule-type {
type string;
description "basic network policy rule type";
}
typedef role-type {
type string;
description "basic network policy role type";
}
grouping ietf-oper-info{
container oper-info{
description
"The oper-info container contains a target leaf list.
These parameters can be used to present a set of targets
which the policy is applied. And the oper-date container
also can be augment by some specific policy to contain
relevant topology information.";
leaf-list targets{
type string;
description "This leaf list can be used to present
a set of targets which the policy is applied.";}
}
}
grouping bnp-role{
leaf role{
description
"A role is an administratively specified characteristic of a managed element.
As a selector for policies, it determines the applicability of the policy to
a particular managed element.";
type role-type;
}
}
grouping ietf-policy-rule{
list policy-rule{
description
"defines a list of policy rules.";
key "rule-name";
leaf rule-name{
type string;
description
"The entry-index is the identification of the policy-rule-entry list";
}
Wang, et al. Expires July 30, 2015 [Page 13]
Internet-Draft Basic network policy January 2015
leaf rule-type{
description
"The rule-type is used to indicate the type of the policy rule.";
type bnp-rule-type;
}
uses bnp-role;
leaf priority{
description
"The priority leaf indicate the priority of the policy rule.
And it will be used when a single client is sending operations
to accomplish multiple tasks.";
type uint32;
}
leaf sequenced-actions{
description
"This leaf gives a policy administrator a way of specifying
the ordering of the policy actions.";
type enumeration{
enum mandatory{
description
"Do the actions in the indicated order, or don't do them at all.";}
enum recommended{
description
"Do the actions in the indicated order if you can,
but if you can't do them in this order, do them in another order if you can.";}
enum dontCare{
description
"I don't care about the order.";}
}
}
leaf execution-strategy{
description
"This leaf defines the execution strategy to be used
upon the sequenced actions is this policy-rule.";
type enumeration{
enum DoUntilSuccess {
description
"execute actions according to predefined order,
until successful execution of a single action.";}
enum DoAll{
description
"execute ALL actions which are part of the modeled set,
according to their predefined order. Continue doing this,
even if one or more of the actions fails.";}
enum DoUntilFailure{
description
Wang, et al. Expires July 30, 2015 [Page 14]
Internet-Draft Basic network policy January 2015
"execute actions according to predefined order,
until the first failure in execution of a single sub-action.";}
}
}
container conditions{
description
"define the policy conditions";
container variable{
description
"The variable container is a generalized aggregation container
which can be used to contain a set of condition variable.
Note that the variable may implicit in the model,
and specific policies (i.e. routing policy, ACL, OoS policy etc.)
can augment this container.";
}
container match{
description
"The match container is a generalized aggregation container
which can be used to contain a set of condition match parameters.
Note that the match may implicit in the model,
and specific policies (i.e. routing policy, ACL, OoS policy etc.)
can augment this container.";
}
container value{
description
"The value container is a generalized aggregation container
which can be used to contain a set of condition value.
Note that the value may implicit in the model,
and specific policies (i.e. routing policy, ACL, OoS policy etc.)
can augment this container.";
}
container policy-time-period{
leaf start{
description
"define the start time.";
type yang:date-and-time;}
leaf end{
description
"define the end time.";
type yang:date-and-time;}
leaf duration{
description
"define the duration time.";
type uint32;}
}
}
container action{
Wang, et al. Expires July 30, 2015 [Page 15]
Internet-Draft Basic network policy January 2015
choice policy-action{
case default-action{
leaf action-null{
description
"the default action is empty, and it can be augmented by specific policies.";
type empty;
}
}
}
}
}
}
grouping ietf-policy-group{
list policy-group{
key "group-name";
leaf group-name{
description
"The group-name is the identification of the policy-group.";
type string;
}
leaf group-type{
description
"The group-type is used to indicate the type of the policy group.";
type bnp-group-type;
}
uses bnp-role;
uses ietf-oper-info;
uses ietf-policy-rule;
}
}
container policy-set{
uses bnp-role;
leaf policy-decision-strategy {
description
"The match-strategy leaf is used to specify
the matching strategy for the policies of the policy rule.
There are two matching strategy: First-Matching and All-Matching.";
type enumeration{
enum First-Matching {
description "The First-Matching strategy is used to cause
the evaluation of the rules in a set such that the only actions
enforced on a given examination of the Policy Set are those for
the first rule that has its conditions evaluate to TRUE.";}
enum All-Matching {
description " The All-Matching strategy is used to cause the
evaluation of all rules in a set; for all of the rules whose
Wang, et al. Expires July 30, 2015 [Page 16]
Internet-Draft Basic network policy January 2015
conditions evaluate to TRUE, the actions are enforced.";}
}
}
uses ietf-policy-group;
uses ietf-policy-rule;
}
}
<CODE ENDS>
7. Security Considerations
TBD.
8. IANA Considerations
TBD.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the
Network Configuration Protocol (NETCONF)", RFC 6020,
October 2010.
[RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A.
Bierman, "Network Configuration Protocol (NETCONF)", RFC
6241', June 2011.
9.2. Informative References
[DMTF-CIM-SCHEMA]
Distributed Management Task Force, Inc., "DMTF
Technologies: CIM Standards CIM Schema: Version 2.5",
http://www.dmtf.org/standards/cim_schema_v25.php, .
[DMTF-CIM-SPEC]
Distributed Management Task Force, Inc., "Common
Information Model (CIM) Specification: Version 2.2",
http://www.dmtf.org/standards/documents/CIM/DSP0004.pdf.,
June 2014.
Wang, et al. Expires July 30, 2015 [Page 17]
Internet-Draft Basic network policy January 2015
[I-D.hares-i2rs-bnp-info-model-01]
Hares, S. and Q. Wu, "An Information Model for Basic
Network Policy", ID https://tools.ietf.org/html/draft-
hares-i2rs-bnp-info-model-01, October 2014.
[POLICY-FWK]
Stevens,M.,Weiss,W.,Mahon,H.,Moore,B.,Strassner,J.,Waters,
G.,Westerinen,A.,Wheeler,J., "Policy Framework", Work in
Progress 1999.
[RFC3060] Ellesson, Ed., Moore , B., Strassner, J., and A.
Westerinen , "Policy Core Information Model -- Version 1
Specification", RFC RFC3644, February 2001.
[RFC3198] Westerinen,A.,Schnizlein,J.,Strassner,J.,Scherling,M.,
Quinn,B.,Herzog,S.,Huynh,A.,Carlson,M.,Perry,J.,Waldbuss
er,S., "Terminology for Policy-Based Management", RFC
RFC3198, November 2001.
[RFC3460] Moore , B., "Policy Core Information Model (PCIM)
Extensions", RFC RFC3644, November 2003.
[RFC3644] Snir,Y.,Ramberg,Y.,Strassner,J.,Cohen,R.,Moore,B., "Policy
Quality of Service (QoS) Information Model", RFC RFC3644,
November 2003.
[RFC3670] Moore,B.,Durham,D.,Strassner,J.,Westerinen,A., Weiss,W,
"Information Model for Describing Network Device QoS
Datapath Mechanisms", RFC RFC3670, January 2004.
Authors' Addresses
Zitao Wang
Huawei Technologies,Co.,Ltd
101 Software Avenue, Yuhua District
Nanjing 210012
China
Email: wangzitao@huawei.com
Linda Dunbar
Huawei Technologies,Co.,Ltd
1700 Alma Drive, Suite 500
Plano, TX 75075
USA
Email: ldunbar@huawei.com
Wang, et al. Expires July 30, 2015 [Page 18]
Internet-Draft Basic network policy January 2015
Qin Wu
Huawei
101 Software Avenue, Yuhua District
Nanjing, Jiangsu 210012
China
Email: bill.wu@huawei.com
Wang, et al. Expires July 30, 2015 [Page 19]