From n.brownlee@auckland.ac.nz Mon Dec 2 14:39:41 2013 Return-Path: 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 7217C1ADF84 for ; Mon, 2 Dec 2013 14:39:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.103 X-Spam-Level: X-Spam-Status: No, score=-0.103 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, 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 P9Myf4pJziig for ; Mon, 2 Dec 2013 14:39:39 -0800 (PST) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) by ietfa.amsl.com (Postfix) with ESMTP id 216201ADF7A for ; Mon, 2 Dec 2013 14:39:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1386023977; x=1417559977; h=message-id:date:from:mime-version:to:cc:subject: content-transfer-encoding; bh=tGvD2y+9a0CgW8rPujaEqCSyqpMYlwr/0K/W4lwVbaA=; b=D1ZMEsCN465IEv062/ag9GLTQdLTzC+XobjslFlU7hqLx1KCprwBDAsB mX1PQUu3uHxnGTB2g46qfadaeESYeAjRAFxCjya/RyNGxnFVOGM/TuC1g TH10sCharo4nXkfbjXjlcndeM2zxcySBgk1uthek6JTsSo5yii3E5aloH 8=; X-IronPort-AV: E=Sophos;i="4.93,813,1378814400"; d="scan'208";a="225494290" X-Ironport-HAT: UNIVERSITY - $RELAY-THROTTLE X-Ironport-Source: 130.216.38.131 - Outgoing - Outgoing-SSL Received: from nevil-laptop1.sfac.auckland.ac.nz (HELO [130.216.38.131]) ([130.216.38.131]) by mx2-int.auckland.ac.nz with ESMTP; 03 Dec 2013 11:39:36 +1300 Message-ID: <529D0C27.8080508@auckland.ac.nz> Date: Tue, 03 Dec 2013 11:39:35 +1300 From: Nevil Brownlee User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Benoit Claise Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPFIX Working Group Subject: [IPFIX] shepherd writeup for text-adt draft X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 22:39:41 -0000 Hi Benoit: Here's the writeup for Brian Trammell's text-adt draft. Cheers, Nevil -- --------------------------------------------------------------------- Nevil Brownlee Computer Science Department Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand From n.brownlee@auckland.ac.nz Mon Dec 2 14:42:05 2013 Return-Path: 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 EDA441ADEA7 for ; Mon, 2 Dec 2013 14:42:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, 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 R0M_6jq8xT4L for ; Mon, 2 Dec 2013 14:42:03 -0800 (PST) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) by ietfa.amsl.com (Postfix) with ESMTP id DD34B1AD845 for ; Mon, 2 Dec 2013 14:42:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1386024121; x=1417560121; h=message-id:date:from:mime-version:to:cc:subject; bh=Lji9Fdf1BA4JP1Ej+jxtGvlQ67B3UhBnS6wFldaqV2w=; b=KxoTJ+6UQnvqdk7qbTEaqkhyvj9XS7DtNBnt//sFueH19Vps9496juXB uflHuyr3ydLKSfpemLEMWWFueEe0+BScOyIs01OplCXBiNYxEbTBjZFa/ Rm1iZ7HPXLRHjtHrFPok1aEkXY5Tg8RN1OPBQQECiZJx79OIwyR28Gc/H g=; X-IronPort-AV: E=Sophos;i="4.93,813,1378814400"; d="txt'?scan'208";a="225494961" X-Ironport-HAT: UNIVERSITY - $RELAY-THROTTLE X-Ironport-Source: 130.216.38.131 - Outgoing - Outgoing-SSL Received: from nevil-laptop1.sfac.auckland.ac.nz (HELO [130.216.38.131]) ([130.216.38.131]) by mx2-int.auckland.ac.nz with ESMTP; 03 Dec 2013 11:42:00 +1300 Message-ID: <529D0CB7.4000104@auckland.ac.nz> Date: Tue, 03 Dec 2013 11:41:59 +1300 From: Nevil Brownlee User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Benoit Claise Content-Type: multipart/mixed; boundary="------------010605030005000704020701" Cc: IPFIX Working Group Subject: [IPFIX] shepherd writeup for text-adt draft (this time WITH the writeup) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 22:42:05 -0000 This is a multi-part message in MIME format. --------------010605030005000704020701 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Oops, here it is again, with the writeup attached! Sorry about that, Nevil Hi Benoit: Here's the writeup for Brian Trammell's text-adt draft. Cheers, Nevil -- --------------------------------------------------------------------- Nevil Brownlee Computer Science Department Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand _______________________________________________ --------------010605030005000704020701 Content-Type: text/plain; charset=UTF-8; name="shepherd-ipfix-text-adt.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="shepherd-ipfix-text-adt.txt" Write-up for: draft-trammell-ipfix-text-adt-03.txt Textual Representation of IPFIX Abstract Data Types === 1. Summary === Document shepherd: Nevil Brownlee Responsible Area Director: Benoit Claise This document is Informational, AD-sponsored by Benoit Claise. This document defines UTF-8 representations for IPFIX abstract data types, to support interoperable usage of the IPFIX Information Elements with protocols based on textual encodings. It describes a set of "canonical textual encodings for the IPFIX abstract data types would allow this set of Information Elements to be used for applications that use JSON or XML, and for these applications to interoperate with IPFIX applications at the Information Element definition level." === 2. Review and Consensus === This draft's -00 version was published in November 2012; at that time the WG was busy with its chartered work items. It was discussed on the IPFIX list, and at later IPFIX meetings; it has been successively improved since. At the WG meeting in Vancouver (November 2013), there was clear consensus that it should become an AD-sponsored document before the IPFIX WG closes. === 3. Intellectual Property === No IPR disclosures have been made directly on this draft, IPR on it has not been discussed in the WG. The author has stated that there are no IPR disclosures for it, nor could there be any. === 4. Other Points === This document has no downward references, and no IANA Considerations. The ID-nits checker complains about it using RFC 2119 capitalisation without citing 2119; I think that since it is Informational, that usage is OK. Overall, I believe that this draft is ready for publication as an RFC. ==== . ==== --------------010605030005000704020701-- From internet-drafts@ietf.org Thu Dec 5 13:21:22 2013 Return-Path: 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 C97711AE17F; Thu, 5 Dec 2013 13:21:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 eKeVS1pMMvAu; Thu, 5 Dec 2013 13:21:19 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 812C51ADDBD; Thu, 5 Dec 2013 13:21:18 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131205212118.21745.85786.idtracker@ietfa.amsl.com> Date: Thu, 05 Dec 2013 13:21:18 -0800 Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action: draft-ietf-ipfix-mediation-protocol-09.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 21:21:23 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IP Flow Information Export Working Group = of the IETF. Title : Operation of the IP Flow Information Export (IPFIX) Prot= ocol on IPFIX Mediators Author(s) : Benoit Claise Atsushi Kobayashi Brian Trammell Filename : draft-ietf-ipfix-mediation-protocol-09.txt Pages : 29 Date : 2013-12-05 Abstract: This document specifies the operation of the IP Flow Information Export (IPFIX) protocol specific to IPFIX Mediators, including Template and Observation Point management, timing considerations, and other Mediator-specific concerns. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipfix-mediation-protocol There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ipfix-mediation-protocol-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipfix-mediation-protocol-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Fri Dec 6 03:31:10 2013 Return-Path: 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 399A81ADF4E; Fri, 6 Dec 2013 03:31:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 3Hhd5TsH6YNR; Fri, 6 Dec 2013 03:31:08 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A95BC1ADBF7; Fri, 6 Dec 2013 03:31:08 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131206113108.29423.99429.idtracker@ietfa.amsl.com> Date: Fri, 06 Dec 2013 03:31:08 -0800 Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action: draft-ietf-ipfix-mediation-protocol-10.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 11:31:10 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IP Flow Information Export Working Group = of the IETF. Title : Operation of the IP Flow Information Export (IPFIX) Prot= ocol on IPFIX Mediators Author(s) : Benoit Claise Atsushi Kobayashi Brian Trammell Filename : draft-ietf-ipfix-mediation-protocol-10.txt Pages : 29 Date : 2013-12-06 Abstract: This document specifies the operation of the IP Flow Information Export (IPFIX) protocol specific to IPFIX Mediators, including Template and Observation Point management, timing considerations, and other Mediator-specific concerns. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipfix-mediation-protocol There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ipfix-mediation-protocol-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipfix-mediation-protocol-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From bclaise@cisco.com Fri Dec 6 03:52:14 2013 Return-Path: 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 63E341AE34F for ; Fri, 6 Dec 2013 03:52:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.501 X-Spam-Level: X-Spam-Status: No, score=-9.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 pxVBRR8bCjYz for ; Fri, 6 Dec 2013 03:52:12 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id 8AF431ADEBB for ; Fri, 6 Dec 2013 03:52:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2962; q=dns/txt; s=iport; t=1386330729; x=1387540329; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=eB6vW6fEoIlr63AXbFkii9jEtl3TJOMRxvduY7bOqAE=; b=By0uBtO1z+SvsqTJgDth2Wd2R7qxsgWeTrwwwR5MoOoLFOkGIo09d7rp uK9RGKP5Sfi/zEZxvFp3uMmr+JOOTv4RDryildV0KgnT8y6kJuPNxUtmU FMISgICLXQ/SOEmxhKMD39tUX6uykFV2EXDuvTg15mZ6HAtP74NjvFekr o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArgFACu5oVKQ/khL/2dsb2JhbABZgwc4g1C2AIElFm0HgiUBAQEEI0gNDQQPDQMBAgoWCwICCQMCAQIBNAcCCAYNBgIBAQWHeQ2xBo94F45/GAaCZYFIA5gUhkWLToMqOw X-IronPort-AV: E=Sophos;i="4.93,840,1378857600"; d="scan'208,217";a="1780743" Received: from ams-core-2.cisco.com ([144.254.72.75]) by aer-iport-1.cisco.com with ESMTP; 06 Dec 2013 11:52:08 +0000 Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id rB6Bq3P0021253 for ; Fri, 6 Dec 2013 11:52:04 GMT Message-ID: <52A1BA62.2050504@cisco.com> Date: Fri, 06 Dec 2013 12:52:02 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: "ipfix@ietf.org" References: <20131205204354.2488.3546.idtracker@ietfa.amsl.com> In-Reply-To: <20131205204354.2488.3546.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20131205204354.2488.3546.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------010505070905020903020901" Subject: [IPFIX] Fwd: New Addition to the IPFIX Experts X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 11:52:14 -0000 This is a multi-part message in MIME format. --------------010505070905020903020901 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit FYI. -------- Original Message -------- Subject: New Addition to the IPFIX Experts Date: Thu, 5 Dec 2013 12:43:54 -0800 From: IESG Secretary Reply-To: To: CC: IANA, The IESG has approved Andrew Feren (andrewf@plixer.com) as an additional expert for the IPFIX IANA registry at http://www.iana.org/assignments/ipfix/ipfix.xhtml. Best regards, IESG Secretary --------------010505070905020903020901 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit FYI.


