2.2.  Syslog Protocol

   Syslog is a mechanism for distribution of logging information
   initially used on Unix systems (see [RFC3164] for BSD syslog).  The
   IETF Syslog Protocol [RFC5424] introduces a layered architecture
   allowing the use of any number of transport protocols, including
   reliable and secure transports, for transmission of syslog messages.

   The Syslog protocol enables a machine to send system log messages
   across networks to event message collectors.  The protocol is simply
   designed to transport and distribute these event messages.  By
   default, no acknowledgements of the receipt are made, except the
   reliable delivery extensions specified in [RFC3195] are used.  The
   Syslog protocol and process does not require a stringent coordination
   between the transport sender and the receiver.  Indeed, the
   transmission of syslog messages may be started on a device without a
   receiver being configured, or even actually physically present.
   Conversely, many devices will most likely be able to receive messages
   without explicit configuration or definitions.

   BSD syslog had little uniformity for the message format and the
   content of syslog messages.  The body of a BSD syslog message has
   traditionally been unstructured text.  This content is human
   friendly, but difficult to parse for applications.  With the Syslog
   Protocol [RFC5424], the IETF has standardized a new message header
   format, including timestamp, hostname, application, and message ID,
   to improve filtering, interoperability, and correlation between
   compliant implementations.

   The Syslog protocol [RFC5424] also introduces a mechanism for
   defining Structured Data Elements (SDEs).  The SDEs allow vendors to
   define their own structured data elements to supplement standardized
   elements.  [RFC5675] defines a mapping from SNMP notifications to

   syslog messages.  [RFC5676] defines an SNMP MIB module to represent
   syslog messages for the purpose of sending those syslog messages as
   notifications to SNMP notification receivers.  [RFC5674] defines the
   way alarms are sent in syslog, which includes the mapping of ITU-
   perceived severities onto syslog message fields and a number of
   alarm-specific definitions from ITU-T X.733 [ITU-X733] and the IETF
   Alarm MIB [RFC3877].

   "Signed Syslog Messages" [RFC5848] defines a mechanism to add origin
   authentication, message integrity, replay resistance, message
   sequencing, and detection of missing messages to the transmitted
   syslog messages to be used in conjunction with the Syslog protocol.

   The Syslog protocol's layered architecture provides support for a
   number of transport mappings.  For interoperability purposes and
   especially in managed networks, where the network path has been
   explicitly provisioned for UDP syslog traffic, the Syslog protocol
   can be used over UDP [RFC5426].  However, to support congestion
   control and reliability, [RFC5426] strongly recommends the use of the
   TLS transport.

   Furthermore, the IETF defined the TLS Transport Mapping for syslog in
   [RFC5425], which provides a secure connection for the transport of
   syslog messages.  [RFC5425] describes the security threats to syslog
   and how TLS can be used to counter such threats.  [RFC6012] defines
   the Datagram Transport Layer Security (DTLS) Transport Mapping for
   syslog, which can be used if a connectionless transport is desired.

   For information on MIB modules related to syslog, see Section 4.2.1.

