From n.brownlee@auckland.ac.nz Sat May 12 11:05:41 2012 Return-Path: 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 4C17721F8581 for ; Sat, 12 May 2012 11:05:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.276 X-Spam-Level: X-Spam-Status: No, score=-106.276 tagged_above=-999 required=5 tests=[AWL=0.323, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MtZ3l69Hphaq for ; Sat, 12 May 2012 11:05:40 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.12.44]) by ietfa.amsl.com (Postfix) with ESMTP id 608F521F851B for ; Sat, 12 May 2012 11:05:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=n.brownlee@auckland.ac.nz; q=dns/txt; s=uoa; t=1336845940; x=1368381940; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=p5oPpiM/zu9kmI5pGF/9uOk4l7+CbEzf5k/2bFYCE/I=; b=MaDvGsPAswIeg/gOjEGUlvcJlXM10qPiBZVk0DktsSzJMaCwmy7Ri3CB W/hxa9OGeefEs029hhikHqpTZfZUic3YbW6Ga53NhyIJn8uGVPDBO2TTI 7I3Cwu2aPkYEthqm0QgRFBVoE0YrKyJRL1gaTfOGfiJkVDsk67zEv1qIE U=; X-IronPort-AV: E=Sophos;i="4.75,577,1330858800"; d="scan'208";a="120935605" X-Ironport-HAT: None - $RELAY-AUTH X-Ironport-Source: 87.210.93.192 - Outgoing - Outgoing-SSL Received: from ip192-93-210-87.adsl2.static.versatel.nl (HELO [192.168.1.10]) ([87.210.93.192]) by mx2-int.auckland.ac.nz with ESMTP; 13 May 2012 06:05:36 +1200 Message-ID: <4FAEA66D.5040900@auckland.ac.nz> Date: Sat, 12 May 2012 11:05:33 -0700 From: Nevil Brownlee User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: IPFIX list Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPFIX] Constraints for IPFIX session at IETF-84 in Vancuover X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 May 2012 18:05:41 -0000 Hi all: Registration for Vancouver is now open, and it's time to ask for an IPFIX WD session. I usually do this by copying the list of constraints from last time. However, this time it seems a good idea to ask the WG! If you have any other WGs you really need to attend, please email me and tell me by next Wednesday (16 May). Thanks, Nevil -- --------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand From acmorton@att.com Sun May 13 10:06:41 2012 Return-Path: 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 ACC0521F8554; Sun, 13 May 2012 10:06:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.394 X-Spam-Level: X-Spam-Status: No, score=-105.394 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qINOSR6QlAXb; Sun, 13 May 2012 10:06:40 -0700 (PDT) Received: from nbfkord-smmo03.seg.att.com (nbfkord-smmo03.seg.att.com [209.65.160.84]) by ietfa.amsl.com (Postfix) with ESMTP id 955F721F854F; Sun, 13 May 2012 10:06:40 -0700 (PDT) Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo03.seg.att.com(mxl_mta-6.11.0-8) over TLS secured channel with ESMTP id f1aefaf4.0.36946.00-490.93934.nbfkord-smmo03.seg.att.com (envelope-from ); Sun, 13 May 2012 17:06:40 +0000 (UTC) X-MXL-Hash: 4fafea203fee9d1e-b683bccbe4e07f07206b7c4c1ae0dc5b40a4547b Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q4DH6cCC030786; Sun, 13 May 2012 13:06:39 -0400 Received: from sflint03.pst.cso.att.com (sflint03.pst.cso.att.com [144.154.234.230]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q4DH6WMY030756 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 13 May 2012 13:06:35 -0400 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by sflint03.pst.cso.att.com (RSA Interceptor); Sun, 13 May 2012 13:06:13 -0400 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q4DH6CZi011344; Sun, 13 May 2012 13:06:12 -0400 Received: from dns.maillennium.att.com (mailgw1.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q4DH66I7010967; Sun, 13 May 2012 13:06:07 -0400 Message-Id: <201205131706.q4DH66I7010967@alpd052.aldc.att.com> Received: from acmt.att.com (vpn-135-70-175-94.vpn.mwst.att.com[135.70.175.94](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20120513170235gw10060l36e>; Sun, 13 May 2012 17:02:41 +0000 X-Originating-IP: [135.70.175.94] X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 13 May 2012 13:06:56 -0400 To: "Aamer Akhter (aakhter)" From: Al Morton Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-RSA-Inspected: yes X-RSA-Classifications: public X-RSA-Action: allow X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.146] X-AnalysisOut: [v=1.0 c=1 a=Vt2btoSP3IcA:10 a=jZD9Sfm6waUA:10 a=ofMgfj31e3] X-AnalysisOut: [cA:10 a=eRgcI_ov3eUA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel0A:1] X-AnalysisOut: [0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a=48vgC7mUAAAA:8 a=YVutamS] X-AnalysisOut: [Y1dF6Lui1zDcA:9 a=twHSKHTm3m0CHogLfp4A:7 a=CjuIK1q_8ugA:10] X-AnalysisOut: [ a=aFSRYU0w_9zJEdOb:21 a=b84Q6Pqyg_Cl9GAn:21] Cc: opsawg@ietf.org, ipfix@ietf.org Subject: [IPFIX] Comments on draft-akhter-opsawg-perfmon-method-02 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 May 2012 17:06:41 -0000 Hi Aamer, I finally made some time to review one of your drafts: http://tools.ietf.org/html/draft-akhter-opsawg-perfmon-method-02 and comments follow below. Not sure exactly which list will be best, so I CC'd ipfix and opsawg. hope this helps, Al -=-=-=-=-=-=-=-=-=-=-=-=-=- Main Comments: 1. Packet Loss Calculation Method (4.1.1) Each metric has a paragraph labeled Calculation Method, but they contain a useful discussion of the possible issues instead. Many details are left to the implementor, with the likely outcome that different implementations will produce different results. For example, "synchronization" is mentioned many times, but what does this process entail? Try to minimize interpretation, perhaps by including a high-level step-by-step procedure for processing each arriving packet, both during initiation (synchronization, when the first few packets arrive) and steady-state processing (which involves using the info from sync). Since this draft is proposed for the Standards Track, it really needs to provide definitions that will stand-up to scrutiny of multiple implementations. 2. Packet Loss "Rate" (4.1.3) This metric is really a Statistic, or a metric derived from the fundamental metrics of Packet Loss and Expected Packet (counts) over a particular measurement interval. Thus, there's no need to talk about measurement points, you've already defined these in the Loss and Expected metrics. Also, this is more accurately named "Loss Ratio", especially when expressed as a percentage as you've done. 3. Jitter (4.1.5 and beyond) This metric will disappoint for use in SLAs or de-jitter buffer sizing if it is based on the RFCC3550 smoothed jitter calculation. Regardless of the measurement interval, only the last 16 packets have any influence over the current value (which is your Average?) General Editorial: There are a number of sentences that seem to contain alternate wordings, as though some deleted text returned somehow. Also, running a spell-check will help. Specific comments follow: 3.1. Quality of Service (QoS) Monitoring The network operator needs to be able to gauge the end user's satisfaction with the network service. While there are many components of the satisfaction such as pricing, packaging, offering, etc., a major component of satisfaction is delivering a consistent service. Consistent Service in what dimensions? Is Service Performance meant here? 4. New Information Elements The information elements are organized into two main groups: Transport Layer: Metrics that might be calculated from observations at higher layers but essentially provide information about the network transport of user date. s/date/data/ 4.1.1. perfPacketLoss Name: perfPacketLoss In this section, s/loss packet/lost packet/ Also, what is the 5-tuple? SSRC + Src IP and Port + Dst IP and Port? At the end: Measurment Timing To be able to calculate this metric a continuous set of the flow's packets (as each would have an incrementing sequence number) needs to be monitored. Therefore, per-packet sampling would prevent this metric from being calculated. s/per-packet/sub-rate/ ?? 4.1.2. perfPacketExpected Name: perfPacketExpected ... Use and Applications The perfPacketExpected is a mid-calculation metric used in the generation of perfPacketLossRate. It is equivilent to the highest received packet sequence number at the time of measurement. True when there is no roll-over in Seq numbers. ... As the value only increments when packets are received, packet loss may be occouring at the time of measurement but perfPacketExpected remains constant. This is an issue worth mitigating, some sort of average packet rate could be used to estimate the number of losses while the Expected count remains constant. Calculation Method: The subtraction of the last sequence number from the first sequence number in monitoring interval yields the expected count. As discussed with perfPacketLost, there might be a delay due to synchronization with the flow's sequence numbers and in such times the value of the metric should be set to 0xFFFFFFFE. Care has to be taken to account for cases where the packet's sequence number field wraps. This is an opportunity for more specifics, as an example (I didn't check the Appendix 3 reference, no access today...) 4.1.3. perfPacketLossRate Name: perfPacketLossPercentage These aren't the same! Which is it? 4.1.4. perfPacketLossEvent Name: perfPacketLossEvent Need "consecutive" in the name, or some other way to distinguish single losses from "bursts". ... Calculation Method: This data value is a simplified version of the Lost Packets metric. Whereas Lost Packets counts individual packet loss, the 'loss event count' metric counts sets of packets that are lost. For example, in the case of a sequence of packets: 1,3,6,7,10 the packets marked 2,4,5,8 and 9 are lost. So, a total How long does the process wait to make the lost determination? 4.1.5. perfPacketInterArrivalJitterAvg Name: perfPacketInterArrivalJitterAvg Description: This metric measures the absolute deviation of the difference in packet spacing at the measurement point compared to the packet spacing at the sender. I don't think that's what 3550 Jitter does... ... Use and Applications The inter arrival jitter data value can be used be network operator to determine the network's impact to the spacing in between a media stream's packets as they traverse the network. What about Source Jitter? this can be very significant, more than network. Again, Min and Max are statistics. 4.2. User and Application Layer 4.2.1. perfSessionSetupDelay Name: perfSessionSetupDelay This seems to be the only two-point metric, worth noting. and [I-D.ietf-pmol-sip-perf-metrics] is an RFC now (which mostly defined metrics, not methods). From janovak@cisco.com Tue May 22 01:58:05 2012 Return-Path: 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 C5E4221F853D; Tue, 22 May 2012 01:58:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tO56jk7CT555; Tue, 22 May 2012 01:58:05 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 7ABFE21F84FC; Tue, 22 May 2012 01:58:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=janovak@cisco.com; l=2864; q=dns/txt; s=iport; t=1337677085; x=1338886685; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=mJ5YAiuzwuVtKnAZUc2+/OUsXwOz0bApdbjZL33z1iM=; b=iJt6R807NLHSr+A4ld+ZHSgy4xy6OZ/M2+sqNEkuKXgu0iFaf2CzgbJe P6lpo8dRkG4+8Q59Gr2Yj/SnrrS+sBNc4i5Vm25tqMbsZwPrlP3MzLJXb xFlJ9a1I0D9BN1daxO1Vdt1JDs4RJvRtHgUJtbb7m1azd1n8K69c4PNmn 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAJhUu0+Q/khL/2dsb2JhbABEtBSBB4IWAQEEEgEdCj8QAgEqBhgGAVYBAQQBGhqHbJ4PoBSLG4RHYgOjJ4FkgmuBVA X-IronPort-AV: E=Sophos;i="4.75,637,1330905600"; d="scan'208";a="138295200" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 22 May 2012 08:58:02 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q4M8w24e024362; Tue, 22 May 2012 08:58:02 GMT Received: from xmb-ams-212.cisco.com ([144.254.75.23]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 22 May 2012 10:58:02 +0200 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: Tue, 22 May 2012 10:58:00 +0200 Message-ID: In-Reply-To: <201205161453.q4GErZNl015927@alpd052.aldc.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-akhter-opsawg-perfmon-ipfix-02 Thread-Index: Ac0zc8BXTR41oCKqTcOQDS4l95WyzAEhILoQ References: <201205161453.q4GErZNl015927@alpd052.aldc.att.com> From: "Jan Novak (janovak)" To: "Aamer Akhter (aakhter)" , , X-OriginalArrivalTime: 22 May 2012 08:58:02.0093 (UTC) FILETIME=[FE4479D0:01CD37F8] Cc: Al Morton , pmol@ietf.org Subject: [IPFIX] Comments on draft-akhter-opsawg-perfmon-ipfix-02 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 08:58:05 -0000 Hi Amer, I have reviewed your draft draft-akhter-opsawg-perfmon-ipfix-02.txt. There seems to be a lot of text overlap with your methodology document - section 1,3, 4 could probably be abbreviated or omitted leaving the document just with raw IPFIX IE specifications or just add the IE specification as sub-sections or a new section into the first document ??=20 Section 2 uses definitions from RFC5610 - I think those you use there are defined in RFC5102 as DataTypeSemantic, units and range while RFC5610 specifies how this information should be exported - here you are defining the IE itself so you should use the definitions from RFC5102 Also the methodology documents already speaks in terms of IPFIX IEs while you are trying to specify some performance metrics - the methodology could have names and an exact definitions of the metric and then a reference which IE represents the particular metric RFC5102 section 2.1 specifies a template for IEs with a MUST so the MUST entries should be literally followed in your IEs spec - namely name, elementID, description, dataType and status. RFC5102 section 2.1 specifies MAY entries for the template - like DataTypeSemantic, units, name - might be preferable to follow the naming as well You interchanged ElementId with name - ElementId should be the numerical ID of the particular IE, while name of the IE is actually missing Instead of using Observation Point - wouldn't be the scope of the element appropriate ?? Or if not then scope should be actually added - are the=20 metrics (like perfPacketLoss) applicable to all the traffic seen by the UUT (or more specifically passing through the Observation Point) or to just individual flows ?? This should also be part of the particular metric definition. Will your IEs be enterprise IEs or IANA ones ?? Section 4.1.2 - Units packets ?? Section 4.1.3 - there is a mis-match between the definition and the range=20 - it should be limited to 0 - 100 + a value when the rate is unknown This definition is also missing in section 4.1.3 of your methodology Sections 4.3.1, 4.3.2 - the values are just numbers/ids so units shouldn't be octets but "none" ?? The IPFIX guys here have had few discussions regarding IE definitions explosions with all the needs like this - have you thought using RFC6313 now (structured data) ?? I am not sure I would use RFC2321 as a reference work :-). huic-ipfix-sipfix is not a work in progress - the ID expired 3 years ago. ie-doctors is a WG doc version 2 now - draft-ietf-ipfix-ie-doctors-02.txt pmol-metrics-framework is RFC 6390 The document would benefit from running it through spell checker. Rgds, Jan The climate of Edinburgh is such that the weak succumb young ....=20 and the strong envy them. Dr. Johnson From dromasca@avaya.com Tue May 22 05:21:20 2012 Return-Path: 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 7868D21F85F6; Tue, 22 May 2012 05:21:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.216 X-Spam-Level: X-Spam-Status: No, score=-103.216 tagged_above=-999 required=5 tests=[AWL=-0.217, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cJ1NmIlhRJc8; Tue, 22 May 2012 05:21:19 -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 8779F21F846C; Tue, 22 May 2012 05:21:18 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAGuDu0+HCzI1/2dsb2JhbABDtBKBB4IVAQEBAQIBAQEBDx4KLQcLBQcEAgEIDQQEAQELAgQMCwEGASYfCQgBAQQTCAESB4dnBQucOp0aiwgZhEFiA5sMiX+Ca4Fd X-IronPort-AV: E=Sophos;i="4.75,638,1330923600"; d="scan'208";a="307581510" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 22 May 2012 08:19:36 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 22 May 2012 08:03:31 -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: Tue, 22 May 2012 14:21:10 +0200 Message-ID: In-Reply-To: <20120515175319.13879.23149.idtracker@ietfa.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [new-work] WG Review: Recharter of Behavior Engineering forHindrance Avoidance (behave) Thread-Index: Ac0yw5+43gY6yitHR8y91/PDlWeIXgFUImpw References: <20120515175319.13879.23149.idtracker@ietfa.amsl.com> From: "Romascanu, Dan (Dan)" To: Cc: "MIB Doctors \(E-mail\)" , IETF IPFIX Working Group Subject: Re: [IPFIX] [new-work] WG Review: Recharter of Behavior Engineering forHindrance Avoidance (behave) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 12:21:20 -0000 Hi,=20 Two comments:=20 1. If I got it right, Information Elements will be defined specifically to meet logging requirements. It would be good to be explicit on this in the deliverables list as well.=20 2. It is not clear what the plans are concerning the MIB module(s). Will there be two separate MIB modules to be used as needed with the existing MIB module defined in RFC 4008? Or eventually there will be one MIB module that updates the one defined in 4008 and adds NAT64 and CGNs capabilities.=20 Thanks and Regards, Dan > -----Original Message----- > From: new-work-bounces@ietf.org [mailto:new-work-bounces@ietf.org] On > Behalf Of IESG Secretary > Sent: Tuesday, May 15, 2012 8:53 PM > To: new-work@ietf.org > Subject: [new-work] WG Review: Recharter of Behavior Engineering > forHindrance Avoidance (behave) >=20 > A modified charter has been submitted for the Behavior Engineering for > Hindrance Avoidance (behave) working group in the Transport Area of the > IETF. The IESG has not made any determination as yet. The modified > charter is provided below for informational purposes only. Please send > your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, May > 22, 2012. >=20 > Behavior Engineering for Hindrance Avoidance (behave) > ----------------------------------------------------- > Current Status: Active > Last updated: 2012-05-10 >=20 > Chairs: > Dan Wing > Dave Thaler >=20 > Transport Area Directors: > Wesley Eddy > Martin Stiemerling >=20 > Transport Area Advisor: > Wesley Eddy >=20 > Mailing Lists: > General Discussion: behave@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/behave > Archive: http://www.ietf.org/mail-archive/web/behave >=20 > Description of Working Group >=20 > The working group creates documents to enable IPv4/IPv4 and IPv6/IPv4 > NATs to function in as deterministic a fashion as possible. >=20 > To support deployments where communicating hosts require using > different address families (IPv4 or IPv6), address family translation > is > needed to establish communication. In BEHAVE's specification work on > this topic it will coordinate with the V6ops WG on requirements and > operational considerations. >=20 > "An IPv4 network" or "an IPv6 network" in the descriptions below refer > to a network with a clearly identifiable administrative domain (e.g., > an > enterprise campus network, a mobile operator's cellular network, a > residential subscriber network, etc.). It will also be that network > that > deploys the necessary equipment for translation. >=20 > BEHAVE will finish four scenarios: (1) An IPv6 network to IPv4 > Internet, (2) an IPv6 Internet to an IPv4 network, (3) an IPv6 network > to an IPv4 network, and (4) an IPv4 network to an IPv6 network. >=20 > Specifically, BEHAVE will update the NAT MIB (RFC 4008) to be > consistent with the management aspects of its IPv6/IPv4 NAT solutions, > and specify IPFIX information elements to meet logging requirements, > reusing existing elements, if possible. >=20 > In addition, when a NAT (such as a NAT64 in the "An IPv6 network to > IPv4 Internet" scenario) serves multiple subscribers, inter-subscriber > fairness issues arise. As such, BEHAVE will complete its work on > Carrier Grade NAT requirements for such scenarios, and update the NAT > MIB as needed to meet such requirements. BEHAVE will not, however, > standardize IPv4-specific behavioral mechanisms. >=20 > The following scenarios remain in scope for discussion, but will not be > solved by BEHAVE: >=20 > * An IPv4 network to IPv6 Internet, i.e. perform translation between > IPv4 and IPv6 for packets in uni- or bi-directional flows that are > initiated from an IPv4 host towards an IPv6 host. The translator > function is intended to service a specific IPv4 network using either > public or private IPv4 address space. >=20 > * IPv4 Internet to an IPv6 network, i.e. perform translation between > IPv4 and IPv6 for packets in uni- or bi-directional flows that are > initiated from an IPv4 host towards an IPv6 host. The translator > function is intended to service a specific IPv6 network where selected > IPv6 hosts and services are to be reachable. >=20 > This group will also provide reviews of any work by the MBoneD WG on > multicast translation, including control traffic (IGMP and MLD), > Single > Source Multicast (SSM) and Any Source Multicast (ASM). >=20 > If the WG deems it necessary, BEHAVE will revise RFCs previously > published by BEHAVE. >=20 > Goals and Milestones >=20 > Done Submit BCP that defines unicast UDP behavioral requirements for > NATs to IESG > Done Submit a BCP that defines TCP behavioral requirements for NATs > to IESG > Done Submit a BCP that defines ICMP behavioral requirements for NATs > to IESG > Done Submit informational that discusses current NAT traversal > techniques used by applications > Done Submit BCP that defines multicast UDP > Done Submit revision of RFC 3489 to IESG behavioral requirements for > NATs to IESG > Done Submit informational document for rfc3489bis test vectors > Done Submit experimental document that describes how an application > can determine the type of NAT it is behind > Done Submit BCP document for DCCP NAT behavior > Done Determine relative prioritization of the four translation cases. > Documented in IETF74 minutes. > Done Determine what solutions(s) and components are needed to solve > each of the four cases. Create new milestones for the > solution(s) and the components. Documented in IETF74 minutes. > Done Submit to IESG: relaying of a TCP bytestream (std) > Done Submit to IESG: relay protocol (std) > Done Submit to IESG: TURN-URI document (std) > Done Submit to IESG: IPv6 relay protocol (std) > Done Submit to IESG: framework for IPv6/IPv4 translation (info) > Done Submit to IESG: stateless IPv6/IPv4 translation (std) > Done Submit to IESG: stateful IPv6/IPv4 translation (std) > Done Submit to IESG: DNS rewriting for IPv6/IPv4 translation (std) > Done Submit to IESG: IPv6 prefix for IPv6/IPv4 translator (std) > Done Determine need and scope of multicast 6/4 translation > Done Submit to IESG: FTP ALG for IPv6/IPv4 translation (std) > Jul 2012 Submit to IESG: large scale NAT requirements (BCP) > Done Submit to IESG: Analysis of NAT-PT considerations with IPv6/IPv4 > translation (info) > Jul 2012 Submit to IESG: avoiding NAT64 with dual-stack host for > local networks (std) > Done Submit to IESG: host-based NAT46 translation for IPv4-only > applications to access IPv6-only servers (std) > Nov 2012 Submit to IESG: updates to NAT MIB for NAT64 (std) > Nov 2012 Submit to IESG: updates to NAT MIB for CGNs (std) > Nov 2012 Submit to IESG: IPFIX information elements (std) > _______________________________________________ > new-work mailing list > new-work@ietf.org > https://www.ietf.org/mailman/listinfo/new-work From dromasca@avaya.com Thu May 24 08:00:15 2012 Return-Path: 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 2708521F8523 for ; Thu, 24 May 2012 08:00:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.459 X-Spam-Level: X-Spam-Status: No, score=-103.459 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BD0T+Ue6AeQd for ; Thu, 24 May 2012 08:00:14 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id C361221F84A0 for ; Thu, 24 May 2012 08:00:13 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqsJAORLvk+HCzI1/2dsb2JhbABDrQOHRYEHghUBAQEBAgESHgoxAxANARUVBgwMB1cBBBsah2YFmhqEIJ0Ljz9gA5sJiX+CbA X-IronPort-AV: E=Sophos;i="4.75,651,1330923600"; d="scan'208";a="349301321" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 24 May 2012 10:58:29 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 24 May 2012 10:42:24 -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: Thu, 24 May 2012 17:00:09 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WGLC Comments on draft-ietf-ipfix-ie-doctors Thread-Index: Ac05vemdZpKe6do1SIGy3WJH+CCJog== From: "Romascanu, Dan (Dan)" To: "IETF IPFIX Working Group" Subject: [IPFIX] WGLC Comments on draft-ietf-ipfix-ie-doctors X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 15:00:15 -0000 Hi, Please find below my Working Group Last Call comments on draft-ietf-ipfix-ie-doctors-02: 1. Editorial cleaning - The I-D needs a serious round of editorial cleaning performed by a native English speaker.=20 2. Section 4.3 talks about the need to designate an expert to advice to IANA on Netflow v9 matters. This request is not however mentioned in the IANA Considerations section.=20 3. It is not clear to me what is the goal of the following piece of process described in Section 4.9:=20 > In order to support transition from experimental registration to IANA registration, the IANA registry provides an optional "enterprise- specific IE reference" column for each Information Element. In cases of promoted enterprise-specific Information Elements, this column in the registry SHOULD contain the private enterprise and Information Element numbers of the enterprise-specific version of the Information Element. If I understand well, an IE shows up in the IANA registry only when a standard IE is added to the registry. What 'transition' is being supported here, and how is it supported by a back reference to a proprietary enterprise registry?=20 4. In Section 5.2, the following change in an IE is considered to be interoperable:=20 > it corrects an ambiguity in the Information Element's definition, which itself leads to non-interoperability (e.g., a prior change to ipv6ExtensionHeaders) How can an IE with a corrected definition be interoperable with an IE with a definition that is that broken that it leads to non-interoperability? Brokenly-defined IEs cannot be fixed, they must be deprecated and new IEs defined with a different name to start with.=20 5. Also in 5.2:=20 > A non-interoperable Information Element change may also be made if it can be reasonably assumed in the eyes of the appointed experts that no unchanged implementation of the Information Element exists; this can be held to happen if a non-interoperable change to an Information Element defined shortly before is proposed to the IPFIX mailing list by the original proposer of the Information Element, and no objection is raised within a reasonable amount of time, to be defined by the expert reviewers. I strongly oppose this. We need to assume that the IANA registry is universally visible and that people who never read the IPFIX mailing list can write applications using IEs. Hence there is no 'reasonable' assumption like the one described here. A non-interoperable change must be performed by deprecating the old IE and defining a new IE with a different name.=20 6. In 5.3:=20 > Names of obsolete Information Elements MAY be reused, but this is NOT RECOMMENDED, as it may cause confusion among users. No, please not! Do not reuse names of obsolete IEs, you can never know what older applications are being deployed and run.=20 7. You may consider to recommend in the Security Considerations sections that IETF documents that define new IEs list in their Security Considerations sections the IEs that have specific security aspects mentioned in descriptions, or their semantics or their usage can generate or are prone to security vulnerabilities. =20 Regards, Dan From bclaise@cisco.com Thu May 24 08:05:58 2012 Return-Path: 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 1FACF21F8649; Thu, 24 May 2012 08:05:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.179 X-Spam-Level: X-Spam-Status: No, score=-10.179 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZFRIxcmL2-D5; Thu, 24 May 2012 08:05:57 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id E3BD321F8648; Thu, 24 May 2012 08:05:56 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q4OF5qMn010051; Thu, 24 May 2012 17:05:52 +0200 (CEST) Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q4OF5pI2021081; Thu, 24 May 2012 17:05:52 +0200 (CEST) Message-ID: <4FBE4E4F.9080503@cisco.com> Date: Thu, 24 May 2012 17:05:51 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" , Wesley Eddy References: <20120515175319.13879.23149.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "MIB Doctors \(E-mail\)" , iesg@ietf.org, IETF IPFIX Working Group Subject: Re: [IPFIX] [new-work] WG Review: Recharter of Behavior Engineering forHindrance Avoidance (behave) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 15:05:58 -0000 Hi Dan, Wes, > Hi, > > Two comments: > > 1. If I got it right, Information Elements will be defined specifically > to meet logging requirements. It would be good to be explicit on this in > the deliverables list as well. Isn't it: Nov 2012 Submit to IESG: IPFIX information elements (std)? > > 2. It is not clear what the plans are concerning the MIB module(s). Will > there be two separate MIB modules to be used as needed with the existing > MIB module defined in RFC 4008? Or eventually there will be one MIB > module that updates the one defined in 4008 and adds NAT64 and CGNs > capabilities. If you're concerned about two deliverables Nov 2012 Submit to IESG: updates to NAT MIB for NAT64 (std) Nov 2012 Submit to IESG: updates to NAT MIB for CGNs (std) While there is apparently one entry in the charter text: Specifically, BEHAVE will update the NAT MIB (RFC 4008) to be consistent with the management aspects of its IPv6/IPv4 NAT solutions, I have the same concern. Regards, Benoit. > > Thanks and Regards, > > Dan > > >> -----Original Message----- >> From: new-work-bounces@ietf.org [mailto:new-work-bounces@ietf.org] On >> Behalf Of IESG Secretary >> Sent: Tuesday, May 15, 2012 8:53 PM >> To: new-work@ietf.org >> Subject: [new-work] WG Review: Recharter of Behavior Engineering >> forHindrance Avoidance (behave) >> >> A modified charter has been submitted for the Behavior Engineering for >> Hindrance Avoidance (behave) working group in the Transport Area of > the >> IETF. The IESG has not made any determination as yet. The modified >> charter is provided below for informational purposes only. Please > send >> your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, May >> 22, 2012. >> >> Behavior Engineering for Hindrance Avoidance (behave) >> ----------------------------------------------------- >> Current Status: Active >> Last updated: 2012-05-10 >> >> Chairs: >> Dan Wing >> Dave Thaler >> >> Transport Area Directors: >> Wesley Eddy >> Martin Stiemerling >> >> Transport Area Advisor: >> Wesley Eddy >> >> Mailing Lists: >> General Discussion: behave@ietf.org >> To Subscribe: https://www.ietf.org/mailman/listinfo/behave >> Archive: http://www.ietf.org/mail-archive/web/behave >> >> Description of Working Group >> >> The working group creates documents to enable IPv4/IPv4 and IPv6/IPv4 >> NATs to function in as deterministic a fashion as possible. >> >> To support deployments where communicating hosts require using >> different address families (IPv4 or IPv6), address family translation >> is >> needed to establish communication. In BEHAVE's specification work on >> this topic it will coordinate with the V6ops WG on requirements and >> operational considerations. >> >> "An IPv4 network" or "an IPv6 network" in the descriptions below refer >> to a network with a clearly identifiable administrative domain (e.g., >> an >> enterprise campus network, a mobile operator's cellular network, a >> residential subscriber network, etc.). It will also be that network >> that >> deploys the necessary equipment for translation. >> >> BEHAVE will finish four scenarios: (1) An IPv6 network to IPv4 >> Internet, (2) an IPv6 Internet to an IPv4 network, (3) an IPv6 network >> to an IPv4 network, and (4) an IPv4 network to an IPv6 network. >> >> Specifically, BEHAVE will update the NAT MIB (RFC 4008) to be >> consistent with the management aspects of its IPv6/IPv4 NAT solutions, >> and specify IPFIX information elements to meet logging requirements, >> reusing existing elements, if possible. >> >> In addition, when a NAT (such as a NAT64 in the "An IPv6 network to >> IPv4 Internet" scenario) serves multiple subscribers, inter-subscriber >> fairness issues arise. As such, BEHAVE will complete its work on >> Carrier Grade NAT requirements for such scenarios, and update the NAT >> MIB as needed to meet such requirements. BEHAVE will not, however, >> standardize IPv4-specific behavioral mechanisms. >> >> The following scenarios remain in scope for discussion, but will not > be >> solved by BEHAVE: >> >> * An IPv4 network to IPv6 Internet, i.e. perform translation between >> IPv4 and IPv6 for packets in uni- or bi-directional flows that are >> initiated from an IPv4 host towards an IPv6 host. The translator >> function is intended to service a specific IPv4 network using either >> public or private IPv4 address space. >> >> * IPv4 Internet to an IPv6 network, i.e. perform translation between >> IPv4 and IPv6 for packets in uni- or bi-directional flows that are >> initiated from an IPv4 host towards an IPv6 host. The translator >> function is intended to service a specific IPv6 network where selected >> IPv6 hosts and services are to be reachable. >> >> This group will also provide reviews of any work by the MBoneD WG on >> multicast translation, including control traffic (IGMP and MLD), >> Single >> Source Multicast (SSM) and Any Source Multicast (ASM). >> >> If the WG deems it necessary, BEHAVE will revise RFCs previously >> published by BEHAVE. >> >> Goals and Milestones >> >> Done Submit BCP that defines unicast UDP behavioral requirements for >> NATs to IESG >> Done Submit a BCP that defines TCP behavioral requirements for NATs >> to IESG >> Done Submit a BCP that defines ICMP behavioral requirements for NATs >> to IESG >> Done Submit informational that discusses current NAT traversal >> techniques used by applications >> Done Submit BCP that defines multicast UDP >> Done Submit revision of RFC 3489 to IESG behavioral requirements for >> NATs to IESG >> Done Submit informational document for rfc3489bis test vectors >> Done Submit experimental document that describes how an application >> can determine the type of NAT it is behind >> Done Submit BCP document for DCCP NAT behavior >> Done Determine relative prioritization of the four translation cases. >> Documented in IETF74 minutes. >> Done Determine what solutions(s) and components are needed to solve >> each of the four cases. Create new milestones for the >> solution(s) and the components. Documented in IETF74 minutes. >> Done Submit to IESG: relaying of a TCP bytestream (std) >> Done Submit to IESG: relay protocol (std) >> Done Submit to IESG: TURN-URI document (std) >> Done Submit to IESG: IPv6 relay protocol (std) >> Done Submit to IESG: framework for IPv6/IPv4 translation (info) >> Done Submit to IESG: stateless IPv6/IPv4 translation (std) >> Done Submit to IESG: stateful IPv6/IPv4 translation (std) >> Done Submit to IESG: DNS rewriting for IPv6/IPv4 translation (std) >> Done Submit to IESG: IPv6 prefix for IPv6/IPv4 translator (std) >> Done Determine need and scope of multicast 6/4 translation >> Done Submit to IESG: FTP ALG for IPv6/IPv4 translation (std) >> Jul 2012 Submit to IESG: large scale NAT requirements (BCP) >> Done Submit to IESG: Analysis of NAT-PT considerations with IPv6/IPv4 >> translation (info) >> Jul 2012 Submit to IESG: avoiding NAT64 with dual-stack host for >> local networks (std) >> Done Submit to IESG: host-based NAT46 translation for IPv4-only >> applications to access IPv6-only servers (std) >> Nov 2012 Submit to IESG: updates to NAT MIB for NAT64 (std) >> Nov 2012 Submit to IESG: updates to NAT MIB for CGNs (std) >> Nov 2012 Submit to IESG: IPFIX information elements (std) >> _______________________________________________ >> new-work mailing list >> new-work@ietf.org >> https://www.ietf.org/mailman/listinfo/new-work > From wwwrun@rfc-editor.org Fri May 25 04:48:22 2012 Return-Path: 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 0340621F8625 for ; Fri, 25 May 2012 04:48:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.162 X-Spam-Level: X-Spam-Status: No, score=-101.162 tagged_above=-999 required=5 tests=[AWL=1.438, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gmXmOrRnJW1g for ; Fri, 25 May 2012 04:48:21 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 9496621F85FF for ; Fri, 25 May 2012 04:48:21 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 592F1B1E01C; Fri, 25 May 2012 04:48:01 -0700 (PDT) To: bclaise@cisco.com, gowri@cisco.com, paitken@cisco.com, syates@cisco.com, rbonica@juniper.net, bclaise@cisco.com, n.brownlee@auckland.ac.nz, quittek@neclab.eu From: RFC Errata System Message-Id: <20120525114801.592F1B1E01C@rfc-editor.org> Date: Fri, 25 May 2012 04:48:01 -0700 (PDT) Cc: ipfix@ietf.org, rfc-editor@rfc-editor.org Subject: [IPFIX] [Technical Errata Reported] RFC6313 (3232) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 11:48:22 -0000 The following errata report has been submitted for RFC6313, "Export of Structured Data in IP Flow Information Export (IPFIX)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6313&eid=3232 -------------------------------------- Type: Technical Reported by: Paul Aitken Section: 4.5.3 Original Text ------------- In the exceptional case of zero instances in the subTemplateMultiList, no data is encoded, only the Semantic field and Template ID field(s), and the Data Record Length field is set to zero. Corrected Text -------------- In the exceptional case of zero instances in the subTemplateMultiList, no data is encoded, only the Semantic field and Template ID field(s), and the Data Records Length field is set to four. Notes ----- s/zero/four/ && s/Record/Records/ - because the Data Record Length field includes two bytes for the Template ID and two bytes for the Data Records Length field itself, as specified on page 23: Data Records Length This is the total length of the Data Records encoding for the Template ID previously specified, including the two bytes for the Template ID and the two bytes for the Data Records Length field itself. Therefore, a Data Records Length < 4 bytes is invalid. This should be noted in the "Data Records Length" definition. Also note the pluralisation of "Records" in the definition. Kudos to Manish Patil, manish.patil@guavus.com Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6313 (draft-ietf-ipfix-structured-data-06) -------------------------------------- Title : Export of Structured Data in IP Flow Information Export (IPFIX) Publication Date : July 2011 Author(s) : B. Claise, G. Dhandapani, P. Aitken, S. Yates Category : PROPOSED STANDARD Source : IP Flow Information Export Area : Operations and Management Stream : IETF Verifying Party : IESG