Definitions of Managed Objects for IP Flow Information Export
draft-ietf-ipfix-mib-10

IANA comments:

Action 1:

Upon approval of this document, the IANA will make the following assignments
in the "Network Management Parameters" registry located at
http://www.iana.org/assignments/smi-numbers
sub-registry "iso.org.dod.internet.mgmt.mib-2 (1.3.6.1.2.1)"

Decimal Name Description References
------- ---- ----------- ----------
[TBD] ipfixMIB IP Flow Information Export [RFC-ipfix-mib-08]
[TBD] ipfixSelectorMIB IP Flow Information Selector [RFC-ipfix-mib-08]


Action 2:

Upon approval of this document, the IANA will create the following
managed mib "IPFIX SELECTOR MIB" located at http://www.iana.org/assignments/TBD

Allocation Procedures: Expert Review
Initial contents of this registry will be:

IPFIX-SELECTOR-MIB DEFINITIONS ::= BEGIN

IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, mib-2
FROM SNMPv2-SMI -- RFC2578
TruthValue
FROM SNMPv2-TC -- RFC2579
MODULE-COMPLIANCE, OBJECT-GROUP
FROM SNMPv2-CONF; -- RFC2580

ipfixSelectorMIB MODULE-IDENTITY
LAST-UPDATED "200906020900Z" -- 02 June 2009
ORGANIZATION "IETF IPFIX Working Group"
CONTACT-INFO
"WG charter:
http://www.ietf.org/html.charters/ipfix-charter.html

Mailing Lists:
General Discussion: ipfix@ietf.org
To Subscribe: http://www1.ietf.org/mailman/listinfo/ipfix
Archive:
http://www1.ietf.org/mail-archive/web/ipfix/current/index.html

Editor:
Thomas Dietz
NEC Europe Ltd.
NEC Laboratories Europe
Network Research Division
Kurfuersten-Anlage 36
69115 Heidelberg
Germany
Phone: +49 6221 4342-128
Email: Thomas.Dietz@nw.neclab.eu

Atsushi Kobayashi
NTT Information Sharing Platform Laboratories
3-9-11 Midori-cho
Musashino-shi
180-8585
Japan
Phone: +81-422-59-3978
Email: akoba@nttv6.net

Benoit Claise
Cisco Systems, Inc.
De Kleetlaan 6a b1
Degem 1831
Belgium
Phone: +32 2 704 5622
Email: bclaise@cisco.com

Gerhard Muenz
Technische Universitaet Muenchen
Department of Informatics
Chair for Network Architectures and Services (I8)
Boltzmannstr. 3
85748 Garching
Germany
Phone: +49 89 289-18008
Email: muenz@net.in.tum.de
URI: http://www.net.in.tum.de/~muenz"
DESCRIPTION
"The IPFIX SELECTOR MIB module defines the standard
filtering and sampling functions that can be referenced in
the ipfixSelectorTable of the IPFIX MIB. The subtree
ipfixSelectorFunctions is a placeholder where all standard
filtering and sampling functions should be located.

The IPFIX SELECTOR MIB module is maintained by IANA and can
be extended through Expert Review [RFC5226], i.e. review by
one of a group of experts designated by an IETF Area
Director. The group of experts MUST check the requested MIB
objects for completeness and accuracy of the description.
Requests for MIB objects that duplicate the functionality of
existing objects SHOULD be declined. The smallest available
OID SHOULD be assigned to a new MIB objects. The
specification of new MIB objects SHOULD follow the structure
specified in RFC-ipfix-mib-08 and MUST be published using a
well-established and persistent publication medium. The
experts will initially be drawn from the Working Group
Chairs and document editors of the IPFIX and PSAMP Working
Groups.

Copyright (c) 2009 IETF Trust and the persons identified as
the document authors. All rights reserved. This version
of this MIB module is part of RFC-ipfix-mib-08; see the RFC itself
for full legal notices."

-- Revision history