2.3.  IP Flow Information eXport (IPFIX) and Packet SAMPling (PSAMP)
      Protocols

   "Specification of the IP Flow Information Export (IPFIX) Protocol for
   the Exchange of IP Traffic Flow Information" (the IPFIX Protocol)
   [RFC5101] defines a push-based data export mechanism for transferring
   IP flow information in a compact binary format from an Exporter to a
   Collector.

   "Architecture for IP Flow Information Export" (the IPFIX
   Architecture) [RFC5470] defines the components involved in IP flow
   measurement and reporting of information on IP flows, particularly, a
   Metering Process generating Flow Records, an Exporting Process that
   sends metered flow information using the IPFIX protocol, and a
   Collecting Process that receives flow information as IPFIX Data
   Records.

   After listing the IPFIX requirements in [RFC3917], NetFlow Version 9
   [RFC3954] was taken as the basis for the IPFIX protocol and the IPFIX
   architecture.

   IPFIX can run over different transport protocols.  The IPFIX Protocol
   [RFC5101] specifies Stream Control Transmission Protocol (SCTP)
   [RFC4960] as the mandatory transport protocol to implement.  Optional
   alternatives are TCP [STD07] and UDP [STD06].

   SCTP is used with its Partial Reliability extension (PR-SCTP)
   specified in [RFC3758].  [RFC6526] specifies an extension to
   [RFC5101], when using the PR-SCTP [RFC3758].  The extension offers
   several advantages over IPFIX export, e.g., the ability to calculate
   Data Record losses for PR-SCTP, immediate reuse of Template IDs
   within an SCTP stream, reduced likelihood of Data Record loss, and
   reduced demands on the Collecting Process.

   IPFIX transmits IP flow information in Data Records containing IPFIX
   Information Elements (IEs) defined by the IPFIX Information Model
   [RFC5102].  IPFIX IEs are quantities with unit and semantics defined
   by the Information Model.  When transmitted over the IPFIX protocol,
   only their values need to be carried in Data Records.  This compact
   encoding allows efficient transport of large numbers of measured flow
   values.  Remaining redundancy in Data Records can be further reduced
   by the methods described in [RFC5473] (for further discussion on
   IPFIX IEs, see Section 4).

   The IPFIX Information Model is extensible.  New IEs can be registered
   at IANA (see "IPFIX Information Elements" in [IANA-PROT]).  IPFIX
   also supports the use of proprietary, i.e., enterprise-specific IEs.

   The PSAMP protocol [RFC5476] extends the IPFIX protocol by means of
   transferring information on individual packets.  [RFC5475] specifies
   a set of sampling and filtering techniques for IP packet selection,
   based on the PSAMP Framework [RFC5474].  The PSAMP Information Model
   [RFC5477] provides a set of basic IEs for reporting packet
   information with the IPFIX/PSAMP protocol.

   The IPFIX model of an IP traffic flow is unidirectional.  [RFC5103]
   adds means of reporting bidirectional flows to IPFIX, for example,
   both directions of packet flows of a TCP connection.

   When enterprise-specific IEs are transmitted with IPFIX, a Collector
   receiving Data Records may not know the type of received data and
   cannot choose the right format for storing the contained information.
   [RFC5610] provides a means of exporting extended type information for
   enterprise-specific Information Elements from an Exporter to a
   Collector.

   Collectors may store received flow information in files.  The IPFIX
   file format [RFC5655] can be used for storing IP flow information in
   a way that facilitates exchange of traffic flow information between
   different systems and applications.

   In terms of IPFIX and PSAMP configurations, the Metering and
   Exporting Processes are configured out of band.  As the IPFIX
   protocol is a push mechanism only, IPFIX cannot configure the
   Exporter.  The actual configuration of selection processes, caches,
   Exporting Processes, and Collecting Processes of IPFIX- and PSAMP-
   compliant monitoring devices is executed using the NETCONF protocol
   [RFC6241] (see Section 2.4.1).  The "Configuration Data Model for
   IPFIX and PSAMP" (the IPFIX Configuration Data Model) [CONF-MODEL]
   has been specified using Unified Modeling Language (UML) class
   diagrams.  The data model is formally defined using the YANG modeling
   language [RFC6020] (see Section 2.4.2).

   At the time of this writing, a framework for IPFIX flow mediation is
   in preparation, which addresses the need for mediation of flow
   information in IPFIX applications in large operator networks, e.g.,
   for aggregating huge amounts of flow data and for anonymization of
   flow information (see the problem statement in [RFC5982]).

   The IPFIX Mediation Framework [RFC6183] defines the intermediate
   device between Exporters and Collectors, which provides an IPFIX
   mediation by receiving a record stream from, e.g., a Collecting
   Process, hosting one or more Intermediate Processes to transform this
   stream, and exporting the transformed record stream into IPFIX
   messages via an Exporting Process.

   Examples for mediation functions are flow aggregation, flow
   selection, and anonymization of traffic information (see [RFC6235]).

   Privacy, integrity, and authentication of the Exporter and Collector
   are important security requirements for IPFIX [RFC3917].
   Confidentiality, integrity, and authenticity of IPFIX data
   transferred from an Exporting Process to a Collecting Process must be
   ensured.  The IPFIX and PSAMP protocols do not define any new
   security mechanisms and rely on the security mechanism of the
   underlying transport protocol, such as TLS [RFC5246] and DTLS
   [RFC6347].

   The primary goal of IPFIX is the reporting of the flow accounting for
   flexible flow definitions and usage-based accounting.  As described
   in the IPFIX Applicability Statement [RFC5472], there are also other
   applications such as traffic profiling, traffic engineering,
   intrusion detection, and QoS monitoring, that require flow-based
   traffic measurements and can be realized using IPFIX.  Furthermore,

   the IPFIX Applicability Statement explains the relation of IPFIX to
   other framework and protocols such as PSAMP, RMON (Remote Network
   Monitoring MIB, Section 4.2.1), and IPPM (IP Performance Metrics,
   Section 3.4)).  Similar flow information could be also used for
   security monitoring.  The addition of Performance Metrics in the
   IPFIX IANA registry [IANA-IPFIX], will extend the IPFIX use case to
   performance management.

   Note that even if the initial IPFIX focus has been around IP flow
   information exchange, non-IP-related IEs are now specified in the
   IPFIX IANA registration (e.g., MAC (Media Access Control) address,
   MPLS (Multiprotocol Label Switching) labels, etc.).  At the time of
   this writing, there are requests to widen the focus of IPFIX and to
   export non-IP related IEs (such as SIP monitoring IEs).

   The IPFIX structured data [RFC6313] is an extension to the IPFIX
   protocol, which supports hierarchical structured data and lists
   (sequences) of Information Elements in Data Records.  This extension
   allows the definition of complex data structures such as variable-
   length lists and specification of hierarchical containment
   relationships between templates.  Furthermore, the extension provides
   the semantics to express the relationship among multiple list
   elements in a structured Data Record.

   For information on data models related to the management of the IPFIX
   and PSAMP protocols, see Sections 4.2.1 and 4.2.2.  For information
   on IPFIX/PSAMP IEs, see Section 4.2.3.

2.4.  Network Configuration

2.4.1.  Network Configuration Protocol (NETCONF)

   The IAB workshop on Network Management [RFC3535] determined advanced
   requirements for configuration management:

   o  robustness: Minimizing disruptions and maximizing stability,

   o  a task-oriented view,

   o  extensibility for new operations,

   o  standardized error handling,

   o  clear distinction between configuration data and operational
      state,

   o  distribution of configurations to devices under transactional
      constraints,

   o  single- and multi-system transactions and scalability in the
      number of transactions and managed devices,

   o  operations on selected subsets of management data,

   o  dumping and reloading a device configuration in a textual format
      in a standard manner across multiple vendors and device types,

   o  a human interface and a programmatic interface,

   o  a data modeling language with a human-friendly syntax,

   o  easy conflict detection and configuration validation, and

   o  secure transport, authentication, and robust access control.

   The NETCONF protocol [RFC6241] provides mechanisms to install,
   manipulate, and delete the configuration of network devices and aims
   to address the configuration management requirements pointed out in
   the IAB workshop.  It uses an XML-based data encoding for the
   configuration data as well as the protocol messages.  The NETCONF
   protocol operations are realized on top of a simple and reliable
   Remote Procedure Call (RPC) layer.  A key aspect of NETCONF is that
   it allows the functionality of the management protocol to closely
   mirror the native command-line interface of the device.

   The NETCONF working group developed the NETCONF Event Notifications
   Mechanism as an optional capability, which provides an asynchronous
   message notification delivery service for NETCONF [RFC5277].  The
   NETCONF notification mechanism enables using general purpose
   notification streams, where the originator of the notification stream
   can be any managed device (e.g., SNMP notifications).

   The NETCONF Partial Locking specification introduces fine-grained
   locking of the configuration datastore to enhance NETCONF for fine-
   grained transactions on parts of the datastore [RFC5717].

   The NETCONF working group also defined the necessary data model to
   monitor the NETCONF protocol [RFC6022], by using the modeling
   language YANG [RFC6020] (see Section 2.4.2).  The monitoring data
   model includes information about NETCONF datastores, sessions, locks,
   and statistics, which facilitate the management of a NETCONF server.

   NETCONF connections are required to provide authentication, data
   integrity, confidentiality, and replay protection.  NETCONF depends
   on the underlying transport protocol for this capability.  For
   example, connections can be encrypted in TLS or SSH, depending on the
   underlying protocol.

   The NETCONF working group defined the SSH transport protocol as the
   mandatory transport binding [RFC6242].  Other optional transport
   bindings are TLS [RFC5539], Blocks Extensible Exchange Protocol
   (BEEP) over TLS [RFC4744], and Simple Object Access Protocol (SOAP)
   over HTTP over TLS [RFC4743].

   The NETCONF Access Control Model (NACM) [RFC6536] provides standard
   mechanisms to restrict protocol access to particular users with a
   pre-configured subset of operations and content.

2.4.2.  YANG - NETCONF Data Modeling Language

   Following the guidelines of the IAB management workshop [RFC3535],
   the NETMOD working group developed a data modeling language defining
   the semantics of operational and configuration data, notifications,
   and operations [RFC6020].  The new data modeling language, called
   YANG, maps directly to XML-encoded content (on the wire) and will
   serve as the normative description of NETCONF data models.

   YANG has the following properties addressing specific requirements on
   a modeling language for configuration management:

   o  YANG provides the means to define hierarchical data models.  It
      supports reusable data types and groupings, i.e., a set of schema
      nodes that can be reused across module boundaries.

   o  YANG supports the distinction between configuration and state
      data.  In addition, it provides support for modeling event
      notifications and the specification of operations that extend the
      base NETCONF operations.

   o  YANG allows the expression of constraints on data models by means
      of type restrictions and XML Path Language (XPATH) 1.0 [XPATH]
      expressions.  XPATH expressions can also be used to make certain
      portions of a data model conditional.

   o  YANG supports the integration of standard- and vendor-defined data
      models.  YANG's augmentation mechanism allows the seamless
      augmentation of standard data models with proprietary extensions.

   o  YANG data models can be partitioned into collections of features,
      allowing low-end devices only to implement the core features of a
      data model while high-end devices may choose to support all
      features.  The supported features are announced via the NETCONF
      capability exchange to management applications.

   o  The syntax of the YANG language is compact and optimized for human
      readers.  An associated XML-based syntax called the YANG
      Independent Notation (YIN) [RFC6020] is available to allow the
      processing of YANG data models with XML-based tools.  The mapping
      rules for the translation of YANG data models into Document Schema
      Definition Languages (DSDL), of which RELAX NG is a major
      component, are defined in [RFC6110].

   o  Devices implementing standard data models can document deviations
      from the data model in separate YANG modules.  Applications
      capable of discovering deviations can make allowances that would
      otherwise not be possible.

   A collection of common data types for IETF-related standards is
   provided in [RFC6021].  This standard data type library has been
   derived to a large extend from common SMIv2 data types, generalizing
   them to a less-constrained NETCONF Framework.

   The document "An Architecture for Network Management using NETCONF
   and YANG" describes how NETCONF and YANG can be used to build network
   management applications that meet the needs of network operators
   [RFC6244].

   The Experimental RFC [RFC6095] specifies extensions for YANG,
   introducing language abstractions such as class inheritance and
   recursive data structures.

   [RFC6087] gives guidelines for the use of YANG within the IETF and
   other standardization organizations.

   Work is underway to standardize a translation of SMIv2 data models
   into YANG data models preserving investments into SNMP MIB modules,
   which are widely available for monitoring purposes [SMI-YANG].

   Several independent and open source implementations of the YANG data
   modeling language and associated tools are available.

   While YANG is a relatively recent data modeling language, some data
   models have already been produced.  The specification of the base
   NETCONF protocol operations has been revised and uses YANG as the
   normative modeling language to specify its operations [RFC6241].  The
   IPFIX working group prepared the normative model for configuring and
   monitoring IPFIX- and PSAMP-compliant monitoring devices using the
   YANG modeling language [CONF-MODEL].

   At the time of this writing, the NETMOD working group is developing
   core system and interface data models.  Following the example of the
   IPFIX configuration model, IETF working groups will prepare models
   for their specific needs.

   For information on data models developed using the YANG modeling
   language, see Sections 4.2.1 and 4.2.2.

3.  Network Management Protocols and Mechanisms with Specific Focus

   This section reviews additional protocols the IETF offers for
   management and discusses for which applications they were designed
   and/or have already been successfully deployed.  These are protocols
   that have mostly reached Proposed Standard status or higher within
   the IETF.

3.1.  IP Address Management

