Re: [IPFIX] review of draft-ietf-ipfix-mib-variable-export-07

Juergen, I don't usually follow examples since I'm usually wondering what happens if I *don't* do what it says...

However I'll change the example for the sake of those who do.

Thanks,
P.

> -----Original Message-----
> From: Juergen Schoenwaelder [mailto:[email protected]]
> Sent: 05 January 2015 15:20
> To: Paul Aitken
> Cc: [email protected]
> Subject: Re: [IPFIX] review of draft-ietf-ipfix-mib-variable-export-07
> 
> Paul,
> 
> I think the example should either be a real-world example or there needs to be a
> clear warning somewhere that this example is not a real-world example in order
> to prevent people from coding along the example and then coming up with ideas
> such as white space padding interface names to make them fixed-length 16
> octets long. There are programmers who code along examples instead of
> reading the underlying specifications and they sometimes end up being (too)
> creative.
> 
> I guess my preference is to show a realistic example but if I am the only one,
> then of course I will go along with what we have (but I would appreciate that
> there is a warning somewhere that this example makes simplifying assumptions).
> 
> /js
> 
> On Mon, Jan 05, 2015 at 11:09:14AM +0100, Paul Aitken wrote:
> > Juergen, thanks for your careful review and all your feedback. I've addressed
> all your points except one:
> >
> >     - p46: Why is the Field Length of mibObjectValueOctetString set to 16?
> >            The interface names in general have variable length.
> >
> > Fixed length is used to simplify the example data record in figure 31.
> >
> > Although interfaces generally do have variable length names, I believe the
> example is clearer with fixed length fields.
> >
> > Changing to variable length would be straightforward if the consensus is that
> it's more realistic example.
> >
> > P.
> >
> >
> > > -----Original Message-----
> > > From: IPFIX [mailto:[email protected]] On Behalf Of Juergen
> > > Schoenwaelder
> > > Sent: 17 December 2014 14:19
> > > To: [email protected]
> > > Subject: [IPFIX] review of draft-ietf-ipfix-mib-variable-export-07
> > >
> > > Hi,
> > >
> > > here is my review of draft-ietf-ipfix-mib-variable-export-07. Most
> > > of the comments are editorial or bug fixes. There is only one real
> > > technical concern related to the encoding of BITS. The current I-D
> > > uses a 64-bit unsigned integer, which limits things to 64 bit
> > > positions. The SMIv2 does not have this limit - it only warns about bit
> positions in excess of 128.
> > >
> > > - RFC4293 is listed as a normative reference but as far as I can tell
> > >   it is only used in an example. I suggest to make this an informative
> > >   reference.
> > >
> > > - p3: 2nd paragraph Introduction: I am not sure the statement "there
> > >   are no dependencies between the SMIv2 and the SNMP protocol" is
> > >   correct.  Perhaps the simplest fix is to simply delete the whole
> > >   paragraph.
> > >
> > > - p4: 1st paragraph Motivation: The 2nd sentence is hard to follow.
> > >
> > > - p5: s/does not specify SNMP notifications/does not specify how to
> > >   carry SNMP notifications in IPFIX/
> > >
> > > - p9: s/in a certain MIB/in a certain MIB module/
> > >
> > > - p10: s/may be also be/may also be/
> > >
> > > - p10: s/described by the MIB./described by the MIB module./
> > >
> > > - p14: s/when when/when/
> > >
> > > - p14: s/references sections/referenced sections/
> > >
> > >   The fact that every listed item refers to two sections may be a bit
> > >   confusing, perhaps change to
> > >
> > >   o  mibIndexIndicator (defined in Section 5.8.5, example in Section
> > > 11.2.2.3)
> > >
> > > - p20: It took me a while to spot the difference between Fig. 7 and
> > >   Fig.8 (I did not immediately spot that the fields are
> > >   swapped). Perhaps mention this more explicitly in the last paragraph
> > >   on p19?
> > >
> > >      Figure 7 shows an IPFIX Options Template Set using Scope Existing
> > >      IFPIX IE and a Non Scope mibObjectValueInteger IE, while Figure 8
> > >      shows an IPFIX Options Template Set using a Scope
> > >      mibObjectValueInteger IE and a Non Scope Existing IFPIX IE.
> > >
> > > - p12: s/name of the MIB/name of the MIB module/
> > >
> > > - p26: s/present the same order/present in the same order/
> > >
> > > - p32: s/not defined as possible/not possible/
> > >
> > > - p37: s/CISCO-PROCESS_MIB/CISCO-PROCESS-MIB/
> > >
> > > - p45: s/ifMTU/ifMtu/ (this shows up several time, do a global
> > > replace)
> > >
> > > - p46: Why is the Field Length of mibObjectValueOctetString set to 16?
> > >        The interface names in general have variable length.
> > >
> > > - p47: why 'ifName = ""'?
> > >
> > > - p52: s/index by IEs:/indexed by IEs:/
> > >
> > > - p58: The VLEN and the OID value seem to be wrong. I think this should
> > >        be VLEN=10 and the OID value 06082B060102010E0A01.
> > >
> > > - p61: I would have named SNMPtotalCounter simply snmpCounter and I
> > >        would have named SNMPgauge snmpGauge. If this change is
> > >        adopted, then these names needs to be changed in several
> > >        places.
> > >
> > > - p64: The encoding of mibObjectValueBits may need to specify how the
> > >        bit positions are counted. That said, there is an issue here
> > >        with using unsigned64. RFC 2578 does not restrict the bit
> > >        positions, it only warns that using bit positions in excess of
> > >        128 may cause interoperability problems. The IPFIX I-D
> > >        essentially limits this to 64 bits. The obvious solution is to
> > >        follow the SNMP encoding rules that encode bits into an octet
> > >        string (an octetArray in IPFIX speak).
> > >
> > > - p67: s/as defined in a MIB//
> > >
> > > - p68: OLD
> > >
> > >        Description: A non-negative sub-identifier.  One Sub number from
> > >        an Object Identifier (OID).
> > >
> > >        NEW
> > >
> > >        Description: A non-negative sub-identifier of an Object
> > >        Identifier (OID).
> > >
> > > - p69: s/was retrieved from SNMP/was retrieved from the MIB/
> > >
> > > - p70: s/could be sampled by SNMP/has been sampled/
> > >
> > > - p70: s/SNMP sampling time/sampling time/
> > >
> > > /js
> > >
> > > --
> > > Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> > > Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
> > > Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
> > >
> > > _______________________________________________
> > > IPFIX mailing list
> > > [email protected]
> > > https://www.ietf.org/mailman/listinfo/ipfix
> 
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
> Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

_______________________________________________
IPFIX mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipfix