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

Paul Aitken <paitken@Brocade.com> Mon, 05 January 2015 10:09 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 E36CB1A1BB8 for <ipfix@ietfa.amsl.com>; Mon, 5 Jan 2015 02:09:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 gk0GO1oxQ-rT for <ipfix@ietfa.amsl.com>; Mon, 5 Jan 2015 02:09:21 -0800 (PST)
Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [IPv6:2620:100:9005:71::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB4AC1A047A for <ipfix@ietf.org>; Mon, 5 Jan 2015 02:09:21 -0800 (PST)
Received: from pps.filterd (m0048192 [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.14.5/8.14.5) with SMTP id t059RuGf015093; Mon, 5 Jan 2015 02:09:20 -0800
Received: from hq1wp-exchub01.corp.brocade.com ([144.49.131.13]) by mx0b-000f0801.pphosted.com with ESMTP id 1rnk7mywqw-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 05 Jan 2015 02:09:20 -0800
Received: from BRMWP-EXCHUB01.corp.brocade.com (172.16.186.99) by HQ1WP-EXCHUB01.corp.brocade.com (10.70.36.101) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 5 Jan 2015 02:09:19 -0800
Received: from EMEAWP-CASH01.corp.brocade.com (172.29.18.10) by BRMWP-EXCHUB01.corp.brocade.com (172.16.186.99) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 5 Jan 2015 03:09:19 -0700
Received: from EMEA-EXCH01.corp.brocade.com ([fe80::18c9:7b21:74fd:7e48]) by EMEAWP-CASH01.corp.brocade.com ([::1]) with mapi; Mon, 5 Jan 2015 11:09:17 +0100
From: Paul Aitken <paitken@Brocade.com>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, "ipfix@ietf.org" <ipfix@ietf.org>
Date: Mon, 5 Jan 2015 11:09:14 +0100
Thread-Topic: [IPFIX] review of draft-ietf-ipfix-mib-variable-export-07
Thread-Index: AdAaBF4AnY0Vd+m1SO6RBJ1L54xa8gK7EqBA
Message-ID: <23B7BE54EACBED43957AB709C564F7B701857F40D7@EMEA-EXCH01.corp.brocade.com>
References: <20141217141829.GA67945@elstar.local>
In-Reply-To: <20141217141829.GA67945@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-05_01:2015-01-02,2015-01-04,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-1501050104
Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/RgVfkLGVmaWc40nhyrb9T7cM7MQ
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: Mon, 05 Jan 2015 10:09:24 -0000

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