Standard for Binary Floating-Point Arithmetic

IPPM working group has furthermore defined [ BCP108] "IP Performance Metrics (IPPM) Metrics Registry", which defines a registry for IP Performance Metrics [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.

The IPPM working group 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. I'm wondering if service is the right word. As you probably know, there are many discussions around: what's a service? what's an application? what's a protocol? I would prefer to use "service classes" instead of "services". However, I defer to you guys. Note: the IPPM charter speaks of "service classes" Regards, Benoit.

= Hi Benoit,

= >> DIAMETER uses port number 3868 for TCP and = SCTP.

= > So just be consistent. Either you give the ports for all protocols, = or for none of them.

= Agree. The document is not about IANA port = numbers.

= Cheers,
= Mehmet

From: ext Benoit Claise [mailto:bclaise@cisco.com]
Sent: = Wednesday, December 01, 2010 1:15 AM
To: Ersue, Mehmet (NSN - = DE/Munich)
Cc: opsawg@ietf.org
Subject: Re: Review = of draft-ersue-opsawg-management-fw-01, part = 1

Hi Mehmet, =

= Hi Benoit,

= thank you for your comments.

> Below is a couple of high level points:

> - add a section about IPPM. Btw, I never understood why IPPM = was not in OPS. My customers see active monitoring as OPS, and they = don't care whether the packet loss, jitter,

> delay, or whatever perf. metric come from active or passive. = Since I'm following IPPM, I could write a section on this = later.

= Actually there is a chapter on IPPM, maybe it is not sufficient yet. =

Now that I reviewed the = second part of the draft, I see it. ;-)

= =

> - I would like to see YANG appear in the table of content, as = this will be important in the future. A proposal in that direction in = the text below

= Agree, NETCONF and YANG belong together.

> - an EMAN section is missing. I could write it = later.

= This is the point I was trying to explain. Since the document is a kind = of standard survey there is not much to write on EMAN yet. I agree it is = important and should be described as new = work.

Yes, maybe without = referring to the IETF drafts, not be stuck in the RFC-editor queue = forever.

> - multiple times, you refer to "data model". Please = refer to RFC3444

= RFC 3444 should be referred.

> - sometimes you use SYSLOG or syslog. You should take the = convention that only the acronyms are upper case. For example: SNMP, = RADIUS.

> - I would like to rewrite/improve the IPFIX/PSAMP = section.

= I asked already Juergen Quittek for IPFIX/PSAMP and with Dave Harrington = for SNMP. But I am fine with your edits too. You guys can decide who is = doing what.

> - How far do you want in referring existing drafts. You might = be stuck for ever for waiting for all drafts to become RFCs. Example: = I-D.baker-ietf-core. You should mention your =

> guidelines somewhere. Something such as: "This RFC is = based on the current status in OPS in 2011. While there are currently = many drafts that improve the protocols in OPS at the =

> IETF, they are not referenced. This document should have an = update every X years" ...

= I think some of the new work is filling an essential gap and should be = mentioned. I know that we can’t refer drafts consistently so they = will be cleaned up before publication.

> - v6ops is weak, but you noted that. = ;-)

> - Personally, I never heard of AgentX, even if I've been in = network management for many years. For my information, is it used = somewhere in the industry? If not, is it worth

> mentioning?

= I think there are companies using AgentX but this does not mean it is = really important. Let’s see what others = say.

> - Do you want to mention IANA ports? It seems that you do it, = but inconsistently. For example, it's done for RADIUS, but not SNMP, = IPFIX and others.

= Actually I don’t want to go into IANA space. We can give a link = though where people can look at.

I mean, for example:

   =
RADIUS has been prepared to use over UDP port 1812 for =
RADIUS

   Authentication and 1813 for =
RADIUS Accounting.

= ...

   DIAMETER uses port number 3868 for =
TCP and SCTP.

So just be = consistent. Either you give the ports for all protocols, or for none of = them.

> - MIB: you should explain how to search if the IETF has = standardized a MIB module for a specific area.

= AFAIK there is no IETF tool to search for MIB objects. I would suggest = to focus right now on the core part of the = draft.

= Concerning Terminology section: I think we should have here only the = basic NM terminology.

= Concerning other issues below: I will try to consider them. We need = probably a conf call at some point.

Sure. Let me know.

Regards, = Benoit

= Cheers,
= Mehmet

From: ext Benoit Claise [mailto:bclaise@cisco.com] =
Sent: Tuesday, November 16, 2010 4:06 PM
To: opsawg@ietf.org; Ersue, Mehmet (NSN = - DE/Munich)
Subject: Review of = draft-ersue-opsawg-management-fw-01, part = 1

Hi Mehmet,

As promised, here is my review. Only part = 1 for now: part 2 will follow.

Below is a couple of high level = points:
- add a section about IPPM. Btw, I never understood why IPPM = was not in OPS. My customers see active monitoring as OPS, and they = don't care whether the packet loss, jitter, delay, or whatever perf. = metric come from active or passive. Since I'm following IPPM, I could = write a section on this later.
- I would like to see YANG appear in = the table of content, as this will be important in the future. A = proposal in that direction in the text below
- an EMAN section is = missing. I could write it later.
- multiple times, you refer to = "data model". Please refer to RFC3444
- sometimes you use = SYSLOG or syslog. You should take the convention that only the acronyms = are upper case. For example: SNMP, RADIUS.
- I would like to = rewrite/improve the IPFIX/PSAMP section.
- How far do you want in = referring existing drafts. You might be stuck for ever for waiting for = all drafts to become RFCs. Example: I-D.baker-ietf-core. You = should mention your guidelines somewhere. Something such as: "This = RFC is based on the current status in OPS in 2011. While there are = currently many drafts that improve the protocols in OPS at the IETF, = they are not referenced. This document should have an update every X = years" ...
- v6ops is weak, but you noted that. ;-)
- = Personally, I never heard of AgentX, even if I've been in network = management for many years. For my information, is it used somewhere in = the industry? If not, is it worth mentioning?
- Do you want to = mention IANA ports? It seems that you do it, but inconsistently. For = example, it's done for RADIUS, but not SNMP, IPFIX and others.
- MIB: = you should explain how to search if the IETF has standardized a MIB = module for a specific area.
- Along the same line (Data models), do = you want to mention where to look:
    example: IPFIX = IANA IE
    example: RADIUS IANA
    = etc...

See = inline.

Network Working = Group           &n= bsp;           &nb= sp;           &nbs= p;       M. Ersue =
Internet-Draft         &= nbsp;           &n= bsp;           &nb= sp; Nokia Siemens Networks
Intended status: = Informational          =             &= nbsp;   October 25, 2010
Expires: April 28, 2011 =

An Overview of the IETF Network Management Framework = and its Standards =
           &nb= sp;      draft-ersue-opsawg-management-fw-01 =

Abstract

   This document gives an overview of = the IETF standard management
   framework and summarizes = existing and ongoing development of IETF
   = standards-track network management protocols and data models. The =
   purpose of this document is on the one hand to help = system developers
   and users to select appropriate = standard management protocols and
   data models to = address relevant management needs. On the other hand =
   the document can be used as an overview and guideline = by other SDOs
   or bodies planning to use IETF management = technologies and data
   models.

Status of This = Memo

   This Internet-Draft is submitted in full = conformance with the
   provisions of BCP 78 and BCP 79. =

   Internet-Drafts are working documents of the = Internet Engineering
   Task Force (IETF). Note that = other groups may also distribute
   working documents as = Internet-Drafts. The list of current Internet-
   = Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents = valid for a maximum of six months
   and may be updated, = replaced, or obsoleted by other documents at any
   = time. It is inappropriate to use Internet-Drafts as reference =
   material or to cite them other than as "work in = progress."

   This Internet-Draft will expire on = April 28, 2011.

