Re: [IPFIX] WGLC for draft-ietf-ipfix-mib-variable-export-05

Benoit Claise <bclaise@cisco.com> Fri, 25 April 2014 13:32 UTC

Return-Path: <bclaise@cisco.com>
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D68F1A0494 for <ipfix@ietfa.amsl.com>; Fri, 25 Apr 2014 06:32:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.772
X-Spam-Level:
X-Spam-Status: No, score=-8.772 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_SUMOF=1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qe61p-K0tHVj for <ipfix@ietfa.amsl.com>; Fri, 25 Apr 2014 06:32:21 -0700 (PDT)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id 973C41A01D1 for <ipfix@ietf.org>; Fri, 25 Apr 2014 06:32:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=37704; q=dns/txt; s=iport; t=1398432736; x=1399642336; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=KkG0fsnmQlqNdn2AXAYcLYjJiyh7qGsGlnd/EUFRaSg=; b=mm2x7qwL7TvasPK5tx9OZcDohadpNYnOLCNQQrlANi09BSnklDe27LIM 6IGXN4OsEO2vmmaQB5Xd4U9wTl7a9tN+WGgUycqNND15z7vDOEwoQozCi r0E3rkWA6TkVCF01hPqdjJPug2tfKE8fLmzC3chCiLYYniik9NIgAwUtr E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ArcEAPJiWlOtJssW/2dsb2JhbABZDoNHiRmyY4h6gSV0giUBAQEDARoDClERCw4TFgEOCQMCAQIBRQYBDAgBAYg1CA3KcReJN4UphDkBA5UTg3KBOIUjjAGCcUI7
X-IronPort-AV: E=Sophos; i="4.97,927,1389744000"; d="scan'208,217"; a="26986266"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 25 Apr 2014 13:32:14 +0000
Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s3PDWCdp017711; Fri, 25 Apr 2014 13:32:12 GMT
Message-ID: <535A63DC.3090308@cisco.com>
Date: Fri, 25 Apr 2014 15:32:12 +0200
From: Benoit Claise <bclaise@cisco.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: Nevil Brownlee <n.brownlee@auckland.ac.nz>, IPFIX Working Group <ipfix@ietf.org>
References: <534C76C7.9030108@auckland.ac.nz>
In-Reply-To: <534C76C7.9030108@auckland.ac.nz>
Content-Type: multipart/alternative; boundary="------------080804080705040804010304"
Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/yXh5eePTvqCUMOIxkAKwrUsXexc
Subject: Re: [IPFIX] WGLC for draft-ietf-ipfix-mib-variable-export-05
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IPFIX WG discussion list <ipfix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipfix>, <mailto:ipfix-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipfix/>
List-Post: <mailto:ipfix@ietf.org>
List-Help: <mailto:ipfix-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipfix>, <mailto:ipfix-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 25 Apr 2014 13:32:25 -0000

Dear all,

I stopped my review at section 4.4.2 (spent a couple of hours already), 
and I'm afraid the draft is not ready.
Here is my feedback.

