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

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