[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 [127.0.0.1]) 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-Level:
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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (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 [198.152.71.100]) 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) ([135.11.50.53]) 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) ([135.64.140.11]) 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, 01 Jun 2011 17:39:51 +0200
Message-ID: <EDC652A26FB23C4EB6384A4584434A0403328F9C@307622ANEX5.global.avaya.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
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

Hi, 

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/indexes/indices/
s/MIB objects/MIB tables/ 

Similarly 

      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
      [RFC5815].

Better say 'functionally corresponds' ...



Thanks and Regards,

Dan