One document matched: draft-wang-netmod-yang-policy-dm-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- edited with XMLSPY v5 rel. 3 U (http://www.xmlspy.com)
by Daniel M Kohn (private) -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC3775 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3775.xml">
<!ENTITY RFC4225 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4225.xml">
<!ENTITY RFC4866 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4866.xml">
<!ENTITY RFC5213 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5213.xml">
<!-- added by sjjeong: -->
<!ENTITY I-D.ietf-netlmm-pmip6-ipv4-support PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-netlmm-pmip6-ipv4-support.xml">
<!ENTITY I-D.ietf-netlmm-grekey-option PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-netlmm-grekey-option.xml">
]>
<rfc category="std" docName="draft-wang-netmod-yang-policy-dm-00"
ipr="trust200902">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<front>
<title abbrev="Basic network policy">Network Policy YANG Data
Model</title>
<author fullname="Zitao Wang" initials="Z." surname="Wang">
<organization abbrev="Huawei">Huawei Technologies,Co.,Ltd</organization>
<address>
<postal>
<street>101 Software Avenue, Yuhua District</street>
<street/>
<city>Nanjing</city>
<region/>
<code>210012</code>
<country>China</country>
</postal>
<email>wangzitao@huawei.com</email>
</address>
</author>
<author fullname="Linda Dunbar" initials="L." surname="Dunbar">
<organization abbrev="Huawei">Huawei Technologies,Co.,Ltd</organization>
<address>
<postal>
<street>1700 Alma Drive, Suite 500</street>
<street/>
<city>Plano</city>
<region>TX</region>
<code>75075</code>
<country>USA</country>
</postal>
<phone/>
<email>ldunbar@huawei.com</email>
</address>
</author>
<author fullname="Qin Wu" initials="Q." surname="Wu">
<organization>Huawei</organization>
<address>
<postal>
<street>101 Software Avenue, Yuhua District</street>
<city>Nanjing</city>
<region>Jiangsu</region>
<code>210012</code>
<country>China</country>
</postal>
<email>bill.wu@huawei.com</email>
</address>
</author>
<date year="2015"/>
<area>OPS Area</area>
<workgroup/>
<abstract>
<t>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.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>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].</t>
<t>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.</t>
<t>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 blocks for such
extensions - policy information bases, policy related protocols.</t>
</section>
<section title="Definitions and Acronyms">
<t><list style="hanging">
<t hangText="ACL:">Access Control List<vspace blankLines="1"/></t>
<t hangText="BNP:">basic network policy<vspace blankLines="1"/></t>
<t hangText="QoS:">Quality of Service<vspace blankLines="1"/></t>
<t hangText="YANG:">A data definition language for NETCONF</t>
</list></t>
<section title="Tree Diagrams">
<t>A simplified graphical representation of the data model is used in
this document. The meaning of the symbols in these diagrams is as
follows:</t>
<t>Each node is printed as:<figure>
<artwork>
<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</artwork>
</figure></t>
<t>If the node is augmented into the tree from another module, its
name is printed as <prefix>:<name>. <figure>
<artwork><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</artwork>
</figure></t>
</section>
</section>
<section title="Design of Network Policy Modules">
<t>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.</t>
<t>This section describes common core network policy yang model
structure and each separate elements: <list style="hanging">
<t hangText="Policy Set">It is a set of Policies which is inserted
into the inheritance hierarchy above both Policy-group and
Policy-Rule.<vspace blankLines="1"/></t>
<t hangText="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.<vspace
blankLines="1"/></t>
<t hangText="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.<vspace blankLines="1"/></t>
</list></t>
<t>The following figure shows the structure of ietf-policy yang
model:</t>
<figure>
<artwork>module: ietf-policy
rw policy-set!
| ....
+--rw policy-group* [group-name]
| ....
+--rw policy-rule* [rule-name]
| ....
</artwork>
</figure>
<section title="The Policy-set">
<t>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.</t>
<t>The following figure shows the snippet of policy-set list:</t>
<figure title="Snippet of data hierarchy related to policy-set">
<artwork> 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]
......
</artwork>
</figure>
<t><list style="symbols">
<t>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]</t>
<t>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.</t>
</list></t>
<section title="policy-role ">
<t>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. "</t>
<t>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
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.</t>
</section>
</section>
<section title="The Policy-group">
<t>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].</t>
<t>The following figure shows the snippet of policy-rule list:</t>
<figure title="Snippet of data hierarchy related to policy-group">
<artwork>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]
....
</artwork>
</figure>
<t><list style="symbols">
<t>The group-name is the identification of the policy-group.
Different policy-group list is distinguished via the leaf group-
name.</t>
<t>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".</t>
<t>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.</t>
</list></t>
</section>
<section title="Policy-rule">
<t>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:<list style="numbers">
<t>The hierarchy of the policy-rule is under the policy-group
list.</t>
<t>The hierarchy of the policy-rule is the same as the
policy-group list.</t>
</list></t>
<t>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.</t>
<t>The following figure shows the snippet of policy-set:</t>
<figure title="Snippet of data hierarchy related to policy-rule">
<artwork>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
</artwork>
</figure>
<t><list style="symbols">
<t>The rule-name is the identification of the policy-rule.
Different policy-rule is distinguished via the leaf rule-name.</t>
<t>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.</t>
<t>The sequenced-actions leaf is an enumeration type which can
indicate the action ordering.</t>
<t>The execution-strategy leaf defines the execution strategy to
be used upon the sequenced actions is this policy-rule.</t>
<t>The condition container include a variable container, a match
container, a value container and a policy-time-period
container.</t>
<t>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.</t>
</list></t>
<figure>
<artwork>augment /ietf-policy:policy-set/ietf-policy:policy-rule+
/ietf-policy:conditions/ietf-policy:variable
+--rw qos-variable!
+--rw qos-rsvp-variable!
</artwork>
</figure>
<t><list style="symbols">
<t>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.</t>
<t>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.</t>
<t>The policy-time-period container include a start time leaf, an
end time leaf, and a duration optional leaf.</t>
<t>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.).</t>
</list></t>
<figure>
<artwork>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!
</artwork>
</figure>
</section>
</section>
<section title="IETF Network Policy data hierarchy">
<t>The following figure provide the structure of basic network policy
yang</t>
<figure title="data hierarchy of Ietf Network Policy">
<artwork>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
+--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
</artwork>
</figure>
</section>
<section title="Usage Examples">
<section title="Routing Policy">
<t>The following figure provide an example of use in routing
policy:</t>
<figure>
<artwork>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! </artwork>
</figure>
<figure>
<artwork>augment /ietf-policy:policy-set/ietf-policy:policy-rule/ietf-policy:action:
+--:(routing-policy-action)
+--rw routing-action!
+--rw accept uint32
+--rw reject uint32
</artwork>
</figure>
<t>o A condition contains a variable and a value and use a match
operator, to connect variable with value. And a simple condition
models an elementary Boolean expression of the form "variable MATCH
value" RFC[3460].</t>
<t>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.</t>
<t>o The neighbor container contain an address leaf. The address leaf
is used to indicate the address of neighbor.</t>
<t>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.</t>
<t>o The routing-action container contains an access leaf and a reject
leaf.</t>
</section>
<section title="QoS Policy">
<t>The following figure provide an example of use in QoS policy:</t>
<figure>
<artwork>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!</artwork>
</figure>
<figure>
<artwork>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!
</artwork>
</figure>
<t>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].</t>
<t>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.</t>
<t>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].</t>
<t>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.</t>
<t>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].</t>
</section>
</section>
<section title="IETF Network Policy YANG Module">
<figure>
<artwork><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";
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";
}
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
"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{
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
conditions evaluate to TRUE, the actions are enforced.";}
}
}
uses ietf-policy-group;
uses ietf-policy-rule;
}
}
<CODE ENDS></artwork>
</figure>
</section>
<section title="Security Considerations">
<t>TBD.</t>
</section>
<section title="IANA Considerations">
<t>TBD.</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2119;
<reference anchor="RFC6020">
<front>
<title>YANG - A Data Modeling Language for the Network Configuration
Protocol (NETCONF)</title>
<author fullname="M.Bjorklund" initials="M." surname="Bjorklund">
<organization/>
</author>
<date month="October" year="2010"/>
</front>
<seriesInfo name="RFC" value="6020"/>
</reference>
<reference anchor="RFC6241">
<front>
<title>Network Configuration Protocol (NETCONF)</title>
<author fullname="R.Enns" initials="R." surname="Enns">
<organization/>
</author>
<author fullname="M.Bjorklund" initials="M." surname="Bjorklund">
<organization/>
</author>
<author fullname="J.Schoenwaelder" initials="J."
surname="Schoenwaelder">
<organization/>
</author>
<author fullname="A.Bierman " initials="A." surname="Bierman">
<organization/>
</author>
<date month="June" year="2011"/>
</front>
<seriesInfo name="RFC" value="6241'"/>
</reference>
</references>
<references title="Informative References">
<reference anchor="I-D.hares-i2rs-bnp-info-model-01">
<front>
<title>An Information Model for Basic Network Policy</title>
<author fullname="S.Hares" initials="S" surname="Hares">
<organization/>
</author>
<author fullname="Q.Wu" initials="Q" surname="Wu">
<organization/>
</author>
<date month="October" year="2014"/>
</front>
<seriesInfo name="ID"
value="https://tools.ietf.org/html/draft-hares-i2rs-bnp-info-model-01"/>
</reference>
<reference anchor="DMTF-CIM-SCHEMA">
<front>
<title>DMTF Technologies: CIM Standards CIM Schema: Version
2.5</title>
<author>
<organization>Distributed Management Task Force,
Inc.</organization>
</author>
<date year=" "/>
</front>
<seriesInfo name=" "
value="http://www.dmtf.org/standards/cim_schema_v25.php"/>
</reference>
<reference anchor="DMTF-CIM-SPEC">
<front>
<title>Common Information Model (CIM) Specification: Version
2.2</title>
<author>
<organization>Distributed Management Task Force,
Inc.</organization>
</author>
<date month="June " year="2014"/>
</front>
<seriesInfo name=" "
value="http://www.dmtf.org/standards/documents/CIM/DSP0004.pdf."/>
</reference>
<reference anchor="POLICY-FWK">
<front>
<title>Policy Framework</title>
<author>
<organization>Stevens,M.,Weiss,W.,Mahon,H.,Moore,B.,Strassner,J.,Waters,G.,Westerinen,A.,Wheeler,J.</organization>
</author>
<date month="Work in Progress" year="1999"/>
</front>
</reference>
<reference anchor="RFC3460">
<front>
<title>Policy Core Information Model (PCIM) Extensions</title>
<author fullname="Bob Moore " initials="B." surname="Moore ">
<organization/>
</author>
<date month="November " year="2003"/>
</front>
<seriesInfo name="RFC" value="RFC3644"/>
</reference>
<reference anchor="RFC3060">
<front>
<title>Policy Core Information Model -- Version 1
Specification</title>
<author fullname="Ed Ellesson " initials="Ed." surname="Ellesson">
<organization/>
</author>
<author fullname="Bob Moore " initials="B." surname="Moore ">
<organization/>
</author>
<author fullname="John Strassner " initials="J."
surname="Strassner">
<organization/>
</author>
<author fullname="Andrea Westerinen " initials="A."
surname="Westerinen ">
<organization/>
</author>
<date month="February " year="2001"/>
</front>
<seriesInfo name="RFC" value="RFC3644"/>
</reference>
<reference anchor="RFC3644">
<front>
<title>Policy Quality of Service (QoS) Information Model</title>
<author>
<organization>Snir,Y.,Ramberg,Y.,Strassner,J.,Cohen,R.,Moore,B.</organization>
</author>
<date month="November " year="2003"/>
</front>
<seriesInfo name="RFC" value="RFC3644"/>
</reference>
<reference anchor="RFC3198">
<front>
<title>Terminology for Policy-Based Management</title>
<author>
<organization>Westerinen,A.,Schnizlein,J.,Strassner,J.,Scherling,M.,
Quinn,B.,Herzog,S.,Huynh,A.,Carlson,M.,Perry,J.,Waldbuss
er,S.</organization>
</author>
<date month="November " year="2001"/>
</front>
<seriesInfo name="RFC" value="RFC3198"/>
</reference>
<reference anchor="RFC3670">
<front>
<title>Information Model for Describing Network Device QoS Datapath
Mechanisms</title>
<author>
<organization>Moore,B.,Durham,D.,Strassner,J.,Westerinen,A.,
Weiss,W</organization>
</author>
<date month="January " year="2004"/>
</front>
<seriesInfo name="RFC" value="RFC3670"/>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 06:47:04 |