Re: [IPFIX] review of draft-ietf-ipfix-mib-variable-export-07
Paul Aitken <paitken@Brocade.com> Tue, 06 January 2015 10:40 UTC
Return-Path: <paitken@Brocade.com>
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E82391A9148 for <ipfix@ietfa.amsl.com>; Tue, 6 Jan 2015 02:40:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.267
X-Spam-Level:
X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1xT2_zwCaoT7 for <ipfix@ietfa.amsl.com>; Tue, 6 Jan 2015 02:40:05 -0800 (PST)
Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [67.231.144.122]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BF8A1A912C for <ipfix@ietf.org>; Tue, 6 Jan 2015 02:40:05 -0800 (PST)
Received: from pps.filterd (m0048193 [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.14.5/8.14.5) with SMTP id t06A0jDX005130; Tue, 6 Jan 2015 02:39:55 -0800
Received: from brmwp-exchub02.corp.brocade.com ([208.47.132.227]) by mx0a-000f0801.pphosted.com with ESMTP id 1rqruk3gdr-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 06 Jan 2015 02:39:54 -0800
Received: from BRMWP-EXMB12.corp.brocade.com (172.16.59.130) by BRMWP-EXCHUB02.corp.brocade.com (172.16.187.99) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 6 Jan 2015 03:39:42 -0700
Received: from EMEAWP-CASH01.corp.brocade.com (172.29.18.10) by BRMWP-EXMB12.corp.brocade.com (172.16.59.130) with Microsoft SMTP Server (TLS) id 15.0.995.29; Tue, 6 Jan 2015 03:39:41 -0700
Received: from EMEA-EXCH01.corp.brocade.com ([fe80::18c9:7b21:74fd:7e48]) by EMEAWP-CASH01.corp.brocade.com ([::1]) with mapi; Tue, 6 Jan 2015 11:39:39 +0100
From: Paul Aitken <paitken@Brocade.com>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
Date: Tue, 06 Jan 2015 11:39:38 +0100
Thread-Topic: [IPFIX] review of draft-ietf-ipfix-mib-variable-export-07
Thread-Index: AdAo+w6yauHZXIbtTFSrXi64X3RftwAnuPWg
Message-ID: <23B7BE54EACBED43957AB709C564F7B70185A1FB01@EMEA-EXCH01.corp.brocade.com>
References: <20141217141829.GA67945@elstar.local> <23B7BE54EACBED43957AB709C564F7B701857F40D7@EMEA-EXCH01.corp.brocade.com> <20150105151940.GA8035@elstar.local>
In-Reply-To: <20150105151940.GA8035@elstar.local>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2015-01-06_04:2015-01-06,2015-01-06,1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1501060102
Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/rGD5ibiK4E1y8DLVRy8E0i3lT2E
Cc: "ipfix@ietf.org" <ipfix@ietf.org>
Subject: Re: [IPFIX] review of draft-ietf-ipfix-mib-variable-export-07
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.15
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: Tue, 06 Jan 2015 10:40:08 -0000
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:j.schoenwaelder@jacobs-university.de] > Sent: 05 January 2015 15:20 > To: Paul Aitken > Cc: ipfix@ietf.org > 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:ipfix-bounces@ietf.org] On Behalf Of Juergen > > > Schoenwaelder > > > Sent: 17 December 2014 14:19 > > > To: ipfix@ietf.org > > > 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 > > > IPFIX@ietf.org > > > 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] review of draft-ietf-ipfix-mib-variable-e… Juergen Schoenwaelder
- Re: [IPFIX] review of draft-ietf-ipfix-mib-variab… Paul Aitken
- Re: [IPFIX] review of draft-ietf-ipfix-mib-variab… Juergen Schoenwaelder
- Re: [IPFIX] review of draft-ietf-ipfix-mib-variab… Brian Trammell
- Re: [IPFIX] review of draft-ietf-ipfix-mib-variab… Paul Aitken
- Re: [IPFIX] review of draft-ietf-ipfix-mib-variab… Paul Aitken
- Re: [IPFIX] review of draft-ietf-ipfix-mib-variab… Juergen Schoenwaelder
- Re: [IPFIX] review of draft-ietf-ipfix-mib-variab… Paul Aitken