- Section 1

    For example,
    in the IPFIX information model [RFC7012  <http://tools.ietf.org/html/rfc7012>], Information Elements coming
    from the SNMP world have already been specified, e.g.,
    ingressInterface and egressInterface both refer to the ifIndex
    defined in [RFC2863  <http://tools.ietf.org/html/rfc2863>].

As Jürgen noted, RFC 7012 doesn't specify the IPFIX information elements 
any longer.
This is done in the IANA registry.

- Section 2

       In the best case, assuming very tight integration of
       an IPFIX Collector with and SNMP polling engine, SNMP data is
       retrieved shortly after Data Records have been received, which
       implies a delay of the sum of the active or inactive timeouts (if
       not null) plus the time to export the Flow Record to the
       Collector.

For active and inactive timeouts, provide a reference to RFC 5470 , 
section 5.1.1. "Flow Expiration"
Even if RFC 5470 doesn't call them active and inactive timeouts (btw, 
don't change that, these are well known terms), this is a good reference.

-  Section 2

    This draft does not specify SNMP notifications, even if the
    specifications in this document could potentially allow this.

draft -> document
Same remark for:

    For each of these the options this draft specifies exactly which
    mibObjectValue to use.

    This draft defines two forms of indexing that can be used for
    SEQUENCE MIB Objects.

- Section 2

    The
    simple and application-wide data types specified in SMIv2 [RFC2578  <http://tools.ietf.org/html/rfc2578>],
    along with a new Textual Conventions

Remove the s

- Section 3

  mibObjectValue

       Refers to any and all of the mibObjectValue Information Elements
       generically.  Any restriction or requirement in this document that
       refers to mibObjectValue applies to the following Information
       Elements defined inSection 10.1  <http://tools.ietf.org/html/draft-ietf-ipfix-mib-variable-export-05#section-10.1>: mibObjectValueInteger,
       mibObjectValueOctetString, mibObjectValueOID, mibObjectValueBITS,
       mibObjectValueCounter, mibObjectValueGauge, mibObjectValueTime,
       mibObjectValueUnsigned, mibObjectValueTable and
       mibObjectValueSequence.

Change mibObjectValue to mibObjectValue Information Elements.
This is how it's used in some sentences in the rest of the document.
However, I also see:  mibObjectValue Field or mibObjectValue field
I don't know what the term field refers to. Please change this to mibObjectValue Information Elements

- Section 4

    The Exporting process MAY extract the data values for mibObjectValue
    fields from a Process that resides on the same device or MAY capture/
    create the data required to match the definition of the MIB Object.
    In particular exporting a value from a MIB does not imply that the
    SNMP process on the Device supports that MIB.
  
Why is Process capitalized?
Also MAY to may. This is not a RFC 2119 keyword required for the implementation.

- Section 4
    The main issue that arises from exporting MIBs in IPFIX is that MIB
    Object Identifiers do not fit into the standard IPFIX Template format
    [RFC7011  <http://tools.ietf.org/html/rfc7011>], as this only provides a 16-bit Information Element
    identifier and the length of the Information Element.

I would remove "and the length of the Information Element", which doesn't add anything to this sentence

- Section 4

    One approach to this problem would be to extend the IPFIX standard to
    allow extended field specifiers so metadata about Fields can be
    included in Data Templates.

Fields -> field

- Section 4

    However, future versions of IPFIX MAY export the required MIB
    metadata as part of newer set versions.

MAY -> may.
Please review all RFC 2119 keywords

- Section 4
    This is a
    standard IPFIX Option Template Set that MUST include a minimum set of
    required fields (seeSection 4.2.1  <http://tools.ietf.org/html/draft-ietf-ipfix-mib-variable-export-05#section-4.2.1>) and MAY include extra fields to
    provide more meta information about one of the mibObjectValue fields.

While you're not yet in the specifications in Section 4, I would not introduce MUST and MAY here.
This also contradicts the REQUIRED and RECOMMENDED in section 4.2.1
Please group the RFC 2119 keywords in section 4.2.1

- Throughout the document
Option Template -> Options Template
Note: IIRC, there were inconsistencies in RFC 5101, which were corrected in RFC 7011

- Major issue: I confused by mibFieldOption
Is this a IE or an Options Template?

The TOC shows:
    4.2.  MIB Field Options - Specifications and Required Fields  .  11
        4.2.1  <http://tools.ietf.org/html/draft-ietf-ipfix-mib-variable-export-05#section-4.2.1>.  mibFieldOption  . . . . . . . . . . . . . . . . . . .12  <http://tools.ietf.org/html/draft-ietf-ipfix-mib-variable-export-05#page-12>
        4.2.2  <http://tools.ietf.org/html/draft-ietf-ipfix-mib-variable-export-05#section-4.2.2>.  mibSubFieldOption . . . . . . . . . . . . . . . . . .13  <http://tools.ietf.org/html/draft-ietf-ipfix-mib-variable-export-05#page-13>
        4.2.3  <http://tools.ietf.org/html/draft-ietf-ipfix-mib-variable-export-05#section-4.2.3>.  mibTypeOption . . . . . . . . . . . . . . . . . . . .13  <http://tools.ietf.org/html/draft-ietf-ipfix-mib-variable-export-05#page-13>
      4.3  <http://tools.ietf.org/html/draft-ietf-ipfix-mib-variable-export-05#section-4.3>.  IPFIX and MIB Data Model  . . . . . . . . . . . . . . . .14  <http://tools.ietf.org/html/draft-ietf-ipfix-mib-variable-export-05#page-14>
      4.4  <http://tools.ietf.org/html/draft-ietf-ipfix-mib-variable-export-05#section-4.4>.  MIB Field Option Template Formats . . . . . . . . . . . .15  <http://tools.ietf.org/html/draft-ietf-ipfix-mib-variable-export-05#page-15>
        4.4.1  <http://tools.ietf.org/html/draft-ietf-ipfix-mib-variable-export-05#section-4.4.1>.  Data Template containing a mibObject Field  . . . . .15  <http://tools.ietf.org/html/draft-ietf-ipfix-mib-variable-export-05#page-15>
        4.4.2  <http://tools.ietf.org/html/draft-ietf-ipfix-mib-variable-export-05#section-4.4.2>.  mibFieldOption Template . . . . . . . . . . . . . . .17  <http://tools.ietf.org/html/draft-ietf-ipfix-mib-variable-export-05#page-17>
        4.4.3  <http://tools.ietf.org/html/draft-ietf-ipfix-mib-variable-export-05#section-4.4.3>.  mibFieldOption Data Records . . . . . . . . . . . . .18  <http://tools.ietf.org/html/draft-ietf-ipfix-mib-variable-export-05#page-18>
        4.4.4  <http://tools.ietf.org/html/draft-ietf-ipfix-mib-variable-export-05#section-4.4.4>.  Option Template containing a mibObject Field  . . . .19  <http://tools.ietf.org/html/draft-ietf-ipfix-mib-variable-export-05#page-19>
        4.4.5  <http://tools.ietf.org/html/draft-ietf-ipfix-mib-variable-export-05#section-4.4.5>.  mibFieldOption Template with Semantics Fields . . . .20  <http://tools.ietf.org/html/draft-ietf-ipfix-mib-variable-export-05#page-20>
        4.4.6.  mibFieldOption Template with extra MIB Object Details  21

It's not clear!

   This document also defines three standard Option Templates (see
    Section 4.2  <http://tools.ietf.org/html/draft-ietf-ipfix-mib-variable-export-05#section-4.2>) that are used as part of the mechanism to export MIB
    Object meta data:

    o  mibFieldOption (Section 4.2.1  <http://tools.ietf.org/html/draft-ietf-ipfix-mib-variable-export-05#section-4.2.1>)

    o  mibSubFieldOption (Section 4.2.2  <http://tools.ietf.org/html/draft-ietf-ipfix-mib-variable-export-05#section-4.2.2>)

    o  mibTypeOption (Section 4.2.3  <http://tools.ietf.org/html/draft-ietf-ipfix-mib-variable-export-05#section-4.2.3>)

Ok, so these are Options Templates.
If this is the case, change the TOC section titles

Then I see in figure 1
                                        +------------------------+
                                        | mibFieldOptionTemplate |
                                        +------------------------+
What is a mibFieldOptionTemplate ?

    This document defines a mibFieldOption Template to export the extra
    meta information required for a mibObjectValue field.

Well, this one above is wrong. This should be Options Template, right?

Then I see
   2.  A mibFieldOption Template Set

           The mibFieldOption Template describes which metadata will be
           sent for each mibObjectValue being exported.

These should be Options Template Set, right?

Then, I look at


        4.2.1. mibFieldOption


    Three fields are REQUIRED to unambiguously export a standalone
    mibObjectValue Field with a mibFieldOption:


Then I look at


        4.4.2. mibFieldOption Template

    The mibFieldOption Template is a Standard Option Template which
    defines the Fields that will be exported to provide enough metadata
    about a mibObjectValue so that the Collector can tie the data values
    in the mibObjectValue back to the definition of the MIB Object.

And I finally understand that mibFieldOption is an Options Template.

What is very confusing to me is that mibFieldOption is apparently simply an Options Template, like we have defined in IPFIX (http://tools.ietf.org/html/rfc7011#section-4.1) or  PSAMP (http://tools.ietf.org/html/rfc5476#section-6.5.1)
However, this Options Template is called like an IPFIX IE: mibFieldOption
This should be called "MIB Field Options Template" throughout the document.

OLD:
    This document also defines three standard Option Templates (see
    Section 4.2  <http://tools.ietf.org/html/draft-ietf-ipfix-mib-variable-export-05#section-4.2>) that are used as part of the mechanism to export MIB
    Object meta data:

    o  mibFieldOption (Section 4.2.1  <http://tools.ietf.org/html/draft-ietf-ipfix-mib-variable-export-05#section-4.2.1>)

    o  mibSubFieldOption (Section 4.2.2  <http://tools.ietf.org/html/draft-ietf-ipfix-mib-variable-export-05#section-4.2.2>)

    o  mibTypeOption (Section 4.2.3  <http://tools.ietf.org/html/draft-ietf-ipfix-mib-variable-export-05#section-4.2.3>)

NEW:
    This document also defines three standard Option Templates (see
    Section 4.2  <http://tools.ietf.org/html/draft-ietf-ipfix-mib-variable-export-05#section-4.2>) that are used as part of the mechanism to export MIB
    Object meta data:

    o  MIB Field Options Template (Section 4.2.1  <http://tools.ietf.org/html/draft-ietf-ipfix-mib-variable-export-05#section-4.2.1>)

    o  MIB SubField Options Template (Section 4.2.2  <http://tools.ietf.org/html/draft-ietf-ipfix-mib-variable-export-05#section-4.2.2>)

    o  MIB Type Options Template (Section 4.2.3  <http://tools.ietf.org/html/draft-ietf-ipfix-mib-variable-export-05#section-4.2.3>)


- Major: Why do we have ...
http://tools.ietf.org/html/draft-ietf-ipfix-mib-variable-export-05#section-4.2.1
http://tools.ietf.org/html/draft-ietf-ipfix-mib-variable-export-05#section-4.4.2
... with slightly different specifications?
As I mentioned previously, there are also some conflicting spec rules at the beginning of the section 4

-

     0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Set ID = 3           |          Length = 26          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        Template ID = 258      |        Field Count = 4        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Scope field count = 2        |0| IE = templateId             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        Field Length = 2       |0| IE = informationElementIndex|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        Field Length = 2       |0| IE = mibObjectIdentifier    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        Field Length = 65535   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Figure 19: Example of tcpCurrEstab mibFieldOption Template Set

This is not an Template Set, but an Options Template Set.
Same remark for all the examples.

- Section 4.2

Why a single in this sentence?
    For each mibObjectValue field that is defined in an IPFIX Template, a
    single mibFieldOption Data Record MUST be exported that provides the
    required minimum information to define the MIB object that is being
    exported (seeSection 4.2.1  <http://tools.ietf.org/html/draft-ietf-ipfix-mib-variable-export-05#section-4.2.1>).

What if we export with UDP? We might want to re-export this metadata information, without which the collector can't interpret the data.
This contradicts:
    Note that the ID of an identical mibFieldOptionTemplate which has
    already been exported MAY be reused without exporting the Template
    again.

- Section 4.2

    This mibFieldOption Data is defined in a template referred to in this
    document as a mibFieldOption Template with the format specified in
    Section 4.4  <http://tools.ietf.org/html/draft-ietf-ipfix-mib-variable-export-05#section-4.4>.

What's mibFieldOption Data?
Template -> Options Template

- Section 4.2

   _  A Template that uses a mibObjectValue Field MUST be exported prior to
    the corresponding mibFieldOption Data Records._   It is RECOMMENDED
    that these are all exported in the same IPFIX Message.  Note that
    this places an implicit size constraint on the export.

_    These MUST all be exported prior to the corresponding Data Records
    which depend upon them._   i.e. referring to Figure 1, the export order
    MUST be:

The two underlined sentences are redundant.

- Major
    While the following are optional, they are nevertheless RECOMMENDED
    in certain circumstances as they are per field:

You don't explain those circumstances

- I arrived at section 4.3, I'm not clear when I need to use mibSubFieldOption ormibTypeOption  

For mibSubFieldOption, this only thing I read so far is:
    To export a mibObjectValue that is contained in a
    mibObjectValueSequence Field with a mibSubFieldOption three fields
    are REQUIRED:

Not too clear.

- Major, Section 4.4.1

    Multiple
    mibFieldOption that refer to a single mibObjectValue MUST NOT be
    exported.

What is Multiple mibFieldOption?
Multiple Data Records. No
Multiple different Data Records. I agree
Multiple Options Template Records. No
Multiple different Options Template Records. I agree
  
- Major, Section 4.4.1

OLD:
     0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Set ID = 2           |          Length               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       Template ID             |         Field Count = 2       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0| IE = Existing IPFIX Field   |        Field Length           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0| IE = mibObjectValueInteger  |        Field Length (mib)     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

           Figure 5: IPFIX Template Set using mibObjectValue Field


NEW:
     0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Set ID = 2           |          Length               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       Template ID             |         Field Count = 2       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0| IE = Existing IPFIX Field   |        Field Length           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0| IE = <mibObjectValue>      |        Field Length (mib)     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

           Figure 5: IPFIX Template Set using mibObjectValue Field

Then you have to explain that <mibObjectValue> could be
      mibObjectValueInteger,
       mibObjectValueOctetString, mibObjectValueOID, mibObjectValueBITS,
       mibObjectValueCounter, mibObjectValueGauge, mibObjectValueTime,
       mibObjectValueUnsigned, mibObjectValueTable and
       mibObjectValueSequence.


I stopped my review at section 4.4.2, but plenty of my feedback would apparently be equivalent for the rest of the draft.


Regards, Benoit


>
> Hi all:
>
> Sorry to be a little slow with this - the dust has settled from IETF-89,
> and I've almost managed to catch up.
>
> The WG Last Call for our MIB Variable Export draft starts now,
> and will end on Wednesday, 30 April.
>
> Please read it, and - better still - post reviews of it to the IPFIX 
> list!
>
> Cheers, Nevil
>