Copyright Notice

   Copyright = (c) 2010 IETF Trust and the persons identified as the
   = document authors. All rights reserved.

   This = document is subject to BCP 78 and the IETF Trust's Legal =
   Provisions Relating to IETF Documents
   = (http://trustee.ietf.org/license-info) in effect on the date of
   publication of = this document. Please review these documents
   = carefully, as they describe your rights and restrictions with respect =

Ersue        &nbs= p;           Expires = April 28, = 2011           &nb= sp;     [Page 1] =

Internet-Draft       &nb= sp; IETF Management = Framework           = October 2010

   to this document. Code = Components extracted from this document must
   include = Simplified BSD License text as described in Section 4.e of =
   the Trust Legal Provisions and are provided without = warranty as
   described in the Simplified BSD License. =

Table of Contents

   1. Introduction . . = . . . . . . . . . . . . . . . . . . . . . . . 4 =
     1.1. Terminology . . . . . . . = . . . . . . . . . . . . . . . . 5
   2. IETF = Standard Management Framework . . . . . . . . . . . . . . 6 =
     2.1. Simple Network Management = Protocol (SNMP) and its =
           = Architectural Principles . . . . . . . . . . . . . . . . . 6 =
     2.2. SNMP and its Versions . . = . . . . . . . . . . . . . . . . 7
     = 2.3. SNMP Security . . . . . . . . . . . . . . . . . . . . . = . 8
       2.3.1. Security = Requirements on the SNMP Management =
           &nb= sp;   Framework . . . . . . . . . . . . . . . . . . . . = . . 8
       2.3.2. = User-Based Security Model (USM) . . . . . . . . . . . 10 =
       2.3.3. View-Based Access = Control Model (VACM) . . . . . . . . 11 =
       2.3.4. SNMP Transport = Subsystem and Transport Security =
           &nb= sp;   Model . . . . . . . . . . . . . . . . . . . . . . = . . 11
       2.3.5. RADIUS = Authentication and Authorization with SNMP =
           &nb= sp;   Transport Models . . . . . . . . . . . . . . . . . . . = 13
     2.4. Supplementary Components of = the IETF Management =
           = Framework . . . . . . . . . . . . . . . . . . . . . . . . 13 =
       2.4.1. NETCONF . . = . . . . . . . . . . . . . . . . . . . . . 13 =
       2.4.2. SYSLOG . . . . . . = . . . . . . . . . . . . . . . . . . 17 =
       2.4.3. IPFIX/PSAMP = . . . . . . . . . . . . . . . . . . . . . 18
   3. = Management Protocols and Mechanisms with specific Focus . . . 20 =
     3.1. IP Address Management with = DHCP . . . . . . . . . . . . . 21
     = 3.2. IPv6 Network Operations . . . . . . . . . . . . . . . . = . 22
     3.3. SNMP Agent Extensibility = (AgentX) Protocol . . . . . . . . 22
     = 3.4. Radius . . . . . . . . . . . . . . . . . . . . . . . . . . 23 =
     3.5. Diameter . . . . . . . . . . . . = . . . . . . . . . . . . . 24
     3.6. = CAPWAP . . . . . . . . . . . . . . . . . . . . . . . . . . 25 =
     3.7. Access Node Control Protocol . . = . . . . . . . . . . . . . 26
     3.8. = Ad-Hoc Network Autoconfiguration . . . . . . . . . . . . . 26 =
     3.9. Policy-based Management . = . . . . . . . . . . . . . . . . 27 =
       3.9.1. IETF Policy = Framework . . . . . . . . . . . . . . . . 27 =
       3.9.2. COPS-PR . . = . . . . . . . . . . . . . . . . . . . . . 27 =
     3.10. Network Performance Management . . . = . . . . . . . . . . . 28
       = 3.10.1. IP Performance Metrics (IPPM) . . . . . . . . . . . . 28 =
       3.10.2. Real-time Flow = Measurement (RTFM) . . . . . . . . . . 29 =
     3.11. Application Management Protocols . . = . . . . . . . . . . . 30
       = 3.11.1. ACAP . . . . . . . . . . . . . . . . . . . . . . . . . 30 =
       3.11.2. XCAP . . . . . . . . . = . . . . . . . . . . . . . . . . 30 =
       3.11.3. EPP . . . . . . . = . . . . . . . . . . . . . . . . . . 31
   4. = Proposed, Draft and Standard Level Data Models . . . . . . . . 31 =
     4.1. Fault Management . . . . . . . . = . . . . . . . . . . . . . 31 =

Ersue        &nbs= p;           Expires = April 28, = 2011           &nb= sp;     [Page 2] =

Internet-Draft       &nb= sp; IETF Management = Framework           = October 2010

     4.2. = Configuration Management . . . . . . . . . . . . . . . . . 33 =
     4.3. Accounting Management . . = . . . . . . . . . . . . . . . . 34
     = 4.4. Performance Management . . . . . . . . . . . . . . . . . . 34 =
     4.5. Security Management . . . = . . . . . . . . . . . . . . . . 36
   5. IANA = Considerations . . . . . . . . . . . . . . . . . . . . . 37 =
   6. Security Considerations . . . . . . . . = . . . . . . . . . . . 37
   7. Contributors . . . . = . . . . . . . . . . . . . . . . . . . . . 37
   8. = Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 37 =
   9. Informative References . . . . . . . . . . . . = . . . . . . . . 37
   Appendix A. New Work related = to IETF Management Framework . . . . 53
     = A.1. Energy Management (eman) . . . . . . . . . . . . . . . . . 53 =
   Appendix B. Open issues . . . . . . . . . . . . . = . . . . . . . . 55 =

<= br>

Ersue         =            Expires = April 28, = 2011           &nb= sp;     [Page 3] =

Internet-Draft       &nb= sp; IETF Management = Framework           = October 2010

1. Introduction

   This = document gives an overview of the IETF standard management =
   framework and summarizes existing and ongoing = development of IETF
   standards-track network management = protocols and data models. The
   purpose of this = document is on the one hand to help system developers
   = and users to select appropriate standard management protocols and =
   data models to address relevant management needs. = On the other hand
   the document can be used as an = overview and guideline by other SDOs
   or bodies planning = to use IETF management technologies and data
   = models. The document can be also used to initiate a discussion =
   between the bodies with the goal to gather new = management
   requirements and to detect possible gaps. =

   [I-D.baker-ietf-core] identifies the key protocols = of the Internet
   Protocol Suite for use in the Smart = Grid. The target audience is
   those people seeking = guidance on how to construct an appropriate
   Internet = Protocol Suite profile for the Smart Grid. In analogy to =
   [I-D.baker-ietf-core] this document gives an overview = on the IETF
   management framework and technologies and = will show usage scenarios
   addressing the Smart Grid = environment.

   The Overview of the 2002 IAB Network = Management Workshop [RFC3535]
   documented strengths and = weaknesses of some IETF management
   protocols. In = choosing existing protocol solutions to meet the
   = management requirements, it is recommended that these strengths and =
   weaknesses be considered. Some of the = recommendations from the 2002
   IAB workshop have become = outdated, some have been standardized, and
   some are = being worked on at the IETF.

   Guidelines for = Considering Operations and Management of New Protocols
   = and Extensions [RFC5706] recommends working groups to consider =
   operations and management needs, and then select = appropriate
   management protocols and data models. = This document can be used to
   ease surveying the IETF = standards-track network management protocols
   and = management data models.

   Section 2 gives an overview = of the IETF standard management framework
   with a = special focus on Simple Network Management Protocol (SNMP) and =
   supplementary components of the IETF management = framework such as
   NETCONF, SYSLOG and IPFIX. = Section 3 discusses IETF management
   protocols and = mechanisms with a specific focus and their use cases.
   = Section 4 discusses Proposed, Draft and Standard Level data models, =

RFC3444

   such as MIBs designed = to address specific set of issues and maps them
   to = different management tasks.

   IETF specifications = must have "multiple, independent, and
   = interoperable implementations" before they can be advanced to Draft =

Ersue        &nbs= p;           Expires = April 28, = 2011           &nb= sp;     [Page 4] =

Internet-Draft       &nb= sp; IETF Management = Framework           = October 2010

   Standard status. An Internet = Standard, which may simply be referred
   to as a = Standard, is characterized by a high degree of technical =
   maturity and by a generally held belief that the = specified protocol
   or service provides significant = benefit to the Internet community
   [RFC2026]. =

   This document mainly refers to Proposed, Draft or = Full Standard
   documents at IETF. =

Give a = reference to those, as your audience is also other = SDOs

As far as it is valuable standard track I-Ds just =
   before publication and Best Current Practice (BCP) = documents are
   referenced. In exceptional cases = and if the document provides
   substantial guideline for = standard usage Informational RFCs are
   noticed. =

   Note: This document uses the expired draft = [I-D.ietf-opsawg-survey-
   management] edited by Dave = Harrington as a starting point and
   enhances it with a = special focus on the description of the IETF
   Standard = Management Framework and SNMP security as well as aims to =
   extend it with explanation of the standards, their = usage scenarios
   and new development at IETF. =

   Note: The document does not cover OAM technologies = on the data-path,
   e.g. OAM of tunnels, MPLS-TP = OAM, Pseudowire, etc. [I-D.ietf-
   = opsawg-oam-overview] gives an overview on the OAM toolset for =
   detecting and reporting connection failures or = measurement of
   connection performance parameters. = [I-D.ietf-mpls-tp-oam-framework]
   describes the OAM = Framework for MPLS-based Transport Networks.

1.1. = Terminology

   This document does not describe = standard requirements. Therefore key
   words from = RFC2119 are not used in the document.

   o CLI: = Command Line Interface

   o Data model: A = mapping of the contents of an information model into =
      a form that is specific to a = particular type of data store or
      = repository.

RFC3444

   o = Information model: An abstraction and representation of the =
      entities in a managed environment, = their properties, attributes
      and = operations, and the way that they relate to each other. It is =
      independent of any specific = repository, software usage, protocol,
      = or platform.

RFC3444

NOTE: To be filled out! =

Not sure = what you want to do.
For example, we have terms defined for Flow, = Flow Record, Template, Metering Process, etc...
Sure, they could be = referenced in this section, we could use the capitalized letter, but = this is a huge job.
Not sure it's worth = it.

Ersue     &= nbsp;           &n= bsp; Expires April 28, = 2011           &nb= sp;     [Page 5] =

Internet-Draft       &nb= sp; IETF Management = Framework           = October 2010

2. IETF Standard Management Framework =

2.1. Simple Network Management Protocol (SNMP) and its = Architectural
      Principles =

   As described in [RFC3410] the current version of = the Internet
   Standard Management Framework, the SNMPv3 = Framework, builds upon both
   the original SNMPv1 and = SNMPv2 Management Framework. The basic
   structure = and components for the Internet Standard Management
   = Framework did not change between its versions and comprises following =
   components:

   o managed nodes, = each with an SNMP entity providing remote access to =
      management instrumentation (the = agent),

   o at least one SNMP entity with = management applications (the
      = manager), and

   o a management protocol used to = convey management information
      between = the SNMP entities, and management information.

   = During its evolution, the fundamental architecture of the Internet =
   Standard Management Framework remained consistent based = on a modular
   architecture, which consists of: =

   o a generic protocol definition independent = of the data it is
      carrying, and =

   o a protocol-independent data definition = language,

   o a virtual database containing = data sets of management information
      = definitions (the Management Information Base, or MIB), and =

   o security and administration. =

   As such following standards build up the basis of = the current IETF
   Standard Management Framework: =

   o SNMPv3 protocol,

   = o the modeling language SMIv2, and

   o = MIBs for different management issues.

   The SNMPv3 = Framework extends the architectural principles of SNMPv1 =
   and SNMPv2 by: =

Ersue       &n= bsp;            = Expires April 28, = 2011           &nb= sp;     [Page 6] =

Internet-Draft       &nb= sp; IETF Management = Framework           = October 2010

   o building on these three = basic architectural components, in some =
      cases incorporating them from the = SNMPv2 Framework by reference,
      and =

   o by using the same layering principles in = the definition of new
      capabilities in = the security and administration portion of the =
      architecture.

2.2. SNMP = and its Versions

   SNMP is based on three conceptual = entities: Manager, Agent, and the
   Management = Information Base (MIB). In any configuration, at least =
   one manager node runs SNMP management software. = Network devices such
   as bridges, routers, and servers = are equipped with an agent. The
   agent is = responsible for providing access to a local MIB of objects =
   that reflects the resources and activity at its = node. Following the
   manager-agent paradigm, an = agent can generate notifications and send
   them as = unsolicited messages to the management application.

   = To enhance this basic functionality, a new version of SNMP has been =
   introduced in 1993. SNMPv2 added bulk transfer = capability and other
   functional extensions like an = administrative model for access
   control, security = extensions, and Manager-to-Manager communication. =

Also the = informs have been introduced.

   SNMPv2 entities can = have a dual role as manager and agent. However,
   = neither SNMPv1 nor SNMPv2 offers sufficient security features. To =
   address the security deficiencies of SNMPv1/v2, SNMPv3 = was issued as
   a set of Proposed Standards in January = 1998 (see [STD62]).

   The BCP document [BCP0074] = "Coexistence between Version 1, Version 2,
   and = Version 3 of the Internet-standard Network Management Framework" =
   gives an overview of the relevant standard documents on = the three
   SNMP versions. The BCP document = furthermore describes how to convert
   MIB modules from = SMIv1 format to SMIv2 format and how to translate
   = notification parameters as well as describes the mapping between the =
   message processing and security models (see [RFC3584]). =

   SNMP utilizes the Management Information Base, a = virtual information
   store of modules of managed = objects. MIB module support is uneven
   across = vendors, and even within devices.

Not sure what you = mean?

The lack of standard MIB
   module support = for all functionality in a device forces operators to
   = use other protocols such as a command line interface (CLI) to do =
   configuration of some aspects of their managed = devices.

I would change completely change the order in this section, = explaining first what SNMP is good at, i.e. monitoring, and then, = express that SNMP is not suitable (and not used that much) for = configuration.
Btw, you can then refer to section 2.4.1, in which you = give the output of the IAB.

Many
   operators = have found it easier to use one protocol for all
   = configurations rather than to split the task across multiple =
   protocols.

   SNMP is good at = determining the operational state of specific
   = functionality, but not necessarily for the complete operational state =

Ersue        &nbs= p;           Expires = April 28, = 2011           &nb= sp;     [Page 7] =

Internet-Draft       &nb= sp; IETF Management = Framework           = October 2010

   of a managed device. =

Hence the = CLI ....

SNMP is also good for statistics gathering for =
   specific functionality. The widespread use of = counters in standard
   MIB modules permits the = interoperable comparison of statistics across
   devices = from different vendors. Counters have been especially useful =
   in monitoring bytes and packets going in and out over = various
   protocol interfaces. SNMP is often used = to poll a device for
   sysUpTime, which serves to report = the time since the last
   reinitialization of the device, = to check for operational liveness,
   and to detect = discontinuities in some counters.

   SNMP traps and = informs can alert an operator or an application when
   = some aspect of a protocol fails or encounters an error condition, and =
   the contents of a notification can be used to guide = subsequent SNMP
   polling to gather additional = information about an event.

   SNMP is widely used for = monitoring fault and performance data. Some
   = operators use SNMP for configuration in various environments, while =
   others find SNMP an inappropriate choice for = configuration in their
   environments. During the = IAB Network Management Workshop the
   attendees expected = that the so-called evolutionary approaches would
   fail = and more focus should be put on new approaches, such as XML- =
   based configuration management. =

You see, = you come back to the same point in the paragraph = above.

   SNMPv1 [RFC1157] is a Full Standard that = the IETF has declared
   Historic and it is not = recommended due to its lack of security
   features. = SNMPv2c [RFC1901] is an Experimental specification (not a =
   standard of any kind) that the IETF has declared = Historic and it is
   not recommended due to its lack of = security features.

   SNMPv3 [STD62] is a Full = Standard that is recommended due to its
   security = features, including support for authentication, encryption, =
   timeliness and integrity checking, and fine-grained = data access
   controls. An overview of the SNMPv3 = document set is in [RFC3410].

   Standards exist to = use SNMP over multiple network protocols,
   including = TCP, UDP, Ethernet, OSI, and others.

2.3. SNMP Security =

2.3.1. Security Requirements on the SNMP Management = Framework

   Several of the classical threats to = network protocols are applicable
   to management problem = space and therefore applicable to any security
   model = used in an SNMP Management Framework. This section lists =
   principal threats, secondary threats, and threats which = are of lesser
   importance as defined in [RFC3411]. =

   The principal threats against which SNMP Security = Models should =

Ersue        &nbs= p;           Expires = April 28, = 2011           &nb= sp;     [Page 8] =

Internet-Draft       &nb= sp; IETF Management = Framework           = October 2010

   provide protection are: =

If I would = be unfamiliar with SNMP, I would be thinking:
"The principal = threats against which SNMP Security Models should provide = protection are". I don't care what it should do, I can about it can = do for me.
Can we change the sentence to "The principal threats = against which SNMP Security Models can provide protection = are"

   Modification of Information: =
      Information might be altered by an = unauthorized entity, e.g. in-
      transit = SNMP messages can be generated to effect unauthorized =
      management operations, including = falsifying the value of an
      object. =

   Masquerade:
      The = masquerade threat is the danger that management operations not =
      authorized for some principal may be = attempted by assuming the
      identity of = another principal that has the appropriate =
      authorizations.

   = Secondary threats against which any Security Model used within this =
   architecture should provide protection are: =

Same = remark here.
See my next remark.

   Message Stream = Modification:
      The SNMP protocol is = typically based upon a connectionless
      = transport service which may operate over any subnetwork service. =
      The re-ordering, delay or replay of = messages can and does occur
      through = the natural operation of many such subnetwork services. =
      The message stream modification = threat is the danger that messages
      = may be maliciously re-ordered, delayed or replayed to an extent =
      which is greater than what can occur = through the natural operation
      of a = subnetwork service, in order to effect unauthorized =
      management operations. =

   Disclosure:
      The = disclosure threat is the danger of eavesdropping on the =
      exchanges between SNMP engines. = Protecting against this threat
      may be = required as a matter of local policy.

   There are at = least two threats against which a Security Model within
   = this architecture need not protect, since they are deemed to be of =
   lesser importance in this context:

   = Denial of Service:
      A Security Model = need not attempt to address the broad range of =
      attacks by which service on behalf of = authorized users is denied.
      Indeed, = such denial-of-service attacks are in many cases =
      indistinguishable from the type of = network failures with which any
      = viable management protocol must cope as a matter of course. =

   Traffic Analysis: =
      A Security Model need not attempt to = address traffic analysis
      = attacks. Many traffic patterns are predictable - entities may be =
      managed on a regular basis by a = relatively small number of =

Ersue        &nbs= p;           Expires = April 28, = 2011           &nb= sp;     [Page 9] =

Internet-Draft       &nb= sp; IETF Management = Framework           = October 2010

      management = stations - and therefore there is no significant =
      advantage afforded by protecting = against traffic analysis.

2.3.2. User-Based Security Model = (USM)

   The User Security Model (USM) provides = authentication and privacy
   services for SNMP = (RFC3414). Specifically, USM is designed to secure =
   against the following principal threats: =

   o Modification of Information: Alteration of = an in-transit message
      generated by an = authorized entity in such a way as to effect =
      unauthorized management operations, = including the setting of
      object = values.

   o Masquerade: Management operations = that are not authorized for some
      = entity may be attempted by that entity by assuming the identity of =
      an authorized entity. =

   o Message Stream Modification: SNMP messages = (transported over a
      connectionless = protocol) could be reordered, delayed, or replayed =
      (duplicated) to affect unauthorized = management operations.

   o Disclosure: An = entity could observe exchanges between a manager =
      and an agent and thereby learn the = values of managed objects, and
      learn = of notification events.

This is a complete repeat from section 2.3.1.
At the = end, I'm wondering why we have section 2.3.1
I would merge section = 2.3.1 and 2.3.2, and explain what SNMP can do for me.

For = example, even in the paragraph above, it's confusing. How do the 2 = sentences fit together?
"Specifically, USM is designed to = secure
   against the following principal threats: = "
"Message Stream Modification: SNMP messages (transported = over a
      connectionless protocol) = could be reordered, delayed, or replayed =
      (duplicated) to affect = unauthorized management operations. =

   USM does not secure against Denial of = Service and attacks based on
   Traffic Analysis. =

   The security services the SNMP Security Model = supports are:

   o Data Integrity is the = provision of the property that data has not =
      been altered or destroyed in an = unauthorized manner, nor have data
      = sequences been altered to an extent greater than can occur non- =
      maliciously.

   = o Data Origin Authentication is the provision of the property that =
      the claimed identity of the user on = whose behalf received data was
      = originated is supported.

   o Data = Confidentiality is the provision of the property that =
      information is not made available or = disclosed to unauthorized
      = individuals, entities, or processes.

   o = Message timeliness and limited replay protection is the provision =
      of the property that a message whose = generation time is outside of
      a = specified time window is not accepted. =