REVISION "200906020900Z" -- 02 June 2009
DESCRIPTION
"Initial version, published as RFC-ipfix-mib-08."

::= { mib-2 zzz }
-- zzz to be assigned by IANA.

--******************************************************************
-- Top Level Structure of the MIB
--******************************************************************

ipfixSelectorObjects OBJECT IDENTIFIER
::= { ipfixSelectorMIB 1 }
ipfixSelectorConformance OBJECT IDENTIFIER
::= { ipfixSelectorMIB 2 }

--==================================================================
-- 1: Objects used by all IPFIX implementations
--==================================================================
--------------------------------------------------------------------
-- 1.1: Packet Selector Functions for IPFIX
--------------------------------------------------------------------
ipfixSelectorFunctions OBJECT IDENTIFIER
::= { ipfixSelectorObjects 1 }

--------------------------------------------------------------------
-- 1.1.1: Function 1: Selecting All Packets
--------------------------------------------------------------------
ipfixFuncSelectAll OBJECT IDENTIFIER
::= { ipfixSelectorFunctions 1 }

ipfixFuncSelectAllAvail OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object indicates the availability of the trivial
function of selecting all packets. This function is always
available."
::= { ipfixFuncSelectAll 1 }

--==================================================================
-- 2: Conformance Information
--==================================================================
ipfixSelectorCompliances OBJECT IDENTIFIER
::= { ipfixSelectorConformance 1 }
ipfixSelectorGroups OBJECT IDENTIFIER
::= { ipfixSelectorConformance 2 }

--------------------------------------------------------------------
-- 2.1: Compliance Statements
--------------------------------------------------------------------
ipfixSelectorBasicCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"An implementation that builds an IPFIX Exporter that
complies to this module MUST implement the objects defined
in the mandatory group ipfixBasicGroup. The implementation
of all other objects depends on the implementation of the
corresponding functionality in the equipment."
MODULE -- this module
MANDATORY-GROUPS {
ipfixSelectorBasicGroup
}
::= { ipfixSelectorCompliances 1 }

--------------------------------------------------------------------
-- 2.2: MIB Grouping
--------------------------------------------------------------------
ipfixSelectorBasicGroup OBJECT-GROUP
OBJECTS {
ipfixFuncSelectAllAvail
}
STATUS current
DESCRIPTION
"The main IPFIX objects."
::= { ipfixSelectorGroups 1 }

END


We understand the above to be the only IANA Actions for this document.

[Ballot comment]
5.3.  The Template Definition Table

    ipfixTemplateDefinitionTable (4)
    |
    +- ipfixTemplateDefinitionEntry (1)
      |
      +- index (5) (ipfixTransportSessionIndex)
          +- index (3) (ipfixTemplateObservationDomainId)
            + index (257) (ipfixTemplateId)
              +- index (1) (ipfixTemplateDefinitionIndex)
              |  +- ipfixTemplateDefinitionIndex (1) = 1
              |  +- ipfixTemplateDefinitionIeId (2) = 158
              |  |                      (flowStartDeltaMicroseconds)
              |  +- ipfixTemplateDefinitionIeLength (3) = 4
              |  +- ipfixTemplateDefinitionEnterprise (4) = 0
              |  +- ipfixTemplateDefinitionFlags (5) = 0
              |
              +- index (2) (ipfixTemplateDefinitionIndex)
              |  +- ipfixTemplateDefinitionIndex (1) = 2
              |  +- ipfixTemplateDefinitionIeId (2) = 159
              |  |                      (flowStartDeltaMicroseconds)

flowStartDeltaMicroseconds is listed twice (for 158 and for 159). This looks wrong.