-------- Original Message --------
Subject: New Addition to the IPFIX Experts
Date: Thu, 5 Dec 2013 12:43:54 -0800
From: IESG Secretary <iesg-secretary@ietf.org>
Reply-To: <iesg@ietf.org>
To: <iana@iana.org>
CC: <iesg@ietf.org> 


IANA,

The IESG has approved Andrew Feren (andrewf@plixer.com) as an additional 
expert for the IPFIX IANA registry at 
http://www.iana.org/assignments/ipfix/ipfix.xhtml.

Best regards,
IESG Secretary


--------------010505070905020903020901-- From iesg-secretary@ietf.org Wed Dec 11 15:21:40 2013 Return-Path: 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 2ADFB1A1F72; Wed, 11 Dec 2013 15:21:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 o7dk9miZKt3c; Wed, 11 Dec 2013 15:21:38 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 39CDE1AE0E7; Wed, 11 Dec 2013 15:21:35 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131211232135.9686.54837.idtracker@ietfa.amsl.com> Date: Wed, 11 Dec 2013 15:21:35 -0800 Cc: ipfix chair , ipfix mailing list , RFC Editor Subject: [IPFIX] Protocol Action: 'Operation of the IP Flow Information Export (IPFIX) Protocol on IPFIX Mediators' to Proposed Standard (draft-ietf-ipfix-mediation-protocol-10.txt) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 23:21:40 -0000 The IESG has approved the following document: - 'Operation of the IP Flow Information Export (IPFIX) Protocol on IPFIX Mediators' (draft-ietf-ipfix-mediation-protocol-10.txt) as Proposed Standard This document is the product of the IP Flow Information Export Working Group. The IESG contact persons are Joel Jaeggli and Benoit Claise. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-ipfix-mediation-protocol/ Technical Summary This document specifies the operation of the IP Flow Information Export (IPFIX) protocol specific to IPFIX Mediators, including Template and Observation Point management, timing considerations, and other Mediator-specific concerns. The document is intended to be a Proposed Standard. It explains, in detail, how IPFIX Mediators should be configured so that IPFIX Exporters and Collectors can work properly (i.e. produce correct expected behaviour) through them. Working Group Summary This draft was first submitted in December 2011. Two of its authors are also authors of the two IPFIX Mediation RFCs, 5982 and 6183. Since then it has received ongoing low-activity-level discussion on the IPFIX list. It has also been discussed at each IETF meeting since then; consensus from those meetings was that the work covered by this draft was needed so that IPFIX mediators could be deployed and used effectively. The draft acknowledges that this work on this is partially supported by the mPlane project, implying that there is strong interest in it within mPlane. Document Quality The document has recieved careful review by Rahul Patel, Paul Aitken and Andrew Ferren Personnel Document shepherd: Nevil Brownlee Responsible Area Director: Joel Jaegli From trammell@tik.ee.ethz.ch Wed Dec 18 10:04:29 2013 Return-Path: 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 B5A631AE006 for ; Wed, 18 Dec 2013 10:04:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.738 X-Spam-Level: X-Spam-Status: No, score=-4.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538] autolearn=unavailable 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 tl8suoqKqbHH for ; Wed, 18 Dec 2013 10:04:28 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id BA8891AE0A6 for ; Wed, 18 Dec 2013 10:04:26 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id EDC8AD9302; Wed, 18 Dec 2013 19:04:23 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 0htPnQLL3BqQ; Wed, 18 Dec 2013 19:04:23 +0100 (MET) Received: from thaleia.local (cust-integra-122-165.antanet.ch [80.75.122.165]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id AEC9DD9300; Wed, 18 Dec 2013 19:04:22 +0100 (MET) Message-ID: <52B1E3A2.4020606@tik.ee.ethz.ch> Date: Wed, 18 Dec 2013 19:04:18 +0100 From: Brian Trammell User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: IPFIX Working Group , nmrg@irtf.org X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: [IPFIX] Reminder: TRAC 2014 CFP -- http://trac2014.ftw.at/ X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Dec 2013 18:04:29 -0000 Greetings, all, The following venue may be of interest to those of you doing network measurement research; the deadline is coming up shortly after the holidays. Cheers, Brian CALL FOR PAPERS TRAC 2014 -- 5th International Workshop on TRaffic Analysis and Characterization Technically Sponsored by IEEE and FP7 mPlane August 4-8 2014 Nicosia, CYPRUS SCOPE The continued evolution of the Internet is characterized by dramatic changes in the way users behave, interact with and use the network. Today's Internet content and applications are increasingly delivered by ever larger content delivery networks (CDNs) and cloud infrastructures. Other changes in the Internet, such as the explosion of mobile traffic and the growing deployment of encryption (e.g. HTTPS Everywhere) demand new approaches for characterizing and analyzing network traffic. Malicious and abusive traffic continues to evolve as well, and techniques for detection must evolve in kind. The fifth edition of the TRAC workshop continues to serve as a forum for scientists and engineers in academia and industry to exchange and discuss their experiences and research results about all aspects of traffic classification, characterization, and analysis. TOPICS The workshop is soliciting high quality papers discussing original and innovative experimental activities, unpublished and not currently submitted for publication elsewhere, on topics including (but not limited) to the following: * Traffic analysis and characterization algorithms and techniques * Detection, analysis, and classification of network anomalies * Platforms for on-line, real-time traffic analysis and characterization * Evaluation of traffic classification and analysis techniques * Data-reduction techniques for traffic analysis and visualization * Privacy-preservation in traffic analysis, classification, and characterization * Effects of anonymization on traffic analysis, classification, and characterization * Identification and classification of encrypted traffic * Advanced algorithms for deep packet inspection * Post-DPI approaches for traffic classification * Applications of traffic analysis to network security * Traffic analysis studies on operational networks and large-scale traffic data sets * Applications of traffic analysis to network operations and management * Ultra-high rate (10 - 100Gbit) traffic analysis, classification, and characterization * Analysis and characterization of mobile and wireless traffic * Forwarding-plane support for network measurement and analysis SUBMISSIONS Prospective authors are invited to submit their papers using the EDAS system. Submitted papers must be no longer than six (6) IEEE style pages including results, figures and references. Papers will be reviewed by the standard reviewing procedure. Accepted papers will be published on the IEEE Xplore Digital Library IMPORTANT DATES Paper submission: January 15, 2014 Notifications: March 15, 2014 Camera-ready: April 1, 2014 ORGANIZING COMMITTEE Workshop Chairs: * Pedro Casas (FTW Vienna Research Center, Austria) * Brian Trammell (ETH Zurich, Switzerland) Honorary Chairs: * Christian Callegari (University of Pisa, Italy) * Sandrine Vaton (TELECOM Bretagne, France) From n.brownlee@auckland.ac.nz Thu Dec 19 12:29:33 2013 Return-Path: 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 622D31AE7CE for ; Thu, 19 Dec 2013 12:29:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.538, 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 MMMl1t_x4Mqt for ; Thu, 19 Dec 2013 12:29:30 -0800 (PST) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) by ietfa.amsl.com (Postfix) with ESMTP id 6F62F1AE7CD for ; Thu, 19 Dec 2013 12:29:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1387484969; x=1419020969; h=message-id:date:from:mime-version:to:cc:subject; bh=XJWuXbsGyaz6OYAqdZOwERRAkIQVfGMQzx2Qba5gqfM=; b=Ea+zDt4oJC48a7l5Gi4juC1eWsDwsLnKmAdL7HpAUYzsShsKjkDngDDo vr6E8DuUCgDnLgBGxAMyQ7DAd7yw+YtWNaHzMQiNKcqO8OKHHucU1K00A x026RfRZRyiVT4kfLBKztwiHQJmj16KyuhS6HiAqkllutj9lgJw0efMiP I=; X-IronPort-AV: E=Sophos;i="4.95,514,1384254000"; d="txt'?scan'208";a="227608162" X-Ironport-HAT: UNIVERSITY - $RELAY-THROTTLE X-Ironport-Source: 130.216.38.131 - Outgoing - Outgoing-SSL Received: from nevil-laptop1.sfac.auckland.ac.nz (HELO [130.216.38.131]) ([130.216.38.131]) by mx2-int.auckland.ac.nz with ESMTP; 20 Dec 2013 09:29:27 +1300 Message-ID: <52B35727.1010106@auckland.ac.nz> Date: Fri, 20 Dec 2013 09:29:27 +1300 From: Nevil Brownlee User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Joel Jaeggli Content-Type: multipart/mixed; boundary="------------010903020201000204030008" Cc: IPFIX Working Group Subject: [IPFIX] Shepherd writeup for cisco-ies draft X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Dec 2013 20:29:33 -0000 This is a multi-part message in MIME format. --------------010903020201000204030008 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Joel: Here's the writeup for the cicso-ies draft. Cheers, Nevil -- --------------------------------------------------------------------- Nevil Brownlee Computer Science Department Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand --------------010903020201000204030008 Content-Type: text/plain; charset=UTF-8; name="shepherd-cisco-ies.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="shepherd-cisco-ies.txt" Write-up for: draft-yourtchenko-cisco-ies-08 Cisco Specific Information Elements reused in IPFIX === 1. Summary === Document shepherd: Nevil Brownlee Responsible Area Director: Joel Jaeggli The document is intended to be Informational, AD-sponsored by Joel. It describes additional Information Elements of Cisco Systems, Inc. that are not listed in RFC3954. Section 4 of [RFC7012] defines the IPFIX Information Elements in the range of 1-127 to be compatible with the NetFlow version 9 fields, as specified in the "Cisco Systems NetFlow Services Export Version 9" [RFC3954]. Since [RFC3954] was specified in 2004, it does not contain all NetFlow version 9 specific fields in the range 1-127. This document is intended to complete the IPFIX Information Elements IANA registry, filling the gaps in the range 1-127. === 2. Review and Consensus === This draft's -00 version was published in July 2011. All three authors are from Cisco Systems. Since then the draft was presented a few times during IPFIX meetings. However, not much feedback was received as this is mainly a FYI-type of document. Nonetheless, there is clear value in the document, as the range 1-127 was in fact a gimmick to take into account the NetFlow evolution while the IPFIX standard was being specified. === 3. Intellectual Property === No IPR disclosures have been made directly on this draft, IPR on it has not been discussed in the WG. === 4. Other Points === This document has no downward references. Its IANA Considerations clearly state what IANA is being asked to do, i.e. add some new IPFIX Information Elements to the IPFIX Information Element Registry. Note that one author is one of the IE-Doctors. The ID-nits checker has no complaints. Overall, I believe that this draft is ready for publication as an RFC. ============================== --------------010903020201000204030008-- From bclaise@cisco.com Tue Dec 24 02:56:36 2013 Return-Path: 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 C1A441ADEA7 for ; Tue, 24 Dec 2013 02:56:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.038 X-Spam-Level: X-Spam-Status: No, score=-10.038 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 QbQ48ygz3ROO for ; Tue, 24 Dec 2013 02:56:34 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) by ietfa.amsl.com (Postfix) with ESMTP id 8B7041ADBCE for ; Tue, 24 Dec 2013 02:56:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5234; q=dns/txt; s=iport; t=1387882591; x=1389092191; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=WvrDF3705eD4Nuw4Lv4S2RQXMzQeYs7hrlZs0Nbd+dk=; b=lS6M8+iRZd28oWwBvWUM2zSHxz9S9oySXMngh5i4Afcf9QHu0mLPfImk AzarTUppEcRHvE5qod0OJFi0QsVioWwMKr3+VJlRa1d7oeJqYDJ4LoJwq NDVtN4sFy/jGp0OOGCai6qMNflI5sd+w6KZi8m2rtSQKW4hYeVjIlXlSI Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhUFAFhnuVKtJXG9/2dsb2JhbABZgws4iTGxH4EcFnSCJQEBAQR4DQQcAwECChYECwkDAgECATsCCAYNBgIBARCHcA3KbxePCgwMBoQwBJgXhkWLT4FvgT87 X-IronPort-AV: E=Sophos;i="4.95,542,1384300800"; d="scan'208,217";a="8839717" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by alln-iport-7.cisco.com with ESMTP; 24 Dec 2013 10:56:30 +0000 Received: from [10.82.235.103] (rtp-vpn5-868.cisco.com [10.82.235.103]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id rBOAuT8N010611 for ; Tue, 24 Dec 2013 10:56:30 GMT Message-ID: <52B9685D.8040406@cisco.com> Date: Tue, 24 Dec 2013 11:56:29 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "ipfix@ietf.org" References: <20131224011416.EE4E77FC3A1@rfc-editor.org> In-Reply-To: <20131224011416.EE4E77FC3A1@rfc-editor.org> X-Forwarded-Message-Id: <20131224011416.EE4E77FC3A1@rfc-editor.org> Content-Type: multipart/alternative; boundary="------------080206070509080601040102" Subject: [IPFIX] Fwd: [RFC State] has been added to the RFC Editor database X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Dec 2013 10:56:36 -0000 This is a multi-part message in MIME format. --------------080206070509080601040102 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Congrats to the authors, document shepherd Nevil, WG chairs, and the community who helped with this draft. Regards, Benoit -------- Original Message -------- Subject: [RFC State] has been added to the RFC Editor database Date: Mon, 23 Dec 2013 17:14:16 -0800 From: To: , CC: , , Author(s), We have received notice that your document draft-trammell-ipfix-tcpcontrolbits-revision-05 has been approved for publication as an RFC. The document has been added to the RFC Editor queue and you can check the status at If you submitted your XML file using the I-D submission tool, we have already retrieved it. If you did not submit the XML file via the I-D submission tool, or if you have an updated version (e.g., updated contact information), please send us the XML file at this time. Please attach the file as draft-trammell-ipfix-tcpcontrolbits-revision-05.xml, and specify any differences between the approved I-D and the document that the XML produces. If you created this document using -ms nroff, please send us the source file. This should help increase the pace with which documents move through the RFC Editor queue. Please let us know if you have any questions. Thank you. The RFC Editor Team . --------------080206070509080601040102 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Congrats to the authors, document shepherd Nevil, WG chairs, and the community who helped with this draft.

Regards, Benoit


-------- Original Message --------
Subject: [RFC State] <draft-trammell-ipfix-tcpcontrolbits-revision-05> has been added to the RFC Editor database
Date: Mon, 23 Dec 2013 17:14:16 -0800
From: <rfc-editor@rfc-editor.org>
To: <trammell@tik.ee.ethz.ch>, <paitken@cisco.com>
CC: <rfc-editor@rfc-editor.org>, <rfc-ise@rfc-editor.org>, <bclaise@cisco.com> 


Author(s),

We have received notice that your document draft-trammell-ipfix-tcpcontrolbits-revision-05 has
been approved for publication as an RFC.  The document has
been added to the RFC Editor queue and you can check the status at
<http://www.rfc-editor.org/queue2.html#draft-trammell-ipfix-tcpcontrolbits-revision>

If you submitted your XML file using the I-D submission tool, we have
already retrieved it.  If you did not submit the XML file via the I-D
submission tool, or if you have an updated version (e.g., updated
contact information), please send us the XML file at this time. Please
attach the file as draft-trammell-ipfix-tcpcontrolbits-revision-05.xml, and specify 
any differences between the approved I-D and the document that the XML produces.

If you created this document using -ms nroff, please send us the
source file.

This should help increase the pace with which documents move through
the RFC Editor queue. 

Please let us know if you have any questions.

Thank you.

The RFC Editor Team

.


--------------080206070509080601040102-- From bclaise@cisco.com Tue Dec 24 03:06:06 2013 Return-Path: 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 68C221AD83F for ; Tue, 24 Dec 2013 03:06:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.039 X-Spam-Level: X-Spam-Status: No, score=-10.039 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 JThCC-c0zPmh for ; Tue, 24 Dec 2013 03:06:05 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) by ietfa.amsl.com (Postfix) with ESMTP id D76D81A802A for ; Tue, 24 Dec 2013 03:06:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=675; q=dns/txt; s=iport; t=1387883161; x=1389092761; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=EX3/0h0Hql3XJBPjuRbQ2pPucH6B2eDAL5NKW+EDPo8=; b=mFRwAet1XS2pFJnLIZMdHgsw6EJXHojGR6Asucoyj803GfB7va6HZ+hi Qg10c7CfGqLevAeONogPX/BbXXW0gCJXasBYtYCppkagk8NoYu9QvwiEC 1TscNqBW5rNMbuzafhwjpQznlw9yGjdOZJwJbnUPzJo7bYEFepgsQSP83 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFANxpuVKtJXG+/2dsb2JhbABZgws4ulCBHRZ0giYBAQQ4QAEQLBYPCQMCAQIBRRMBBwEBiAANymkTBI8bBxaEIAEDmBeGRYtPgy47 X-IronPort-AV: E=Sophos;i="4.95,542,1384300800"; d="scan'208";a="8835132" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by alln-iport-6.cisco.com with ESMTP; 24 Dec 2013 11:06:01 +0000 Received: from [10.82.235.103] (rtp-vpn5-868.cisco.com [10.82.235.103]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id rBOB5xp8023548; Tue, 24 Dec 2013 11:06:00 GMT Message-ID: <52B96A97.1030408@cisco.com> Date: Tue, 24 Dec 2013 12:05:59 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: draft-ietf-ipfix-data-link-layer-monitoring@tools.ietf.org References: <52A5975A.7000900@cisco.com> In-Reply-To: <52A5975A.7000900@cisco.com> X-Forwarded-Message-Id: <52A5975A.7000900@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ipfix@ietf.org" Subject: [IPFIX] draft-ietf-ipfix-data-link-layer-monitoring status X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Dec 2013 11:06:06 -0000 Dear authors, A gentle reminder that this draft is in "Approved-announcement to be sent::Revised I-D Needed" for 33 days See https://datatracker.ietf.org/doc/draft-ietf-ipfix-data-link-layer-monitoring/ This state is a new state that the IESG implemented recently to improve the speed of documents delivery. It means that the document is approved, but that agreed changes should be included in a new version before the draft goes in the RFC editor queue. However, 33 days in that state is way too long in my opinion, and defeats the purpose of this new document state. If you don't know what to do, let the document shepherd or me know. Regards, Benoit From paitken@cisco.com Tue Dec 24 05:52:42 2013 Return-Path: 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 E02C71ADF4E for ; Tue, 24 Dec 2013 05:52:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.039 X-Spam-Level: X-Spam-Status: No, score=-10.039 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 c_xa49nlN0Au for ; Tue, 24 Dec 2013 05:52:41 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id 10D181ADF23 for ; Tue, 24 Dec 2013 05:52:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1145; q=dns/txt; s=iport; t=1387893157; x=1389102757; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=671gMfNZdqZPtBIH5QmzarORrZK3zOMvndsXvFnzlCI=; b=C6nAkyq0OUJHeeHSjeslfBbJc0PZFB1rppuqouVk7Sh7q5Skgf1l69np tDyDH/42jxnaab75+vZqD+WOSoLOt7gUVimLy2bt9nN9x9w+6zHMrjctY vPupeZM/8k49PWZbbx1oNq1zHdsmK6LqBzcaBj1+Gz8/R50aacyoWCwL3 o=; X-IronPort-AV: E=Sophos;i="4.95,543,1384300800"; d="scan'208";a="2051443" Received: from ams-core-3.cisco.com ([144.254.72.76]) by aer-iport-2.cisco.com with ESMTP; 24 Dec 2013 13:52:36 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id rBODqaYi031705 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Dec 2013 13:52:36 GMT Received: from [10.21.69.138] (sjc-vpn3-1418.cisco.com [10.21.69.138]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id rBODqYCU024044; Tue, 24 Dec 2013 13:52:35 GMT Message-ID: <52B9919D.1090609@cisco.com> Date: Tue, 24 Dec 2013 06:52:29 -0700 From: Paul Aitken User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Benoit Claise , draft-ietf-ipfix-data-link-layer-monitoring@tools.ietf.org References: <52A5975A.7000900@cisco.com> <52B96A97.1030408@cisco.com> In-Reply-To: <52B96A97.1030408@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] draft-ietf-ipfix-data-link-layer-monitoring status X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Dec 2013 13:52:43 -0000 Benoit, Thanks for this (second) reminder. As I told you before, I will work on this document during the holidays. We have discussed the reasons for that many times. I'm connected <7am on Christmas Eve for this specific purpose. P. On 24/12/2013 04:05, Benoit Claise wrote: > Dear authors, > > A gentle reminder that this draft is in "Approved-announcement to be > sent::Revised I-D Needed" for 33 days > See > https://datatracker.ietf.org/doc/draft-ietf-ipfix-data-link-layer-monitoring/ > This state is a new state that the IESG implemented recently to > improve the speed of documents delivery. > It means that the document is approved, but that agreed changes should > be included in a new version before the draft goes in the RFC editor > queue. > However, 33 days in that state is way too long in my opinion, and > defeats the purpose of this new document state. > If you don't know what to do, let the document shepherd or me know. > > Regards, Benoit > > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From paitken@cisco.com Tue Dec 24 15:21:38 2013 Return-Path: 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 1F9901AE12D; Tue, 24 Dec 2013 15:21:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.038 X-Spam-Level: X-Spam-Status: No, score=-10.038 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 o7-0Hyjvq87t; Tue, 24 Dec 2013 15:21:36 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id 1BA291AE12A; Tue, 24 Dec 2013 15:21:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3357; q=dns/txt; s=iport; t=1387927292; x=1389136892; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=jzl7lbtRmb6UU2MuyKAXY5twsMs7udeA0lr5MeZObEA=; b=FuAsxDU6Wa+4UmOiSCif7Q8kZfqfFA7ICjoM0vL+A/U44CB64SkVdrKV bmRpNy7fIBxo7cz2XPmeqAjYBXEMMQmsbaPfSsSiL0IF7vR/yCoghTq2o hmmnM2LlWkMpursDm3jUjcKQj5ncknCsxmZ6zZP1YdZouU4GQ5MmWMoH4 U=; X-IronPort-AV: E=Sophos;i="4.95,545,1384300800"; d="scan'208,217";a="2063492" Received: from ams-core-2.cisco.com ([144.254.72.75]) by aer-iport-2.cisco.com with ESMTP; 24 Dec 2013 23:21:31 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id rBONLVdn007937 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Dec 2013 23:21:31 GMT Received: from [10.21.69.138] (sjc-vpn3-1418.cisco.com [10.21.69.138]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id rBONLSsP012699; Tue, 24 Dec 2013 23:21:29 GMT Message-ID: <52BA16F3.4000507@cisco.com> Date: Tue, 24 Dec 2013 16:21:23 -0700 From: Paul Aitken User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Ben Campbell , Benoit Claise References: <9F0317F4-CAC5-49C7-89C8-199FA2B78DF0@nostrum.com> <528DF263.3010908@cisco.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------000000050301030005010201" Cc: "gen-art@ietf.org Team \(gen-art@ietf.org\)" , draft-ietf-ipfix-data-link-layer-monitoring.all@tools.ietf.org, ipfix@ietf.org Subject: Re: [IPFIX] Gen-ART Telechat Review of draft-ietf-ipfix-data-link-layer-monitoring-07 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Dec 2013 23:21:38 -0000 This is a multi-part message in MIME format. --------------000000050301030005010201 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Benoit, Ben, >>> As I understand it the context is that certain data elements can include payload octets. This is subject to the security considerations in 5477, which basically say don't include too much, because of guidance from 2804. But my reading of 2804 does not give specific guidance things like how much payload one can capture before it becomes too much. >>> >>> I think the simplest solution would be to keep the reference to the 5477 security considerations, and reiterate that this model is not intended for gross capture of payloads, perhaps with an _informative_ reference to 2804. >> The informative reference would be in line with RFC 5477. So yes. >> Not sure if we need the reiteration. > I think a sentence or two would save the reader from having to flip back and forth between docs. But it's not a big deal one way or ahother. I've moved RFC2804 to an Informative reference, and changed the text to say: With sufficient length, this element also reports octets from the IP payload. However full packet capture of arbitrary packet streams is explicitly out of scope per the Security Considerations section of RFC5477 and RFC2804. P. --------------000000050301030005010201 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Benoit, Ben,

As I understand it the context is that certain data elements can include payload octets. This is subject to the security considerations in 5477, which basically say don't include too much, because of guidance from 2804. But my reading of 2804 does not give specific guidance things like how much payload one can capture before it becomes too much.

I think the simplest solution would be to keep the reference to the 5477 security considerations, and reiterate that this model is not intended for gross capture of payloads, perhaps with an _informative_ reference to 2804.

The informative reference would be in line with RFC 5477. So yes.
Not sure if we need the reiteration.

I think a sentence or two would save the reader from having to flip back and forth between docs. But it's not a big deal one way or ahother.

I've moved RFC2804 to an Informative reference, and changed the text to say:

With sufficient length, this element also reports octets from the IP payload. However full packet capture of arbitrary packet streams is explicitly out of scope per the Security Considerations section of RFC5477 and RFC2804.

P.
--------------000000050301030005010201-- From internet-drafts@ietf.org Tue Dec 24 15:27:05 2013 Return-Path: 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 2671E1AE00A; Tue, 24 Dec 2013 15:27:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 H0kGlLZia9ef; Tue, 24 Dec 2013 15:27:03 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C8151AE131; Tue, 24 Dec 2013 15:27:03 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.90 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131224232703.27726.24565.idtracker@ietfa.amsl.com> Date: Tue, 24 Dec 2013 15:27:03 -0800 Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action: draft-ietf-ipfix-data-link-layer-monitoring-08.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Dec 2013 23:27:05 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IP Flow Information Export Working Group = of the IETF. Title : Information Elements for Data Link Layer Traffic = Measurement Authors : Shingo Kashima Atsushi Kobayashi Paul Aitken Filename : draft-ietf-ipfix-data-link-layer-monitoring-08.txt Pages : 38 Date : 2013-12-24 Abstract: This document describes Information Elements related to the data link layer. They are used by the IP Flow Information Export (IPFIX) protocol for encoding measured data link layer traffic information. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipfix-data-link-layer-monitorin= g/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ipfix-data-link-layer-monitoring-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipfix-data-link-layer-monitor= ing-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ben@nostrum.com Tue Dec 24 21:06:35 2013 Return-Path: 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 9C2551AE1F5; Tue, 24 Dec 2013 21:06:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.036 X-Spam-Level: X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no 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 AFfP-JMlQrqE; Tue, 24 Dec 2013 21:06:34 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4966B1AE160; Tue, 24 Dec 2013 21:06:34 -0800 (PST) Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id rBP56PWW030402 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 24 Dec 2013 23:06:26 -0600 (CST) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ben Campbell In-Reply-To: <52BA16F3.4000507@cisco.com> Date: Tue, 24 Dec 2013 23:06:24 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9F0317F4-CAC5-49C7-89C8-199FA2B78DF0@nostrum.com> <528DF263.3010908@cisco.com> <52BA16F3.4000507@cisco.com> To: Paul Aitken X-Mailer: Apple Mail (2.1827) Received-SPF: pass (shaman.nostrum.com: 173.172.146.58 is authenticated by a trusted mechanism) Cc: "gen-art@ietf.org Team \(gen-art@ietf.org\)" , draft-ietf-ipfix-data-link-layer-monitoring.all@tools.ietf.org, ipfix@ietf.org Subject: Re: [IPFIX] Gen-ART Telechat Review of draft-ietf-ipfix-data-link-layer-monitoring-07 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Dec 2013 05:06:35 -0000 On Dec 24, 2013, at 5:21 PM, Paul Aitken wrote: > Benoit, Ben, >=20 >>>> As I understand it the context is that certain data elements can = include payload octets. This is subject to the security considerations = in 5477, which basically say don't include too much, because of guidance = from 2804. But my reading of 2804 does not give specific guidance things = like how much payload one can capture before it becomes too much. >>>>=20 >>>> I think the simplest solution would be to keep the reference to the = 5477 security considerations, and reiterate that this model is not = intended for gross capture of payloads, perhaps with an _informative_ = reference to 2804. >>>>=20 >>> The informative reference would be in line with RFC 5477. So yes. >>> Not sure if we need the reiteration. >>>=20 >> I think a sentence or two would save the reader from having to flip = back and forth between docs. But it's not a big deal one way or ahother. >>=20 >=20 > I've moved RFC2804 to an Informative reference, and changed the text = to say: >=20 > With sufficient length, this element also reports octets from the IP = payload. However full packet capture of arbitrary packet streams is = explicitly out of scope per the Security Considerations section of = RFC5477 and RFC2804. Works for me. Thanks, Ben. (P.S. Happy [whichever holiday works for you] )= From paitken@cisco.com Thu Dec 26 14:51:20 2013 Return-Path: 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 D8F5F1AE086 for ; Thu, 26 Dec 2013 14:51:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.039 X-Spam-Level: X-Spam-Status: No, score=-10.039 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 kEN3l9rZ_ubd for ; Thu, 26 Dec 2013 14:51:19 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id 85C9D1AE080 for ; Thu, 26 Dec 2013 14:51:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=162; q=dns/txt; s=iport; t=1388098275; x=1389307875; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=wl4J+EA1SCL3bLpqc8NQ11k84DC9gsfTyXEDdvBswwY=; b=QvEucIYeXHwj+OiRcEpB6F0h6bbyIAzpI3V9LXywsxqY/lbZPxq9FgCG kV5Y+tF4foxLBaJr3EHWtIz7OUU3ZJGH5HLJlJQqPdpeLJanBBqFD6tDb PoTsykb0B3cNOO1FSNX8wh3lx3gpiG658D+0UwE+Vf5V0MQeuYKaIf5lk Y=; X-IronPort-AV: E=Sophos;i="4.95,557,1384300800"; d="scan'208";a="2136481" Received: from ams-core-1.cisco.com ([144.254.72.81]) by aer-iport-2.cisco.com with ESMTP; 26 Dec 2013 22:51:14 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id rBQMpDbr016078 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Dec 2013 22:51:14 GMT Received: from [10.21.67.227] (sjc-vpn3-995.cisco.com [10.21.67.227]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id rBQMpCdC026503; Thu, 26 Dec 2013 22:51:12 GMT Message-ID: <52BCB2DA.4040908@cisco.com> Date: Thu, 26 Dec 2013 15:51:06 -0700 From: Paul Aitken User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "Carlos Pignataro (cpignata)" , IETF IPFIX Working Group References: <52BCA68B.9000301@cisco.com> <9B2768D6-E87B-4D24-98B5-EB736C8CBFEE@cisco.com> In-Reply-To: <9B2768D6-E87B-4D24-98B5-EB736C8CBFEE@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [IPFIX] producing plain-text IETF drafts on a mac ? X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Dec 2013 22:51:21 -0000 Carlos, > xml2rfc? Not when the source is .docx, or .odf. The windows / linux generic-text-printer option doesn't seem to be available for mac. P. From wwwrun@rfc-editor.org Mon Dec 30 07:13:40 2013 Return-Path: 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 0AF051AE18E for ; Mon, 30 Dec 2013 07:13:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.26 X-Spam-Level: X-Spam-Status: No, score=0.26 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.538, SPF_HELO_PASS=-0.001, 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 Lc5jRtzz2EXX for ; Mon, 30 Dec 2013 07:13:37 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2607:f170:8000:1500::d3]) by ietfa.amsl.com (Postfix) with ESMTP id F03451AE01F for ; Mon, 30 Dec 2013 07:13:36 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 29E9F7FC393; Mon, 30 Dec 2013 07:13:31 -0800 (PST) To: bclaise@cisco.com, trammell@tik.ee.ethz.ch, bclaise@cisco.com, joelja@bogus.com, n.brownlee@auckland.ac.nz, quittek@neclab.eu From: RFC Errata System Message-Id: <20131230151331.29E9F7FC393@rfc-editor.org> Date: Mon, 30 Dec 2013 07:13:31 -0800 (PST) Cc: rfc-editor@rfc-editor.org, ipfix@ietf.org Subject: [IPFIX] [Technical Errata Reported] RFC7012 (3852) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Dec 2013 15:13:40 -0000 The following errata report has been submitted for RFC7012, "Information Model for IP Flow Information Export (IPFIX)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7012&eid=3852 -------------------------------------- Type: Technical Reported by: Stewart Bryant Section: 3.1.15-17 Original Text ------------- 3.1.15. dateTimeSeconds The type "dateTimeSeconds" represents a time value expressed with second-level precision. 3.1.16. dateTimeMilliseconds The type "dateTimeMilliseconds" represents a time value expressed with millisecond-level precision. 3.1.17. dateTimeMicroseconds The type "dateTimeMicroseconds" represents a time value expressed with microsecond-level precision. 3.1.18. dateTimeNanoseconds The type "dateTimeNanoseconds" represents a time value expressed with nanosecond-level precision. Corrected Text -------------- 3.1.15. dateTimeSeconds The type "dateTimeSeconds" represents a time value in units of seconds based on coordinated universal time (UTC). The choice of an epoch, for example, 00:00 UTC, January 1, 1970, is left to corresponding encoding specifications for this type, for example, the IPFIX protocol specification. Leap seconds are excluded. Note that transformation of values might be required between different encodings if different epoch values are used. 3.1.16. dateTimeMilliseconds The type "dateTimeMilliseconds" represents a time value in units of milliseconds based on coordinated universal time (UTC). The choice of an epoch, for example, 00:00 UTC, January 1, 1970, is left to corresponding encoding specifications for this type, for example, the IPFIX protocol specification. Leap seconds are excluded. Note that transformation of values might be required between different encodings if different epoch values are used. 3.1.17. dateTimeMicroseconds The type "dateTimeMicroseconds" represents a time value in units of microseconds based on coordinated universal time (UTC). The choice of an epoch, for example, 00:00 UTC, January 1, 1970, is left to corresponding encoding specifications for this type, for example, the IPFIX protocol specification. Leap seconds are excluded. Note that transformation of values might be required between different encodings if different epoch values are used. 3.1.18. dateTimeNanoseconds The type "dateTimeNanoseconds" represents a time value in units of nanoseconds based on coordinated universal time (UTC). The choice of an epoch, for example, 00:00 UTC, January 1, 1970, is left to corresponding encoding specifications for this type, for example, the IPFIX protocol specification. Leap seconds are excluded. Note that transformation of values might be required between different encodings if different epoch values are used. Notes ----- Although section 1.1 says : - "Definitions of timestamp data types have been clarified." The edited text has removed the epoch definition, and this does not seem to have been incorporated elsewhere in the RFC. Without a specified epoch, there is no unique definition of the timestamps. My proposal above is to revert to the RFC5102 definitions. RFC7102 is intended to be backwards compatible with RFC5102 and thus the definitions need to be technically identical. Alternatively, if the text is now included elsewhere in RFC7012 or in another RFC, it would be helpful to the reader to provide a reference to the epoch definition in an editorial update to dateTimeX definitions in RFC7102. 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. -------------------------------------- RFC7012 (draft-ietf-ipfix-information-model-rfc5102bis-10) -------------------------------------- Title : Information Model for IP Flow Information Export (IPFIX) Publication Date : September 2013 Author(s) : B. Claise, Ed., B. Trammell, Ed. Category : PROPOSED STANDARD Source : IP Flow Information Export Area : Operations and Management Stream : IETF Verifying Party : IESG From andrewf@plixer.com Mon Dec 30 08:23:28 2013 Return-Path: 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 E37D11AE532 for ; Mon, 30 Dec 2013 08:23:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] 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 ZF2_psfiSmQc for ; Mon, 30 Dec 2013 08:23:26 -0800 (PST) Received: from mx1.plixer.com (mx1.plixer.com [64.140.243.154]) by ietfa.amsl.com (Postfix) with ESMTP id AA5FF1AE12A for ; Mon, 30 Dec 2013 08:23:25 -0800 (PST) Received: from [10.1.15.178] (64.140.243.154) by mx1.plixer.com (10.1.5.1) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 30 Dec 2013 11:23:18 -0500 Message-ID: <52C19DF7.4050501@plixer.com> Date: Mon, 30 Dec 2013 11:23:19 -0500 From: Andrew Feren User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: RFC Errata System , , , , , References: <20131230151331.29E9F7FC393@rfc-editor.org> In-Reply-To: <20131230151331.29E9F7FC393@rfc-editor.org> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Cc: ipfix@ietf.org Subject: Re: [IPFIX] [Technical Errata Reported] RFC7012 (3852) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Dec 2013 16:23:29 -0000 The encoding for the time data types is specified RFC 7011 Sections 6.1.7 through 6.1.10. -Andrew On 12/30/2013 10:13 AM, RFC Errata System wrote: > The following errata report has been submitted for RFC7012, > "Information Model for IP Flow Information Export (IPFIX)". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=7012&eid=3852 > > -------------------------------------- > Type: Technical > Reported by: Stewart Bryant > > Section: 3.1.15-17 > > Original Text > ------------- > 3.1.15. dateTimeSeconds > > The type "dateTimeSeconds" represents a time value expressed with > second-level precision. > > 3.1.16. dateTimeMilliseconds > > The type "dateTimeMilliseconds" represents a time value expressed > with millisecond-level precision. > > 3.1.17. dateTimeMicroseconds > > The type "dateTimeMicroseconds" represents a time value expressed > with microsecond-level precision. > > 3.1.18. dateTimeNanoseconds > > The type "dateTimeNanoseconds" represents a time value expressed with > nanosecond-level precision. > > > Corrected Text > -------------- > 3.1.15. dateTimeSeconds > > The type "dateTimeSeconds" represents a time value in units of > seconds based on coordinated universal time (UTC). The choice of an > epoch, for example, 00:00 UTC, January 1, 1970, is left to > corresponding encoding specifications for this type, for example, the > IPFIX protocol specification. Leap seconds are excluded. Note that > transformation of values might be required between different > encodings if different epoch values are used. > > 3.1.16. dateTimeMilliseconds > > The type "dateTimeMilliseconds" represents a time value in units of > milliseconds based on coordinated universal time (UTC). The choice > of an epoch, for example, 00:00 UTC, January 1, 1970, is left to > corresponding encoding specifications for this type, for example, the > IPFIX protocol specification. Leap seconds are excluded. Note that > transformation of values might be required between different > encodings if different epoch values are used. > > 3.1.17. dateTimeMicroseconds > > The type "dateTimeMicroseconds" represents a time value in units of > microseconds based on coordinated universal time (UTC). The choice > of an epoch, for example, 00:00 UTC, January 1, 1970, is left to > corresponding encoding specifications for this type, for example, the > IPFIX protocol specification. Leap seconds are excluded. Note that > transformation of values might be required between different > encodings if different epoch values are used. > > 3.1.18. dateTimeNanoseconds > > The type "dateTimeNanoseconds" represents a time value in units of > nanoseconds based on coordinated universal time (UTC). The choice of > an epoch, for example, 00:00 UTC, January 1, 1970, is left to > corresponding encoding specifications for this type, for example, the > IPFIX protocol specification. Leap seconds are excluded. Note that > transformation of values might be required between different > encodings if different epoch values are used. > > > Notes > ----- > Although section 1.1 says : - "Definitions of timestamp data types have been clarified." The edited text has removed the epoch definition, and this does not seem to have been incorporated elsewhere in the RFC. > > Without a specified epoch, there is no unique definition of the timestamps. > > My proposal above is to revert to the RFC5102 definitions. RFC7102 is intended to be backwards compatible with RFC5102 and thus the definitions need to be technically identical. Alternatively, if the text is now included elsewhere in RFC7012 or in another RFC, it would be helpful to the reader to provide a reference to the epoch definition in an editorial update to dateTimeX definitions in RFC7102. > > 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. > > -------------------------------------- > RFC7012 (draft-ietf-ipfix-information-model-rfc5102bis-10) > -------------------------------------- > Title : Information Model for IP Flow Information Export (IPFIX) > Publication Date : September 2013 > Author(s) : B. Claise, Ed., B. Trammell, Ed. > Category : PROPOSED STANDARD > Source : IP Flow Information Export > Area : Operations and Management > Stream : IETF > Verifying Party : IESG > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From paitken@cisco.com Mon Dec 30 18:59:19 2013 Return-Path: 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 8FD231AE38C for ; Mon, 30 Dec 2013 18:59:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.039 X-Spam-Level: X-Spam-Status: No, score=-10.039 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 mryiJYZNgh9H for ; Mon, 30 Dec 2013 18:59:17 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id DCBDD1AE37E for ; Mon, 30 Dec 2013 18:59:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5565; q=dns/txt; s=iport; t=1388458751; x=1389668351; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=LZvTt10IPlhN2LT/nOjZhp1XbjELClMZ0gLxZDZyohk=; b=dBZWN8MZlGbkHv/JpRij/5hAy0oft0An2pyXoeLbuOAvWqVi/MDYaWMx 6eFj6c3xHNVS9BaL0a8JTK71/9Xk9cc6C7tZCAw4FurLWj2b7bs0fqlNJ 10cItbXItskutDRSIh27SwvgdQsdf/doppy+lfpV+4s+lSwHzgXN6Sqwe 8=; X-IronPort-AV: E=Sophos;i="4.95,578,1384300800"; d="scan'208";a="2972383" Received: from ams-core-1.cisco.com ([144.254.72.81]) by aer-iport-1.cisco.com with ESMTP; 31 Dec 2013 02:59:10 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id rBV2x9ei008191 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 31 Dec 2013 02:59:10 GMT Received: from [10.21.126.180] (sjc-vpn6-1716.cisco.com [10.21.126.180]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id rBV2wuvE018159; Tue, 31 Dec 2013 02:58:58 GMT Message-ID: <52C232EB.30802@cisco.com> Date: Mon, 30 Dec 2013 19:58:51 -0700 From: Paul Aitken User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Andrew Feren , RFC Errata System , bclaise@cisco.com, trammell@tik.ee.ethz.ch, joelja@bogus.com, n.brownlee@auckland.ac.nz, quittek@neclab.eu References: <20131230151331.29E9F7FC393@rfc-editor.org> <52C19DF7.4050501@plixer.com> In-Reply-To: <52C19DF7.4050501@plixer.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ipfix@ietf.org Subject: Re: [IPFIX] [Technical Errata Reported] RFC7012 (3852) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Dec 2013 02:59:19 -0000 +1 If anyone was going to raise an errata on this, it would have been me ;-) I've pointed this issue out before, probably more than once - and have been encouraged to read RFC 3444. P. On 30/12/2013 09:23, Andrew Feren wrote: > The encoding for the time data types is specified RFC 7011 Sections > 6.1.7 through 6.1.10. > > -Andrew > > On 12/30/2013 10:13 AM, RFC Errata System wrote: >> The following errata report has been submitted for RFC7012, >> "Information Model for IP Flow Information Export (IPFIX)". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=7012&eid=3852 >> >> -------------------------------------- >> Type: Technical >> Reported by: Stewart Bryant >> >> Section: 3.1.15-17 >> >> Original Text >> ------------- >> 3.1.15. dateTimeSeconds >> >> The type "dateTimeSeconds" represents a time value expressed with >> second-level precision. >> >> 3.1.16. dateTimeMilliseconds >> >> The type "dateTimeMilliseconds" represents a time value expressed >> with millisecond-level precision. >> >> 3.1.17. dateTimeMicroseconds >> >> The type "dateTimeMicroseconds" represents a time value expressed >> with microsecond-level precision. >> >> 3.1.18. dateTimeNanoseconds >> >> The type "dateTimeNanoseconds" represents a time value expressed with >> nanosecond-level precision. >> >> >> Corrected Text >> -------------- >> 3.1.15. dateTimeSeconds >> >> The type "dateTimeSeconds" represents a time value in units of >> seconds based on coordinated universal time (UTC). The choice of an >> epoch, for example, 00:00 UTC, January 1, 1970, is left to >> corresponding encoding specifications for this type, for example, the >> IPFIX protocol specification. Leap seconds are excluded. Note that >> transformation of values might be required between different >> encodings if different epoch values are used. >> >> 3.1.16. dateTimeMilliseconds >> >> The type "dateTimeMilliseconds" represents a time value in units of >> milliseconds based on coordinated universal time (UTC). The choice >> of an epoch, for example, 00:00 UTC, January 1, 1970, is left to >> corresponding encoding specifications for this type, for example, the >> IPFIX protocol specification. Leap seconds are excluded. Note that >> transformation of values might be required between different >> encodings if different epoch values are used. >> >> 3.1.17. dateTimeMicroseconds >> >> The type "dateTimeMicroseconds" represents a time value in units of >> microseconds based on coordinated universal time (UTC). The choice >> of an epoch, for example, 00:00 UTC, January 1, 1970, is left to >> corresponding encoding specifications for this type, for example, the >> IPFIX protocol specification. Leap seconds are excluded. Note that >> transformation of values might be required between different >> encodings if different epoch values are used. >> >> 3.1.18. dateTimeNanoseconds >> >> The type "dateTimeNanoseconds" represents a time value in units of >> nanoseconds based on coordinated universal time (UTC). The choice of >> an epoch, for example, 00:00 UTC, January 1, 1970, is left to >> corresponding encoding specifications for this type, for example, the >> IPFIX protocol specification. Leap seconds are excluded. Note that >> transformation of values might be required between different >> encodings if different epoch values are used. >> >> >> Notes >> ----- >> Although section 1.1 says : - "Definitions of timestamp data types have been clarified." The edited text has removed the epoch definition, and this does not seem to have been incorporated elsewhere in the RFC. >> >> Without a specified epoch, there is no unique definition of the timestamps. >> >> My proposal above is to revert to the RFC5102 definitions. RFC7102 is intended to be backwards compatible with RFC5102 and thus the definitions need to be technically identical. Alternatively, if the text is now included elsewhere in RFC7012 or in another RFC, it would be helpful to the reader to provide a reference to the epoch definition in an editorial update to dateTimeX definitions in RFC7102. >> >> 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. >> >> -------------------------------------- >> RFC7012 (draft-ietf-ipfix-information-model-rfc5102bis-10) >> -------------------------------------- >> Title : Information Model for IP Flow Information Export (IPFIX) >> Publication Date : September 2013 >> Author(s) : B. Claise, Ed., B. Trammell, Ed. >> Category : PROPOSED STANDARD >> Source : IP Flow Information Export >> Area : Operations and Management >> Stream : IETF >> Verifying Party : IESG >> _______________________________________________ >> 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 From trammell@tik.ee.ethz.ch Tue Dec 31 00:50:26 2013 Return-Path: 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 23AA71AE1D8 for ; Tue, 31 Dec 2013 00:50:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.738 X-Spam-Level: X-Spam-Status: No, score=-4.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538] 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 ccIbJtxk9dEF for ; Tue, 31 Dec 2013 00:50:23 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 090A61AE23B for ; Tue, 31 Dec 2013 00:50:23 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 4B65AD9303; Tue, 31 Dec 2013 09:50:16 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id j6qM79Up4lVg; Tue, 31 Dec 2013 09:50:16 +0100 (MET) Received: from [10.0.27.113] (cust-integra-122-165.antanet.ch [80.75.122.165]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id DAD8FD9300; Tue, 31 Dec 2013 09:50:12 +0100 (MET) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Brian Trammell In-Reply-To: <52C232EB.30802@cisco.com> Date: Tue, 31 Dec 2013 09:50:11 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <535E38C8-A1C0-4FD5-991C-D9A132D97923@tik.ee.ethz.ch> References: <20131230151331.29E9F7FC393@rfc-editor.org> <52C19DF7.4050501@plixer.com> <52C232EB.30802@cisco.com> To: Paul Aitken X-Mailer: Apple Mail (2.1827) Cc: "ipfix@ietf.org Group" , "joelja@bogus.com Jaeggli" , Nevil Brownlee , RFC Errata System Subject: Re: [IPFIX] [Technical Errata Reported] RFC7012 (3852) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Dec 2013 08:50:26 -0000 hi Paul, all, +n. The separation between ADTs and ADT encoding between 7012 and 7011 was = explicit and purposeful. Specifically, we do _not_ want to exclude other = representations of the IPFIX Information Model from being based upon = other encodings of these ADTs, whether ISO 8601 (which either has no = epoch or epoch 0000-00-00 00:00 UTC, depending on how you count), NTP = (1904), Julian day based counting, etc, etc, etc=85 If there is confusion on this point, I=92d suggest adding more = explanatory text on this point to Paragraph 2 of the front matter to = section 3.1. But as is, I emphatically recommend rejection of this = reported erratum. Best regards, Brian On 31 Dec 2013, at 03:58, Paul Aitken wrote: > +1 >=20 > If anyone was going to raise an errata on this, it would have been me = ;-) >=20 > I've pointed this issue out before, probably more than once - and have = been encouraged to read RFC 3444. >=20 > P. >=20 >=20 > On 30/12/2013 09:23, Andrew Feren wrote: >> The encoding for the time data types is specified RFC 7011 Sections >> 6.1.7 through 6.1.10. >>=20 >> -Andrew >>=20 >> On 12/30/2013 10:13 AM, RFC Errata System wrote: >>> The following errata report has been submitted for RFC7012, >>> "Information Model for IP Flow Information Export (IPFIX)". >>>=20 >>> -------------------------------------- >>> You may review the report below and at: >>> http://www.rfc-editor.org/errata_search.php?rfc=3D7012&eid=3D3852 >>>=20 >>> -------------------------------------- >>> Type: Technical >>> Reported by: Stewart Bryant >>>=20 >>> Section: 3.1.15-17 >>>=20 >>> Original Text >>> ------------- >>> 3.1.15. dateTimeSeconds >>>=20 >>> The type "dateTimeSeconds" represents a time value expressed with >>> second-level precision. >>>=20 >>> 3.1.16. dateTimeMilliseconds >>>=20 >>> The type "dateTimeMilliseconds" represents a time value expressed >>> with millisecond-level precision. >>>=20 >>> 3.1.17. dateTimeMicroseconds >>>=20 >>> The type "dateTimeMicroseconds" represents a time value expressed >>> with microsecond-level precision. >>>=20 >>> 3.1.18. dateTimeNanoseconds >>>=20 >>> The type "dateTimeNanoseconds" represents a time value expressed = with >>> nanosecond-level precision. >>>=20 >>>=20 >>> Corrected Text >>> -------------- >>> 3.1.15. dateTimeSeconds >>>=20 >>> The type "dateTimeSeconds" represents a time value in units of >>> seconds based on coordinated universal time (UTC). The choice of = an >>> epoch, for example, 00:00 UTC, January 1, 1970, is left to >>> corresponding encoding specifications for this type, for example, = the >>> IPFIX protocol specification. Leap seconds are excluded. Note = that >>> transformation of values might be required between different >>> encodings if different epoch values are used. >>>=20 >>> 3.1.16. dateTimeMilliseconds >>>=20 >>> The type "dateTimeMilliseconds" represents a time value in units = of >>> milliseconds based on coordinated universal time (UTC). The = choice >>> of an epoch, for example, 00:00 UTC, January 1, 1970, is left to >>> corresponding encoding specifications for this type, for example, = the >>> IPFIX protocol specification. Leap seconds are excluded. Note = that >>> transformation of values might be required between different >>> encodings if different epoch values are used. >>>=20 >>> 3.1.17. dateTimeMicroseconds >>>=20 >>> The type "dateTimeMicroseconds" represents a time value in units = of >>> microseconds based on coordinated universal time (UTC). The = choice >>> of an epoch, for example, 00:00 UTC, January 1, 1970, is left to >>> corresponding encoding specifications for this type, for example, = the >>> IPFIX protocol specification. Leap seconds are excluded. Note = that >>> transformation of values might be required between different >>> encodings if different epoch values are used. >>>=20 >>> 3.1.18. dateTimeNanoseconds >>>=20 >>> The type "dateTimeNanoseconds" represents a time value in units = of >>> nanoseconds based on coordinated universal time (UTC). The = choice of >>> an epoch, for example, 00:00 UTC, January 1, 1970, is left to >>> corresponding encoding specifications for this type, for example, = the >>> IPFIX protocol specification. Leap seconds are excluded. Note = that >>> transformation of values might be required between different >>> encodings if different epoch values are used. >>>=20 >>>=20 >>> Notes >>> ----- >>> Although section 1.1 says : - "Definitions of timestamp data types = have been clarified." The edited text has removed the epoch definition, = and this does not seem to have been incorporated elsewhere in the RFC. >>>=20 >>> Without a specified epoch, there is no unique definition of the = timestamps. >>>=20 >>> My proposal above is to revert to the RFC5102 definitions. RFC7102 = is intended to be backwards compatible with RFC5102 and thus the = definitions need to be technically identical. Alternatively, if the text = is now included elsewhere in RFC7012 or in another RFC, it would be = helpful to the reader to provide a reference to the epoch definition in = an editorial update to dateTimeX definitions in RFC7102. >>>=20 >>> 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. >>>=20 >>> -------------------------------------- >>> RFC7012 (draft-ietf-ipfix-information-model-rfc5102bis-10) >>> -------------------------------------- >>> Title : Information Model for IP Flow Information = Export (IPFIX) >>> Publication Date : September 2013 >>> Author(s) : B. Claise, Ed., B. Trammell, Ed. >>> Category : PROPOSED STANDARD >>> Source : IP Flow Information Export >>> Area : Operations and Management >>> Stream : IETF >>> Verifying Party : IESG >>> _______________________________________________ >>> 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 From stbryant@cisco.com Tue Dec 31 01:37:04 2013 Return-Path: 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 6F2AA1AE1A6 for ; Tue, 31 Dec 2013 01:37:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.039 X-Spam-Level: X-Spam-Status: No, score=-15.039 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 wPpf-CPey6PN for ; Tue, 31 Dec 2013 01:37:02 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id EEA151AE0A0 for ; Tue, 31 Dec 2013 01:37:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8043; q=dns/txt; s=iport; t=1388482616; x=1389692216; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=e0h9OWmTc9ekCrROgu/s4v6GPlpPfGHPybinEmhzNCo=; b=ccWa87ijYPeiIboaUX/0yzOQOHL4nZnAmALJtB3H6x0CR8cO12/bypRI pVI8enCNGUcdqF+nm69f4GvcPG8ezEyOEG6ogg0VYqDb35e4pulojds5U SUr2FMMGI8gsWJrIsoL1fWFxL1o2qD43QFj9E0OTwVtYesB3GyLWCMgIN s=; X-IronPort-AV: E=Sophos;i="4.95,580,1384300800"; d="scan'208";a="294569582" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-5.cisco.com with ESMTP; 31 Dec 2013 09:36:56 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id rBV9at0V011118 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 31 Dec 2013 09:36:55 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.230]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0123.003; Tue, 31 Dec 2013 03:36:55 -0600 From: "Stewart Bryant (stbryant)" To: Brian Trammell Thread-Topic: [IPFIX] [Technical Errata Reported] RFC7012 (3852) Thread-Index: AQHPBXG0FeT2zCgxjUSJ8sXFC0eRipptUJiAgACxkYCAAGIpgP//qHkC Date: Tue, 31 Dec 2013 09:36:54 +0000 Message-ID: <0BEF0D66-E9DB-40E7-A2E4-ABCBCA5634CB@cisco.com> References: <20131230151331.29E9F7FC393@rfc-editor.org> <52C19DF7.4050501@plixer.com> <52C232EB.30802@cisco.com>, <535E38C8-A1C0-4FD5-991C-D9A132D97923@tik.ee.ethz.ch> In-Reply-To: <535E38C8-A1C0-4FD5-991C-D9A132D97923@tik.ee.ethz.ch> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "joelja@bogus.com Jaeggli" , Nevil Brownlee , "ipfix@ietf.org Group" , RFC Errata System Subject: Re: [IPFIX] [Technical Errata Reported] RFC7012 (3852) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Dec 2013 09:37:04 -0000 Certainly something is needed. I was thinking of using IPFIX as an informat= ion gathering method in a radio context, and went to look at the definition= of the types and could not find the epoch, or even a reference to the epoc= h. Now part of the problem (which was my fault) was that I did not notice a= t the time that the elements were defined by the obsolete RFC5102 and went = straight to the new RFC. However having the definitions in an obsolete RFC = also seems problematic, since it puts the IEs in a strange state. Since RFC= 7012 replaces RFC5102 and includes the definitions you would expect the de= finition in RFC7012 to replace the definition in RFC5102, but those definit= ions are, as I explained incomplete. I need to look at this some more when = I get back to work, but I am now also concerned that if the epoch can chang= e, the definition of the existing IEs is now unreliable. You will notice in the errata that I did suggest that an alternative resolu= tion would be to include a reference to the epoch text. Stewart Sent from my iPad > On 31 Dec 2013, at 08:50, "Brian Trammell" wrot= e: >=20 > hi Paul, all, >=20 > +n. >=20 > The separation between ADTs and ADT encoding between 7012 and 7011 was ex= plicit and purposeful. Specifically, we do _not_ want to exclude other repr= esentations of the IPFIX Information Model from being based upon other enco= dings of these ADTs, whether ISO 8601 (which either has no epoch or epoch 0= 000-00-00 00:00 UTC, depending on how you count), NTP (1904), Julian day ba= sed counting, etc, etc, etc=85 >=20 > If there is confusion on this point, I=92d suggest adding more explanator= y text on this point to Paragraph 2 of the front matter to section 3.1. But= as is, I emphatically recommend rejection of this reported erratum. >=20 > Best regards, >=20 > Brian >=20 >> On 31 Dec 2013, at 03:58, Paul Aitken wrote: >>=20 >> +1 >>=20 >> If anyone was going to raise an errata on this, it would have been me ;-= ) >>=20 >> I've pointed this issue out before, probably more than once - and have b= een encouraged to read RFC 3444. >>=20 >> P. >>=20 >>=20 >>> On 30/12/2013 09:23, Andrew Feren wrote: >>> The encoding for the time data types is specified RFC 7011 Sections >>> 6.1.7 through 6.1.10. >>>=20 >>> -Andrew >>>=20 >>>> On 12/30/2013 10:13 AM, RFC Errata System wrote: >>>> The following errata report has been submitted for RFC7012, >>>> "Information Model for IP Flow Information Export (IPFIX)". >>>>=20 >>>> -------------------------------------- >>>> You may review the report below and at: >>>> http://www.rfc-editor.org/errata_search.php?rfc=3D7012&eid=3D3852 >>>>=20 >>>> -------------------------------------- >>>> Type: Technical >>>> Reported by: Stewart Bryant >>>>=20 >>>> Section: 3.1.15-17 >>>>=20 >>>> Original Text >>>> ------------- >>>> 3.1.15. dateTimeSeconds >>>>=20 >>>> The type "dateTimeSeconds" represents a time value expressed with >>>> second-level precision. >>>>=20 >>>> 3.1.16. dateTimeMilliseconds >>>>=20 >>>> The type "dateTimeMilliseconds" represents a time value expressed >>>> with millisecond-level precision. >>>>=20 >>>> 3.1.17. dateTimeMicroseconds >>>>=20 >>>> The type "dateTimeMicroseconds" represents a time value expressed >>>> with microsecond-level precision. >>>>=20 >>>> 3.1.18. dateTimeNanoseconds >>>>=20 >>>> The type "dateTimeNanoseconds" represents a time value expressed wit= h >>>> nanosecond-level precision. >>>>=20 >>>>=20 >>>> Corrected Text >>>> -------------- >>>> 3.1.15. dateTimeSeconds >>>>=20 >>>> The type "dateTimeSeconds" represents a time value in units of >>>> seconds based on coordinated universal time (UTC). The choice of an >>>> epoch, for example, 00:00 UTC, January 1, 1970, is left to >>>> corresponding encoding specifications for this type, for example, th= e >>>> IPFIX protocol specification. Leap seconds are excluded. Note that >>>> transformation of values might be required between different >>>> encodings if different epoch values are used. >>>>=20 >>>> 3.1.16. dateTimeMilliseconds >>>>=20 >>>> The type "dateTimeMilliseconds" represents a time value in units of >>>> milliseconds based on coordinated universal time (UTC). The choice >>>> of an epoch, for example, 00:00 UTC, January 1, 1970, is left to >>>> corresponding encoding specifications for this type, for example, th= e >>>> IPFIX protocol specification. Leap seconds are excluded. Note that >>>> transformation of values might be required between different >>>> encodings if different epoch values are used. >>>>=20 >>>> 3.1.17. dateTimeMicroseconds >>>>=20 >>>> The type "dateTimeMicroseconds" represents a time value in units of >>>> microseconds based on coordinated universal time (UTC). The choice >>>> of an epoch, for example, 00:00 UTC, January 1, 1970, is left to >>>> corresponding encoding specifications for this type, for example, th= e >>>> IPFIX protocol specification. Leap seconds are excluded. Note that >>>> transformation of values might be required between different >>>> encodings if different epoch values are used. >>>>=20 >>>> 3.1.18. dateTimeNanoseconds >>>>=20 >>>> The type "dateTimeNanoseconds" represents a time value in units of >>>> nanoseconds based on coordinated universal time (UTC). The choice o= f >>>> an epoch, for example, 00:00 UTC, January 1, 1970, is left to >>>> corresponding encoding specifications for this type, for example, th= e >>>> IPFIX protocol specification. Leap seconds are excluded. Note that >>>> transformation of values might be required between different >>>> encodings if different epoch values are used. >>>>=20 >>>>=20 >>>> Notes >>>> ----- >>>> Although section 1.1 says : - "Definitions of timestamp data types hav= e been clarified." The edited text has removed the epoch definition, and th= is does not seem to have been incorporated elsewhere in the RFC. >>>>=20 >>>> Without a specified epoch, there is no unique definition of the timest= amps. >>>>=20 >>>> My proposal above is to revert to the RFC5102 definitions. RFC7102 is = intended to be backwards compatible with RFC5102 and thus the definitions n= eed to be technically identical. Alternatively, if the text is now included= elsewhere in RFC7012 or in another RFC, it would be helpful to the reader = to provide a reference to the epoch definition in an editorial update to da= teTimeX definitions in RFC7102. >>>>=20 >>>> 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. >>>>=20 >>>> -------------------------------------- >>>> RFC7012 (draft-ietf-ipfix-information-model-rfc5102bis-10) >>>> -------------------------------------- >>>> Title : Information Model for IP Flow Information Export= (IPFIX) >>>> Publication Date : September 2013 >>>> Author(s) : B. Claise, Ed., B. Trammell, Ed. >>>> Category : PROPOSED STANDARD >>>> Source : IP Flow Information Export >>>> Area : Operations and Management >>>> Stream : IETF >>>> Verifying Party : IESG >>>> _______________________________________________ >>>> 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 >=20 > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From trammell@tik.ee.ethz.ch Tue Dec 31 04:44:29 2013 Return-Path: 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 354E31AE270 for ; Tue, 31 Dec 2013 04:44:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.738 X-Spam-Level: X-Spam-Status: No, score=-4.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538] 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 b7o8SUsPpC8r for ; Tue, 31 Dec 2013 04:44:20 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 10C561ADFE4 for ; Tue, 31 Dec 2013 04:44:19 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id A9DF6D9305; Tue, 31 Dec 2013 13:44:12 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id y2+mcltJX9RM; Tue, 31 Dec 2013 13:44:12 +0100 (MET) Received: from thaleia.local (cust-integra-122-165.antanet.ch [80.75.122.165]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 349D1D9304; Tue, 31 Dec 2013 13:44:12 +0100 (MET) Message-ID: <52C2BC12.6090108@tik.ee.ethz.ch> Date: Tue, 31 Dec 2013 13:44:02 +0100 From: Brian Trammell User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: "Stewart Bryant (stbryant)" References: <20131230151331.29E9F7FC393@rfc-editor.org> <52C19DF7.4050501@plixer.com> <52C232EB.30802@cisco.com>, <535E38C8-A1C0-4FD5-991C-D9A132D97923@tik.ee.ethz.ch> <0BEF0D66-E9DB-40E7-A2E4-ABCBCA5634CB@cisco.com> In-Reply-To: <0BEF0D66-E9DB-40E7-A2E4-ABCBCA5634CB@cisco.com> X-Enigmail-Version: 1.2.3 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig7C43592A5B68C2E03FC50C71" Cc: "joelja@bogus.com Jaeggli" , Nevil Brownlee , "ipfix@ietf.org Group" , RFC Errata System Subject: Re: [IPFIX] [Technical Errata Reported] RFC7012 (3852) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Dec 2013 12:44:29 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig7C43592A5B68C2E03FC50C71 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable hi Stewart, Stewart Bryant (stbryant) wrote: > Certainly something is needed. I was thinking of using IPFIX as an info= rmation gathering method in a radio context, and went to look at the defi= nition of the types and could not find the epoch, or even a reference to = the epoch. Now part of the problem (which was my fault) was that I did no= t notice at the time that the elements were defined by the obsolete RFC51= 02 and went straight to the new RFC. However having the definitions in an= obsolete RFC also seems problematic, since it puts the IEs in a strange = state. Since RFC 7012 replaces RFC5102 and includes the definitions you w= ould expect the definition in RFC7012 to replace the definition in RFC510= 2, but those definitions are, as I explained incomplete. This is intentional. See below. > I need to look at this some more when I get back to work, but I am now = also concerned that if the epoch can change, the definition of the existi= ng IEs is now unreliable. The definition of the existing IEs is based upon the definition of the ADT itself in 7012 as well as the definition of the ADT representation within the IPFIX protocol in 7011. It is not the intention that reading 7012 tells you how to encode IEs for use with IPFIX; that's what section 6.1 of 7011 is for. > You will notice in the errata that I did suggest that an alternative re= solution would be to include a reference to the epoch text. The point is that the ADT _explicitly_ does not have a binding to an epoch, as epochs are only necessary when using integral representations of timestamps. IPFIX's representations for these ADTs are integral, but bindings to other representations need not be (see, for example, draft-trammell-ipfix-text-adt, which recommends ISO8601-style timestamps for textual representations of IE values). I'd suggest instead somehow expanding the present text in 7012 to reiterate that if you're using IPFIX, the representations of the ADTs are in 7011: OLD para 2 sec 3.1 7012: The current encodings of these data types for use with the IPFIX protocol are defined in [RFC7011]; encodings allowing the use of the IPFIX Information Elements [IANA-IPFIX] with other protocols may be defined in the future by referencing this document. NEW para 2 sec 3.1 7012: The abstract data type definitions in this section are intended only to define the values which can be taken by Information Elements of each type. The encodings of these data types for use with the IPFIX protocol are defined in Section 6.1 of [RFC7011]; encodings allowing the use of the IPFIX Information Elements [IANA-IPFIX] with other protocols may be defined in the future by referencing this document. Best regards, Brian > Stewart >=20 >=20 >=20 > Sent from my iPad >=20 >> On 31 Dec 2013, at 08:50, "Brian Trammell" w= rote: >> >> hi Paul, all, >> >> +n. >> >> The separation between ADTs and ADT encoding between 7012 and 7011 was= explicit and purposeful. Specifically, we do _not_ want to exclude other= representations of the IPFIX Information Model from being based upon oth= er encodings of these ADTs, whether ISO 8601 (which either has no epoch o= r epoch 0000-00-00 00:00 UTC, depending on how you count), NTP (1904), Ju= lian day based counting, etc, etc, etc=85 >> >> If there is confusion on this point, I=92d suggest adding more explana= tory text on this point to Paragraph 2 of the front matter to section 3.1= =2E But as is, I emphatically recommend rejection of this reported erratu= m. >> >> Best regards, >> >> Brian >> >>> On 31 Dec 2013, at 03:58, Paul Aitken wrote: >>> >>> +1 >>> >>> If anyone was going to raise an errata on this, it would have been me= ;-) >>> >>> I've pointed this issue out before, probably more than once - and hav= e been encouraged to read RFC 3444. >>> >>> P. >>> >>> >>>> On 30/12/2013 09:23, Andrew Feren wrote: >>>> The encoding for the time data types is specified RFC 7011 Sections >>>> 6.1.7 through 6.1.10. >>>> >>>> -Andrew >>>> >>>>> On 12/30/2013 10:13 AM, RFC Errata System wrote: >>>>> The following errata report has been submitted for RFC7012, >>>>> "Information Model for IP Flow Information Export (IPFIX)". >>>>> >>>>> -------------------------------------- >>>>> You may review the report below and at: >>>>> http://www.rfc-editor.org/errata_search.php?rfc=3D7012&eid=3D3852 >>>>> >>>>> -------------------------------------- >>>>> Type: Technical >>>>> Reported by: Stewart Bryant >>>>> >>>>> Section: 3.1.15-17 >>>>> >>>>> Original Text >>>>> ------------- >>>>> 3.1.15. dateTimeSeconds >>>>> >>>>> The type "dateTimeSeconds" represents a time value expressed with= >>>>> second-level precision. >>>>> >>>>> 3.1.16. dateTimeMilliseconds >>>>> >>>>> The type "dateTimeMilliseconds" represents a time value expressed= >>>>> with millisecond-level precision. >>>>> >>>>> 3.1.17. dateTimeMicroseconds >>>>> >>>>> The type "dateTimeMicroseconds" represents a time value expressed= >>>>> with microsecond-level precision. >>>>> >>>>> 3.1.18. dateTimeNanoseconds >>>>> >>>>> The type "dateTimeNanoseconds" represents a time value expressed = with >>>>> nanosecond-level precision. >>>>> >>>>> >>>>> Corrected Text >>>>> -------------- >>>>> 3.1.15. dateTimeSeconds >>>>> >>>>> The type "dateTimeSeconds" represents a time value in units of >>>>> seconds based on coordinated universal time (UTC). The choice of= an >>>>> epoch, for example, 00:00 UTC, January 1, 1970, is left to >>>>> corresponding encoding specifications for this type, for example,= the >>>>> IPFIX protocol specification. Leap seconds are excluded. Note t= hat >>>>> transformation of values might be required between different >>>>> encodings if different epoch values are used. >>>>> >>>>> 3.1.16. dateTimeMilliseconds >>>>> >>>>> The type "dateTimeMilliseconds" represents a time value in units = of >>>>> milliseconds based on coordinated universal time (UTC). The choi= ce >>>>> of an epoch, for example, 00:00 UTC, January 1, 1970, is left to >>>>> corresponding encoding specifications for this type, for example,= the >>>>> IPFIX protocol specification. Leap seconds are excluded. Note t= hat >>>>> transformation of values might be required between different >>>>> encodings if different epoch values are used. >>>>> >>>>> 3.1.17. dateTimeMicroseconds >>>>> >>>>> The type "dateTimeMicroseconds" represents a time value in units = of >>>>> microseconds based on coordinated universal time (UTC). The choi= ce >>>>> of an epoch, for example, 00:00 UTC, January 1, 1970, is left to >>>>> corresponding encoding specifications for this type, for example,= the >>>>> IPFIX protocol specification. Leap seconds are excluded. Note t= hat >>>>> transformation of values might be required between different >>>>> encodings if different epoch values are used. >>>>> >>>>> 3.1.18. dateTimeNanoseconds >>>>> >>>>> The type "dateTimeNanoseconds" represents a time value in units o= f >>>>> nanoseconds based on coordinated universal time (UTC). The choic= e of >>>>> an epoch, for example, 00:00 UTC, January 1, 1970, is left to >>>>> corresponding encoding specifications for this type, for example,= the >>>>> IPFIX protocol specification. Leap seconds are excluded. Note t= hat >>>>> transformation of values might be required between different >>>>> encodings if different epoch values are used. >>>>> >>>>> >>>>> Notes >>>>> ----- >>>>> Although section 1.1 says : - "Definitions of timestamp data types = have been clarified." The edited text has removed the epoch definition, a= nd this does not seem to have been incorporated elsewhere in the RFC. >>>>> >>>>> Without a specified epoch, there is no unique definition of the tim= estamps. >>>>> >>>>> My proposal above is to revert to the RFC5102 definitions. RFC7102 = is intended to be backwards compatible with RFC5102 and thus the definiti= ons need to be technically identical. Alternatively, if the text is now i= ncluded elsewhere in RFC7012 or in another RFC, it would be helpful to th= e reader to provide a reference to the epoch definition in an editorial u= pdate to dateTimeX definitions in RFC7102. >>>>> >>>>> 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. >>>>> >>>>> -------------------------------------- >>>>> RFC7012 (draft-ietf-ipfix-information-model-rfc5102bis-10) >>>>> -------------------------------------- >>>>> Title : Information Model for IP Flow Information Exp= ort (IPFIX) >>>>> Publication Date : September 2013 >>>>> Author(s) : B. Claise, Ed., B. Trammell, Ed. >>>>> Category : PROPOSED STANDARD >>>>> Source : IP Flow Information Export >>>>> Area : Operations and Management >>>>> Stream : IETF >>>>> Verifying Party : IESG >>>>> _______________________________________________ >>>>> 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 >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix --------------enig7C43592A5B68C2E03FC50C71 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - https://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBCgAGBQJSwrwbAAoJENt3nsOmbNJcICAH/3Ohn77knO1+W7BFiG1zXxJ0 tq4FaztuZNhcWSkbYsaiwnHFpLTAwizdSXQ32i+wn9pNLa5IYg6bS2naWwgvGlNW zG16MS/NorRTIrplcd3RAgBocCDjKMsOaOxOYowNO/6+OWmgJomWgq328V9TbpNi ZUEcHK8/rfSAScPje3/Z4XLkM1xLgtsIqlUdxcbpOdeOj/QXSPh9nhX11fsBDdut GB8i/Bm//AitUXC/fTLKnaKHEwpnfSNsYLyjFed2kb7peQK+32i19HSue1pKamSz Aurkqw9/zioJ+jVxlDV1QdiewDOL8FvAjCR/xxTQxSnpSGDWXgnXl4f/+j4l/pY= =HbM2 -----END PGP SIGNATURE----- --------------enig7C43592A5B68C2E03FC50C71--