Ersue        =             = Expires April 28, = 2011           &nb= sp;    [Page 10] =

Internet-Draft       &nb= sp; IETF Management = Framework           = October 2010

   See [RFC3414] in [STD62] for a = detailed description of SNMPv3 USM.

2.3.3. View-Based = Access Control Model (VACM)

I'm confused by the placement of = this section, as 2.3.1, 2.3.2, and 2.3.4 discuss security, while this = one doesn't
Can we restructure = this.

   The View-Based Access Control facility of = SNMP enables the
   configuration of agents to provide = different levels of access to the
   agent's MIB. An = agent entity can restrict access to its MIB for a
   = particular manager entity in two ways:

   o It = can restrict access to a certain portion of its MIB, e.g., an =
      agent may restrict most manager = principals to viewing performance-
      = related statistics and allow only a single designated manager =
      principal to view and update = configuration parameters.

   o The agent can = limit the operations that a principal can use on =
      that portion of the MIB. E.g., = a particular manager principal
      could = be limited to read-only access to a portion of an agent's =
      MIB.

   The access = control policy to be used by an agent must be pre-
   = configured for each manager. The policy is based on a table that =
   details the access privileges of the various authorized = managers.

   VACM defines five elements that make up = the Access Control Model:
   groups, security level, = contexts, MIB views, and access policy.

   See = [RFC3415] in [STD62] for a detailed description of SNMPv3 VACM. =