3.1.1.  Dynamic Host Configuration Protocol (DHCP)

   Dynamic Host Configuration Protocol (DHCP) [RFC2131] provides a
   framework for passing configuration information to hosts on a TCP/IP
   network and, as such, enables autoconfiguration in IP networks.  In
   addition to IP address management, DHCP can also provide other
   configuration information, such as default routers, the IP addresses
   of recursive DNS servers, and the IP addresses of NTP servers.  As
   described in [RFC6272], DHCP can be used for IPv4 and IPv6 Address
   Allocation and Assignment as well as for Service Discovery.

   There are two versions of DHCP: one for IPv4 (DHCPv4) [RFC2131] and
   one for IPv6 (DHCPv6) [RFC3315].  DHCPv4 was defined as an extension
   to BOOTP (Bootstrap Protocol) [RFC0951].  DHCPv6 was subsequently
   defined to accommodate new functions required by IPv6 such as
   assignment of multiple addresses to an interface and to address
   limitations in the design of DHCPv4 resulting from its origins in
   BOOTP.  While both versions bear the same name and perform the same
   functionality, the details of DHCPv4 and DHCPv6 are sufficiently
   different that they can be considered separate protocols.

   In addition to the assignment of IP addresses and other configuration
   information, DHCP options like the Relay Agent Information option
   (DHCPv4) [RFC3046] and, the Interface-Id Option (DHCPv6) [RFC3315]
   are widely used by ISPs.

   DHCPv6 includes Prefix Delegation [RFC3633], which is used to
   provision a router with an IPv6 prefix for use in the subnetwork
   supported by the router.

   The following are examples of DHCP options that provide configuration
   information or access to specific servers.  A complete list of DHCP
   options is available at [IANA-PROT].

   o  "DNS Configuration options for Dynamic Host Configuration Protocol
      for IPV6 (DHCPv6)" [RFC3646] describes DHCPv6 options for passing
      a list of available DNS recursive name servers and a domain search
      list to a client.

   o  "DHCP Options for Service Location Protocol" [RFC2610] describes
      DHCPv4 options and methods through which entities using the
      Service Location Protocol can find out the address of Directory
      Agents in order to transact messages and how the assignment of
      scope for configuration of Service Location Protocol (SLP) User
      and Service Agents can be achieved.

   o  "Dynamic Host Configuration Protocol (DHCPv6) Options for Session
      Initiation Protocol (SIP) Servers" [RFC3319] specifies DHCPv6
      options that allow SIP clients to locate a local SIP server that
      is to be used for all outbound SIP requests, a so-called "outbound
      proxy server".

   o  "Dynamic Host Configuration Protocol (DHCP) Options for Broadcast
      and Multicast Control Servers" [RFC4280] defines DHCPv6 options to
      discover the Broadcast and Multicast Service (BCMCS) controller in
      an IP network.

   Built directly on UDP and IP, DHCP itself has no security provisions.
   There are two different classes of potential security issues related
   to DHCP: unauthorized DHCP Servers and unauthorized DHCP Clients.
   The recommended solutions to these risks generally involve providing
   security at lower layers, e.g., careful control over physical access
   to the network, security techniques implemented at Layer 2 but also
   IPsec at Layer 3 can be used to provide authentication.

3.1.2.  Ad Hoc Network Autoconfiguration

   Ad hoc nodes need to configure their network interfaces with locally
   unique addresses as well as globally routable IPv6 addresses, in
   order to communicate with devices on the Internet.  The IETF AUTOCONF
   working group developed [RFC5889], which describes the addressing
   model for ad hoc networks and how nodes in these networks configure
   their addresses.

   The ad hoc nodes under consideration are expected to be able to
   support multi-hop communication by running MANET (Mobile Ad Hoc
   Network) routing protocols as developed by the IETF MANET working
   group.

   From the IP layer perspective, an ad hoc network presents itself as a
   Layer 3 multi-hop network formed over a collection of links.  The
   addressing model aims to avoid problems for parts of the system that
   are ad hoc unaware, such as standard applications running on an ad
   hoc node or regular Internet nodes attached to the ad hoc nodes.

3.2.  IPv6 Network Operations

   The IPv6 Operations (V6OPS) working group develops guidelines for the
   operation of a shared IPv4/IPv6 Internet and provides operational
   guidance on how to deploy IPv6 into existing IPv4-only networks, as
   well as into new network installations.

   o  "Basic Transition Mechanisms for IPv6 Hosts and Routers" [RFC4213]
      specifies IPv4 compatibility mechanisms for dual-stack and
      configured tunneling that can be implemented by IPv6 hosts and
      routers.  "Dual stack" implies providing complete implementations
      of both IPv4 and IPv6, and configured tunneling provides a means
      to carry IPv6 packets over unmodified IPv4 routing
      infrastructures.

   o  "Transition Scenarios for 3GPP Networks" [RFC3574] lists different
      scenarios in 3GPP defined packet network that would need IPv6 and
      IPv4 transition, where "Analysis on IPv6 Transition in Third
      Generation Partnership Project (3GPP) Networks" [RFC4215] does a
      more detailed analysis of the transition scenarios that may come
      up in the deployment phase of IPv6 in 3GPP packet networks.

   o  "Scenarios and Analysis for Introducing IPv6 into ISP Networks"
      [RFC4029] describes and analyzes different scenarios for the
      introduction of IPv6 into an ISP's existing IPv4 network.  "IPv6
      Deployment Scenarios in 802.16 Networks" [RFC5181] provides a
      detailed description of IPv6 deployment, integration methods, and
      scenarios in wireless broadband access networks (802.16) in
      coexistence with deployed IPv4 services.  [RFC4057] describes the
      scenarios for IPv6 deployment within enterprise networks.

   o  "Application Aspects of IPv6 Transition" [RFC4038] specifies
      scenarios and application aspects of IPv6 transition considering
      how to enable IPv6 support in applications running on IPv6 hosts,
      and giving guidance for the development of IP-version-independent
      applications.

   o  "IANA-Reserved IPv4 Prefix for Shared Address Space" [RFC6598]
      updates RFC 5735 and requested the allocation of an IPv4/10
      address block to be used as "Shared Carrier-Grade Network Address

      Translation (CGN) Space" by Service Providers to number the
      interfaces that connect CGN devices to Customer Premises Equipment
      (CPE).

3.3.  Policy-Based Management

