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

["Ersue, Mehmet (NSN - DE/Munich)" <[e-mail]>]

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:[e-mail]] 
Sent: Wednesday, December 01, 2010 1:15 AM
To: Ersue, Mehmet (NSN - DE/Munich)
Cc: [e-mail]
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:[e-mail]] 
Sent: Tuesday, November 16, 2010 4:06 PM
To: [e-mail]; 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                                           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/
<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
<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
<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.