Explain = that we can read, read-write and notification = views.

2.3.4. SNMP Transport Subsystem and Transport = Security Model

   The User-based Security Model (USM) = was designed to be independent of
   other existing = security infrastructures to ensure it could function
   = when third-party authentication services were not available. As a =
   result, USM utilizes a separate user and key-management =
   infrastructure. Operators have reported that = having to deploy
   another user and key-management = infrastructure in order to use SNMPv3
   is costly and = hinders the deployment of SNMPv3.

   SNMP Transport = Subsystem [RFC5590] extends the existing SNMP
   framework = and transport model and enables the use of transport
   = protocols to provide message security unifying the administrative =
   security management for SNMP, and other management = interfaces.

   Transport Models are tied into the SNMP = framework through the
   Transport Subsystem. The = Transport Security Model has been designed
   to work on = top of lower-layer, secure Transport Models. The
   = Transport Security Model [RFC5591] and the Secure Shell Transport =
   Model [RFC5592] utilize the Transport Subsystem. =

Ersue        &nbs= p;           Expires = April 28, = 2011           &nb= sp;    [Page 11] =

Internet-Draft       &nb= sp; IETF Management = Framework           = October 2010

   The Transport Security Model is an = alternative to the existing SNMPv1
   Security Model = [RFC3584], the SNMPv2c Security Model [RFC3584], and
   = the User-based Security Model [RFC3414]. The Secure Shell = Transport
   Model defines furthermore an alternative to = existing standard
   transport mappings described in = [RFC3417] such as SNMP over OSI, SNMP
   over IPX and SNMP = over UDP. SNMP over UDP has been so far the most
   = commonly used SNMP transport binding. The Experimental RFC = [RFC3430]
   defines a transport mapping with TCP. =

   The new SNMP Transport Subsystem modifies the = Abstract Service
   Interfaces to pass transport-specific = security parameters to other
   subsystems. This = includes transport-specific security parameters
   that = are translated into the transport-independent parameters such as =
   securityName and securityLevel.

   = The SNMP Transport Subsystem utilizes one or more lower-layer =
   security mechanisms to provide message-oriented = security services.
   These include authentication of the = sender, encryption, timeliness
   checking, and data = integrity checking.

   A secure Transport Model = establishes an authenticated and possibly
   encrypted = link between the Transport Models of two SNMP engines.
   = After a transport-layer tunnel is established, SNMP messages can be =
   sent through this tunnel from one SNMP engine to the = other. The new
   Transport Model supports sending = multiple SNMP messages through the
   same tunnel to = amortize the costs of establishing a security
   = association.

   The Transport Model on top of a secure = transport protocol performs
   security functions within = the Transport Subsystem, including the
   translation of = transport-security parameters to/from Security-Model-
   = independent parameters. To accommodate this, an implementation- =
   specific cache of transport-specific information is = introduced and
   the data flows on this path are extended = to pass Security-Model-
   independent values. For = this purpose, the Transport Subsystem
   extends SNMPv3 = Abstract Service Interfaces (ASI). New Security
   = Models can be defined using the modified ASIs and the transport- =
   information cache.

   [RFC5592] = introduces a Transport Model (Secure Shell Transport
   = Model), which makes use of the commonly deployed Secure Shell =
   security infrastructure establishing a channel between = itself and the
   SSH Transport Model of another SNMP = engine.

   Different IETF standards use security = layers at the transport or
   application layer to address = security threads (e.g. TLS [RFC5246],
   Simple = Authentication and Security Layer (SASL) [RFC4422], and SSH =
   [RFC4251]). Different management interfaces, = e.g. CLI, SYSLOG =