3.3.1.  IETF Policy Framework

   The IETF specified a general policy framework [RFC2753] for managing,
   sharing, and reusing policies in a vendor-independent, interoperable,
   and scalable manner.  [RFC3460] specifies the Policy Core Information
   Model (PCIM) as an object-oriented information model for representing
   policy information.  PCIM has been developed jointly in the IETF
   Policy Framework (POLICY) working group and the Common Information
   Model (CIM) activity in the Distributed Management Task Force (DMTF).
   PCIM has been published as extensions to CIM [DMTF-CIM].

   The IETF Policy Framework is based on a policy-based admission
   control specifying two main architectural elements: the Policy
   Enforcement Point (PEP) and the Policy Decision Point (PDP).  For the
   purpose of network management, policies allow an operator to specify
   how the network is to be configured and monitored by using a
   descriptive language.  Furthermore, it allows the automation of a
   number of management tasks, according to the requirements set out in
   the policy module.

   The IETF Policy Framework has been accepted by the industry as a
   standard-based policy management approach and has been adopted by
   different SDOs, e.g., for 3GGP charging standards.

3.3.2.  Use of Common Open Policy Service (COPS) for Policy Provisioning
        (COPS-PR)

   [RFC3159] defines the Structure of Policy Provisioning Information
   (SPPI), an extension to the SMIv2 modeling language used to write
   Policy Information Base (PIB) modules.  COPS-PR [RFC3084] uses the
   Common Open Policy Service (COPS) protocol [RFC2748] for the
   provisioning of policy information.  COPS provides a simple client/
   server model for supporting policy control over QoS signaling
   protocols.  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).  Policy data is modeled using PIB modules.

   COPS-PR has not been widely deployed, and operators have stated that
   its use of binary encoding for management data makes it difficult to
   develop automated scripts for simple configuration management tasks

   in most text-based scripting languages.  In the IAB Workshop on
   Network Management [RFC3535], the consensus of operators and protocol
   developers indicated a lack of interest in PIB modules for use with
   COPS-PR.

   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 PIB modules as Proposed Standard, and the
   use of COPS-PR is not recommended.

3.4.  IP Performance Metrics (IPPM)

   The IPPM working group has defined metrics for accurately measuring
   and reporting the quality, performance, and reliability of Internet
   data delivery.  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.

   These metrics are designed for use by network operators and their
   customers, and they provide unbiased quantitative measures of
   performance.  The IPPM metrics have been developed inside an active
   measurement context, that is, the devices used to measure the metrics
   produce their own traffic.  However, most of the metrics can be used
   inside a passive context as well.  At the time of this writing, there
   is no work planned in the area of passive measurement.

   As a property, individual IPPM performance and reliability metrics
   need to be well defined and concrete: thus, implementable.
   Furthermore, the methodology used to implement a metric needs to be
   repeatable with consistent measurements.

   IPPMs have been adopted by different organizations, e.g., the Metro
   Ethernet Forum.

   Note that this document does not aim to cover OAM technologies on the
   data-path and, as such, the discussion of IPPM-based active versus
   passive monitoring as well as the data plane measurement and its
   diagnostics is rather incomplete.  For a detailed overview and
   discussion of IETF OAM standards and IPPM measurement mechanisms, the
   reader is referred to the documents listed at the end of Section 1.2
   ("Related Work") but especially to [OAM-OVERVIEW].

   The following are essential IPPM documents:

   o  "Framework for IP Performance Metrics" [RFC2330] defines a general
      framework for particular metrics developed by the IPPM working
      group, and it defines the fundamental concepts of 'metric' and
      'measurement methodology'.  It also 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  "A One-way Delay Metric for IPPM" [RFC2679] defines a metric for
      the one-way delay of packets across Internet paths.  It builds on
      notions introduced in the IPPM Framework document.

   o  "A Round-trip Delay Metric for IPPM" [RFC2681] defines a metric
      for the round-trip delay of packets across network paths and
      closely follows the corresponding metric for one-way delay.

   o  "IP Packet Delay Variation Metric for IP Performance Metrics
      (IPPM)" [RFC3393] refers to a metric for variation in the 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  "A One-way Packet Loss Metric for IPPM" [RFC2680] defines a metric
      for one-way packet loss across Internet paths.

   o  "A One-Way Packet Duplication Metric" [RFC5560] defines a metric
      for the case where multiple copies of a packet are received, and
      it discusses methods to summarize the results of streams.

   o  "Packet Reordering Metrics" [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] defines a
      series of metrics for connectivity between a pair of Internet
      hosts.

   o  "Framework for Metric Composition" [RFC5835] describes a detailed
      framework for composing and aggregating metrics.

   o  "Guidelines for Considering New Performance Metric Development"
      [BCP170] describes the framework and process for developing
      Performance Metrics of protocols and applications transported over
      IETF-specified protocols.

   To measure these metrics, two protocols and a sampling method have
   been standardized:

   o  "A One-way Active Measurement Protocol (OWAMP)" [RFC4656] measures
      unidirectional characteristics such as one-way delay and one-way
      loss between network devices and enables the interoperability of
      these measurements.  OWAMP is discussed in more detail in
      [OAM-OVERVIEW].

   o  "A Two-Way Active Measurement Protocol (TWAMP)" [RFC5357] adds
      round-trip or two-way measurement capabilities to OWAMP.  TWAMP is
      discussed in more detail in [OAM-OVERVIEW].

   o  "Network performance measurement with periodic streams" [RFC3432]
      describes a periodic sampling method and relevant metrics for
      assessing the performance of IP networks, as an alternative to the
      Poisson sampling method described in [RFC2330].

   For information on MIB modules related to IP Performance Metrics see
   Section 4.2.4.

