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

[Benoit Claise <[e-mail]>]

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                                           M. Ersue
> Internet-Draft                                    Nokia Siemens Networks
> Intended status: Informational                          October 25, 2010
> Expires: April 28, 2011
>
>
>  An Overview of the IETF Network Management Framework and its Standards
>                   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                    Expires April 28, 2011                 [Page 1]
> 
> Internet-Draft          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
>                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
>                Model  . . . . . . . . . . . . . . . . . . . . . . . . 11
>        2.3.5.  RADIUS Authentication and Authorization with SNMP
>                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                    Expires April 28, 2011                 [Page 2]
> 
> Internet-Draft          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
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Ersue                    Expires April 28, 2011                 [Page 3]
> 
> Internet-Draft          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                    Expires April 28, 2011                 [Page 4]
> 
> Internet-Draft          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                    Expires April 28, 2011                 [Page 5]
> 
> Internet-Draft          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                    Expires April 28, 2011                 [Page 6]
> 
> Internet-Draft          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                    Expires April 28, 2011                 [Page 7]
> 
> Internet-Draft          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                    Expires April 28, 2011                 [Page 8]
> 
> Internet-Draft          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                    Expires April 28, 2011                 [Page 9]
> 
> Internet-Draft          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                [Page 10]
> 
> Internet-Draft          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                    Expires April 28, 2011                [Page 11]
> 
> Internet-Draft          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                    Expires April 28, 2011                [Page 12]
> 
> Internet-Draft          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                    Expires April 28, 2011                [Page 13]
> 
> Internet-Draft          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                    Expires April 28, 2011                [Page 14]
> 
> Internet-Draft          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                    Expires April 28, 2011                [Page 15]
> 
> Internet-Draft          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                    Expires April 28, 2011                [Page 16]
> 
> Internet-Draft          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                    Expires April 28, 2011                [Page 17]
> 
> Internet-Draft          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                    Expires April 28, 2011                [Page 18]
> 
> Internet-Draft          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                [Page 19]
> 
> Internet-Draft          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                    Expires April 28, 2011                [Page 20]
> 
> Internet-Draft          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                    Expires April 28, 2011                [Page 21]
> 
> Internet-Draft          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                    Expires April 28, 2011                [Page 22]
> 
> Internet-Draft          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                    Expires April 28, 2011                [Page 23]
> 
> Internet-Draft          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                    Expires April 28, 2011                [Page 24]
> 
> Internet-Draft          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                    Expires April 28, 2011                [Page 25]
> 
> Internet-Draft          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                    Expires April 28, 2011                [Page 26]
> 
> Internet-Draft          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.