Ersue        &nbs= p;           Expires = April 28, = 2011           &nb= sp;    [Page 12] =

Internet-Draft       &nb= sp; IETF Management = Framework           = October 2010

   [RFC5424] and NETCONF [RFC4741], = use a secure transport layer to
   provide secure = information and message exchange to build management
   = applications.

   Detailed description of the Transport = Subsystem for SNMP and
   Transport Security Model for = SNMP can be found in [RFC5590] and
   [RFC5591]. = Secure Shell Transport Model for SNMP is specified in
   = [RFC5592] and Transport Layer Security (TLS) Transport Model for SNMP =
   is described in [RFC5953].

2.3.5. RADIUS = Authentication and Authorization with SNMP Transport =
        Models =

   [RFC5608] describes the use of a RADIUS (Remote = Authentication
   Dial-In User Service) authentication and = authorization service by
   SNMP secure Transport Models = for authentication of users and
   authorization of secure = transport session creation.

   The secure transport = protocols selected for use with RADIUS and SNMP
   need to = support user authentication methods that are compatible with =
   those that exist in RADIUS. Transport Models rely = upon the
   underlying secure transport for user = authentication services. The
   SSH protocol = provides a secure transport channel with support for
   = channel authentication via local accounts and integration with =
   various external authentication and authorization = services such as
   RADIUS, Kerberos, etc. SSH = Server integration with RADIUS
   traditionally uses the = username and password mechanism.

   Service = authorization and access control authorization are the use =
   cases for RADIUS support of management access via = SNMP. User
   authentication needs to be done prior = to each of these use cases.
   Service authorization = allows a RADIUS server to authorize an
   authenticated = principal to use SNMP, optionally over a secure
   = transport, typically using an SNMP Transport Model (see [RFC5608]). =

   Access control authorization, i.e. how RADIUS = attributes and messages
   are applied to the specific = application area of SNMP Access Control
   Models, and = VACM in particular is currently being specified in the
   = ISMS (Integrated Security Model for SNMP) WG [I-D.ietf-isms-radius- =
   vacm].

2.4. Supplementary Components of = the IETF Management Framework

2.4.1. NETCONF =

Add YANG = in the title

   SNMP works well for device monitoring and = with its stateless nature
   SNMP is also useful for = statistics and status polling but SNMP has
   limited = configuration management support. =

Ersue        &nbs= p;           Expires = April 28, = 2011           &nb= sp;    [Page 13] =

Internet-Draft       &nb= sp; IETF Management = Framework           = October 2010

   o There is a semantic = mismatch between the task-oriented view =
      preferred by operators and the = data-centric view provided by SNMP,

   o SNMP = does not separate clearly between configuration data and =
      operational state, =

   o Implementing SNMP transactional model and = the protocol constraints
      is complex, = and

   o SNMP modeling language has limited = support for structured data
      types and = relationships among managed objects.

The points above are very = interesting for a new reader, and should cut/pasted somewhere in the = SNMP section.
In this section, there are = hidden.

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

   o Robustness: = Minimizing disruptions and maximizing stability,

   = o Support of task-oriented view,

   o = Extensible 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 Dump and reload a device = configuration in a textual format in a =
      standard manner across multiple = vendors and device types,

   o Support a human = interface and a programmatic interface,

   o = 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 [RFC4741] is a Proposed Standard that provides =
   mechanisms to install, manipulate, and delete the = configuration of
   network devices and aims to address = the advanced configuration =

Ersue        &nbs= p;           Expires = April 28, = 2011           &nb= sp;    [Page 14] =