3.5.  Remote Authentication Dial-In User Service (RADIUS)

   "Remote Authentication Dial In User Service (RADIUS)" [RFC2865]
   describes a client/server protocol for carrying authentication,
   authorization, and configuration information between a Network Access
   Server (NAS), which desires to authenticate its links, and a shared
   authentication server.  The companion document "Radius Accounting"
   [RFC2866] describes a protocol for carrying accounting information
   between a NAS and a shared accounting server.  [RFC2867] adds
   required new RADIUS accounting attributes and new values designed to
   support the provision of tunneling in dial-up networks.

   The RADIUS protocol is widely used in environments like enterprise
   networks, where a single administrative authority manages the network
   and protects the privacy of user information.  RADIUS is deployed in
   the networks of fixed broadband access provider as well as cellular
   broadband operators.

   RADIUS uses attributes to carry the specific authentication,
   authorization, information, and configuration details.  RADIUS is
   extensible with a known limitation of a maximum of 255 attribute
   codes and 253 octets as attribute content length.  RADIUS has Vendor-
   Specific Attributes (VSAs), which have been used both for vendor-
   specific purposes (as an addition to standardized attributes) as well
   as to extend the limited attribute code space.

   The RADIUS protocol uses a shared secret along with the MD5 hash
   algorithm to secure passwords [RFC1321].  Based on the known threads,
   additional protection like IPsec tunnels [RFC4301] are used to
   further protect the RADIUS traffic.  However, building and
   administering large IPsec-protected networks may become a management
   burden, especially when the IPsec-protected RADIUS infrastructure
   should provide inter-provider connectivity.  Moving towards TLS-based
   security solutions [RFC5246] and establishing dynamic trust
   relationships between RADIUS servers has become a trend.  Since the
   introduction of TCP transport for RADIUS [RFC6613], it became natural
   to have TLS support for RADIUS.  An ongoing work is "Transport Layer
   Security (TLS) encryption for RADIUS" [RFC6614].

   "RADIUS Attributes for Tunnel Protocol Support" [RFC2868] defines a
   number of RADIUS attributes designed to support the compulsory
   provision of tunneling in dial-up network access.  Some applications
   involve compulsory tunneling, i.e., the tunnel is created without any
   action from the user and without allowing the user any choice in the
   matter.  In order to provide this functionality, specific RADIUS
   attributes are needed to carry the tunneling information from the
   RADIUS server to the tunnel end points.  "Signalling Connection
   Control Part User Adaptation Layer (SUA)" [RFC3868] defines the
   necessary attributes, attribute values, and the required IANA
   registries.

   "RADIUS and IPv6" [RFC3162] specifies the operation of RADIUS over
   IPv6 and the RADIUS attributes used to support the IPv6 network
   access.  "RADIUS Delegated-IPv6-Prefix Attribute" [RFC4818] describes
   how to transport delegated IPv6 prefix information over RADIUS.

   "RADIUS Attributes for Virtual LAN and Priority Support" [RFC4675]
   defines additional attributes for dynamic Virtual LAN assignment and
   prioritization, for use in provisioning of access to IEEE 802 local
   area networks usable with RADIUS and diameter.

   "Common Remote Authentication Dial In User Service (RADIUS)
   Implementation Issues and Suggested Fixes" [RFC5080] describes common
   issues seen in RADIUS implementations and suggests some fixes.  Where
   applicable, unclear statements and errors in previous RADIUS
   specifications are clarified.  People designing extensions to RADIUS
   protocol for various deployment cases should get familiar with
   "RADIUS Design Guidelines" [RFC6158] in order to avoid, e.g., known
   interoperability challenges.

   "RADIUS Extension for Digest Authentication" [RFC5090] defines an
   extension to the RADIUS protocol to enable support of Digest
   Authentication, for use with HTTP-style protocols like the Session
   Initiation Protocol (SIP) and HTTP.

   "Carrying Location Objects in RADIUS and DIAMETER" [RFC5580]
   describes procedures for conveying access-network ownership and
   location information based on civic and geospatial location formats
   in RADIUS and diameter.

   "Remote Authentication Dial-In User Service (RADIUS) Authorization
   for Network Access Server (NAS) Management" [RFC5607] specifies
   required RADIUS attributes and their values for authorizing a
   management access to a NAS.  Both local and remote management are
   supported, with access rights and management privileges.  Specific
   provisions are made for remote management via Framed Management
   protocols, such as SNMP and NETCONF, and for management access over a
   secure transport protocol.

   "RADIUS (Remote Authentication Dial In User Service) Support For
   Extensible Authentication Protocol (EAP)" [RFC3579] describes how to
   use RADIUS to convey an EAP [RFC3748] payload between the
   authenticator and the EAP server using RADIUS.  RFC 3579 is widely
   implemented, for example, in WLAN and 802.1 X environments.  "IEEE
   802.1X Remote Authentication Dial In User Service (RADIUS) Usage
   Guidelines" [RFC3580] describes how to use RADIUS with IEEE 802.1X
   authenticators.  In the context of 802.1X and EAP-based
   authentication, the VSAs described in [RFC2458] have been widely
   accepted by the industry.  "RADIUS Extensions" [RFC2869] is another
   important RFC related to EAP use.  RFC 2869 describes additional
   attributes for carrying AAA information between a NAS and a shared
   accounting server using RADIUS.  It also defines attributes to
   encapsulate EAP message payload.

   There are different MIB modules defined for multiple purposes to use
   with RADIUS (see Sections 4.2.3 and 4.2.5).