[Ballot comment]
5.3.  The Template Definition Table

  The Template Definition table lists all the Information Elements
  contained in a Template or Options Template.  Therefore it has the
  same indexes as the corresponding Template table plus the Template
  Id.  Its own index denotes the order of the Information Element
  inside the Template.  Besides the Information Element Id and the
  length of the encoded value the table contains the enterprise number
  for enterprise specific Information Elements and flags for each
  Information Element.  The flags indicate if the Information Element
  is used for scoping or as a Flow Key.

  To resume the above example again the Exporter is configured to
  export the octets received and dropped at the Observation Point since
  the last export of these values.  In addition it exports the start
  and end time of the flow relative to the timestamp contained in the
  IPFIX header.  This leads to the following Template Definition table
  on the Exporter:










Dietz, et al.          draft-ietf-ipfix-mib-09.txt            [Page 12]
?
Internet-Draft                  IPFIX MIB                  December 2009


    ipfixTemplateDefinitionTable (4)
    |
    +- ipfixTemplateDefinitionEntry (1)
      |
      +- index (5) (ipfixTransportSessionIndex)
          +- index (3) (ipfixTemplateObservationDomainId)
            + index (257) (ipfixTemplateId)
              +- index (1) (ipfixTemplateDefinitionIndex)
              |  +- ipfixTemplateDefinitionIndex (1) = 1
              |  +- ipfixTemplateDefinitionIeId (2) = 158
              |  |                      (flowStartDeltaMicroseconds)
              |  +- ipfixTemplateDefinitionIeLength (3) = 4
              |  +- ipfixTemplateDefinitionEnterprise (4) = 0
              |  +- ipfixTemplateDefinitionFlags (5) = 0
              |
              +- index (2) (ipfixTemplateDefinitionIndex)
              |  +- ipfixTemplateDefinitionIndex (1) = 2
              |  +- ipfixTemplateDefinitionIeId (2) = 159
              |  |                      (flowStartDeltaMicroseconds)

flowStartDeltaMicroseconds is listed twice (for 158 and for 159). This looks wrong.

Moved to the agenda of the 12/17 telechat. The WG chairs and the document editor asked for a new version to be issued before the document is discussed in the telechat.

[Ballot comment]
Just a couple of minor issues for you to think about if the I-D is revised or during AUTH-48.

---

Use of citations within REFERENCE clauses.
I think you should not use square brackets for referenced documents
inside the MIB module itself. Just remove the [], but you may need to
fix up some text elsewhere to ensure that the referenced documents
are cited from somewhere int he document.

---

Section 5.3
Right at the end of the example in the section you have:
                  +- ipfixTemplateDefinitionEnterprise (5) = 0
                  +- ipfixTemplateDefinitionFlags (4) = 0
The OIDs are reversed.

---
ipfixTemplateDefinitionFlags

You have...

  Thus we get the following values for an Information Element:

  '0'H
      The Information Element is neither used for scoping nor
      as Flow Key.
  '1'H (scope)
      The Information Element is used for scoping.
  '2'H (flowKey)
      The Information Element is used as Flow Key.
  '3'H (scope | flowKey)
      This combination is not allowed."

I know what you are trying to say, but ipfixTemplateDefinitionFlags has
SYNTAX BITS and you can't convert that into hex (if you had wanted to
you could have used SYNTAX INTEGER).

I think you just have to rephrase this in terms of bits.

Gen-ART review from Brian Carpenter:

Summary:  Ready
--------

Comments:
---------

The technical description is clear and did not raise any questions in my
mind. I did not check the MIB module in detail.


Editorial issues:
-----------------