Internet-Draft       &nb= sp; IETF Management = Framework           = October 2010

   management requirements pointed in = the IAB workshop. It uses an
   Extensible Markup = Language (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. This reduces implementation costs and
   = allows timely access to new features. In addition, applications = can
   access both the syntactic and semantic content of = the device's native
   user interface. =

   Additionally NETCONF WG developed the NETCONF Event = Notifications
   Mechanism as an optional capability, = which provides an asynchronous
   message notification = delivery service for NETCONF [RFC5277]. NETCONF
   = notification mechanism enables using general purpose notification =
   streams, which can not only transport NETCONF = notifications but also
   alarms from other sources, where = the originator of the NETCONF
   notification stream can = be any managed device (e.g. SNMP alarms).

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

   NETCONF WG also defined the necessary = data model to monitor the
   NETCONF protocol by using = YANG. The monitoring data model includes
   = information about NETCONF datastores, sessions, locks, and =
   statistics, which facilitate the management of a = NETCONF server.
   NETCONF monitoring document also = defines methods for NETCONF clients
   to discover data = models supported by a NETCONF server and defines a
   new = operation to retrieve them [RFC6022].

   ADD: Describe = how an SNMP agent and a NETCONF server may co-exist on
   = the same managed device using the same datastore for the management =
   data model.

   NETCONF defined SSH = transport binding as the mandatory secure
   transport of = its RPC messages [RFC4742]. Other optional secure
   = transport bindings are available for TLS [RFC5539], BEEP (over TLS) =
   [RFC4744], and SOAP (over HTTP over TLS) = [RFC4743]. There is an
   implementation available = using NETCONF over SOAP as a Web Service
   [RFC5381]. =

   Currently NETCONF workgroup is focusing on bug = fixing of the NETCONF
   base protocol standard [4741bis] = and the SSH transport protocol
   mapping [4742bis] as = well as the specification of the NETCONF Access
   Control = Model (NACM). NACM is going to provide a secure operating =

Ersue        &nbs= p;           Expires = April 28, = 2011           &nb= sp;    [Page 15] =

Internet-Draft       &nb= sp; IETF Management = Framework           = October 2010

   environment for NETCONF and = proposes standard mechanisms to restrict
   protocol = access to particular users with a pre-configured subset of =
   operations and content.

   NETMOD WG = developed YANG as the normative modeling language for the =
   modeling of configuration data for usage with = NETCONF. YANG follows

the

   following design goals = addressing specific requirements on a modeling
   language = for configuration management:

   o Allow = modeling of standard and vendor defined modules for multi- =
      vendor interoperability, =

   o Define semantics and data organization, = i.e. models operational
      and = configuration data, notifications, and operations,

   = o "human-readable", easy to use and text-based, =

   o Enable addition of new content to existing = data models and can be
      extended at = IETF as necessary,

   o Map directly to XML = content (on the wire), and

   o Basic types = compatible with SMIv2 and preserves therefore =
      investments in SNMP MIBs. =

   NETMOD WG furthermore developed Common YANG Data = Types to be used
   with YANG [RFC6021] and a guidelines = document for authors and
   reviewers of YANG Data Model = Documents [I-D
   draft-ietf-netmod-yang-usage] as well as = the mapping rules for
   translating YANG data models into = Document Schema Definition
   Languages (DSDL) = [I-D.ietf-netmod-dsdl-map]. The architecture
   = document "An Architecture for Network Management using NETCONF and =
   YANG" describes how NETCONF and YANG can help to = build network
   management applications that meet the = needs of network operators
   = [I-D.draft-ietf-netmod-arch].

   IPFIX WG prepared the = normative IPFIX/PSAMP configuration model for
   = configuring and monitoring IPFIX and PSAMP compliant Monitoring =
   Devices with the YANG modeling language and is = proposing to use
   NETCONF for the configuration of these = entities [I-D.ietf-ipfix-
   configuration-model]. =

   At the time of this writing, the rechartering = discussion of the
   NETMOD WG is ongoing. NETMOD WG = aims to focus in its second phase on
   the development of = core system and core interface data models. The
   = WG will not develop models for specific topic areas or workgroups at =
   IETF. Such modeling work will be done in = corresponding WGs, e.g.
   DNSOP WG will develop the DNS = configuration model using YANG. =

Ersue        &nbs= p;           Expires = April 28, = 2011           &nb= sp;    [Page 16] =

Internet-Draft       &nb= sp; IETF Management = Framework           = October 2010

2.4.1.1. YANG - NETCONF Modeling Language =

   Following the guideline and requests of the IAB = management workshop
   the NETMOD workgroup developed a = "human-friendly" modeling language
   defining = the semantics of operational data, configuration data,
   = notifications, and operations [RFC6020]. The new modeling language =
   focuses on readability and ease of use and will serve = as the
   normative description of NETCONF data models. =

   ADD: Input from YANG team?

this section should be more = visible. At least in the table of = content.

2.4.2. SYSLOG

Missing one important = part.
Everybody uses http://www.faqs.org/rfcs/rfc3164.html these days.
Must explain that this RFC is informational = only

   The SYSLOG protocol [RFC5424] allows a = machine to send system log
   messages across networks to = event message collectors. The protocol
   is simply = designed to transport these event messages. No
   = acknowledgement of the receipt is made. One of the fundamental =
   tenets of the SYSLOG protocol and process is its = simplicity.

... from a development point of = view.

No
   stringent coordination is = required between the transmitters and the
   = receivers. 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. This simplicity has greatly aided the acceptance and =
   deployment of SYSLOG.

   Since each = process, application and operating system was written
   = somewhat independently, there has been little uniformity to the =
   message format or content of SYSLOG messages. =

   The IETF has developed a new Proposed Standard = version of the
   protocol that allows the use of any = number of transport protocols
   including reliable = transports and secure transports [RFC5424]. The
   = IETF has also standardized the application of message security for =
   SYSLOG messages using TLS [RFC5425], and has defined a = mechanism to
   digitally sign log data to ensure its = integrity as log data is moved
   across the network = and/or copied to different data stores [RFC5848].

   =

Part of = 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. =

   SYSLOG message content has traditionally been = unstructured natural
   language text. This content = is human-friendly, but difficult for
   applications to = parse and correlate across vendors, or correlate with
   = other event reporting such as SNMP traps.

This paragraph should be moved at = the top of the section, after that you introduced RFC 3164.
Also you = must stress the issue of inconsistencies (level and message) across = vendors or even platform types within vendors.
Since this is a = printf, it's basically for a develop to create his own = message.

The IETF syslog protocol
   includes = structured data elements to aid application-parsing. The =

Ersue        &nbs= p;           Expires = April 28, = 2011           &nb= sp;    [Page 17] =

Internet-Draft       &nb= sp; IETF Management = Framework           = October 2010

   structured data element design = allows vendors to define their own
   structured data = elements to supplement standardized elements.
   [RFC5675] = defines a mapping from SNMP notifications to SYSLOG
   = messages and [RFC5676] defines the corresponding managed objects for =
   this purpose. And [RFC5674] defines the way = alarms are send 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 and the IETF Alarm MIB.

   The IETF has = standardized MIB Textual-Conventions for facility and
   = severity labels and codes to encourage consistency between syslog and =
   MIB representations of these event properties. = The intent is that
   these textual conventions will be = imported and used in MIB modules
   that would otherwise = define their own representations. [RFC5427]

   = [RFC5848] "Signed Syslog Messages" 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 layered architecture provides for support of any =
   number of transport mappings. However, for = interoperability
   purposes, syslog protocol implementers = are required to support the
   transmission of Syslog = Messages over UDP as defined in [RFC5426].

   IETF = furthermore defined the TLS transport mapping for Syslog in =
   [RFC5425], which provides a secure connection for the = transport of
   syslog messages and describes the security = threats to syslog and how
   TLS can be used to counter = such threats. Datagram Transport Layer
   Security = (DTLS) Transport Mapping for Syslog is defined in [RFC6012], =
   which can be used in cases where a connection-less = transport is
   desired.

   IETF working = groups are encouraged to standardize structured data
   = elements, extensible human-friendly text, and consistent facility/ =
   severity values for SYSLOG to report events specific to = their
   protocol.

2.4.3. IPFIX/PSAMP =

   IPFIX [RFC5101] is = a Proposed Standard, which defines a push-based
   data = export mechanism for formatting and transferring IP flow =
   information from an exporter to a collector. = PSAMP defines a
   standard set of capabilities for = network elements to sample subsets
   of packets by = statistical and other methods.

   The IPFIX working = group

sometimes you use WG, sometimes = not.

has specified the Information Model (to
   = describe IP flows) and the IPFIX protocol for the export of flow =

Ersue        &nbs= p;           Expires = April 28, = 2011           &nb= sp;    [Page 18] =

Internet-Draft       &nb= sp; IETF Management = Framework           = October 2010

   information from routers or = measurement probes to external systems
   [RFC5101], = [RFC5102]. IPFIX protocol exports flow data e.g. from =
   routers and probes (IPv4, IPv6) and works on top of = UDP, TCP or SCTP.

Well SCTP is a must, not the = others.

   Several applications using the IPFIX protocol = are available.

   IPFIX [RFC5101] is a Proposed = Standard approach for transmitting IP
   traffic flow = information over the network from an exporting process
   = to an information collecting process. IPFIX defines a common =
   representation of flow data and a standard means of = communicating the
   data over a number of transport = protocols.

   [RFC3917] specifies the observation = point, flows, exporting and the
   collecting process as = well as a metering process that consists of a
   packet = header capturing, time stamping, classifying, sampling, and =
   maintaining flow records.

yes but RFC3917 is = informational.
RFC3917 specifies the = requirements.

   IPFIX Information = Model defines Information Elements (IEs) for
   = distinguishing flows and for reporting flow characteristics =
   [RFC5102]. Information Model for PSAMP extends = the IPFIX information
   model by IEs for packet header = and payload information [RFC5477] and
   defines packet = selection methods for filtering and sampling of such
   = data. IPFIX and PSAMP packet sampling use the same packet = processing
   (aka. packet mediation). PSAMP packet = information is exported with
   the IPFIX protocol based = on a shared information model.

   The IPFIX WG has = developed an XML-based configuration data model in
   = close collaboration with the NETMOD WG and uses YANG as modeling =
   language [I-D.ietf-ipfix-configuration-model]. = The model specifies
   the necessary data for configuring = and monitoring selection
   processes, caches, exporting = processes, and collecting processes of
   IPFIX and PSAMP = compliant monitoring devices.

   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. = IPFIX Mediation Framework 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 [I-D.ietf-ipfix-mediators-
   = framework].

   The work on IP Flow Anonymization = Support describes anonymization
   techniques for IP flow = data and the export of anonymized data
   = [I-D.ietf-ipfix-anon]. =

Ersue        =             = Expires April 28, = 2011           &nb= sp;    [Page 19] =

Internet-Draft       &nb= sp; IETF Management = Framework           = October 2010

   The document 'IPFIX Export per = SCTP Stream' [I-D.ietf-ipfix-export-
   per-sctp-stream] = specifies a reliability extension based on a method
   for = exporting a Template Record and its associated Data Sets in a =
   single SCTP stream, for limiting each Template ID to a = single SCTP
   stream and imposing in-order transmission. =

   [I-D.ietf-ipfix-structured-data] proposes an = extension to the IPFIX
   protocol to support the export = of hierarchically structured data and
   lists (sequences) = of Information Elements in data records. The
   = document describes how to distribute structured data with an abstract =
   data type and a new Information Element, e.g. for the = distribution of
   security keys or performance = measures. This application can also be
   used for = the distribution of logging information if standard SYSLOG =
   based logging is not available.

   = There are several applications such as usage-based accounting, =
   traffic profiling, traffic engineering, intrusion = detection, and QoS
   monitoring, that require flow-based = traffic measurements, which can
   be realized on top of = IPFIX. IPFIX can also be used e.g. for the
   = monitoring of the protocols like SIP and the related media transfer, =
   which is indeed based on flows on application = layer. The
   requirements to such a monitoring = application are e.g. measuring
   signaling quality (e.g., = session request delay, session completion
   ratio, or = hops for request), media QoS (e.g., jitter, delay or bit =
   rate), and user experience (e.g., Mean Opinion Score). =

   Several applications require sampling packets from = specific data
   flows, or across multiple data flows, and = reporting information about
   the packets. = Measurement-based network management is a prime
   = example. The PSAMP WG developed the protocol for reporting = observed
   packets by extending the IPFIX protocol. = In order to reduce the
   amount of data to be processed = for selecting observed IP packets,
   packet selection = methods have been defined.

   PSAMP standardizes = sampling, selection, metering, and reporting
   strategies = for different purposes and includes support for packet
   = sampling in IPv4, IPv6, and MPLS-based networks. To simplify the =
   solution, the IPFIX protocol is used for the export of = the PSAMP
   reports to collector applications. =

   NOTE: Input from IPFIX WG?

yes, I would like to improve this. = Missing biflow, file, IPFIX-structured data, = etc...

3. Management Protocols and Mechanisms with = specific Focus

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

Ersue        &nbs= p;           Expires = April 28, = 2011           &nb= sp;    [Page 20] =

Internet-Draft       &nb= sp; IETF Management = Framework           = October 2010

   IETF.

3.1. IP = Address Management with DHCP

   BOOTP (Bootstrap = Protocol), originally defined in [RFC951], has been
   = used by network clients during the bootstrap process to obtain an IP =
   address from a configuration server. BOOTP = requires manual
   intervention to add configuration = information for each client, and
   does not provide a = mechanism for reclaiming disused IP addresses.

   The = Draft Standard Dynamic Host Configuration Protocol (DHCP) =
   [RFC2131] was defined as an extension to BOOTP. = DHCP provides a
   framework for passing configuration = information to hosts on a TCP/IP
   network and does as = such enable autoconfiguration in IP networks. In
   = addition to IP address management, DHCP can also provide other =
   configuration information, particularly the IP = addresses of local
   caching DNS resolvers or servers = providing servers. As described in
   = [I-D.baker-ietf-core] DHCP can be used for IPv4 and IPv6 Address =
   Allocation and Assignment as well as Service Discovery. =

   There are two versions of DHCP, one for IPv4 = [RFC2131] and one for
   IPv6 [RFC3315]. While both = versions bear the same name and perform
   much the same = purpose, the details of the protocol for IPv4 and IPv6
   = are sufficiently different that they can be considered separate =
   protocols.

   Following are examples, = where DHCP options have been used to provide
   = configuration information or access to specific servers. =

   o [RFC3646] describes two DHCPv6 options for = passing a list of
      available DNS = recursive name servers and a domain search list to a =
      client.

   o = [RFC2610] describes how 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 SLP User and Service = Agents can be achieved.

   o [RFC3319] specifies = two 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 [RFC4280] defines new options to discover the Broadcast and =
      Multicast Service (BCMCS) controller = in an IP network. =

Ersue      =             &= nbsp; Expires April 28, = 2011           &nb= sp;    [Page 21] =

Internet-Draft       &nb= sp; IETF Management = Framework           = October 2010

3.2. IPv6 Network Operations =

   The IPv6 Operations Working Group (v6ops) 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.

   NOTE: Input = planned from V6ops Workgroup.

3.3. SNMP Agent = Extensibility (AgentX) Protocol

   The Draft Standard = [RFC2741] "Agent Extensibility (AgentX) Protocol" =
   defines a framework for extensible SNMP agents = including master
   agents and subagents, the AgentX = protocol used to communicate between
   them, and how the = extensible agent processes SNMP protocol messages.

   = Within the SNMP framework, a managed node contains a processing =
   entity called agent, which has access to management = information.
   Within the AgentX framework, an agent is = further defined to consist
   of:

   = o a single processing entity called the master agent, which sends =
      and receives SNMP protocol messages = in an agent role (as specified
      by the = SNMP framework documents) but typically has little or no =
      direct access to management = information, and

   o zero or more processing = entities called subagents, which are
      = "shielded" from the SNMP protocol messages processed by the = master
      agent, but which have access = to management information.

   The internal operations = of AgentX are invisible to an SNMP entity
   operating in = a manager role. From a manager's point of view, an =
   extensible agent behaves exactly as would a = non-extensible
   (monolithic) agent that has access to = the same management
   instrumentation. =

   [RFC2741] specifies furthermore a TCP binding for = the AgentX
   protocol.

   The Draft = Standard [RFC2742] "Definitions of Managed Objects for =
   Extensible SNMP Agents" describes objects managing = SNMP agents that
   use the AgentX Protocol and specifies = a MIB module, which is
   compliant to the SMIv2, and = semantically identical to the peer SMIv1
   definitions. =

Ersue      =             &= nbsp; Expires April 28, = 2011           &nb= sp;    [Page 22] =

Internet-Draft       &nb= sp; IETF Management = Framework           = October 2010

3.4. Radius

   Radius = [RFC2865],

RADIUS

the remote Authentication Dial In = User Service, is
   a Draft Standard that 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. =

   This protocol is widely implemented and is used in = environments like
   enterprise networks, where a single = administrative authority manages
   the network, and = protects the privacy of user information.

   RADIUS is = extensible with Vendor-Specific Attributes (VSAs), which =
   are mostly vendor-specific.

   The = RADIUS protocol uses a shared secret along with the MD5 hashing =
   algorithm to secure passwords. Based on the known = threads additional
   protection like IPsec tunnels are = used to further protect the RADIUS
   traffic. =

   Radius has been prepared to use over UDP port 1812 = for RADIUS
   Authentication and 1813 for RADIUS = Accounting assigned by IANA.

   [RFC3162] 'RADIUS and = IPv6' specifies the operation of RADIUS over
   IPv6 and = the RADIUS attributes used to support the IPv6 network
   = access.

   [RFC4675] 'RADIUS Attributes for Virtual = LAN and Priority Support'
   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.

   = [RFC5080] 'Common RADIUS Implementation Issues and Suggested Fixes' =
   describes common issues seen in RADIUS implementations = and suggests
   some fixes. Where applicable, = unclear statements and errors in
   previous RADIUS = specifications are clarified.

   [RFC5090] 'RADIUS = Extension for Digest Authentication' 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. =

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

   NOTE: Need more discussion of Radius RFCs = and use cases. =

Ersue        &nbs= p;           Expires = April 28, = 2011           &nb= sp;    [Page 23] =

Internet-Draft       &nb= sp; IETF Management = Framework           = October 2010

3.5. Diameter

When a name is not an acronym, one = sentence of explanation would help.
Idem for syslog btw.
Same = thing for CAPWAP. I read the next section, but I've got no clue what = it's supposed to stand for.

   Diameter [RFC3588] = is a Proposed Standard that 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 Authentication, = Authorization, Accounting
   situations and in roaming = situations. Diameter is not directly
   backwards = compatible, but provides an upgrade path for RADIUS. =

   Diameter is designed to resolve a number of known = problems with
   RADIUS. Diameter supports server = failover, reliable transport over
   TCP and SCTP, agents = for proxy and redirect and relay, 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 = important differences to Radius are:
   - Use of reliable = transport protocols (TCP or SCTP, not UDP),
   - Network = and transport layer security (IPsec or TLS),
   - Stateful = and stateless models,
   - Dynamic discovery of peers = (using DNS SRV and NAPTR),
   - Supports application layer = acknowledgements, defines failover
   methods and state = machines [RFC3539],
   - Error notification, =
   - Better roaming support,
   - Easier to = extend, and
   - Basic support for user-sessions and = accounting.

   The Diameter protocol has been enhanced = for the use with 3GPP IP
   Multimedia Subsystem = (IMS). Different IMS interfaces (e.g. Cx) are =
   supported by Diameter applications [3GPPIMS]. =

   The 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 an = application identifier and can add
   new command codes = and/or new mandatory Attribute-Value Pairs (AVPs).

   = Following are examples of Diameter applications:
   - = Diameter Mobile IPv4 Application [RFC4004],
   - Diameter = Network Access Server Application (NASREQ, [RFC4005]),
   = - Diameter Extensible Authentication Protocol Application [RFC4072], =
   - Diameter Credit-Control Application [RFC4006], =
   - Diameter Session Initiation Protocol Application = [RFC4740], and =

Ersue        &nbs= p;           Expires = April 28, = 2011           &nb= sp;    [Page 24] =

Internet-Draft       &nb= sp; IETF Management = Framework           = October 2010

   - Diameter Quality-of-Service = Application [RFC5866].

   [RFC5516] 'Diameter Command = Code Registration for the Third
   Generation Partnership = Project (3GPP) Evolved Packet System (EPS)'
   registers a = set of IANA Diameter Command Codes to use in new vendor- =
   specific Diameter applications defined for the 3GPP) = Evolved Packet
   System (EPS).

   = [RFC5447] 'Diameter Mobile IPv6: Support for Network Access Server to =
   Diameter Server Interaction' describes the = bootstrapping of the
   Mobile IPv6 framework and the = support of interworking with existing
   Authentication, = Authorization, and Accounting (AAA) infrastructures
   by = using the Diameter Network Access Server to home AAA server =
   interface.

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

   [RFC5729] = 'Clarifications on the Routing of Diameter Requests Based =
   on the Username and the Realm' defines the behavior = required of
   Diameter agents to route requests when the = User-Name AVP contains a
   Network Access Identifier = 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.

   The IANA has = assigned TCP and SCTP port number 3868 to Diameter.

   = NOTE: Need more discussion of Diameter RFCs and use cases. =

