[IPFIX] AD review of draft-ietf-ipfix-configuration-model-09.txt

"Romascanu, Dan (Dan)" <dromasca@avaya.com> Wed, 01 June 2011 15:39 UTC

Return-Path: <dromasca@avaya.com>
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 48836E08F4 for <ipfix@ietfa.amsl.com>; Wed, 1 Jun 2011 08:39:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.253
X-Spam-Status: No, score=-103.253 tagged_above=-999 required=5 tests=[AWL=0.346, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id noME7aMF9qB7 for <ipfix@ietfa.amsl.com>; Wed, 1 Jun 2011 08:39:55 -0700 (PDT)
Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com []) by ietfa.amsl.com (Postfix) with ESMTP id 5D554E08E8 for <ipfix@ietf.org>; Wed, 1 Jun 2011 08:39:55 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EADxc5k2HCzI1/2dsb2JhbABTpiR3qC+DWgKbE4YgBJU1ik0
X-IronPort-AV: E=Sophos;i="4.65,303,1304308800"; d="scan'208";a="249287501"
Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([]) by de307622-de-outbound.net.avaya.com with ESMTP; 01 Jun 2011 11:39:53 -0400
X-IronPort-AV: E=Sophos;i="4.65,303,1304308800"; d="scan'208";a="658443638"
Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 01 Jun 2011 11:39:52 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 1 Jun 2011 17:39:51 +0200
Message-ID: <EDC652A26FB23C4EB6384A4584434A0403328F9C@307622ANEX5.global.avaya.com>
Thread-Topic: AD review of draft-ietf-ipfix-configuration-model-09.txt
Thread-Index: AcwgciV7zMizbAuASkCAs/BaNPh4Cw==
From: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
To: "IPFIX Working Group" <ipfix@ietf.org>
Subject: [IPFIX] AD review of draft-ietf-ipfix-configuration-model-09.txt
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
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: Wed, 01 Jun 2011 15:39:56 -0000


I performed the AD review of
draft-ietf-ipfix-configuration-model-09.txt. This document is in good
shape and I am sending it to IETF Last Call. Please consider the
comments below together with the other IETF Last Call comments. 

Technical Comments are marked T and Editorial comments are marked R. 

T1. Section 4.2.2 - how is probability expressed - as a value between 0
and 1?

T2. Section 4.7: 

   If SCTP is transport protocol, Exporter or
   Collector may be multi-homed SCTP endpoints (see [RFC4960], Section
   6.4) and use more than one IP address.

A capitalized 2119 MAY seems to be appropriate here. 

E1. In Section 4.1: 

   However, indexes SHOULD only be used as identifiers if
   an SNMP agent on the same Monitoring Device enables access to the
   corresponding MIB objects.

s/MIB objects/MIB tables/ 


      ifIndex SHOULD only be used if an SNMP agent enables
      access to the corresponding MIB object in the ifTable.
      Similarly, a physical entity is either identified by its name
      (entPhysicalName) or the entPhysicalIndex value of the
      corresponding object in the ENTITY-MIB module [RFC4133].
      entPhysicalIndex SHOULD only be used if an SNMP agent enables
      access to the corresponding MIB object in the entPhysicalTable.

Indices are by definition not-accessible, but accessing the tables that
they index should be sufficient as the index can be extracted from the
OIDs of the objects in the table. 

E2. In section 4.3

cacheDiscontinuityTime:  Timestamp of the most recent occasion at
      which dataRecords suffered a discontinuity.  In contrast to
      ipfixMeteringProcessDiscontinuityTime, the time is absolute and
      not relative to sysUpTime.
      Note that this parameter corresponds to
      ipfixMeteringProcessDiscontinuityTime in the IPFIX MIB module

Better say 'functionally corresponds' ...

Thanks and Regards,