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

"Romascanu, Dan (Dan)" <dromasca@avaya.com> Thu, 07 July 2011 09:59 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 02EBD21F87CA for <ipfix@ietfa.amsl.com>; Thu, 7 Jul 2011 02:59:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.033
X-Spam-Level:
X-Spam-Status: No, score=-103.033 tagged_above=-999 required=5 tests=[AWL=0.566, 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 Lsk1XpX-+a3k for <ipfix@ietfa.amsl.com>; Thu, 7 Jul 2011 02:59:33 -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 D185521F87B2 for <ipfix@ietf.org>; Thu, 7 Jul 2011 02:59:32 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgoBAKeCFU6HCzI1/2dsb2JhbABTmGWPNHexHAKbGIY4BJdhiyg
X-IronPort-AV: E=Sophos;i="4.65,492,1304308800"; d="scan'208";a="255300558"
Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 07 Jul 2011 05:59:30 -0400
Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.10]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 07 Jul 2011 05:52:39 -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: Thu, 7 Jul 2011 11:59:26 +0200
Message-ID: <EDC652A26FB23C4EB6384A4584434A040358E429@307622ANEX5.global.avaya.com>
In-Reply-To: <4E14E0B4.8000509@net.in.tum.de>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [IPFIX] AD review of draft-ietf-ipfix-configuration-model-09.txt
Thread-Index: Acw8K5ItQPFR9sUETp6A/b1fj+hQUAAYJbaA
References: <EDC652A26FB23C4EB6384A4584434A0403328F9C@307622ANEX5.global.avaya.com> <4E14E0B4.8000509@net.in.tum.de>
From: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
To: "Gerhard Muenz" <muenz@net.in.tum.de>
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: Thu, 07 Jul 2011 09:59:34 -0000

Hi Gerhard, 


Thank you for the answers and for addressing my comments. The proposed
changes are fine. 

Can you issue the revised I-D before the submission deadline on Monday,
so that I can place the document on the agenda of the 7/14 IESG
telechat? 

Regards,

Dan 
> -----Original Message-----
> From: Gerhard Muenz [mailto:muenz@net.in.tum.de]
> Sent: Thursday, July 07, 2011 1:25 AM
> To: Romascanu, Dan (Dan)
> Cc: IPFIX Working Group
> Subject: Re: [IPFIX] AD review of
draft-ietf-ipfix-configuration-model-
> 09.txt
> 
> 
> 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