[OPSAWG] Review of draft-ersue-opsawg-management-fw-01, part 2

[Benoit Claise <[e-mail]>]

Hi Mehmet,

Here is the review of the remaining part.
>
>
>       3.9. Policy-based Management
>
>
>
>         3.9.1. IETF Policy Framework
>
>
>
>     IETF specified a general framework for managing, sharing, and reusing
>     policies in a vendor independent, interoperable, and scalable manner
>     as well as defining an extensible information model for representing
>     policies.  The policy framework is based on a policy-based admission
>     control specifying the two main architectural elements the Policy
>     Enforcement Point (PEP) and the Policy Decision Point (PDP).
>
>     For the purposes of network management, policies allow an operator to
>     specify how the network is to be configured and monitored through a
>     descriptive language.  Furthermore, it allows the automation of a
>     number of management tasks, according to the requirements set out in
>     the policy module.
>
>     IETF Policy Framework [RFC2753  <http://tools.ietf.org/html/rfc2753>] has been accepted by the industry as
>     a standard-based policy approach and has been adopted by different
>     SDOs e.g. 3GGP charging standards.
>
>
>
>         3.9.2. COPS-PR
>
>
>
>     [RFC3159] defines the Structure of Policy Provisioning Information
>     (SPPI), an extension to the SMI modeling language used to write
>     Policy Information Base (PIB) modules.  COPS-PR [RFC3084  <http://tools.ietf.org/html/rfc3084>] uses the
>     Common Open Policy Service (COPS) protocol for support of policy
>     provisioning.  COPS-PR and the Structure of Policy Provisioning
>     Information (SPPI) have been approved as Proposed Standards.
I would cut/paste this sentence below.
Expressed like this, it means that this is an important standard, but 
the end of the section is quite different.
>     The COPS-PR specification is independent of the type of policy being
>     provisioned (QoS, Security, etc.) but focuses on the mechanisms and
>     conventions used to communicate provisioned information between
>     policy-decision-points (PDPs) and policy enforcement points (PEPs).
>     COPS-PR does not make any assumptions about the policy data model
>     being communicated, but describes the message formats and objects
>     that carry the modeled policy data.  Policy data is modeled using
>     Policy Information Base modules (PIB modules).
>
>
>
>
> Ersue                    Expires April 28, 2011                [Page 27]
>
> Internet-Draft          IETF Management Framework           October 2010
>
>
>     COPS-PR has not had wide deployment, and operators have stated that
>     its use of binary encoding (BER) for management data makes it
>     difficult to develop automated scripts for simple configuration
>     management tasks in most text-based scripting languages.  In an IAB
>     Workshop on Network Management [RFC3535  <http://tools.ietf.org/html/rfc3535>], the consensus of operators
>     and protocol developers indicated a lack of interest in PIB modules
>     for use with COPS-PR.
>
>     As a result, the IESG has not approved any policy models (PIB
>     modules) as IETF standard, and the use of COPS-PR is not recommended.
"As a result, even if COPS-PR and the Structure of Policy Provisioning
Information (SPPI) were initially approved as Proposed Standards, the 
IESG has not approved any policy models (PIB modules) as IETF standard, 
and the use of COPS-PR is not recommended.
>
>
>       3.10. Network Performance Management
>
>
>
>         3.10.1. IP Performance Metrics (IPPM)
>
>
>
>     The IPPM WG has defined metrics for accurately measuring and
>     reporting the quality, performance, and reliability of Internet data
>     delivery services.  The metrics include connectivity, one-way delay
>     and loss, round-trip delay and loss, delay variation, loss patterns,
>     packet reordering, bulk transport capacity, and link bandwidth
>     capacity.
See my comment on the list regarding "services"
>     These metrics are designed for network operator use and provide
>     unbiased quantitative measures of performance.
This sentence, copied from the charter, should be in here.

    The metrics developed by the WG were developed inside an active
    measurement context, that is, the devices used to measure the metrics
    produce their own traffic. However, most metrics can be used inside a
    passive context as well. No work is planned is this area though,
    this may be changed with AD approval.

>     The main properties of individual IPPM performance and reliability
>     metrics are that the metrics should be well-defined and concrete thus
>     implementable, and they should exhibit no bias for IP clouds
>     implemented with identical technology.  In addition, the methodology
>     used to implement a metric should have the property of being
>     repeatable with consistent measurements.
>
>     IETF IP Performance Metrics have been introduced widely in the
>     industry and adopted by different SDOs such as ITU-T.
Actually, any others than ITU-T?

>     Following are examples of essential IPPM documents published as
>     Proposed Standard:
>
>     o  IPPM Framework document [RFC2330  <http://tools.ietf.org/html/rfc2330>] defines a general framework for
>        particular metrics developed by IPPM WG and defines the
>        fundamental concepts of 'metric' and 'measurement methodology' and
>        discusses the issue of measurement uncertainties and errors as
>        well as introduces the notion of empirically defined metrics and
>        how metrics can be composed.
>
>     o  One-way Delay Metric for IPPM [RFC2679  <http://tools.ietf.org/html/rfc2679>] defines a metric for one-
>        way delay of packets across Internet paths.  It builds on notions
>        introduced in the IPPM Framework document.
>
>
>
> Ersue                    Expires April 28, 2011                [Page 28]
>
> Internet-Draft          IETF Management Framework           October 2010
>
>
>     o  Round-trip Delay Metric for IPPM [RFC2681  <http://tools.ietf.org/html/rfc2681>] defines a metric for
>        round-trip delay of packets across network paths and follows
>        closely the corresponding metric for One-way Delay.
>
>     o  IP Packet Delay Variation Metric [RFC3393  <http://tools.ietf.org/html/rfc3393>] refers to a metric for
>        variation in delay of packets across network paths and is based on
>        the difference in the One-Way-Delay of selected packets called "IP
>        Packet Delay Variation (ipdv)".
>
>     o  One-way Packet Loss Metric for IPPM [RFC2680  <http://tools.ietf.org/html/rfc2680>] defines a metric for
>        one-way packet loss across Internet paths.
>
>     o  One-Way Packet Duplication Metric [RFC5560  <http://tools.ietf.org/html/rfc5560>] defines a metric for
>        the case, where multiple copies of a packet are received and
>        discusses methods to summarize the results of streams.
>
>     o  Packet Reordering Metrics [RFC4737  <http://tools.ietf.org/html/rfc4737>] defines metrics to evaluate
>        whether a network has maintained packet order on a packet-by-
>        packet basis and discusses the measurement issues, including the
>        context information required for all metrics.
>
>     o  IPPM Metrics for Measuring Connectivity [RFC2678  <http://tools.ietf.org/html/rfc2678>] defines a series
>        of metrics for connectivity between a pair of Internet hosts.
>
>     o  Framework for Metric Composition [RFC5835  <http://tools.ietf.org/html/rfc5835>] describes a detailed
>        framework for composing and aggregating metrics.
"Next to the metrics, two protocols to measure those metrics are 
standardized:"
>     o  A One-way Active Measurement Protocol (OWAMP) [RFC4656  <http://tools.ietf.org/html/rfc4656>] measures
>        unidirectional characteristics such as one-way delay and one-way
>        loss between network devices and enables the interoperability of
>        these measurements.
>
>     o  A Two-Way Active Measurement Protocol (TWAMP) [RFC5357  <http://tools.ietf.org/html/rfc5357>] adds
>        round-trip or two-way measurement capabilities to OWAMP.
>
>     For the "Information Model and XML Data Model for Traceroute
>     Measurements [RFC5388  <http://tools.ietf.org/html/rfc5388>] and the BCP document [BCP108] "IP Performance
>     Metrics (IPPM) Metrics Registry" seesection 4.4  <http://tools.ietf.org/html/draft-ersue-opsawg-management-fw-01#section-4.4>  'Performance
>     Management'.
>
>
>
>         3.10.2. Real-time Flow Measurement (RTFM)
>
>
>
>     (Real-Time) Traffic Flow Measurement: Architecture [RFC2722  <http://tools.ietf.org/html/rfc2722>]
>     specifies the general framework for describing network traffic flows,
>     an architecture for traffic flow measurement and reporting, and
>     indicates how it can be used within the Internet.  As such RTFM is a
>     mechanism for configuring meters and meter readers, and for
>     collecting the flow data from remote meters.
>
>
>
> Ersue                    Expires April 28, 2011                [Page 29]
>
> Internet-Draft          IETF Management Framework           October 2010
>
>
>     RTFM is e.g. used for the measurement of DNS performance.
I consider RTFM as an experiment done before IPFIX.
btw, http://tools.ietf.org/html//rfc2724 is experimental.
Again, it depends on the target audience. If we want to keep a history 
of what has been done in OPS, that's interesting. Otherwise, I would 
remove RTFM
>
>
>       3.11. Application Management Protocols
>
>
>
Can you please add a sentence or two regarding what we mean by 
"application" in this context.
Maybe, I've been too much involved in DPI ;-)
>
>
>         3.11.1. ACAP
>
>
>
>     The Application Configuration Access Protocol (ACAP) [RFC2244  <http://tools.ietf.org/html/rfc2244>] is
>     designed to support remote storage and access of program option,
>     configuration and preference information.  The data store model is
>     designed to allow a client relatively simple access to interesting
>     data, to allow new information to be easily added without server re-
>     configuration, and to promote the use of both standardized data and
>     custom or proprietary data.  Key features include "inheritance" which
>     can be used to manage default values for configuration settings and
>     access control lists which allow interesting personal information to
>     be shared and group information to be restricted.
>
>     ACAP's primary purpose is to allow users access to their
>     configuration data from multiple network-connected computers.  Users
>     can then sit down in front of any network-connected computer, run any
>     ACAP-enabled application and have access to their own configuration
>     data.  Because it is hoped that many applications will become ACAP-
>     enabled, client simplicity was preferred to server or protocol
>     simplicity whenever reasonable.
>
>
>
>         3.11.2. XCAP
>
>
>
>     XCAP [RFC4825  <http://tools.ietf.org/html/rfc4825>] is a Proposed Standard protocol that allows a client
>     to read, write, and modify application configuration data stored in
>     XML format on a server.
>
>     XCAP is a protocol that can be used to manipulate per-user data.
>     XCAP is a set of conventions for mapping XML documents and document
>     components into HTTP URIs, rules for how the modification of one
>     resource affects another, data validation constraints, and
>     authorization policies associated with access to those resources.
>     Because of this structure, normal HTTP primitives can be used to
>     manipulate the data.  XCAP is meant to support the configuration
>     needs for a multiplicity of applications, rather than just a single
>     one.
>
>     XCAP was not designed as a general purpose XML search protocol, XML
>     database update protocol, nor a general purpose, XML-based
>     configuration protocol for network elements.
>
>
>
>
>
>
>
> Ersue                    Expires April 28, 2011                [Page 30]
>
> Internet-Draft          IETF Management Framework           October 2010
>
>
>
>
>         3.11.3. EPP
>
>
>
>     The Extensible Provision Protocol [RFC5730  <http://tools.ietf.org/html/rfc5730>] is an Internet Standard
>     [STD69] that describes an application layer client-server protocol
>     for the provisioning and management of objects stored in a shared
>     central repository.  EPP permits multiple service providers to
>     perform object provisioning operations using a shared central object
>     repository, and addresses the requirements for a generic registry
>     registrar protocol.
>
>     EPP is specified in XML and defines generic object management
>     operations and an extensible framework that maps protocol operations
>     to objects.  EPP is a stateful XML protocol that can be layered over
>     multiple transport protocols.  Protected using lower-layer security
>     protocols, clients exchange identification, authentication, and
>     option information, and then engage in a series of client-initiated
>     command-response exchanges.
>
>     EPP has been adopted by numerous domain name registries mainly for
>     the communication between domain name registries and domain name
>     registrars and for allocating objects within registries over the
>     Internet.
>
>
>
>     4. Proposed, Draft and Standard Level Data Models
>
>
>
>     This section lists solutions for which information or data models
>     have been standardized at the IETF, so that existing solutions can be
>     reused and the data models can be applied to new solutions.
>
>     Management data models have a slightly different interpretation for
>     interoperability.  This is discussed in detail in [BCP27]
>     "Advancement of MIB specifications on the IETF Standards Track"
>     [RFC2438  <http://tools.ietf.org/html/rfc2438>] with special considerations about the advancement process
>     for management data models.  However most IETF management data models
>     never advance beyond Proposed Standard.
Note that MIB is just one data model.
What about IPFIX?
>     This section discusses management data models that have reached at
>     least Proposed Standard status in the IETF.
>
>
>
>       4.1. Fault Management
>
>
>
>     Draft Standards:
>
>     [RFC3418  <http://tools.ietf.org/html/rfc3418>], part of SNMPv3 standard [STD62], contains objects in the
>     system group that are often polled to determine if a device is still
>     operating, and sysUpTime can be used to detect if a system has
>     rebooted, and counters have been reinitialized.
>
>
>
>
> Ersue                    Expires April 28, 2011                [Page 31]
>
> Internet-Draft          IETF Management Framework           October 2010
>
>
>     [RFC3413  <http://tools.ietf.org/html/rfc3413>], part of SNMPv3 standard [STD62], includes objects designed
>     for managing notifications, including tables for addressing, retry
>     parameters, security, lists of targets for notifications, and user
>     customization filters.
>
>     An RMON monitor [RFC2819  <http://tools.ietf.org/html/rfc2819>] can be configured to recognize conditions,
>     most notably error conditions, and continuously to check for them.
>     When one of these conditions occurs, the event may be logged, and
>     management stations may be notified in a number of ways (for further
>     discussion on RMON seesection 4.4  <http://tools.ietf.org/html/draft-ersue-opsawg-management-fw-01#section-4.4>  'Performance Management').
>
>     Proposed Standards:
>
>     The IETF SYSLOG protocol [RFC5424  <http://tools.ietf.org/html/rfc5424>] is a Proposed Standard that
>     includes a mechanism for defining Structured Data Elements (SDEs).
>     The SYSLOG protocol document defines an initial set of SDEs that
>     relate to content time quality, content origin, and meta-information
>     about the message, such as language.  Proprietary SDEs can be used to
>     supplement the IETF-defined SDEs.
>
>     DISMAN-EVENT-MIB in [RFC2981  <http://tools.ietf.org/html/rfc2981>] and DISMAN-EXPRESSION-MIB in [RFC2982  <http://tools.ietf.org/html/rfc2982>]
>     provide a superset of the capabilities of the RMON alarm and event
>     groups.  These modules provide mechanisms for thresholding and
>     reporting anomalous events to management applications.
>
>     The ALARM MIB in [RFC3877  <http://tools.ietf.org/html/rfc3877>] and the Alarm Reporting Control MIB in
>     [RFC3878  <http://tools.ietf.org/html/rfc3878>] specify mechanisms for expressing state transition models
>     for persistent problem states.
>
>     ALARM MIB defines:
>     - a mechanisms for expressing state transition models for persistent
>     problem states,
>     - a mechanism to correlate a notification with subsequent state
>     transition notifications about the same entity/object, and
>     - a generic alarm reporting mechanism (extends ITU-T work X.733 [ITU-
>     X733).
>
>     [RFC3878] in particular defines objects for controlling the reporting
>     of alarm conditions and extends ITU-T work M.3100 Amendment 3 [ITU-
>     M3100].
>
>     Other MIB modules that may be applied to Fault Management include:
>
>     o  NOTIFICATION-LOG-MIB [RFC3014  <http://tools.ietf.org/html/rfc3014>] describes managed objects used for
>        logging SNMP Notifications.
>
>     o  ENTITY-STATE-MIB [RFC4268  <http://tools.ietf.org/html/rfc4268>] describes extensions to the Entity MIB
>        to provide information about the state of physical entities.
>
>
>
> Ersue                    Expires April 28, 2011                [Page 32]
>
> Internet-Draft          IETF Management Framework           October 2010
>
>
>     o  ENTITY-SENSOR-MIB [RFC3433  <http://tools.ietf.org/html/rfc3433>] describes managed objects for
>        extending the Entity MIB to provide generalized access to
>        information related to physical sensors, which are often found in
>        networking equipment (such as chassis temperature, fan RPM, power
>        supply voltage).
>
>
>
>       4.2. Configuration Management
>
>
>
>     Draft standards:
>
>     It is expected that standard XML-based data models will be developed
>     for use with NETCONF, and working groups might identify specific
>     NETCONF data models that would be applicable to the new protocol.
>
>     At the time of this writing, only the YANG module for the monitoring
>     of the NETCONF protocol exists as proposed standard.  NETMOD WG is
>     going to be rechartered to develop core system models in YANG.
>
>     MIB modules for monitoring of network configuration (e.g. for
>     physical and logical network topologies) already exist and provide
>     some of the desired capabilities.  New MIB modules might be developed
>     for the target functionality to allow operators to monitor and modify
>     the operational parameters, such as timer granularity, event
>     reporting thresholds, target addresses, and so on.
>
>     [RFC3418  <http://tools.ietf.org/html/rfc3418>], part of SNMPv3 standard [STD62], contains objects in the
>     system group that are often polled to determine if a device is still
>     operating, and sysUpTime can be used to detect if a system has
>     rebooted and caused potential discontinuity in counters.  Other
>     objects in the system MIB are useful for identifying the type of
>     device, the location of the device, the person responsible for the
>     device, etc.
this paragraph above is a repeat from section 4.1
>     [RFC3413  <http://tools.ietf.org/html/rfc3413>], part of STD 62 SNMPv3, includes objects designed for
>     configuring notification destinations, and for configuring proxy-
>     forwarding SNMP agents, which can be used to forward messages through
>     firewalls and NAT devices.
>
>     The Interfaces MIB [RFC2863  <http://tools.ietf.org/html/rfc2863>] is used for managing Network Interfaces.
>     This includes the 'interfaces' group of MIB-II and discusses the
>     experience gained from the definition of numerous media-specific MIB
>     modules for use in conjunction with the 'interfaces' group for
>     managing various sub-layers beneath the internetwork-layer.
>
>     Proposed standards:
>
>     The Entity MIB [RFC4133  <http://tools.ietf.org/html/rfc4133>] is used for managing multiple logical and
>     physical entities managed by a single SNMP agent.  This module
>
>
>
> Ersue                    Expires April 28, 2011                [Page 33]
>
> Internet-Draft          IETF Management Framework           October 2010
>
>
>     provides a useful mechanism for identifying the entities comprising a
>     system.  There are also event notifications defined for configuration
>     changes that may be useful to management applications.
>
>     [RFC3165] supports the use of user-written scripts to delegate
>     management functionality.
>
>     Policy Based Management MIB [RFC4011  <http://tools.ietf.org/html/rfc4011>] defines objects that enable
>     policy-based monitoring using SNMP, using a scripting language, and a
>     script execution environment.
>
>     Few vendors have implemented MIB modules that support scripting.
>     Some vendors consider running user-developed scripts within the
>     managed device as a violation of support agreements.
>
>
>
>       4.3. Accounting Management
>
>
>
>     DIAMETER [RFC3588  <http://tools.ietf.org/html/rfc3588>] and RADIUS [RFC2866  <http://tools.ietf.org/html/rfc2866>] can be used to exchange
>     accounting related information.
>
>     IETF so far did only develop Informational RFCs as data model for
>     accounting.  RADIUS Accounting Client MIB for IPv6 [RFC4670  <http://tools.ietf.org/html/rfc4670>] and
>     RADIUS Accounting Server MIB for IPv6 [RFC4671  <http://tools.ietf.org/html/rfc4671>] allow the gathering
>     of accounting data.
>
>
>
>       4.4. Performance Management
>
>
Should we mention the IPPM perf metrics in here?
>     MIB modules typically contain counters to determine the frequency and
>     rate of an occurrence.
>
>     RMON [RFC2819  <http://tools.ietf.org/html/rfc2819>] has the full standard status [STD59] and defines
>     objects for managing remote network monitoring devices.  An
>     organization may employ many remote management probes, one per
>     network segment, to manage its internet.  These devices may be used
>     for a network management service provider to access a client network,
>     often geographically remote.  Most of the objects in the RMON MIB
>     module are suitable for the management of any type of network, where
>     some of them are specific to management of Ethernet networks.
>
>     RMON allows a probe to be configured to perform diagnostics and to
>     collect statistics continuously, even when communication with the
>     management station may not be possible or efficient.  The alarm group
>     periodically takes statistical samples from variables in the probe
>     and compares them to previously configured thresholds.  If the
>     monitored variable crosses a threshold, an event is generated.
>
>     The RMON host group discovers hosts on the network by keeping a list
>     of source and destination MAC Addresses seen in good packets
>
>
>
> Ersue                    Expires April 28, 2011                [Page 34]
>
> Internet-Draft          IETF Management Framework           October 2010
>
>
>     promiscuously received from the network, and contains statistics
>     associated with each host.  The hostTopN group is used to prepare
>     reports that describe the hosts that top a list ordered by one of
>     their statistics.  The available statistics are samples of one of
>     their base statistics over an interval specified by the management
>     station.  Thus, these statistics are rate based.  The management
>     station also selects how many such hosts are reported.
>
>     The RMON matrix group stores statistics for conversations between
>     sets of two addresses.  The filter group allows packets to be matched
>     by a filter equation.  These matched packets form a data stream that
>     may be captured or may generate events.  The Packet Capture group
>     allows packets to be captured after they flow through a channel.  The
>     event group controls the generation and notification of events from
>     this device.
Don't want to start a lengthy debate here, but my personal view is that 
RMON host, matrix are superseded by IPFIX: more granular, more flexible
At the minimum, we should mention IPFIX somewhere here. This comes back 
to my point before that MIBs are not the only data model at the IETF.

Regards, Benoit.
>     Draft standards:
>
>     The RMON-2 MIB [RFC4502  <http://tools.ietf.org/html/rfc4502>] extends RMON by providing RMON analysis up
>     to the application layer.  The SMON MIB [RFC2613  <http://tools.ietf.org/html/rfc2613>] extends RMON by
>     providing RMON analysis for switched networks.
>
>     Proposed standards:
>
>     RMON MIB Extensions for High Capacity Alarms [RFC3434  <http://tools.ietf.org/html/rfc3434>] describes
>     managed objects for extending the alarm thresholding capabilities
>     found in the RMON MIB and provides similar threshold monitoring of
>     objects based on the Counter64 data type.
>
>     RMON MIB Extensions for High Capacity Networks [RFC3273  <http://tools.ietf.org/html/rfc3273>] defines
>     objects for managing RMON devices for use on high-speed networks.
>
>     RMON MIB Extensions for Interface Parameters Monitoring [RFC3144  <http://tools.ietf.org/html/rfc3144>]
>     describes an extension to the RMON MIB with a method of sorting the
>     interfaces of a monitored device according to values of parameters
>     specific to this interface.
>
>     [RFC4710] describes Real-Time Application Quality of Service
>     Monitoring.  RAQMON is part of the RMON protocol family, and supports
>     end-2-end QoS monitoring for multiple concurrent applications and
>     does not relate to a specific application transport.  RAQMON is
>     scalable and works well with encrypted payload and signaling.  RAQMON
>     uses TCP to transport RAQMON PDUs.
>
>     [RFC4711] proposes an extension to the Remote Monitoring MIB
>     [RFC2819  <http://tools.ietf.org/html/rfc2819>] and describes managed objects used for real-time
>     application Quality of Service (QoS) monitoring.  [RFC4712  <http://tools.ietf.org/html/rfc4712>] specifies
>     two transport mappings for the RAQMON information model using TCP as
>
>
>
> Ersue                    Expires April 28, 2011                [Page 35]
>
> Internet-Draft          IETF Management Framework           October 2010
>
>
>     a native transport and SNMP to carry the RAQMON information from a
>     RAQMON Data Source (RDS) to a RAQMON Report Collector (RRC).
>
>     Application Performance Measurement MIB [RFC3729  <http://tools.ietf.org/html/rfc3729>] uses the
>     architecture created in the RMON MIB and defines objects by providing
>     measurement and analysis of the application performance as
>     experienced by end-users.  Application performance measurement
>     measures the quality of service delivered to end-users by
>     applications.
>
>     Transport Performance Metrics MIB [RFC4150  <http://tools.ietf.org/html/rfc4150>] describes managed objects
>     used for monitoring selectable performance metrics and statistics
>     derived from the monitoring of network packets and sub-application
>     level transactions.  The metrics can be defined through reference to
>     existing IETF, ITU, and other standards organizations' documents.
>
>     IPPM WG defined an Information Model and XML Data Model for
>     Traceroute Measurements [RFC5388  <http://tools.ietf.org/html/rfc5388>], which defines a common information
>     model dividing the information elements into two semantically
>     separated groups (configuration elements and results elements) with
>     an additional element to relate configuration elements and results
>     elements by means of a common unique identifier.  Based on the
>     information model, an XML data model is provided to store the results
>     of traceroute measurements.
>
>     IPPM WG has furthermore defined the BCP document [BCP108] "IP
>     Performance Metrics (IPPM) Metrics Registry", which defines a
>     registry for IP Performance Metrics [RFC4148  <http://tools.ietf.org/html/rfc4148>].  The IANA-assigned
>     registry contains an initial set of OBJECT IDENTITIES to currently
>     defined metrics in the IETF as well as defines the rules for adding
>     IP Performance Metrics that are defined in the future.
>
>     SIP Package for Voice Quality Reporting [I-D.ietf-sipping-rtcp-
>     summary] defines a SIP event package that enables the collection and
>     reporting of metrics that measure the quality for Voice over Internet
>     Protocol (VoIP) sessions.
>
>     Traffic Flow Measurement: Meter MIB [RFC2720  <http://tools.ietf.org/html/rfc2720>] defines a MIB for use
>     in controlling an RTFM Traffic Meter, in particular for specifying
>     the flows to be measured and provides a mechanism for retrieving flow
>     data from the meter using SNMP.
>
>
>
>       4.5. Security Management
>
>
>
>     Proposed standards:
>
>     RADIUS Authentication Server MIB for IPv6 [RFC4669  <http://tools.ietf.org/html/rfc4669>] defines a set of
>     extensions that instrument RADIUS authentication server functions and
>
>
>
> Ersue                    Expires April 28, 2011                [Page 36]
>
> Internet-Draft          IETF Management Framework           October 2010
>
>
>     RADIUS Authentication Client MIB for IPv6 [RFC4668  <http://tools.ietf.org/html/rfc4668>] defines a set of
>     extensions for RADIUS authentication client functions.  Both RFCs add
>     support for version-neutral IP address formats.  Using these
>     extensions, IP-based management stations can manage RADIUS
>     authentication clients and servers.
>
>     Following are Radius MIBs published as Informational RFC:
>
>     o  RADIUS Dynamic Authorization Client MIB [RFC4672  <http://tools.ietf.org/html/rfc4672>] describes the
>        Dynamic Authorization Client (DAC) functions that support the
>        dynamic authorization extensions defined in [RFC5176  <http://tools.ietf.org/html/rfc5176>].
>
>     o  RADIUS Dynamic Authorization Server MIB [RFC4673  <http://tools.ietf.org/html/rfc4673>] describes the
>        Dynamic Authorization Server (DAS) functions that support the
>        dynamic authorization extensions defined in [RFC5176  <http://tools.ietf.org/html/rfc5176>].
>
>
>
>     5. IANA Considerations
>
>
>
>     This document does not introduce any new codepoints or name spaces
>     for registration with IANA.
>
>     Note to RFC Editor: this section may be removed on publication as an
>     RFC.
>
>
>
>     6. Security Considerations
>
>
>
>     This document introduces no new security concerns.
>
>
>
>     7. Contributors
>
>
>
>     This document uses the expired draft [I-D.ietf-opsawg-survey-
>     management] edited by Dave Harrington as a starting point.
>
>
>
>     8. Acknowledgements
>
>
>
>     The authors would like to thank to ...
>