I question whether this document really needs the pre-5378
disclaimer ("This document may contain material from IETF Documents
or IETF Contributions published or made publicly available before
November 10, 2008..."). There is nothing in the Acknowledgments
or anywhere else to suggest that it incorporates any such text.
So why is it there?

This could matter, since a reader who doesn't actually understand
the rules in detail might conclude that extracting the MIB text and
including it in a product is not allowed, whereas *every* version
of the IETF copyright rules has allowed this. It would be better
if the disclaimer can be dropped from the RFC.

  == Outdated reference: draft-ietf-ipfix-architecture has been published as
    RFC 5470

  == Outdated reference: draft-ietf-ipfix-as has been published as RFC 5472

  == Outdated reference: draft-ietf-psamp-framework has been published as RFC
    5474

  == Outdated reference: draft-ietf-psamp-sample-tech has been published as
    RFC 5475

  == Outdated reference: draft-ietf-psamp-protocol has been published as RFC
    5476

IANA comments:

Upon approval of this document, IANA will make the following
assignment in the "iso.org.dod.internet.mgmt.mib-2 (1.3.6.1.2.1)"
registry at
http://www.iana.org/assignments/smi-numbers

Decimal Name Description References
------- ---- ----------- ----------
[tbd] ipfixMIB IP Flow Information Export MIB [RFC-ipfix-mib-06]

We understand the above to be the only IANA Action for this document.

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

Juergen Quittek is the document shepherd. He has reviewed it personally
and believes that this version is ready for forwarding to the IESG
for publication.

(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?

The document had multiple individual reviews from key WG members.
The shepherd has no concern about the depth or breadth of the reviews.

(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization, or XML?

The document shepherd sees no need for an additional particular review
except that a review by a MIB doctor is required.

(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he
or she is uncomfortable with certain parts of the document, or
has concerns whether there really is a need for it. In any
event, if the WG has discussed those issues and has indicated
that it still wishes to advance the document, detail those
concerns here. Has an IPR disclosure related to this document
been filed? If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on
this issue.

There is no such concern.

(1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

There is a strong consensus in the IPFIX WG to publish this version
of the document. There are no particular issues in the document
without strong consensus in the IPFIX WG.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarize the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is
entered into the ID Tracker.)

There was no appeal.

(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See
http://www.ietf.org/ID-Checklist.html and
http://tools.ietf.org/tools/idnits/.) Boilerplate checks are
not enough; this check needs to be thorough. Has the document
met all formal review criteria it needs to, such as the MIB
Doctor, media type, and URI type reviews? If the document
does not already indicate its intended status at the top of
the first page, please indicate the intended status here.

The document shepherd checked for ID nits and validated the contained SMI
section with smilint. No issues have been found.

(1.h) Has the document split its references into normative and
informative? Are there normative references to documents that
are not ready for advancement or are otherwise in an unclear
state? If such normative references exist, what is the
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

One reference has been outdated since the document was submitted:
RFC 2434 has recently been obsoleted by RFC 5226. This should be fixed
after IETF last call. More references may be obsoleted by then.

(1.i) Has the Document Shepherd verified that the document's IANA
Considerations section exists and is consistent with the body
of the document? If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified? If
the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggest a
reasonable name for the new registry? See [RFC2434]. If the
document describes an Expert Review process, has the Document
Shepherd conferred with the Responsible Area Director so that
the IESG can appoint the needed Expert during IESG Evaluation?

IANA considerations have been checked.

(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?

Yes. The contained MIB module has been checked with smilint.

(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Write-Up. Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary

This document defines managed objects for IP Flow Information Export
(IPFIX). These objects provide information for monitoring IPFIX
Exporters and IPFIX Collectors including the basic configuration
information.


Working Group Summary

This work originates from the PSAMP MIB module. The PSAMP WG had MIB
development already chartered when there was no such plan in the
IPFIX WG. But after the first versions of the PSAMP MIB module had
been discussed it became clear that a lot of its content should
rather be part of an IPFIX MIB module than of a PSAMP MIB module.
Therefore, the IPFIX WG got a MIB module into its charter and took
over most of the content of the former PSAMP MIB. The PSAMP MIB
module is to be completed after the completions of the IPFIX MIB
module.

Document Quality

The document underwent several reviews and two WG last calls in
the IPFIX WG. This way, a high document quality has been achieved
already. Still a review by a MIB doctor would be desirable.

Personnel

Juergen Quittek is shepherding this document. Dan Romascanu is the
responsible Area director.