3.6. CAPWAP

   Wireless LAN 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.

   Based on the CAPWAP = Architecture Taxonomy work [RFC4118] CAPWAP
   workgroup = developed the CAPWAP protocol to facilitate control,
   = management and provisioning of WLAN Termination Points (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 =

Ersue        &nbs= p;           Expires = April 28, = 2011           &nb= sp;    [Page 25] =

Internet-Draft       &nb= sp; IETF Management = Framework           = October 2010

   control plane including the = primitives to control data access. The
   protocol = document also defines how configuration management of WTPs =
   can be done and defines CAPWAP operations responsible = for debugging,
   gathering statistics, logging, and = firmware management as well as
   discusses operational = and transport considerations.

   CAPWAP protocol is = defined 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 CAPWAP Protocol Binding for IEEE 802.11.

   = CAPWAP Base MIB [RFC5833] describes managed objects for modeling the =
   CAPWAP Protocol and provides configuration and WTP = status-monitoring
   aspects of CAPWAP, where CAPWAP = Binding MIB [RFC5834] describes
   managed objects for = modeling of CAPWAP protocol for IEEE 802.11
   wireless = binding.
   (RFC 5833 and RFC 5834 have been published as = Informational RFCs to
   provide the basis for future work = on a SNMP management of the CAPWAP
   protocol.) =

3.7. Access Node Control Protocol

   The = Access Node Control Protocol (ANCP) [I-D.ietf-ancp-protocol] =
   realizes a control plane between a service-oriented = layer 3 edge
   device (the Network Access Server, NAS) = and a layer 2 Access Node
   (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 configurations = and operations
   between a NAS and an Access Node. =

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

   Framework and Requirements for an = Access Node Control Mechanism and
   the use cases for = ANCP are documented in [RFC5851]. Security Threats =
   and Security Requirements for ANCP are discussed in = [RFC5713].

3.8. 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. AUTOCONF WG =
   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 =

Ersue        &nbs= p;           Expires = April 28, = 2011           &nb= sp;    [Page 26] =

Internet-Draft       &nb= sp; IETF Management = Framework           = October 2010

   support multi-hop communication by = running MANET routing protocols as
   developed by the = IETF MANET WG.

   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 ad-hoc-unaware parts of =
   the system, such as standard applications running on an = ad-hoc node
   or regular Internet nodes attached to the = ad-hoc nodes.

3.9. Policy-based Management =

3.9.1.

This is where I arrived.
My flight was long, but it was = not long enough ;-)

Regards, = Benoit.

The IPPM working group 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. I'm wondering if service is the right word. As you probably know, there are many discussions around: what's a service? what's an application? what's a protocol? I would prefer to use "service classes" instead of "services". However, = I defer to you guys.=20 Note: the IPPM charter speaks of "service classes" Regards, Benoit.

3.9.2. = COPS-PR

3.9.2. COPS-PR

4.4. Performance Management