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

"Romascanu, Dan (Dan)" <dromasca@avaya.com> Mon, 11 July 2011 09:05 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 8FB1121F88D5 for <ipfix@ietfa.amsl.com>; Mon, 11 Jul 2011 02:05:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.147
X-Spam-Level:
X-Spam-Status: No, score=-103.147 tagged_above=-999 required=5 tests=[AWL=0.452, 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 pjmwG4K0EU-u for <ipfix@ietfa.amsl.com>; Mon, 11 Jul 2011 02:05:15 -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 2A0B321F8893 for <ipfix@ietf.org>; Mon, 11 Jul 2011 02:05:15 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvIAALe7Gk7GmAcF/2dsb2JhbABTmAmPN3ereAKaeIVbXwSXb4su
X-IronPort-AV: E=Sophos;i="4.65,514,1304308800"; d="scan'208";a="255883452"
Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 11 Jul 2011 05:05:13 -0400
Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.10]) by co300216-co-erhwest-out.avaya.com with ESMTP; 11 Jul 2011 05:03:43 -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: Mon, 11 Jul 2011 11:05:10 +0200
Message-ID: <EDC652A26FB23C4EB6384A4584434A040358EA30@307622ANEX5.global.avaya.com>
In-Reply-To: <EDC652A26FB23C4EB6384A4584434A040358E429@307622ANEX5.global.avaya.com>
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+hQUAAYJbaAAMcsVkA=
References: <EDC652A26FB23C4EB6384A4584434A0403328F9C@307622ANEX5.global.avaya.com><4E14E0B4.8000509@net.in.tum.de> <EDC652A26FB23C4EB6384A4584434A040358E429@307622ANEX5.global.avaya.com>
From: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
To: "Romascanu, Dan (Dan)" <dromasca@avaya.com>, "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: Mon, 11 Jul 2011 09:05:16 -0000

Hi Gerhard, 

Please make sure that the updated version will be submitted today before
the pre-IETF Internet Draft final submission cut-off by 17:00 PT (00:00
UTC). If a revised version of the document is not submitted today I will
need to mover the document from the agenda of the IESG telechat of this
week to the next one which will take place only after the IETF meeting. 

Thanks and Regards,

Dan 

> -----Original Message-----
> From: ipfix-bounces@ietf.org [mailto:ipfix-bounces@ietf.org] On Behalf
> Of Romascanu, Dan (Dan)
> Sent: Thursday, July 07, 2011 12:59 PM
> To: Gerhard Muenz
> Cc: IPFIX Working Group
> Subject: Re: [IPFIX] AD review of
draft-ietf-ipfix-configuration-model-
> 09.txt
> 
> 
> 
> 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
> _______________________________________________
> IPFIX mailing list
> IPFIX@ietf.org
> https://www.ietf.org/mailman/listinfo/ipfix