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

Gerhard Muenz <muenz@net.in.tum.de> Wed, 06 July 2011 22:25 UTC

Return-Path: <muenz@net.in.tum.de>
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 06E8121F8AF2 for <ipfix@ietfa.amsl.com>; Wed, 6 Jul 2011 15:25:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Level:
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35]
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 RslugNjM9CZA for <ipfix@ietfa.amsl.com>; Wed, 6 Jul 2011 15:25:08 -0700 (PDT)
Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) by ietfa.amsl.com (Postfix) with ESMTP id 5F44621F8AEB for <ipfix@ietf.org>; Wed, 6 Jul 2011 15:25:08 -0700 (PDT)
Received: from [131.159.20.248] (vpn-4.net.in.tum.de [131.159.20.248]) by mail.net.in.tum.de (Postfix) with ESMTPSA id 10FAA2088DD5; Thu, 7 Jul 2011 00:28:00 +0200 (CEST)
Message-ID: <4E14E0B4.8000509@net.in.tum.de>
Date: Thu, 07 Jul 2011 00:24:52 +0200
From: Gerhard Muenz <muenz@net.in.tum.de>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
References: <EDC652A26FB23C4EB6384A4584434A0403328F9C@307622ANEX5.global.avaya.com>
In-Reply-To: <EDC652A26FB23C4EB6384A4584434A0403328F9C@307622ANEX5.global.avaya.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: IPFIX Working Group <ipfix@ietf.org>
Subject: Re: [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, 06 Jul 2011 22:25:09 -0000

Dan,

Please find my replies inline.

On 01.06.2011 17:39, Romascanu, Dan (Dan) wrote:
> 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?

I have added the following sentence:
"The probability is 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.

Changed.

> 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.

Changed as follows:

       "ifIndex SHOULD only be used if an SNMP agent enables
       access to 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 entPhysicalTable."

I hope that this is what you suggested.

> 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' ...

Changed. I also adopted this wording in the YANG descriptions.

Thanks,
Gerhard

> Thanks and Regards,
>
> Dan
>
> _______________________________________________
> IPFIX mailing list
> IPFIX@ietf.org
> https://www.ietf.org/mailman/listinfo/ipfix