3.6.  Diameter Base Protocol (Diameter)

   Diameter [RFC3588] provides an Authentication, Authorization, and
   Accounting (AAA) framework for applications such as network access or
   IP mobility.  Diameter is also intended to work in local AAA and in
   roaming scenarios.  Diameter provides an upgrade path for RADIUS but
   is not directly backwards compatible.

   Diameter is designed to resolve a number of known problems with
   RADIUS.  Diameter supports server failover, reliable transport over
   TCP and SCTP, well-documented functions for proxy, redirect and relay
   agent functions, server-initiated messages, auditability, and
   capability negotiation.  Diameter also provides a larger attribute
   space for Attribute-Value Pairs (AVPs) and identifiers than RADIUS.
   Diameter features make it especially appropriate for environments,

   where the providers of services are in different administrative
   domains than the maintainer (protector) of confidential user
   information.

   Other notable differences to RADIUS are as follows:

   o  Network and Transport Layer Security (IPsec or TLS),

   o  Stateful and stateless models,

   o  Dynamic discovery of peers (using DNS Service Record (SRV) and
      Naming Authority Pointer (NAPTR)),

   o  Concept of an application that describes how a specific set of
      commands and Attribute-Value Pairs (AVPs) are treated by diameter
      nodes.  Each application has an IANA-assigned unique identifier,

   o  Support of application layer acknowledgements, failover methods
      and state machines,

   o  Basic support for user-sessions and accounting,

   o  Better roaming support,

   o  Error notification, and

   o  Easy extensibility.

   The Diameter protocol is designed to be extensible to support, e.g.,
   proxies, brokers, mobility and roaming, Network Access Servers
   (NASREQ), and Accounting and Resource Management.  Diameter
   applications extend the Diameter base protocol by adding new commands
   and/or attributes.  Each application is defined by a unique IANA-
   assigned application identifier and can add new command codes and/or
   new mandatory AVPs.

   The Diameter application identifier space has been divided into
   Standards Track and 'First Come First Served' vendor-specific
   applications.  The following are examples of Diameter applications
   published at IETF:

   o  Diameter Base Protocol Application [RFC3588]: Required support
      from all Diameter implementations.

   o  Diameter Base Accounting Application [RFC3588]: A Diameter
      application using an accounting protocol based on a server-
      directed model with capabilities for real-time delivery of
      accounting information.

   o  Diameter Mobile IPv4 Application [RFC4004]: A Diameter application
      that allows a Diameter server to authenticate, authorize, and
      collect accounting information for Mobile IPv4 services rendered
      to a mobile node.

   o  Diameter Network Access Server Application (NASREQ, [RFC4005]): A
      Diameter application used for AAA services in the NAS environment.

   o  Diameter Extensible Authentication Protocol Application [RFC4072]:
      A Diameter application that carries EAP packets between a NAS and
      a back-end authentication server.

   o  Diameter Credit-Control Application [RFC4006]: A Diameter
      application that can be used to implement real-time credit-control
      for a variety of end-user services such as network access, Session
      Initiation Protocol (SIP) services, messaging services, and
      download services.

   o  Diameter Session Initiation Protocol Application [RFC4740]: A
      Diameter application designed to be used in conjunction with SIP
      and provides a Diameter client co-located with a SIP server, with
      the ability to request the authentication of users and
      authorization of SIP resources usage from a Diameter server.

   o  Diameter Quality-of-Service Application [RFC5866]: A Diameter
      application allowing network elements to interact with Diameter
      servers when allocating QoS resources in the network.

   o  Diameter Mobile IPv6 IKE (MIP6I) Application [RFC5778]: A Diameter
      application that enables the interaction between a Mobile IP home
      agent and a Diameter server and is used when the mobile node is
      authenticated and authorized using IKEv2 [RFC5996].

   o  Diameter Mobile IPv6 Auth (MIP6A) Application [RFC5778]: A
      Diameter application that enables the interaction between a Mobile
      IP home agent and a Diameter server and is used when the mobile
      node is authenticated and authorized using the Mobile IPv6
      Authentication Protocol [RFC4285].

   The large majority of Diameter applications are vendor-specific and
   mainly used in various SDOs outside the IETF.  One example SDO using
   diameter extensively is 3GPP (e.g., 3GPP 'IP Multimedia Subsystem'
   (IMS) uses diameter-based interfaces (e.g., Cx) [3GPPIMS]).
   Recently, during the standardization of the '3GPP Evolved Packet
   Core' [3GPPEPC], diameter was chosen as the only AAA signaling
   protocol.

   One part of diameter's extensibility mechanism is an easy and
   consistent way of creating new commands for the need of applications.
   RFC 3588 proposed to define diameter command code allocations with a
   new RFC.  This policy decision caused undesired use and redefinition
   of existing command codes within SDOs.  Diverse RFCs have been
   published as simple command code allocations for other SDO purposes
   (see [RFC3589], [RFC5224], [RFC5431], and [RFC5516]).  [RFC5719]
   changed the command code policy and added a range for vendor-specific
   command codes to be allocated on a 'First Come First Served' basis by
   IANA.

   The implementation and deployment experience of diameter has led to
   the ongoing development of an update of the base protocol [DIAMETER],
   which introduces TLS as the preferred security mechanism and
   deprecates the in-band security negotiation for TLS.

   Some Diameter protocol enhancements and clarifications that logically
   fit better into [DIAMETER], are also needed on the existing
   deployments based on RFC 3588.  Therefore, protocol extensions
   specifically usable in large inter-provider roaming network scenarios
   are made available for RFC 3588.  Two currently existing
   specifications are mentioned below:

   o  "Clarifications on the Routing of Diameter Requests Based on the
      Username and the Realm" [RFC5729] defines the behavior required
      for Diameter agents to route requests when the User-Name AVP
      contains a NAI formatted with multiple realms.  These multi-realm
      Network Access Identifiers are used in order to force the routing
      of request messages through a predefined list of mediating realms.

   o  "Diameter Straightforward-Naming Authority Pointer (S-NAPTR)
      Usage" [RFC6408] describes an improved DNS-based dynamic Diameter
      agent discovery mechanism without having to do diameter capability
      exchange beforehand with a number of agents.

   There have been a growing number of Diameter Framework documents from
   the IETF that basically are just a collection of AVPs for a specific
   purpose or a system architecture with semantic AVP descriptions and a
   logic for "imaginary" applications.  From a standardization point of
   view, this practice allows the development of larger system
   architecture documents that do not need to reference AVPs or
   application logic outside the IETF.  Below are examples of a few
   recent AVP and Framework documents:

   o  "Diameter Mobile IPv6: Support for Network Access Server to
      Diameter Server Interaction" [RFC5447] describes the bootstrapping
      of the Mobile IPv6 framework and the support of interworking with
      existing AAA infrastructures by using the diameter NAS-to-home-AAA
      server interface.

   o  "Traffic Classification and Quality of Service (QoS) Attributes
      for Diameter" [RFC5777] defines a number of Diameter AVPs for
      traffic classification with actions for filtering and QoS
      treatment.

   o  "Diameter Proxy Mobile IPv6: Mobile Access Gateway and Local
      Mobility Anchor Interaction with Diameter Server" [RFC5779]
      defines AAA interactions between Proxy Mobile IPv6 (PMIPv6)
      entities (MAG and LMA) and a AAA server within a PMIPv6 Domain.

   For information on MIB modules related to diameter, see
   Section 4.2.5.

3.7.  Control and Provisioning of Wireless Access Points (CAPWAP)

   Wireless LAN (WLAN) product architectures have evolved from single
   autonomous Access Points to systems consisting of a centralized
   Access Controller (AC) and Wireless Termination Points (WTPs).  The
   general goal of centralized control architectures is to move access
   control, including user authentication and authorization, mobility
   management, and radio management from the single access point to a
   centralized controller, where an Access Point pulls the information
   from the AC.

   Based on "Architecture Taxonomy for Control and Provisioning of
   Wireless Access Points (CAPWAP)" [RFC4118], the CAPWAP working group
   developed the CAPWAP protocol [RFC5415] to facilitate control,
   management, and provisioning of WTPs specifying the services,
   functions, and resources relating to 802.11 WLAN Termination Points
   in order to allow for interoperable implementations of WTPs and ACs.
   The protocol defines the CAPWAP control plane, including the
   primitives to control data access.  The protocol document also
   specifies how configuration management of WTPs can be done and
   defines CAPWAP operations responsible for debugging, gathering
   statistics, logging, and managing firmware as well as discusses
   operational and transport considerations.

   The CAPWAP protocol is prepared to be independent of Layer 2
   technologies, and meets the objectives in "Objectives for Control and
   Provisioning of Wireless Access Points (CAPWAP)" [RFC4564].  Separate

   binding extensions enable the use with additional wireless
   technologies.  [RFC5416] defines the CAPWAP Protocol Binding for IEEE
   802.11.

   CAPWAP Control messages, and optionally CAPWAP Data messages, are
   secured using DTLS [RFC6347].  DTLS is used as a tightly integrated,
   secure wrapper for the CAPWAP protocol.

   For information on MIB modules related to CAPWAP, see Section 4.2.2.

3.8.  Access Node Control Protocol (ANCP)

   The Access Node Control Protocol (ANCP) [RFC6320] realizes a control
   plane between a service-oriented Layer 3 edge device, the NAS and a
   Layer 2 Access Node (AN), e.g., Digital Subscriber Line Access Module
   (DSLAM).  As such, ANCP operates in a multi-service reference
   architecture and communicates QoS-, service-, and subscriber-related
   configuration and operation information between a NAS and an AN.

   The main goal of this protocol is to configure and manage access
   equipment and allow them to report information to the NAS in order to
   enable and optimize configuration.

   The framework and requirements for an AN control mechanism and the
   use cases for ANCP are documented in [RFC5851].

   ANCP offers authentication and authorization between AN and NAS nodes
   and provides replay protection and data-origin authentication.  The
   ANCP solution is also robust against Denial-of-Service (DoS) attacks.
   Furthermore, the ANCP solution is recommended to offer
   confidentiality protection.  Security Threats and Security
   Requirements for ANCP are discussed in [RFC5713].

3.9.  Application Configuration Access Protocol (ACAP)

   The Application Configuration Access Protocol (ACAP) [RFC2244] is
   designed to support remote storage and access of program option,
   configuration, and preference information.  The datastore model is
   designed to allow a client relatively simple access to interesting
   data, to allow new information to be easily added without server
   reconfiguration, 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 that allow interesting personal information
   to be shared and group information to be restricted.

   ACAP's primary purpose is to allow applications access to their
   configuration data from multiple network-connected computers.  Users
   can then use any network-connected computer, run any ACAP-enabled
   application, and have access to their own configuration data.  To
   enable wide usage client simplicity has been preferred to server or
   protocol simplicity whenever reasonable.

   The ACAP 'authenticate' command uses Simple Authentication and
   Security Layer (SASL) [RFC4422] to provide basic authentication,
   authorization, integrity, and privacy services.  All ACAP
   implementations are required to implement the CRAM-MD5 (Challenge-
   Response Authentication Mechanism) [RFC2195] for authentication,
   which can be disabled based on the site security policy.

3.10.  XML Configuration Access Protocol (XCAP)

   The Extensible Markup Language (XML) Configuration Access Protocol
   (XCAP) [RFC4825] has been designed for and is commonly used with SIP-
   based solutions, in particular, for instant messages, presence, and
   SIP conferences.  XCAP is a protocol that allows a client to read,
   write, and modify application configuration data stored in XML format
   on a server, where the main functionality is provided by so-called
   "XCAP Application Usages".

   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.  Like ACAP, XCAP supports the configuration
   needs for a multiplicity of applications.

   All XCAP servers are required to implement HTTP Digest Authentication
   [RFC2617].  Furthermore, XCAP servers are required to implement HTTP
   over TLS (HTTPS) [RFC2818].  It is recommended that administrators
   use an HTTPS URI as the XCAP root URI, so that the digest client
   authentication occurs over TLS.

   The following list summarizes important XCAP application usages:

   o  XCAP server capabilities [RFC4825] can be read by clients to
      determine which extensions, application usages, or namespaces a
      server supports.

   o  A resource lists application is any application that needs access
      to a list of resources, identified by a URI, to which operations,
      such as subscriptions, can be applied [RFC4826].

   o  A Resource List Server (RLS) Services application is a SIP
      application, where a server receives SIP SUBSCRIBE requests for
      resources and generates subscriptions towards the resource list
      [RFC4826].

   o  A Presence Rules application uses authorization policies, also
      known as authorization rules, to specify what presence information
      can be given to which watchers, and when [RFC4827].

   o  A 'pidf-manipulation' application defines how XCAP is used to
      manipulate the contents of PIDF-based presence documents
      [RFC4827].