From trammell@tik.ee.ethz.ch Tue Mar 1 07:04:11 2011 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 087EA3A683D for ; Tue, 1 Mar 2011 07:04:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ALIZi8Vdy9DJ for ; Tue, 1 Mar 2011 07:04:10 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id A1ACC3A681B for ; Tue, 1 Mar 2011 07:04:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 24D96D931C; Tue, 1 Mar 2011 16:05:11 +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 ZQXnWwQMYUfO; Tue, 1 Mar 2011 16:05:10 +0100 (MET) Received: from [10.0.0.2] (unknown [109.130.186.174]) (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 B54AFD9343; Tue, 1 Mar 2011 16:05:10 +0100 (MET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1082) From: Brian Trammell In-Reply-To: <4D6AD72C.1040701@auckland.ac.nz> Date: Tue, 1 Mar 2011 16:05:09 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <7BC8386D-AFE8-46BD-9724-810E4EA7E6D8@tik.ee.ethz.ch> References: <4D6AD72C.1040701@auckland.ac.nz> To: Nevil Brownlee , IPFIX Working Group X-Mailer: Apple Mail (2.1082) Subject: Re: [IPFIX] WGLC for 'flow selection' draft X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 15:04:11 -0000 Hi, Nevil, all, I have reviewed the Flow Selection draft for WGLC, and have identified = several significant issues with it that, in my opinion, must be = addressed before the document is sent to the IESG in fulfillment of = point 5 of the WG's current charter. My first issue is a structural one. Much of the text in this document = deals with a very specific subset of flow selection, that which has to = do with measurement-edge flow sampling in order to handle resource = exhaustion. This is a very useful case, but kind of ancillary to = content-based flow selection at a mediator, which in my understanding is = the most widely useful application of flow selection, and the hardest to = get right. I would have expected to see a smaller section 4, a much = larger section 5 (containing much of the content of section 4.3), and a = greatly expanded section 6.1. The difference in flow selection between the metering and recording = process is unclear. This "flow recording" is a new architectural = concept, and one which is only implicitly defined. If this is a useful = concept, it must be explicitly defined (in terminology), and explicit = reasons must be given for superceding the IPFIX Architecture and = Mediator framework. That said, the point of this distinction is not clear with respect to = the problem the authors are trying to solve here. Why is flow recording = not just a function of the metering process? What is the use of = distinguishing flows that the MP simply never metered as opposed to = those it metered but never wrote?=20 Third, the selection of flow keys for key-based selection in the = subsections of section 7 seems arbitrary. Specifically, why can't I = select flows based on protocolIdentifier? It is also unclear how to = apply this flow selection system for selecting the set of flows for any = but a very simplistic set of keys. A good example: all flows involving a = given set of networks: "All flows which belong to Organization Foo", = where Foo controls the netblocks 130.229.0.0/16, 199.38.128.0/17, and = 199.57.198.0/23. Also, keep in mind that _any_ IE, basically, may be a = Flow Key field. What if I only want to select 3-packet TCP flows (i.e., = zero content complete handshakes)? I would submit that this case -- arbitrary key space subsets -- must be = handled by any flow selection draft that comes out of the WG; it's = fairly common especially at the mediator level. If, instead, the scope = of this document really is intended only to handle flow sampling use = cases for resource constraint avoidance, that is certainly useful, but I = would suggest in that case that it should be made Informational, and = that an updated working group charter reflect a need to handle = generalized flow selection in a separate document. Fourth, how do the timestamp-range information elements work with = _multiple_ periods of selection in the resource-restriction use case? = Let's say I get two spikes of length epsilon - a few seconds - at time T = and time U =3D T+k where k is long (say, a day). Then we say the = selection period was k long, when it was actually epsilon at both T and = U. Are there timeouts for differentiating these selection events from = each other? It's not clear from the document what I can do with = timestamps + counts that I can't do with counts alone.=20 The following are specific technical or editorial issues with the draft: 1. In section 4.3, "The selection of the flow records to be exported = implies performing a complete scanning of the memory area where flow information is stored, thus jeopardizing the efficiency of the overall exporting process" is not correct. Efficient decision algorithms need not scan each flow completely as it = passes the EP. If you've designed your templates right, you can generate = buffer offset lists for random access, for example. This statement seems = very implementation-specific. 2. The redefinition of information element names in the subsections of = Section 7 is not allowed. Please refer to the IANA Information Element = registry. 3. "Export" is the preferred noun form in English, not "exporting". 4. "At Mediators' level" -> "on an IPFIX Mediator". 5. The name of the selectorMethod IE is not prefixed to make it clear = this is specific to flow selection. 6. I have not reviewed the details of the other timestamp and count IEs, = since it's not clear what they're for. However, the names are = uncharacteristically cryptic for IPFIX. Best regards, Brian On Feb 27, 2011, at 11:58 PM, Nevil Brownlee wrote: >=20 > Hi all: >=20 > A little while ago, Benoit commented "I didn't see the WGLC notice for > this draft." Looking back through my notes, I see that at IETF 79 in > Maastricht we agreed that "it would be ready for WGLC after its = Editors > had published a new draft." Its -03 draft was published on 7 December > 2010, so I started on its writeup, but failed to send out its WGLC > note. Ditto for its -04 draft. I apologise for that. >=20 > On 14 Feb I called for reviews of it; Benoit has posted a review, > thanks very much. I still need one or two more reviews, and I'm - > at last - starting its WG Last Call now. It will end on 14 March. >=20 > Cheers, Nevil >=20 > --=20 > --------------------------------------------------------------------- > Nevil Brownlee Computer Science Department | ITS > Phone: +64 9 373 7599 x88941 The University of Auckland > FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From dromasca@avaya.com Tue Mar 1 07:55:52 2011 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76A7D3A68D9 for ; Tue, 1 Mar 2011 07:55:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.519 X-Spam-Level: X-Spam-Status: No, score=-102.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oyOgB9009WS5 for ; Tue, 1 Mar 2011 07:55:51 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 71EC43A67B6 for ; Tue, 1 Mar 2011 07:55:51 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiEHABqmbE3GmAcF/2dsb2JhbACYNo4WdKJmApl9hWEEj3k X-IronPort-AV: E=Sophos;i="4.62,247,1297054800"; d="scan'208";a="267223150" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 01 Mar 2011 10:56:54 -0500 X-IronPort-AV: E=Sophos;i="4.62,247,1297054800"; d="scan'208";a="588353002" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 01 Mar 2011 10:56:54 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 1 Mar 2011 16:56:51 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AD review of draft-ietf-ipfix-structured-data-04.txt Thread-Index: AcvYKUepWt0AE7dNTtOE6bEnVwSgHg== From: "Romascanu, Dan (Dan)" To: Subject: [IPFIX] AD review of draft-ietf-ipfix-structured-data-04.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 15:55:52 -0000 Please find below the AD review of draft-ietf-ipfix-structured-data-04.txt.=20 The document is in pretty good shape. However I would suggest that the authors address the questions and issues in this review and issue a revised I-D if necessary before proceeding to IETF Last Call.=20 The comments are divided in Technical (T) and Editorial (E).=20 T1. What is the use case of the "undefined" semantics defined in 4.4.1. Different collecting processes may interpret differently the data type. T2. The definitions of what needs to be included in the Semantic field of the IPFIX data types is not clear. For example in 4.5.1 - how is the relationship among the different Information Element values within the Structured Data Information Element encoded? etc. need to point to the new semantics and registry defined in the IANA consideration section.=20 T3. Need to mention in what units the length in all Element Length data types encoding is expressed (the above can be deducted from 5101 or from the examples but there is no reason not to mention these in section 4.5) T4. The following paragraph in section 8 may raise questions:=20 > Typically new Information Elements based on the basicList data=20 type make sense. For example, bgpPathList, bgpSequenceList and=20 bgpSetList, of abstract types and semantics basicList/ordered,=20 basicList/ordered, and basicList/exactlyOneOf respectively would=20 define the complete semantic of the list. However, the community=20 needs some more research and feedback before starting to specify=20 new Information Elements based on the subTemplateList and=20 subTemplateMultiList data types. So this specification doesn't=20 specify any new Information Elements beyond the ones in Section=20 4.3.=20 =20 People may ask what kind of research and feedback is still needed, and if research is still needed why does this specification go to Standards Track rather than Experimental? Does anything prevent us from saying that it is expected that such new IE's be standardized in the future based on implementations made first on vendors space?=20 T5. Section 11.1 - Can new abstract data types be added to the newly created abstract data types registry? If so what is the policy?=20 T6. I think that also the Security Considerations of [RFC5102] apply. E1. Idnits complain about:=20 =3D=3D The copyright year in the IETF Trust and authors Copyright Line = does not match the current year E2. All examples are IPv4. This is not a problem by itself, but gives the impression of an IPv4 centric document. Any reason not to provide at least one example that uses IPv6 addresses? Or at least a note that despite the fact that all examples use IPv4 addresses, the document applies for IPv6 as well.=20 From Thomas.Dietz@neclab.eu Wed Mar 2 08:10:08 2011 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 904DC3A683E for ; Wed, 2 Mar 2011 08:10:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tq9p78YmXVyR for ; Wed, 2 Mar 2011 08:10:07 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 5CBBA3A6818 for ; Wed, 2 Mar 2011 08:10:07 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 216382C000205; Wed, 2 Mar 2011 17:12:23 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office.hd) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vpebhw6uNDUY; Wed, 2 Mar 2011 17:12:23 +0100 (CET) Received: from METHONE.office.hd (Methone.office.hd [192.168.24.54]) by smtp0.neclab.eu (Postfix) with ESMTP id 00C042C000200; Wed, 2 Mar 2011 17:12:13 +0100 (CET) Received: from DAPHNIS.office.hd ([169.254.2.136]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0270.001; Wed, 2 Mar 2011 17:11:02 +0100 From: Thomas Dietz To: "ipfix@ietf.org" Thread-Topic: New Version Notification for draft-ietf-ipfix-psamp-mib-03 Thread-Index: AQHL2PQyB2/apPk8gUujvQEOTJg9R5QaNpNA Date: Wed, 2 Mar 2011 16:11:02 +0000 Message-ID: <75581E268A48F849916117B977D76D37162D6AE9@DAPHNIS.office.hd> References: <20110302160805.A0CB63A6853@core3.amsl.com> In-Reply-To: <20110302160805.A0CB63A6853@core3.amsl.com> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.1.1.10] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_009C_01CBD8FC.CE965CF0" MIME-Version: 1.0 Cc: Juergen Quittek Subject: [IPFIX] FW: New Version Notification for draft-ietf-ipfix-psamp-mib-03 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 16:10:08 -0000 ------=_NextPart_000_009C_01CBD8FC.CE965CF0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Dear all, I just posted a new version of the PSAMP MIB document. I hope I have addressed all your comments that come up in the WGLC. Best Regards, Thomas -- Thomas Dietz NEC Europe Ltd., NEC Laboratories, Network Research Division, 69115 Heidelberg, Germany NEC Europe Limited, Registered in England 2832014 Registered Office: NEC House, 1 Victoria Road, London W3 6BL > -----Original Message----- > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > Sent: Wednesday, March 02, 2011 5:08 PM > To: dietz@neclab.eu > Cc: bclaise@cisco.com; Juergen Quittek > Subject: New Version Notification for draft-ietf-ipfix-psamp-mib-03 > > > A new version of I-D, draft-ietf-ipfix-psamp-mib-03.txt has been > successfully submitted by Thomas Dietz and posted to the IETF repository. > > Filename: draft-ietf-ipfix-psamp-mib > Revision: 03 > Title: Definitions of Managed Objects for Packet Sampling > Creation_date: 2011-03-02 > WG ID: ipfix > Number_of_pages: 28 > > Abstract: > This memo defines a portion of the Management Information Base (MIB) > for use with network management protocols in the Internet community. > In particular, it describes extensions to the IPFIX MIB module > [RFC5815]. For IPFIX implementations that use packet Sampling > (PSAMP) techniques as described in [RFC5475], this memo defines the > PSAMP MIB module containing managed objects for providing information > on applied packet selection functions and their parameters. > > > > The IETF Secretariat. > ------=_NextPart_000_009C_01CBD8FC.CE965CF0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISNDCCA58w ggKHoAMCAQICASYwDQYJKoZIhvcNAQEFBQAwcTELMAkGA1UEBhMCREUxHDAaBgNVBAoTE0RldXRz Y2hlIFRlbGVrb20gQUcxHzAdBgNVBAsTFlQtVGVsZVNlYyBUcnVzdCBDZW50ZXIxIzAhBgNVBAMT GkRldXRzY2hlIFRlbGVrb20gUm9vdCBDQSAyMB4XDTk5MDcwOTEyMTEwMFoXDTE5MDcwOTIzNTkw MFowcTELMAkGA1UEBhMCREUxHDAaBgNVBAoTE0RldXRzY2hlIFRlbGVrb20gQUcxHzAdBgNVBAsT FlQtVGVsZVNlYyBUcnVzdCBDZW50ZXIxIzAhBgNVBAMTGkRldXRzY2hlIFRlbGVrb20gUm9vdCBD QSAyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqwujNeCLKRSxFIWvPBDkOW81XUqu 3ephjZVJ9G9koxpgZqSpQCKE2dSl5XiTDmgBrblNXDrO07ioQkDfz6O6gllqkhusHJraCCslJ/lp I0fx4Ossepv1EwLQfjR8wp48AFmr9doM9TI8K6xQ2tbD3oOUyqgMmTIOCEhWW2r72uFYWAFJX3JB PBUGAY5draq4k7TNnuun6GotUjTbOu9cdVHa2/Mx+e5xmDLEVBVEDPmbVe2t3xgIoKOGiknuUwWP GUzV3lh5m9JqHEKrxdWnz2gPluThYZh2YciRfNY+AOKRUIfhnQrmrZfSHcY6fcu82gM01Y5bAfVq B7cWtm5KfwIDAQABo0IwQDAdBgNVHQ4EFgQUMcN5G7r1U9cX4Il6LRdsCrMrnTMwDwYDVR0TBAgw BgEB/wIBBTAOBgNVHQ8BAf8EBAMCAQYwDQYJKoZIhvcNAQEFBQADggEBAJRkWa05ZOcp6xP+WsOL E1fIBCTwdHfAYONn++mJpoO/loJ8btTDPe+egG67KbSYerE7VOs5F0d+Go4L/B8xWTEEss4X8yzH YjZV4iLYiVW0mEiqZPrWHDbYRHhaWiM6V5f1ejBPrp9qTEsrjqAD4z7gqdTSe9KzqOJyPK2e/4BZ 5JtFtPY7sM05GZgy5eohYZDkMSGONLH3LzVKhRDa54o3Ib5ZY+DyhYgxU9RUFIVwefQuBncndS8f uIr5/sW62Dbkg+znZbe/Y1rzRq+BlDfUQYzWI9Yez/VoG0Rjolq6pzVZoeVwBZsOI1eZlAptujlj KIaS8xiE2PvRzwVWZFcwggQhMIIDCaADAgECAgIAxzANBgkqhkiG9w0BAQUFADBxMQswCQYDVQQG EwJERTEcMBoGA1UEChMTRGV1dHNjaGUgVGVsZWtvbSBBRzEfMB0GA1UECxMWVC1UZWxlU2VjIFRy dXN0IENlbnRlcjEjMCEGA1UEAxMaRGV1dHNjaGUgVGVsZWtvbSBSb290IENBIDIwHhcNMDYxMjE5 MTAyOTAwWhcNMTkwNjMwMjM1OTAwWjBaMQswCQYDVQQGEwJERTETMBEGA1UEChMKREZOLVZlcmVp bjEQMA4GA1UECxMHREZOLVBLSTEkMCIGA1UEAxMbREZOLVZlcmVpbiBQQ0EgR2xvYmFsIC0gRzAx MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA6ZvDZ4X5Da71jVTDllA1PWLpbkztlNcA W5UidNQg6zSP1uzAMQQLmYHiphTSUqAoI4SLdIkEXlvg4njBeMsWyyg1OXstkEXQ7aAAeny/Sg4b AMOG6VwrMRF7DPOCJEOMHDiLamgAmu7cT3ir0sYTm3at7t4m6O8Br3QPwQmi9mvOvdPNFDBP9eXj pMhim4IaAycwDQJlYE3t0QkjKpY1WCfTdsZxtpAdxO3/NYZ9bzOz2w/FEcKKg6GUXUFr2NIQ9Uz9 ylGs2b3vkoO72uuLFlZWQ8/h1RM9ph8nMM1JVNvJEzSacXXFbOqnC5j5IZ0nrz6jOTlIaoytyZn7 wxLyvQIDAQABo4HZMIHWMHAGA1UdHwRpMGcwZaBjoGGGX2h0dHA6Ly9wa2kudGVsZXNlYy5kZS9j Z2ktYmluL3NlcnZpY2UvYWZfRG93bmxvYWRBUkwuY3JsPy1jcmxfZm9ybWF0PVhfNTA5Ji1pc3N1 ZXI9RFRfUk9PVF9DQV8yMB0GA1UdDgQWBBRJt8bP6D0ff+pEexMp9/EKcD7eZDAfBgNVHSMEGDAW gBQxw3kbuvVT1xfgiXotF2wKsyudMzAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIB AjANBgkqhkiG9w0BAQUFAAOCAQEAO+Fad8BIF9ypGOyBr1qJ8L0okqbKWRgScOwo8ueuf5Ys5/Jd GTH2Eyt0vb2Asrn3Z8k5onk74RER7mt4kTN+O18mJ3VTZY4zY+7Pc8OwkiNJIVB1I6EfGOKUhT0/ M+l3II2iveahhSlA9j9zMlgNCWum2oVswD+7jWZkViROrg0/MjUBW+mMgtlyWU+xhoXxdIVW5cP4 XPON7kezUwVw5+VNimmDKOETCYaeXsjqWB4MH/mk1FoEaP0oPosCtli19qEsN1cAZ6sjaI1jpe+Z a1z9S1b2q0CHNNQRkmzsh8UKCwczcrRvDB1ULNhRx8y/MNNDcvEyv4zOSWOoAPfyHDCCBS8wggQX oAMCAQICBA0hCkcwDQYJKoZIhvcNAQEFBQAwWjELMAkGA1UEBhMCREUxEzARBgNVBAoTCkRGTi1W ZXJlaW4xEDAOBgNVBAsTB0RGTi1QS0kxJDAiBgNVBAMTG0RGTi1WZXJlaW4gUENBIEdsb2JhbCAt IEcwMTAeFw0wODEwMjQwODUyMDhaFw0xOTA2MzAwMDAwMDBaMIGQMQswCQYDVQQGEwJERTEYMBYG A1UEChMPTkVDIEV1cm9wZSBMdGQuMSAwHgYDVQQLExdORUMgTGFib3JhdG9yaWVzIEV1cm9wZTES MBAGA1UEAxMJTkVDTEFCLUNBMTEwLwYJKoZIhvcNAQkBFiJ6ZXJ0aWZpemllcnVuZ3NzdGVsbGVA bncubmVjbGFiLmV1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAnvIVsbURqjIOcbnf ruYkRceWOZpyvM2ebnYpbd1cP+zdWm6yR7HSO9ppOe1ZZFIasArqQpedPEFvcncSG94FRuW3ND4r Rcq08mbpUTmpWmXfdYlJpQezbsOHCWR74NXoEEbK6TPZIMFpJr6dzQDAxnRc7UOgO6JQ1V42Z39B PhIbPIWz64t8svafxbORmxulJn7F5zDLDcR1AEGyn+L9b645AGwapoKNh7cSQFTqdb6kGyPQjLWf tv09dvmBDKesrcyLZXuDWJ1LMeizSjUEygdSszNXD3gePgJaVaZDS3o923W5gAyPCTSxpAFj8XJ+ /7Ap5jJwYhjJgJ8khFR7JQIDAQABo4IBxDCCAcAwEgYDVR0TAQH/BAgwBgEB/wIBATALBgNVHQ8E BAMCAQYwHQYDVR0OBBYEFE8ch3od4C+Z9r4VqtE1nQ5K5ro2MB8GA1UdIwQYMBaAFEm3xs/oPR9/ 6kR7Eyn38QpwPt5kMC0GA1UdEQQmMCSBInplcnRpZml6aWVydW5nc3N0ZWxsZUBudy5uZWNsYWIu ZXUwgYgGA1UdHwSBgDB+MD2gO6A5hjdodHRwOi8vY2RwMS5wY2EuZGZuLmRlL2dsb2JhbC1yb290 LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMD2gO6A5hjdodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2dsb2Jh bC1yb290LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIGiBggrBgEFBQcBAQSBlTCBkjBHBggrBgEFBQcw AoY7aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY2FjZXJ0L2NhY2Vy dC5jcnQwRwYIKwYBBQUHMAKGO2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2Ev cHViL2NhY2VydC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQBsMQ+dD0mmi48dgDU4R6Q/ eXcY0zQcHNp1Vu1s3kwO0WahWB0tiqVBodvfTAWG44xuw0I7NXSTwQ68FU5P0GIQnvRFZyVJlDjr SNlLYxjqfmgb+KVm67o383cZIuDakEE0f29kULIEn2fg/HsDiBAXTsb4I19XaN0TXLI+PMhU+GDp sGCJrydeugEV7qi15q8yymjSAsYgnrc2wJuXpyQ9r3qCtP6aedAPSHqOT8ga1dLT2YRZFs3vNm7T HSr5JJymWMbfpD6OcbRTnNAjSMDHwJxgRBAflA6WzDVm7fk4jiWyLvJwWTMk19t8QLiKG7D0nYvj cEUYyiOSE+SFUTEdMIIFNTCCBB2gAwIBAgIED+0gWzANBgkqhkiG9w0BAQUFADCBkDELMAkGA1UE BhMCREUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVDIExhYm9yYXRvcmll cyBFdXJvcGUxEjAQBgNVBAMTCU5FQ0xBQi1DQTExMC8GCSqGSIb3DQEJARYiemVydGlmaXppZXJ1 bmdzc3RlbGxlQG53Lm5lY2xhYi5ldTAeFw0xMDA0MjAxMjQ5MTVaFw0xMzA0MTkxMjQ5MTVaMGAx CzAJBgNVBAYTAkRFMRgwFgYDVQQKEw9ORUMgRXVyb3BlIEx0ZC4xIDAeBgNVBAsTF05FQyBMYWJv cmF0b3JpZXMgRXVyb3BlMRUwEwYDVQQDEwxUaG9tYXMgRGlldHowggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQD2mMcvPbgraEaWMV6uNCs6t88lhBczgfxybD46mwr8D3VaQLEnqTsBOAf/ Y8ARtq+P6Dkm2MBMXQG+Ebo2qhif6O4dH7whcG9E88F9247R2EJjcXmxMYZWYGQTI2vGw/joerRB waiwfxCXWBTLutbdWEEKL/DG9A1yQRPGJc+jJYfgm0ekYn+WESOLYaBH7G9aIIZQ7en3afhPpbQA Ajh92K240TG+VgBpe1vnDdth28Ps5XeN+otookDZHwwGQYwYrPZJtnhGIyjKMm7OkXL62Rf3aSoI doVUwYYS67RYYNOY0C7qOVyCUF+z4Bkn758sZhZzotiLQVT3AZ625PrvAgMBAAGjggHEMIIBwDAJ BgNVHRMEAjAAMAsGA1UdDwQEAwIF4DApBgNVHSUEIjAgBggrBgEFBQcDAgYIKwYBBQUHAwQGCisG AQQBgjcUAgIwHQYDVR0OBBYEFH9fxgi2EshupgLF49SzaAX0QFoMMB8GA1UdIwQYMBaAFE8ch3od 4C+Z9r4VqtE1nQ5K5ro2MCEGA1UdEQQaMBiBFlRob21hcy5EaWV0ekBuZWNsYWIuZXUwfQYDVR0f BHYwdDA4oDagNIYyaHR0cDovL2NkcDEucGNhLmRmbi5kZS9uZWNsYWItY2EvcHViL2NybC9jYWNy bC5jcmwwOKA2oDSGMmh0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvbmVjbGFiLWNhL3B1Yi9jcmwvY2Fj cmwuY3JsMIGYBggrBgEFBQcBAQSBizCBiDBCBggrBgEFBQcwAoY2aHR0cDovL2NkcDEucGNhLmRm bi5kZS9uZWNsYWItY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MEIGCCsGAQUFBzAChjZodHRwOi8v Y2RwMi5wY2EuZGZuLmRlL25lY2xhYi1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZIhvcN AQEFBQADggEBACnPHI1mIY1TVY9Aj8zsHHxiwMRx02Hp6DLZGYXHGG9IkflrRKNiDIV2LbBDpXVH vojMxTtCt10iwbyVMGaevet/VHYCJSHzrCLkw+GkvuhDU70lNsWw9P+mai7OHa+NQ6im8+4RnY1B yhqidcCt3hIV9B69ax0/KIhIFpiWz/lKZVIghki07I4m8mf1sbvCORKxudH0TVLlRJlX1r8S+8ea 9e+Q8pgXfrsCeyxBV3KAjszRQkqDZsbD7jQHQWokkMPIjbaTjw6V/5SRzmcAy0XlKNOCbldlzmCB jDZTQWdSH/AFDy5L2l4j0Ck0vVlQv+r1F4omsb4BelRq+vHd+lExggQ4MIIENAIBATCBmTCBkDEL MAkGA1UEBhMCREUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVDIExhYm9y YXRvcmllcyBFdXJvcGUxEjAQBgNVBAMTCU5FQ0xBQi1DQTExMC8GCSqGSIb3DQEJARYiemVydGlm aXppZXJ1bmdzc3RlbGxlQG53Lm5lY2xhYi5ldQIED+0gWzAJBgUrDgMCGgUAoIICczAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMTAzMDIxNjExMDFaMCMGCSqGSIb3 DQEJBDEWBBQU4WGR3x+HL33Lf2QP87NBM7QCiDCBqgYJKwYBBAGCNxAEMYGcMIGZMIGQMQswCQYD VQQGEwJERTEYMBYGA1UEChMPTkVDIEV1cm9wZSBMdGQuMSAwHgYDVQQLExdORUMgTGFib3JhdG9y aWVzIEV1cm9wZTESMBAGA1UEAxMJTkVDTEFCLUNBMTEwLwYJKoZIhvcNAQkBFiJ6ZXJ0aWZpemll cnVuZ3NzdGVsbGVAbncubmVjbGFiLmV1AgQP7SBbMIGsBgsqhkiG9w0BCRACCzGBnKCBmTCBkDEL MAkGA1UEBhMCREUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVDIExhYm9y YXRvcmllcyBFdXJvcGUxEjAQBgNVBAMTCU5FQ0xBQi1DQTExMC8GCSqGSIb3DQEJARYiemVydGlm aXppZXJ1bmdzc3RlbGxlQG53Lm5lY2xhYi5ldQIED+0gWzCBtwYJKoZIhvcNAQkPMYGpMIGmMAsG CWCGSAFlAwQBKjALBglghkgBZQMEARYwCgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4GCCqGSIb3 DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAL BglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATAKBggqhkiG9w0CBTANBgkqhkiG 9w0BAQEFAASCAQDl5WWAawbIGraE4ED0ZLotcmVytr7JGE1QjOOJX1SG7LkRtblrFHO6IpzCANt8 z+FTk4m2Xq65THpG7OZL99dtyVYWMaQToPsc/zY3bqC9VHnV1YY6ttNIM2SlK1BFrNpCZ50TUG3S W3XUfg6pvD1PQsf52FkIoEvdnnvETmwi8c5gfuN8RFTaD7I9aBffS9lXKogrtmAq9UqdeVPjbGnV 8oUvfFG9FI8oftwEhjsQqJ910zCGzixLMbGtdeyGPwIQhkAAFpVIT16MyM4Sq3ZKvIThjawYXAnn Lw1GVlwdjYlaxRTCKBGQKbAPfJPiJl2TzVb0ohyyz7a2aKJ3icNdAAAAAAAA ------=_NextPart_000_009C_01CBD8FC.CE965CF0-- From Internet-Drafts@ietf.org Wed Mar 2 08:15:03 2011 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DEFD3A6835; Wed, 2 Mar 2011 08:15:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vqDmGPY0hIvF; Wed, 2 Mar 2011 08:15:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E5273A6818; Wed, 2 Mar 2011 08:15:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110302161502.30225.15815.idtracker@localhost> Date: Wed, 02 Mar 2011 08:15:02 -0800 Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action:draft-ietf-ipfix-psamp-mib-03.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 16:15:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Flow Information Export Working Group of the IETF. Title : Definitions of Managed Objects for Packet Sampling Author(s) : T. Dietz, et al. Filename : draft-ietf-ipfix-psamp-mib-03.txt Pages : 28 Date : 2011-03-02 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes extensions to the IPFIX MIB module [RFC5815]. For IPFIX implementations that use packet Sampling (PSAMP) techniques as described in [RFC5475], this memo defines the PSAMP MIB module containing managed objects for providing information on applied packet selection functions and their parameters. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipfix-psamp-mib-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ipfix-psamp-mib-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-02080805.I-D@ietf.org> --NextPart-- From n.brownlee@auckland.ac.nz Thu Mar 3 18:28:12 2011 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88B8A3A6874 for ; Thu, 3 Mar 2011 18:28:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.181 X-Spam-Level: X-Spam-Status: No, score=-103.181 tagged_above=-999 required=5 tests=[AWL=0.418, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ENBoVOLuwn7C for ; Thu, 3 Mar 2011 18:28:11 -0800 (PST) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by core3.amsl.com (Postfix) with ESMTP id F19D73A6806 for ; Thu, 3 Mar 2011 18:28:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=n.brownlee@auckland.ac.nz; q=dns/txt; s=uoa; t=1299205760; x=1330741760; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; z=Message-ID:=20<4D704E7B.5080309@auckland.ac.nz>|Date:=20 Fri,=2004=20Mar=202011=2015:29:15=20+1300|From:=20Nevil =20Brownlee=20|MIME-Version: =201.0|To:=20IPFIX=20Working=20Group=20 |Subject:=20DRAFT=20agenda=20for=20Prague=20IETF |Content-Transfer-Encoding:=207bit; bh=NgaQhWflpNIA7+DMMQcWu+AKIuDa/0L/TTXtvMHx15Q=; b=I81dzHskBKKHluhat9sEAZRLsVBuSZ0vseFc0FW/y8FLtcgIVIxRjWp7 9ko4MmAPVeuseJV3xqFDRdAuSmNObXXT6tfC0BWZXfdF0Nn909Os5sZDL 1YCHGmUZ9Uy0SrXv095Lh/WGGty6Al1pFQXlpxQMsKpQM6DfkQzLpSUpS I=; X-IronPort-AV: E=Sophos;i="4.62,262,1296990000"; d="scan'208";a="49117117" 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; 04 Mar 2011 15:29:15 +1300 Message-ID: <4D704E7B.5080309@auckland.ac.nz> Date: Fri, 04 Mar 2011 15:29:15 +1300 From: Nevil Brownlee User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.14) Gecko/20110221 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: IPFIX Working Group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPFIX] DRAFT agenda for Prague IETF X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 02:28:12 -0000 Hi all: Here's my first draft of our agenda for the IPFIX meeting in Prague. Please let me know if you have changes you'd like to suggest. When it comes to 'new charter' discussions, I'd like to have brief presentations about each, so do let me know who will be presenting each. Also, if you're publishing new versions, cutoff date is 14 March. Cheers, Nevil =========================================== IP Flow Information Export WG (ipfix) Agenda for IETF #80, Beijing DRAFT-00 <<<< Wednesday, March 29, 1300-1500, Vienna room (may change) =========================================== Chairs: Juergen Quittek Nevil Brownlee AGENDA: 1. Agenda review = 5 min 2. Update from last meeting / WG Status (Nevil) = 15 min Export-per-sctp-Stream - in queue, waiting on sctpstream-reset Mediators-framework - approved, in RFC-EDITOR Anonymisation Support - one remaining DISCUSS Config Model - new version, Juergen to do write-up Structured Data - AD review done, waiting for -05 PSAMP MIB - new version, Nevil will do write-up Flow Selection Techniques - WGLC done, waiting for -03 Nevil is shepherd for this. 3. Current WG drafts = 0 min All in (2) above. 4. What next for IPFIX? = 5 min We're now ready to consider how IPFIX should develop. This section of the agenda is intended as (the continuation of) our re-chartering discussion. For any of these we need to work out - Who is prepares to _work_ on them? - How long do we expect them to take? a) Progressing IPFIX Standards-Track RFCs to Draft Standard = 20 min - Fix errata, add clarification text, would we need anything else? - Would need inter-operation reports from several implementors. (+ report from Prague interoperation event) b) Recent drafts - draft-trammell-ipfix-ie-doctors-00 = 60 min Guidelines for Information Elements, 1 Oct 10 - draft-trammel-ipfix-a9n-02 IPFIX Aggregation, 22 Feb 11 - draft-claise-ipfix-mediation-protocol-03 Protocol for PFIX Mediation, 14 Feb 11 - draft-johnson-ipfix-mib-variable-export-00 Exporting MIB objects, 19 Oct 10 - draft-akhter-ipfix-perfmon-01 App and Network Performance measurements, 25 Oct 10 - draft-claise-export-application-info-in-ipfix Export of Application Information in IPFIX, 18 Oct 10 5. Any Other Business = 15 min Presentation slides will be available at https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=80 (search for IPFIX in the Operations and Management Area) Participation via jabber is offered at ipfix@jabber.ietf.org -- --------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand From bclaise@cisco.com Fri Mar 4 01:31:29 2011 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 413DF3A68CE for ; Fri, 4 Mar 2011 01:31:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.689 X-Spam-Level: X-Spam-Status: No, score=-2.689 tagged_above=-999 required=5 tests=[AWL=-0.091, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z2f09q8h6jBm for ; Fri, 4 Mar 2011 01:31:27 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id EDB623A68B3 for ; Fri, 4 Mar 2011 01:31:26 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p249HWHL024585; Fri, 4 Mar 2011 10:17:32 +0100 (CET) Received: from [10.55.43.51] (ams-bclaise-8712.cisco.com [10.55.43.51]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p249HVfo026645; Fri, 4 Mar 2011 10:17:32 +0100 (CET) Message-ID: <4D70AE2B.5000100@cisco.com> Date: Fri, 04 Mar 2011 10:17:31 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------080103050302040301080308" Cc: ipfix@ietf.org Subject: Re: [IPFIX] AD review of draft-ietf-ipfix-structured-data-04.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 09:31:29 -0000 This is a multi-part message in MIME format. --------------080103050302040301080308 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Dan, Thanks for your review. Inline. > Please find below the AD review of > draft-ietf-ipfix-structured-data-04.txt. > > The document is in pretty good shape. However I would suggest that the > authors address the questions and issues in this review and issue a > revised I-D if necessary before proceeding to IETF Last Call. > > The comments are divided in Technical (T) and Editorial (E). > > T1. What is the use case of the "undefined" semantics defined in 4.4.1. > Different collecting processes may interpret differently the data type. The use case is when none of the other semantics apply. An example is an IPFIX Mediator that translates from RFC5101 to IPFIX structured data. The Collecting Process (part of the IPFIX Mediator) doesn't know what the semantic is (it can only guess), so it should use "undefined" when re-exporting. Typical example, a Flow Record received with 2 output interfaces in the RFC5101 style. > > T2. The definitions of what needs to be included in the Semantic field > of the IPFIX data types is not clear. For example in 4.5.1 - how is the > relationship among the different Information Element values within the > Structured Data Information Element encoded? etc. need to point to the > new semantics and registry defined in the IANA consideration section. OLD: Semantic The Semantic field indicates the relationship among the different Information Element values within this Structured Data Information Element. NEW: Semantic A numeric value that represents the relationship among the different Information Element values within this Structured Data Information Element. Refer to IANA's IPFIX "structured data types semantics registry. > T3. Need to mention in what units the length in all Element Length data > types encoding is expressed > (the above can be deducted from 5101 or from the examples but there is > no reason not to mention these in section 4.5) Section 4.5.1 OLD: Element Length The Element Length field indicates the length of each list element specified by Field ID, or contains the value 0xFFFF if the length is encoded as a variable-length Information Element at the start of the basicList Content, per Section 7 of [RFC5101]. The Element Length field is effectively part of the header, so even in the case of a zero-element list, it MUST NOT be omitted. NEW: Element Length _Per Section 7 of [RFC 5101],_ the Element Length field indicates the length,_in octets,_of each list element specified by Field ID, or contains the value 0xFFFF if the length is encoded as a variable-length Information Element at the start of the basicList Content. The Element Length field is effectively part of the header, so even in the case of a zero-element list, it MUST NOT be omitted. > T4. The following paragraph in section 8 may raise questions: > >> Typically new Information Elements based on the basicList data > type make sense. For example, bgpPathList, bgpSequenceList and > bgpSetList, of abstract types and semantics basicList/ordered, > basicList/ordered, and basicList/exactlyOneOf respectively would > define the complete semantic of the list. However, the community > needs some more research and feedback before starting to specify > new Information Elements based on the subTemplateList and > subTemplateMultiList data types. So this specification doesn't > specify any new Information Elements beyond the ones in Section > 4.3. > > People may ask what kind of research and feedback is still needed, and > if research is still needed why does this specification go to Standards > Track rather than Experimental? Does anything prevent us from saying > that it is expected that such new IE's be standardized in the future > based on implementations made first on vendors space? OLD: Typically new Information Elements based on the basicList data type make sense. For example, bgpPathList, bgpSequenceList and bgpSetList, of abstract types and semantics basicList/ordered, basicList/ordered, and basicList/exactlyOneOf respectively would define the complete semantic of the list. However, the community needs some more research and feedback before starting to specify new Information Elements based on the subTemplateList and subTemplateMultiList data types. So this specification doesn't specify any new Information Elements beyond the ones in Section 4.3. NEW: The authors anticipate the creation of both enterprise-specific and IANA Information Elements based on the IPFIX structured data types. For example, bgpPathList, bgpSequenceList and bgpSetList, of abstract types and semantics basicList/ordered, basicList/ordered, and basicList/exactlyOneOf respectively would define the complete semantic of the list. This specification doesn't specify any new Information Elements beyond the ones in Section 4.3. > T5. Section 11.1 - Can new abstract data types be added to the newly > created abstract data types registry? If so what is the policy? Actually, you discovered a problem with the IANA section. 11.1. New Abstract Data Types Section 4.1 . of this document specifies several new IPFIX abstract data types. PerSection 6 of the IPFIX information model [RFC5102 ], new abstract data types can be added to the IPFIX information model. This requires creation of a new IPFIX "abstract data types" registry at http://www.iana.org/assignments/ipfix. This registry should include all the abstract data types fromSection 3.1 of [RFC5102] . Abstract data types to be added to the IPFIX "abstract data types" registry are listed below. However, this old text is not valid any more. In the mean time, this "abstract data types" registry has been created already, http://www.iana.org/assignments/ipfix/ipfix.xml#informationElementDataTypes, as the outcome of the RFC5610 publication. New section 11.1. New Abstract Data Types Section 4.1 . of this document specifies several new IPFIX abstract data types. PerSection 6 of the IPFIX information model [RFC5102 ], new abstract data types can be added to the IPFIX information model, in the IPFIX Information Element Data Types registry. Abstract data types to be added to the IPFIX "Information Element Data Types" registry are listed below. EDITOR'S NOTE: IANA, please pick the number three values in the http://www.iana.org/assignments/ipfix/ipfix.xml#informationElementDataTypes for the basicList, subTemplateList, and subTemplateMultiList Dan, to answer you question about the process to add data types, the above sentence " PerSection 6 of the IPFIX information model [RFC5102 ]" should do the trick. > T6. I think that also the Security Considerations of [RFC5102] apply. OLD: Section 12. Security Considerations The same security considerations as for the IPFIX Protocol [RFC5101 ] apply. NEW: 12. Security Considerations The same security considerations as for the IPFIX Protocol [RFC5101 ] and the IPFIX information model [RFC5102] apply. > > > > E1. Idnits complain about: > > == The copyright year in the IETF Trust and authors Copyright Line does > not > match the current year Done. > E2. All examples are IPv4. This is not a problem by itself, but gives > the impression of an IPv4 centric document. Any reason not to provide at > least one example that uses IPv6 addresses? Or at least a note that > despite the fact that all examples use IPv4 addresses, the document > applies for IPv6 as well. We will change one example with IPv6. Are you fine with the answers? Shall we post the new version? Regards, Benoit > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix --------------080103050302040301080308 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Dan,

Thanks for your review.
Inline.
Please find below the AD review of
draft-ietf-ipfix-structured-data-04.txt. 

The document is in pretty good shape. However I would suggest that the
authors address the questions and issues in this review and issue a
revised I-D if necessary before proceeding to IETF Last Call. 

The comments are divided in Technical (T) and Editorial (E). 

T1. What is the use case of the "undefined" semantics defined in 4.4.1.
Different collecting processes may interpret differently the data type.
The use case is when none of the other semantics apply.
An example is an IPFIX Mediator that translates from RFC5101 to IPFIX structured data. The Collecting Process (part of the IPFIX Mediator) doesn't know what the semantic is (it can only guess), so it should use "undefined" when re-exporting. Typical example, a Flow Record received with 2 output interfaces in the RFC5101 style.

T2. The definitions of what needs to be included in the Semantic field
of the IPFIX data types is not clear. For example in 4.5.1 - how is the
relationship among the different Information Element values within the
Structured Data Information Element encoded? etc. need to point to the
new semantics and registry defined in the IANA consideration section.
OLD:
      Semantic
     
          The Semantic field indicates the relationship among the
          different Information Element values within this Structured
          Data Information Element.
NEW:
      Semantic
     
          A numeric value that represents the relationship among the
          different Information Element values within this Structured
          Data Information Element. Refer to IANA's IPFIX "structured 
          data types semantics registry. 

T3. Need to mention in what units the length in all Element Length data
types encoding is expressed
(the above can be deducted from 5101 or from the examples but there is
no reason not to mention these in section 4.5)
Section 4.5.1
OLD:
      Element Length
     
          The Element Length field indicates the length of each list
          element specified by Field ID, or contains the value 0xFFFF if
          the length is encoded as a variable-length Information Element    
          at the start of the basicList Content, per Section 7 of
          [RFC5101].
     
          The Element Length field is effectively part of the header, so
          even in the case of a zero-element list, it MUST NOT be
          omitted.
NEW:

      Element Length
     
          Per Section 7 of [RFC 5101], the Element Length field indicates 
          the length, in octets, of each list element specified by Field ID, 
          or contains the value 0xFFFF if the length is encoded as a variable-length 
          Information Element at the start of the basicList Content.

          The Element Length field is effectively part of the header, so
          even in the case of a zero-element list, it MUST NOT be
          omitted.


T4. The following paragraph in section 8 may raise questions: 


Typically new Information Elements based on the basicList data 

     type make sense.  For example, bgpPathList, bgpSequenceList and 
     bgpSetList, of abstract types and semantics basicList/ordered, 
     basicList/ordered, and basicList/exactlyOneOf respectively would 
     define the complete semantic of the list.  However, the community 
     needs some more research and feedback before starting to specify 
     new Information Elements based on the subTemplateList and 
     subTemplateMultiList data types.  So this specification doesn't 
     specify any new Information Elements beyond the ones in Section 
     4.3. 
      
People may ask what kind of research and feedback is still needed, and
if research is still needed why does this specification go to Standards
Track rather than Experimental? Does anything prevent us from saying
that it is expected that such new IE's be standardized in the future
based on implementations made first on vendors space?
OLD:
     Typically new Information Elements based on the basicList data 
     type make sense.  For example, bgpPathList, bgpSequenceList and 
     bgpSetList, of abstract types and semantics basicList/ordered, 
     basicList/ordered, and basicList/exactlyOneOf respectively would 
     define the complete semantic of the list.  However, the community 
     needs some more research and feedback before starting to specify 
     new Information Elements based on the subTemplateList and 
     subTemplateMultiList data types.  So this specification doesn't 
     specify any new Information Elements beyond the ones in Section 
     4.3.


NEW:

    The authors anticipate the creation of both enterprise-specific and IANA Information Elements based
    on the IPFIX structured data types. For example, bgpPathList, bgpSequenceList and bgpSetList,
    of abstract types and semantics basicList/ordered, basicList/ordered, and basicList/exactlyOneOf respectively
    would define the complete semantic of the list. This specification doesn't specify any new Information Elements
    beyond the ones in Section 4.3. 
T5. Section 11.1 - Can new abstract data types be added to the newly
created abstract data types registry? If so what is the policy?
Actually, you discovered a problem with the IANA section.
11.1. New Abstract Data Types
     
      Section 4.1. of this document specifies several new IPFIX abstract
      data types.  Per Section 6 of the IPFIX information model
      [RFC5102], new abstract data types can be added to the IPFIX
      information model.  This requires creation of a new IPFIX
      "abstract data types" registry at
      http://www.iana.org/assignments/ipfix.  This registry should
      include all the abstract data types from Section 3.1 of [RFC5102].
     
      Abstract data types to be added to the IPFIX "abstract data types"
      registry are listed below.
However, this old text is not valid any more.
In the mean time, this "abstract data types" registry has been created already, http://www.iana.org/assignments/ipfix/ipfix.xml#informationElementDataTypes, as the outcome of the RFC5610 publication.

New section 
11.1. New Abstract Data Types
     
      Section 4.1. of this document specifies several new IPFIX abstract
      data types.  Per Section 6 of the IPFIX information model
      [RFC5102], new abstract data types can be added to the IPFIX
      information model, in the IPFIX Information Element Data Types registry.
     
      Abstract data types to be added to the IPFIX "Information Element Data Types"
      registry are listed below.

      EDITOR'S NOTE: IANA, please pick the number three values in the 
      http://www.iana.org/assignments/ipfix/ipfix.xml#informationElementDataTypes
      for the basicList, subTemplateList, and subTemplateMultiList



Dan, to answer you question about the process to add data types, the above sentence "
Per Section 6 of the IPFIX information model [RFC5102]" should do the trick.

T6. I think that also the Security Considerations of [RFC5102] apply.
OLD:

Section 12. Security Considerations

    The same security considerations as for the IPFIX Protocol
    [RFC5101] apply.

NEW:

12. Security Considerations

    The same security considerations as for the IPFIX Protocol
    [RFC5101] and the IPFIX information model [RFC5102] apply.



E1. Idnits complain about: 

== The copyright year in the IETF Trust and authors Copyright Line does
not
     match the current year
Done.
E2. All examples are IPv4. This is not a problem by itself, but gives
the impression of an IPv4 centric document. Any reason not to provide at
least one example that uses IPv6 addresses? Or at least a note that
despite the fact that all examples use IPv4 addresses, the document
applies for IPv6 as well.
We will change one example with IPv6.


Are you fine with the answers?
Shall we post the new version?

Regards, Benoit

_______________________________________________
IPFIX mailing list
IPFIX@ietf.org
https://www.ietf.org/mailman/listinfo/ipfix

--------------080103050302040301080308-- From dromasca@avaya.com Fri Mar 4 08:40:12 2011 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D56403A6817 for ; Fri, 4 Mar 2011 08:40:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.537 X-Spam-Level: X-Spam-Status: No, score=-102.537 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5vReBG-3eHYa for ; Fri, 4 Mar 2011 08:40:07 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 493453A67AF for ; Fri, 4 Mar 2011 08:40:06 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgABAGOlcE2HCzI1/2dsb2JhbACYJ4ZEh3h0pgICmTeFYQSQDA X-IronPort-AV: E=Sophos;i="4.62,264,1297054800"; d="scan'208,217";a="235246664" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 04 Mar 2011 11:41:00 -0500 X-IronPort-AV: E=Sophos;i="4.62,264,1297054800"; d="scan'208,217";a="610757469" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 04 Mar 2011 11:40:59 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBDA8A.EE0171C3" Date: Fri, 4 Mar 2011 17:40:50 +0100 Message-ID: In-Reply-To: <4D70AE2B.5000100@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPFIX] AD review of draft-ietf-ipfix-structured-data-04.txt Thread-Index: AcvaTxw+tlHeB/JkSm2EUvc4rytKRwAOu8kA References: <4D70AE2B.5000100@cisco.com> From: "Romascanu, Dan (Dan)" To: "Benoit Claise" Cc: ipfix@ietf.org Subject: Re: [IPFIX] AD review of draft-ietf-ipfix-structured-data-04.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 16:40:12 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBDA8A.EE0171C3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Benoit, =20 Thank you for your answers. They all seem reasonable to me with two observations:=20 =20 T1: can you clarify with text what you explained in your answer? other people may have the same question =20 T3: the clarification about the length applies not only to 4.5.1 but also to other sections in 4.5. You need either to make the clarification global at the start of the section or to include it in all length field definitions where needed=20 =20 Please issue the new version with these changes and we can proceed to IETF Last Call.=20 =20 Regards, =20 Dan =20 ________________________________ From: Benoit Claise [mailto:bclaise@cisco.com]=20 Sent: Friday, March 04, 2011 11:18 AM To: Romascanu, Dan (Dan) Cc: ipfix@ietf.org Subject: Re: [IPFIX] AD review of draft-ietf-ipfix-structured-data-04.txt =09 =09 Hi Dan, =09 Thanks for your review. Inline. =09 Please find below the AD review of draft-ietf-ipfix-structured-data-04.txt.=20 =09 The document is in pretty good shape. However I would suggest that the authors address the questions and issues in this review and issue a revised I-D if necessary before proceeding to IETF Last Call.=20 =09 The comments are divided in Technical (T) and Editorial (E).=20 =09 T1. What is the use case of the "undefined" semantics defined in 4.4.1. Different collecting processes may interpret differently the data type. The use case is when none of the other semantics apply. An example is an IPFIX Mediator that translates from RFC5101 to IPFIX structured data. The Collecting Process (part of the IPFIX Mediator) doesn't know what the semantic is (it can only guess), so it should use "undefined" when re-exporting. Typical example, a Flow Record received with 2 output interfaces in the RFC5101 style. =09 =09 T2. The definitions of what needs to be included in the Semantic field of the IPFIX data types is not clear. For example in 4.5.1 - how is the relationship among the different Information Element values within the Structured Data Information Element encoded? etc. need to point to the new semantics and registry defined in the IANA consideration section.=20 OLD: =09 Semantic =20 The Semantic field indicates the relationship among the different Information Element values within this Structured Data Information Element. NEW: =09 Semantic =20 A numeric value that represents the relationship among the different Information Element values within this Structured Data Information Element. Refer to IANA's IPFIX "structured=20 data types semantics registry.=20 T3. Need to mention in what units the length in all Element Length data types encoding is expressed (the above can be deducted from 5101 or from the examples but there is no reason not to mention these in section 4.5) Section 4.5.1 OLD: =09 Element Length =20 The Element Length field indicates the length of each list element specified by Field ID, or contains the value 0xFFFF if the length is encoded as a variable-length Information Element =20 at the start of the basicList Content, per Section 7 of [RFC5101]. =20 The Element Length field is effectively part of the header, so even in the case of a zero-element list, it MUST NOT be omitted. NEW: =09 =09 Element Length =20 Per Section 7 of [RFC 5101], the Element Length field indicates=20 the length, in octets, of each list element specified by Field ID,=20 or contains the value 0xFFFF if the length is encoded as a variable-length=20 Information Element at the start of the basicList Content. =09 The Element Length field is effectively part of the header, so even in the case of a zero-element list, it MUST NOT be omitted. =09 T4. The following paragraph in section 8 may raise questions:=20 =09 Typically new Information Elements based on the basicList data=20 type make sense. For example, bgpPathList, bgpSequenceList and=20 bgpSetList, of abstract types and semantics basicList/ordered,=20 basicList/ordered, and basicList/exactlyOneOf respectively would=20 define the complete semantic of the list. However, the community=20 needs some more research and feedback before starting to specify=20 new Information Elements based on the subTemplateList and=20 subTemplateMultiList data types. So this specification doesn't=20 specify any new Information Elements beyond the ones in Section=20 4.3.=20 =20 People may ask what kind of research and feedback is still needed, and if research is still needed why does this specification go to Standards Track rather than Experimental? Does anything prevent us from saying that it is expected that such new IE's be standardized in the future based on implementations made first on vendors space?=20 OLD: =09 Typically new Information Elements based on the basicList data=20 type make sense. For example, bgpPathList, bgpSequenceList and=20 bgpSetList, of abstract types and semantics basicList/ordered,=20 basicList/ordered, and basicList/exactlyOneOf respectively would=20 define the complete semantic of the list. However, the community=20 needs some more research and feedback before starting to specify=20 new Information Elements based on the subTemplateList and=20 subTemplateMultiList data types. So this specification doesn't=20 specify any new Information Elements beyond the ones in Section=20 4.3.=20 NEW: =09 The authors anticipate the creation of both enterprise-specific and IANA Information Elements based=20 on the IPFIX structured data types. For example, bgpPathList, bgpSequenceList and bgpSetList, of abstract types and semantics basicList/ordered, basicList/ordered, and basicList/exactlyOneOf respectively would define the complete semantic of the list. This specification doesn't specify any new Information Elements beyond the ones in Section 4.3.=20 =09 T5. Section 11.1 - Can new abstract data types be added to the newly created abstract data types registry? If so what is the policy?=20 Actually, you discovered a problem with the IANA section. =09 =09 11.1. New Abstract Data Types =20 Section 4.1 . of this document specifies several new IPFIX abstract data types. Per Section 6 of the IPFIX information model [RFC5102 ], new abstract data types can be added to the IPFIX information model. This requires creation of a new IPFIX "abstract data types" registry at http://www.iana.org/assignments/ipfix. This registry should include all the abstract data types from Section 3.1 of [RFC5102] . =20 Abstract data types to be added to the IPFIX "abstract data types" registry are listed below. However, this old text is not valid any more. In the mean time, this "abstract data types" registry has been created already, http://www.iana.org/assignments/ipfix/ipfix.xml#informationElementDataTy pes, as the outcome of the RFC5610 publication. =09 New section=20 =09 =09 11.1. New Abstract Data Types =20 Section 4.1 . of this document specifies several new IPFIX abstract data types. Per Section 6 of the IPFIX information model [RFC5102 ], new abstract data types can be added to the IPFIX information model, in the IPFIX Information Element Data Types registry. =20 Abstract data types to be added to the IPFIX "Information Element Data Types" registry are listed below. =09 EDITOR'S NOTE: IANA, please pick the number three values in the=20 =09 http://www.iana.org/assignments/ipfix/ipfix.xml#informationElementDataTy pes for the basicList, subTemplateList, and subTemplateMultiList =09 =09 =09 Dan, to answer you question about the process to add data types, the above sentence " Per Section 6 of the IPFIX information model [RFC5102 ]" should do the trick. T6. I think that also the Security Considerations of [RFC5102] apply. OLD: =09 Section 12. Security Considerations =09 The same security considerations as for the IPFIX Protocol [RFC5101 ] apply. =09 NEW: =09 12. Security Considerations =09 The same security considerations as for the IPFIX Protocol [RFC5101 ] and the IPFIX information model [RFC5102] apply. =09 =09 =09 =09 E1. Idnits complain about:=20 =09 =3D=3D The copyright year in the IETF Trust and authors Copyright Line does not match the current year Done. =09 E2. All examples are IPv4. This is not a problem by itself, but gives the impression of an IPv4 centric document. Any reason not to provide at least one example that uses IPv6 addresses? Or at least a note that despite the fact that all examples use IPv4 addresses, the document applies for IPv6 as well.=20 We will change one example with IPv6. =09 =09 Are you fine with the answers? Shall we post the new version? =09 Regards, Benoit =09 =09 _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix ------_=_NextPart_001_01CBDA8A.EE0171C3 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 Benoit,
 
Thank=20 you for your answers. They all seem reasonable to me with two = observations:=20
 
T1:=20 can you clarify with text what you explained in your answer? other = people may=20 have the same question
 
T3:=20 the clarification about the length applies not only to 4.5.1 but also to = other=20 sections in 4.5. You need either to make the clarification global at the = start=20 of the section or to include it in all length field definitions where = needed=20
 
Please=20 issue the new version with these changes and we can proceed to IETF Last = Call.=20
 
Regards,
 
Dan
 

From: Benoit Claise = [mailto:bclaise@cisco.com]=20
Sent: Friday, March 04, 2011 11:18 AM
To: = Romascanu, Dan=20 (Dan)
Cc: ipfix@ietf.org
Subject: Re: [IPFIX] AD = review of=20 draft-ietf-ipfix-structured-data-04.txt

Hi Dan,

Thanks for your review.
Inline.
Please find below the AD review of
draft-ietf-ipfix-structured-data-04.txt.=20

The document is in pretty good shape. However I would suggest that the
authors address the questions and issues in this review and issue a
revised I-D if necessary before proceeding to IETF Last Call.=20

The comments are divided in Technical (T) and Editorial (E).=20

T1. What is the use case of the "undefined" semantics defined in 4.4.1.
Different collecting processes may interpret differently the data type.
The use case is when none of the other semantics=20 apply.
An example is an IPFIX Mediator that translates from RFC5101 = to=20 IPFIX structured data. The Collecting Process (part of the IPFIX = Mediator)=20 doesn't know what the semantic is (it can only guess), so it should = use=20 "undefined" when re-exporting. Typical example, a Flow Record received = with 2=20 output interfaces in the RFC5101 style.
T2. The definitions of what needs to be included in the Semantic field
of the IPFIX data types is not clear. For example in 4.5.1 - how is the
relationship among the different Information Element values within the
Structured Data Information Element encoded? etc. need to point to the
new semantics and registry defined in the IANA consideration section.=20
OLD:
      Semantic
    =20
          The Semantic field indicates the relationship among the
          different Information Element values within this Structured
          Data Information Element.
NEW:
      Semantic
    =20
          A numeric value that represents the relationship among the
          different Information Element values within this Structured
          Data Information Element. Refer to IANA's IPFIX "structured=20
          data types semantics registry.=20

T3. Need to mention in what units the =
length in all Element Length data
types encoding is expressed
(the above can be deducted from 5101 or from the examples but there is
no reason not to mention these in section 4.5)
Section 4.5.1
OLD:
      =
Element Length
    =20
          The Element Length field indicates the length of each list
          element specified by Field ID, or contains the value 0xFFFF if
          the length is encoded as a variable-length Information Element =
  =20
          at the start of the basicList Content, per Section 7 of
          [RFC5101].
    =20
          The Element Length field is effectively part of the header, so
          even in the case of a zero-element list, it MUST NOT be
          omitted.
NEW:

      Element Length
    =20
          Per Section 7 of [RFC 5101], the Element Length field =
indicates=20
          the length, in octets, of each list element specified =
by Field ID,=20
          or contains the value 0xFFFF if the length is encoded as a =
variable-length=20
          Information Element at the start of the basicList Content.

          The Element Length field is effectively part of the header, so
          even in the case of a zero-element list, it MUST NOT be
          omitted.


T4. The following paragraph in section 8 =
may raise questions:=20


Typically new Information =
Elements based on the basicList data=20

     type make sense.  For example, =
bgpPathList, bgpSequenceList and=20
     bgpSetList, of abstract types and semantics basicList/ordered,=20
     basicList/ordered, and basicList/exactlyOneOf respectively would=20
     define the complete semantic of the list.  However, the community=20
     needs some more research and feedback before starting to specify=20
     new Information Elements based on the subTemplateList and=20
     subTemplateMultiList data types.  So this specification doesn't=20
     specify any new Information Elements beyond the ones in Section=20
     4.3.=20
     =20
People may ask what kind of research and feedback is still needed, and
if research is still needed why does this specification go to Standards
Track rather than Experimental? Does anything prevent us from saying
that it is expected that such new IE's be standardized in the future
based on implementations made first on vendors space?=20
OLD:
     Typically =
new Information Elements based on the basicList data=20
     type make sense.  For example, bgpPathList, bgpSequenceList and=20
     bgpSetList, of abstract types and semantics basicList/ordered,=20
     basicList/ordered, and basicList/exactlyOneOf respectively would=20
     define the complete semantic of the list.  However, the community=20
     needs some more research and feedback before starting to specify=20
     new Information Elements based on the subTemplateList and=20
     subTemplateMultiList data types.  So this specification doesn't=20
     specify any new Information Elements beyond the ones in Section=20
     4.3.


NEW:

    The authors = anticipate=20 the creation of both enterprise-specific and IANA Information Elements = based=20
    on the IPFIX structured data types. For = example,=20 bgpPathList, bgpSequenceList and bgpSetList,
    of = abstract=20 types and semantics basicList/ordered, basicList/ordered, and=20 basicList/exactlyOneOf respectively
    would define = the=20 complete semantic of the list. This specification doesn't specify any = new=20 Information Elements
    beyond the ones in Section = 4.3.=20 
T5. Section 11.1 - Can new abstract data =
types be added to the newly
created abstract data types registry? If so what is the policy?=20
Actually, you discovered a problem with the IANA=20 section.
11.1. New Abstract Data =
Types
    =20
      Section 4.1. of this document =
specifies several new IPFIX abstract
      data types.  Per Section 6 of the IPFIX information =
model
      [RFC5102], new abstract data types can be =
added to the IPFIX
      information model.  This requires creation of a new IPFIX
      "abstract data types" registry at
      http://www.iana.org/assignments/ipfix.  =
This registry should
      include all the abstract data types from Section 3.1 of [RFC5102].
    =20
      Abstract data types to be added to the IPFIX "abstract data types"
      registry are listed below.
However, this old text is not = valid any=20 more.
In the mean time, this "abstract data types" registry has = been=20 created already, http://www.iana.org/assignments/ipfix/ipfix.xml#informationEl= ementDataTypes,=20 as the outcome of the RFC5610 publication.

New section 
11.1. New Abstract Data Types
    =20
      Section 4.1. of this document =
specifies several new IPFIX abstract
      data types.  Per Section 6 of the IPFIX information =
model
      [RFC5102], new abstract data types can be =
added to the IPFIX
      information model, in the IPFIX Information Element Data Types =
registry.
    =20
      Abstract data types to be added to the IPFIX "Information Element =
Data Types"
      registry are listed below.

      EDITOR'S NOTE: IANA, please pick the number three values in the=20
      http://www.iana.org/assignments/ipfix/ipfix.xml#informationEl=
ementDataTypes
      for the basicList, subTemplateList, and subTemplateMultiList



Dan, to answer you question about the process to add data types, the =
above sentence "
Per Section 6 of the IPFIX information =
model [RFC5102]" should do the trick.

T6. I think that also the Security =
Considerations of [RFC5102] apply.
OLD:

Section 12. Security=20 Considerations

    The same security = considerations as=20 for the IPFIX Protocol
    [RFC5101]=20 apply.

NEW:

12. Security=20 Considerations

    The same security = considerations as=20 for the IPFIX Protocol
    [RFC5101]=20 and the IPFIX information model [RFC5102] apply.


E1. Idnits complain about:=20

=3D=3D The copyright year in the IETF Trust and authors Copyright Line =
does
not
     match the current year
Done.
E2. All examples are IPv4. This is not a =
problem by itself, but gives
the impression of an IPv4 centric document. Any reason not to provide at
least one example that uses IPv6 addresses? Or at least a note that
despite the fact that all examples use IPv4 addresses, the document
applies for IPv6 as well.=20
We will change one example with IPv6.


Are = you=20 fine with the answers?
Shall we post the new = version?

Regards,=20 Benoit
_______________________________________________
IPFIX mailing list
IPFIX@ietf.org
https://www.ietf.org=
/mailman/listinfo/ipfix

------_=_NextPart_001_01CBDA8A.EE0171C3-- From bclaise@cisco.com Fri Mar 4 14:28:12 2011 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3662B3A6970 for ; Fri, 4 Mar 2011 14:28:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.682 X-Spam-Level: X-Spam-Status: No, score=-2.682 tagged_above=-999 required=5 tests=[AWL=-0.084, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RPSacrbAj0sn for ; Fri, 4 Mar 2011 14:28:10 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id EFFC53A68AB for ; Fri, 4 Mar 2011 14:28:08 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p24MPUY8007974; Fri, 4 Mar 2011 23:25:30 +0100 (CET) Received: from [10.55.43.51] (ams-bclaise-8712.cisco.com [10.55.43.51]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p24MPQFM010366; Fri, 4 Mar 2011 23:25:28 +0100 (CET) Message-ID: <4D7166D6.6050500@cisco.com> Date: Fri, 04 Mar 2011 23:25:26 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.14) Gecko/20110221 Thunderbird/3.1.8 MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: <4D70AE2B.5000100@cisco.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------060605080106060205030502" Cc: ipfix@ietf.org Subject: Re: [IPFIX] AD review of draft-ietf-ipfix-structured-data-04.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 22:28:12 -0000 This is a multi-part message in MIME format. --------------060605080106060205030502 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Dan, Your comments make sense Let me produce a new version of the draft, including them. Regards, Benoit. > Hi Benoit, > Thank you for your answers. They all seem reasonable to me with two > observations: > T1: can you clarify with text what you explained in your answer? other > people may have the same question > T3: the clarification about the length applies not only to 4.5.1 but > also to other sections in 4.5. You need either to make the > clarification global at the start of the section or to include it in > all length field definitions where needed > Please issue the new version with these changes and we can proceed to > IETF Last Call. > Regards, > Dan > > ------------------------------------------------------------------------ > *From:* Benoit Claise [mailto:bclaise@cisco.com] > *Sent:* Friday, March 04, 2011 11:18 AM > *To:* Romascanu, Dan (Dan) > *Cc:* ipfix@ietf.org > *Subject:* Re: [IPFIX] AD review of > draft-ietf-ipfix-structured-data-04.txt > > Hi Dan, > > Thanks for your review. > Inline. >> Please find below the AD review of >> draft-ietf-ipfix-structured-data-04.txt. >> >> The document is in pretty good shape. However I would suggest that the >> authors address the questions and issues in this review and issue a >> revised I-D if necessary before proceeding to IETF Last Call. >> >> The comments are divided in Technical (T) and Editorial (E). >> >> T1. What is the use case of the "undefined" semantics defined in 4.4.1. >> Different collecting processes may interpret differently the data type. > The use case is when none of the other semantics apply. > An example is an IPFIX Mediator that translates from RFC5101 to > IPFIX structured data. The Collecting Process (part of the IPFIX > Mediator) doesn't know what the semantic is (it can only guess), > so it should use "undefined" when re-exporting. Typical example, a > Flow Record received with 2 output interfaces in the RFC5101 style. >> T2. The definitions of what needs to be included in the Semantic field >> of the IPFIX data types is not clear. For example in 4.5.1 - how is the >> relationship among the different Information Element values within the >> Structured Data Information Element encoded? etc. need to point to the >> new semantics and registry defined in the IANA consideration section. > OLD: > > Semantic > > The Semantic field indicates the relationship among the > different Information Element values within this Structured > Data Information Element. > > NEW: > > Semantic > > A numeric value that represents the relationship among the > different Information Element values within this Structured > Data Information Element. Refer to IANA's IPFIX "structured > data types semantics registry. > >> T3. Need to mention in what units the length in all Element Length data >> types encoding is expressed >> (the above can be deducted from 5101 or from the examples but there is >> no reason not to mention these in section 4.5) > Section 4.5.1 > OLD: > > Element Length > > The Element Length field indicates the length of each list > element specified by Field ID, or contains the value 0xFFFF if > the length is encoded as a variable-length Information Element > at the start of the basicList Content, per Section 7 of > [RFC5101]. > > The Element Length field is effectively part of the header, so > even in the case of a zero-element list, it MUST NOT be > omitted. > > NEW: > > Element Length > > _Per Section 7 of [RFC 5101],_ the Element Length field indicates > the length,_in octets,_of each list element specified by Field ID, > or contains the value 0xFFFF if the length is encoded as a variable-length > Information Element at the start of the basicList Content. > > The Element Length field is effectively part of the header, so > even in the case of a zero-element list, it MUST NOT be > omitted. > > >> T4. The following paragraph in section 8 may raise questions: >> >>> Typically new Information Elements based on the basicList data >> type make sense. For example, bgpPathList, bgpSequenceList and >> bgpSetList, of abstract types and semantics basicList/ordered, >> basicList/ordered, and basicList/exactlyOneOf respectively would >> define the complete semantic of the list. However, the community >> needs some more research and feedback before starting to specify >> new Information Elements based on the subTemplateList and >> subTemplateMultiList data types. So this specification doesn't >> specify any new Information Elements beyond the ones in Section >> 4.3. >> >> People may ask what kind of research and feedback is still needed, and >> if research is still needed why does this specification go to Standards >> Track rather than Experimental? Does anything prevent us from saying >> that it is expected that such new IE's be standardized in the future >> based on implementations made first on vendors space? > OLD: > > Typically new Information Elements based on the basicList data > type make sense. For example, bgpPathList, bgpSequenceList and > bgpSetList, of abstract types and semantics basicList/ordered, > basicList/ordered, and basicList/exactlyOneOf respectively would > define the complete semantic of the list. However, the community > needs some more research and feedback before starting to specify > new Information Elements based on the subTemplateList and > subTemplateMultiList data types. So this specification doesn't > specify any new Information Elements beyond the ones in Section > 4.3. > > > > NEW: > > The authors anticipate the creation of both > enterprise-specific and IANA Information Elements based > on the IPFIX structured data types. For example, bgpPathList, > bgpSequenceList and bgpSetList, > of abstract types and semantics basicList/ordered, > basicList/ordered, and basicList/exactlyOneOf respectively > would define the complete semantic of the list. This > specification doesn't specify any new Information Elements > beyond the ones in Section 4.3. >> T5. Section 11.1 - Can new abstract data types be added to the newly >> created abstract data types registry? If so what is the policy? > Actually, you discovered a problem with the IANA section. > > > 11.1. New Abstract Data Types > > > Section 4.1 . of this document specifies several new IPFIX abstract > data types. PerSection 6 of the IPFIX information model > [RFC5102 ], new abstract data types can be added to the IPFIX > information model. This requires creation of a new IPFIX > "abstract data types" registry at > http://www.iana.org/assignments/ipfix. This registry should > include all the abstract data types fromSection 3.1 of [RFC5102] . > > Abstract data types to be added to the IPFIX "abstract data types" > registry are listed below. > > However, this old text is not valid any more. > In the mean time, this "abstract data types" registry has been > created already, > http://www.iana.org/assignments/ipfix/ipfix.xml#informationElementDataTypes, > as the outcome of the RFC5610 publication. > > New section > > > 11.1. New Abstract Data Types > > > Section 4.1 . of this document specifies several new IPFIX abstract > data types. PerSection 6 of the IPFIX information model > [RFC5102 ], new abstract data types can be added to the IPFIX > information model, in the IPFIX Information Element Data Types registry. > > Abstract data types to be added to the IPFIX "Information Element Data Types" > registry are listed below. > > EDITOR'S NOTE: IANA, please pick the number three values in the > http://www.iana.org/assignments/ipfix/ipfix.xml#informationElementDataTypes > for the basicList, subTemplateList, and subTemplateMultiList > > > > Dan, to answer you question about the process to add data types, the above sentence " > PerSection 6 of the IPFIX information model [RFC5102 ]" should do the trick. > >> T6. I think that also the Security Considerations of [RFC5102] apply. > OLD: > > Section 12. Security Considerations > > The same security considerations as for the IPFIX Protocol > [RFC5101 ] apply. > > NEW: > > 12. Security Considerations > > The same security considerations as for the IPFIX Protocol > [RFC5101 ] and the IPFIX > information model [RFC5102] apply. >> >> E1. Idnits complain about: >> >> == The copyright year in the IETF Trust and authors Copyright Line does >> not >> match the current year > Done. >> E2. All examples are IPv4. This is not a problem by itself, but gives >> the impression of an IPv4 centric document. Any reason not to provide at >> least one example that uses IPv6 addresses? Or at least a note that >> despite the fact that all examples use IPv4 addresses, the document >> applies for IPv6 as well. > We will change one example with IPv6. > > > Are you fine with the answers? > Shall we post the new version? > > Regards, Benoit >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix > --------------060605080106060205030502 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Dan,

Your comments make sense
Let me produce a new version of the draft, including them.

Regards, Benoit.
Hi Benoit,
 
Thank you for your answers. They all seem reasonable to me with two observations:
 
T1: can you clarify with text what you explained in your answer? other people may have the same question
 
T3: the clarification about the length applies not only to 4.5.1 but also to other sections in 4.5. You need either to make the clarification global at the start of the section or to include it in all length field definitions where needed
 
Please issue the new version with these changes and we can proceed to IETF Last Call.
 
Regards,
 
Dan
 

From: Benoit Claise [mailto:bclaise@cisco.com]
Sent: Friday, March 04, 2011 11:18 AM
To: Romascanu, Dan (Dan)
Cc: ipfix@ietf.org
Subject: Re: [IPFIX] AD review of draft-ietf-ipfix-structured-data-04.txt

Hi Dan,

Thanks for your review.
Inline.
Please find below the AD review of
draft-ietf-ipfix-structured-data-04.txt. 

The document is in pretty good shape. However I would suggest that the
authors address the questions and issues in this review and issue a
revised I-D if necessary before proceeding to IETF Last Call. 

The comments are divided in Technical (T) and Editorial (E). 

T1. What is the use case of the "undefined" semantics defined in 4.4.1.
Different collecting processes may interpret differently the data type.
The use case is when none of the other semantics apply.
An example is an IPFIX Mediator that translates from RFC5101 to IPFIX structured data. The Collecting Process (part of the IPFIX Mediator) doesn't know what the semantic is (it can only guess), so it should use "undefined" when re-exporting. Typical example, a Flow Record received with 2 output interfaces in the RFC5101 style.
T2. The definitions of what needs to be included in the Semantic field
of the IPFIX data types is not clear. For example in 4.5.1 - how is the
relationship among the different Information Element values within the
Structured Data Information Element encoded? etc. need to point to the
new semantics and registry defined in the IANA consideration section.
OLD:
      Semantic
     
          The Semantic field indicates the relationship among the
          different Information Element values within this Structured
          Data Information Element.
NEW:
      Semantic
     
          A numeric value that represents the relationship among the
          different Information Element values within this Structured
          Data Information Element. Refer to IANA's IPFIX "structured 
          data types semantics registry. 

T3. Need to mention in what units the length in all Element Length data
types encoding is expressed
(the above can be deducted from 5101 or from the examples but there is
no reason not to mention these in section 4.5)
Section 4.5.1
OLD:
      Element Length
     
          The Element Length field indicates the length of each list
          element specified by Field ID, or contains the value 0xFFFF if
          the length is encoded as a variable-length Information Element    
          at the start of the basicList Content, per Section 7 of
          [RFC5101].
     
          The Element Length field is effectively part of the header, so
          even in the case of a zero-element list, it MUST NOT be
          omitted.
NEW:

      Element Length
     
          Per Section 7 of [RFC 5101], the Element Length field indicates 
          the length, in octets, of each list element specified by Field ID, 
          or contains the value 0xFFFF if the length is encoded as a variable-length 
          Information Element at the start of the basicList Content.

          The Element Length field is effectively part of the header, so
          even in the case of a zero-element list, it MUST NOT be
          omitted.


T4. The following paragraph in section 8 may raise questions: 


Typically new Information Elements based on the basicList data 

     type make sense.  For example, bgpPathList, bgpSequenceList and 
     bgpSetList, of abstract types and semantics basicList/ordered, 
     basicList/ordered, and basicList/exactlyOneOf respectively would 
     define the complete semantic of the list.  However, the community 
     needs some more research and feedback before starting to specify 
     new Information Elements based on the subTemplateList and 
     subTemplateMultiList data types.  So this specification doesn't 
     specify any new Information Elements beyond the ones in Section 
     4.3. 
      
People may ask what kind of research and feedback is still needed, and
if research is still needed why does this specification go to Standards
Track rather than Experimental? Does anything prevent us from saying
that it is expected that such new IE's be standardized in the future
based on implementations made first on vendors space?
OLD:
     Typically new Information Elements based on the basicList data 
     type make sense.  For example, bgpPathList, bgpSequenceList and 
     bgpSetList, of abstract types and semantics basicList/ordered, 
     basicList/ordered, and basicList/exactlyOneOf respectively would 
     define the complete semantic of the list.  However, the community 
     needs some more research and feedback before starting to specify 
     new Information Elements based on the subTemplateList and 
     subTemplateMultiList data types.  So this specification doesn't 
     specify any new Information Elements beyond the ones in Section 
     4.3.


NEW:

    The authors anticipate the creation of both enterprise-specific and IANA Information Elements based
    on the IPFIX structured data types. For example, bgpPathList, bgpSequenceList and bgpSetList,
    of abstract types and semantics basicList/ordered, basicList/ordered, and basicList/exactlyOneOf respectively
    would define the complete semantic of the list. This specification doesn't specify any new Information Elements
    beyond the ones in Section 4.3. 
T5. Section 11.1 - Can new abstract data types be added to the newly
created abstract data types registry? If so what is the policy?
Actually, you discovered a problem with the IANA section.
11.1. New Abstract Data Types
     
      Section 4.1. of this document specifies several new IPFIX abstract
      data types.  Per Section 6 of the IPFIX information model
      [RFC5102], new abstract data types can be added to the IPFIX
      information model.  This requires creation of a new IPFIX
      "abstract data types" registry at
      http://www.iana.org/assignments/ipfix.  This registry should
      include all the abstract data types from Section 3.1 of [RFC5102].
     
      Abstract data types to be added to the IPFIX "abstract data types"
      registry are listed below.
However, this old text is not valid any more.
In the mean time, this "abstract data types" registry has been created already, http://www.iana.org/assignments/ipfix/ipfix.xml#informationElementDataTypes, as the outcome of the RFC5610 publication.

New section 
11.1. New Abstract Data Types
     
      Section 4.1. of this document specifies several new IPFIX abstract
      data types.  Per Section 6 of the IPFIX information model
      [RFC5102], new abstract data types can be added to the IPFIX
      information model, in the IPFIX Information Element Data Types registry.
     
      Abstract data types to be added to the IPFIX "Information Element Data Types"
      registry are listed below.

      EDITOR'S NOTE: IANA, please pick the number three values in the 
      http://www.iana.org/assignments/ipfix/ipfix.xml#informationElementDataTypes
      for the basicList, subTemplateList, and subTemplateMultiList



Dan, to answer you question about the process to add data types, the above sentence "
Per Section 6 of the IPFIX information model [RFC5102]" should do the trick.

T6. I think that also the Security Considerations of [RFC5102] apply.
OLD:

Section 12. Security Considerations

    The same security considerations as for the IPFIX Protocol
    [RFC5101] apply.

NEW:

12. Security Considerations

    The same security considerations as for the IPFIX Protocol
    [RFC5101] and the IPFIX information model [RFC5102] apply.

E1. Idnits complain about: 

== The copyright year in the IETF Trust and authors Copyright Line does
not
     match the current year
Done.
E2. All examples are IPv4. This is not a problem by itself, but gives
the impression of an IPv4 centric document. Any reason not to provide at
least one example that uses IPv6 addresses? Or at least a note that
despite the fact that all examples use IPv4 addresses, the document
applies for IPv6 as well.
We will change one example with IPv6.


Are you fine with the answers?
Shall we post the new version?

Regards, Benoit
_______________________________________________
IPFIX mailing list
IPFIX@ietf.org
https://www.ietf.org/mailman/listinfo/ipfix


--------------060605080106060205030502-- From Internet-Drafts@ietf.org Mon Mar 7 01:45:07 2011 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B24E33A694D; Mon, 7 Mar 2011 01:45:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.544 X-Spam-Level: X-Spam-Status: No, score=-102.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gYRSPNhcXwPZ; Mon, 7 Mar 2011 01:45:03 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FD6A28C0D7; Mon, 7 Mar 2011 01:45:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110307094502.21971.71447.idtracker@localhost> Date: Mon, 07 Mar 2011 01:45:02 -0800 Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action:draft-ietf-ipfix-structured-data-05.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2011 09:45:07 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Flow Information Export Working Group of the IETF. Title : Export of Structured Data in IPFIX Author(s) : B. Claise, et al. Filename : draft-ietf-ipfix-structured-data-05.txt Pages : 74 Date : 2011-03-07 This document specifies an extension to the IP Flow Information eXport (IPFIX) protocol specification in [RFC5101] and the IPFIX information model specified in [RFC5102] to support hierarchical structured data and lists (sequences) of Information Elements in data records. This extension allows definition of complex data structures such as variable-length lists and specification of hierarchical containment relationships between Templates. Finally, the semantics are provided in order to express the relationship among multiple list elements in a structured data record. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipfix-structured-data-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ipfix-structured-data-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-07014312.I-D@ietf.org> --NextPart-- From iesg-secretary@ietf.org Mon Mar 7 07:40:33 2011 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAB8D3A68DC; Mon, 7 Mar 2011 07:40:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.322 X-Spam-Level: X-Spam-Status: No, score=-102.322 tagged_above=-999 required=5 tests=[AWL=0.277, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yWbBu3i9W4yc; Mon, 7 Mar 2011 07:40:32 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2CA63A67E7; Mon, 7 Mar 2011 07:40:32 -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: 3.12 Message-ID: <20110307154032.7510.35691.idtracker@localhost> Date: Mon, 07 Mar 2011 07:40:32 -0800 Cc: ipfix@ietf.org Subject: [IPFIX] Last Call: (Export of Structured Data in IPFIX) to Proposed Standard X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2011 15:40:33 -0000 The IESG has received a request from the IP Flow Information Export WG (ipfix) to consider the following document: - 'Export of Structured Data in IPFIX' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-03-21. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-ipfix-structured-data/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-ipfix-structured-data/ No IPR declarations have been submitted directly on this I-D. From Internet-Drafts@ietf.org Wed Mar 9 02:15:02 2011 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B85BA3A68EC; Wed, 9 Mar 2011 02:15:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.564 X-Spam-Level: X-Spam-Status: No, score=-102.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LGvMhteLS3hK; Wed, 9 Mar 2011 02:15:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 081503A6846; Wed, 9 Mar 2011 02:15:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110309101502.16501.96963.idtracker@localhost> Date: Wed, 09 Mar 2011 02:15:02 -0800 Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action:draft-ietf-ipfix-configuration-model-09.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 10:15:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Flow Information Export Working Group of the IETF. Title : Configuration Data Model for IPFIX and PSAMP Author(s) : G. Muenz, et al. Filename : draft-ietf-ipfix-configuration-model-09.txt Pages : 124 Date : 2011-03-09 This document specifies a data model for configuring and monitoring Selection Processes, Caches, Exporting Processes, and Collecting Processes of IPFIX and PSAMP compliant Monitoring Devices using the NETCONF protocol [RFC4741]. The data model is defined using UML (Unified Modeling Language) class diagrams and formally specified using YANG [RFC6020]. The configuration data is encoded in Extensible Markup Language (XML). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipfix-configuration-model-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ipfix-configuration-model-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-09020531.I-D@ietf.org> --NextPart-- From trammell@tik.ee.ethz.ch Wed Mar 9 05:38:41 2011 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8403D3A67E4 for ; Wed, 9 Mar 2011 05:38:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M2zUA9dGbw+j for ; Wed, 9 Mar 2011 05:38:37 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id 60A9D3A69D3 for ; Wed, 9 Mar 2011 05:38:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 8593BD933F for ; Wed, 9 Mar 2011 14:39:52 +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 4S55-nBVF0lP for ; Wed, 9 Mar 2011 14:39:52 +0100 (MET) Received: from pb-10243.ethz.ch (pb-10243.ethz.ch [82.130.102.152]) (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 4E733D9336 for ; Wed, 9 Mar 2011 14:39:52 +0100 (MET) From: Brian Trammell Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 9 Mar 2011 14:39:51 +0100 References: <20110309132300.D8FFA3A69BC@core3.amsl.com> To: IPFIX Working Group Message-Id: <1541E0F7-3E50-41A7-9015-3C33C488F7DC@tik.ee.ethz.ch> Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [IPFIX] Fwd: New Version Notification for draft-trammell-ipfix-ie-doctors-01 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 13:38:41 -0000 Greetings, all, We've posted an updated version of the IE-Doctors draft. This revision = expands on the -00 revision, with tweaks to the Information Element = definition guidelines, and a greatly expanded set of guidelines on = defining new IPFIX applications via Internet-Draft. At this point, the = authors believe that the document is functionally complete, and ready = for adoption as a WG item. Indeed, all further open issues should be = decided with the IPFIX WG, and input from the IESG and IANA. Best regards, Brian Begin forwarded message: > From: IETF I-D Submission Tool > Date: March 9, 2011 2:23:00 PM GMT+01:00 > To: trammell@tik.ee.ethz.ch > Cc: bclaise@cisco.com > Subject: New Version Notification for = draft-trammell-ipfix-ie-doctors-01=20 >=20 >=20 > A new version of I-D, draft-trammell-ipfix-ie-doctors-01.txt has been = successfully submitted by Brian Trammell and posted to the IETF = repository. >=20 > Filename: draft-trammell-ipfix-ie-doctors > Revision: 01 > Title: Guidelines for Authors and Reviewers of IPFIX = Information Elements > Creation_date: 2011-03-09 > WG ID: Independent Submission > Number_of_pages: 24 >=20 > Abstract: > This document provides guidelines for the definition of IPFIX > Information Elements for addition to the IANA IPFIX Information > Element registry, in order to extend the applicability of the IPFIX > protocol to new operations and management areas. >=20 >=20 >=20 > The IETF Secretariat. >=20 From trammell@tik.ee.ethz.ch Wed Mar 9 06:58:43 2011 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B52C63A6855 for ; Wed, 9 Mar 2011 06:58:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oFBO4SAEYW3i for ; Wed, 9 Mar 2011 06:58:42 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id 6A8763A6A12 for ; Wed, 9 Mar 2011 06:58:42 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 91202D9366 for ; Wed, 9 Mar 2011 15:59:58 +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 bGy9+jPT6F+q for ; Wed, 9 Mar 2011 15:59:58 +0100 (MET) Received: from pb-10243.ethz.ch (pb-10243.ethz.ch [82.130.102.152]) (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 3309FD933F for ; Wed, 9 Mar 2011 15:59:58 +0100 (MET) From: Brian Trammell Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 9 Mar 2011 15:59:57 +0100 Message-Id: <0D1AFB82-A46F-47BD-9086-40B301AE54FE@tik.ee.ethz.ch> To: IPFIX Working Group Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [IPFIX] DEMONS IPFIX Interoperability Test, Prague, 24-25 March 2011 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 14:58:43 -0000 Greetings, all, An updated test protocol for the IPFIX Interoperability Event sponsored = by DEMONS is now available at http://fp7-demons.eu/?p=3D164. If you have = an IPFIX implementation, plan to attend, and have not yet registered, = please do contact me via email at trammell@tik.ee.ethz.ch. See you in Prague! Best regards, Brian Trammell= From muenz@net.in.tum.de Wed Mar 9 08:29:40 2011 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CC3E3A6881 for ; Wed, 9 Mar 2011 08:29:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TlWiKYTDeW5M for ; Wed, 9 Mar 2011 08:29:39 -0800 (PST) Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) by core3.amsl.com (Postfix) with ESMTP id DBDD23A683E for ; Wed, 9 Mar 2011 08:29:38 -0800 (PST) Received: by mail.net.in.tum.de (Postfix, from userid 81) id 043E8202FDA4; Wed, 9 Mar 2011 17:30:42 +0100 (CET) To: X-PHP-Originating-Script: 0:func.inc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 09 Mar 2011 17:30:41 +0100 From: Gerhard Muenz Message-ID: <2c8d71fe537f337b6443454b4dabd2f9@net.in.tum.de> X-Sender: muenz@net.in.tum.de User-Agent: Roundcube Webmail/0.5.1 Subject: [IPFIX] Fwd: I-D Action:draft-ietf-ipfix-configuration-model-09.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 16:29:40 -0000 Dear all, I have submitted a new version of the configuration draft which addresses the comments made by Lada and Mehmet/Bernd during the second WGLC. Thanks again for your valuable feedback. There was some concern about the size of the yang module. The configuration could be split into Exporter and Collector configuration, or even into OP/MP, EP, and CP configuration. However, if I understand correctly, references (leafrefs) across yang modules are only possible if the source module imports the destination module. Hence, as MP refers to EP, the MP module would need to import the EP module. Similary, the CP module would need to import the EP module as well. In addition, all modules would need to import one module with common type definitions. All in all, it seems that we would not gain much by splitting the module. So, the current draft still contains a single yang module. Kind regards, Gerhard -------- Original Message -------- Subject: [IPFIX] I-D Action:draft-ietf-ipfix-configuration-model-09.txt Date: Wed, 09 Mar 2011 02:15:02 -0800 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ipfix@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Flow Information Export Working Group of the IETF. Title : Configuration Data Model for IPFIX and PSAMP Author(s) : G. Muenz, et al. Filename : draft-ietf-ipfix-configuration-model-09.txt Pages : 124 Date : 2011-03-09 This document specifies a data model for configuring and monitoring Selection Processes, Caches, Exporting Processes, and Collecting Processes of IPFIX and PSAMP compliant Monitoring Devices using the NETCONF protocol [RFC4741]. The data model is defined using UML (Unified Modeling Language) class diagrams and formally specified using YANG [RFC6020]. The configuration data is encoded in Extensible Markup Language (XML). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipfix-configuration-model-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From Quittek@neclab.eu Wed Mar 9 19:14:47 2011 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 151BD3A6870 for ; Wed, 9 Mar 2011 19:14:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.424 X-Spam-Level: X-Spam-Status: No, score=-102.424 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wJYwR23zUm6B for ; Wed, 9 Mar 2011 19:14:45 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 867F93A67D6 for ; Wed, 9 Mar 2011 19:14:45 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 102DB2C000200; Thu, 10 Mar 2011 04:17:37 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office.hd) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rIY6agBOQ6fx; Thu, 10 Mar 2011 04:17:36 +0100 (CET) Received: from METHONE.office.hd (Methone.office.hd [192.168.24.54]) by smtp0.neclab.eu (Postfix) with ESMTP id E7E3A2C0001DE; Thu, 10 Mar 2011 04:17:26 +0100 (CET) Received: from DAPHNIS.office.hd ([169.254.2.136]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0270.001; Thu, 10 Mar 2011 04:15:52 +0100 From: Juergen Quittek To: Gerhard Muenz , IETF IPFIX Working Group Thread-Topic: [IPFIX] Fwd: I-D Action:draft-ietf-ipfix-configuration-model-09.txt Thread-Index: Acve0XYItWeiim2sEEKtitCUIJJNlw== Date: Thu, 10 Mar 2011 03:15:49 +0000 Message-ID: In-Reply-To: <2c8d71fe537f337b6443454b4dabd2f9@net.in.tum.de> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.8.0.101117 x-originating-ip: [10.7.0.92] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [IPFIX] Fwd: I-D Action:draft-ietf-ipfix-configuration-model-09.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 03:14:47 -0000 Hi Gerhard, Do you consider this draft ready for requesting publication? Or would it be better to discuss the YANG module at Prague? Thanks, Juergen Am 09.03.11 17:30 schrieb "Gerhard Muenz" unter : >=20 > Dear all, >=20 > I have submitted a new version of the configuration draft which > addresses the comments made by Lada and Mehmet/Bernd during the second > WGLC. Thanks again for your valuable feedback. >=20 > There was some concern about the size of the yang module. The > configuration could be split into Exporter and Collector configuration, > or even into OP/MP, EP, and CP configuration. However, if I understand > correctly, references (leafrefs) across yang modules are only possible > if the source module imports the destination module. Hence, as MP refers > to EP, the MP module would need to import the EP module. Similary, the > CP module would need to import the EP module as well. In addition, all > modules would need to import one module with common type definitions. >=20 > All in all, it seems that we would not gain much by splitting the > module. So, the current draft still contains a single yang module. >=20 > Kind regards, > Gerhard >=20 > -------- Original Message -------- > Subject: [IPFIX] I-D Action:draft-ietf-ipfix-configuration-model-09.txt > Date: Wed, 09 Mar 2011 02:15:02 -0800 > From: Internet-Drafts@ietf.org > To: i-d-announce@ietf.org > Cc: ipfix@ietf.org >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the IP Flow Information Export Working > Group of the IETF. >=20 >=20 > Title : Configuration Data Model for IPFIX and PSAMP > Author(s) : G. Muenz, et al. > Filename : draft-ietf-ipfix-configuration-model-09.txt > Pages : 124 > Date : 2011-03-09 >=20 > This document specifies a data model for configuring and monitoring > Selection Processes, Caches, Exporting Processes, and Collecting > Processes of IPFIX and PSAMP compliant Monitoring Devices using the > NETCONF protocol [RFC4741]. The data model is defined using UML > (Unified Modeling Language) class diagrams and formally specified > using YANG [RFC6020]. The configuration data is encoded in > Extensible Markup Language (XML). >=20 > A URL for this Internet-Draft is: > =20 >=20 http://www.ietf.org/internet-drafts/draft-ietf-ipfix-configuration-model-09= .tx> t >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. >=20 > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From muenz@net.in.tum.de Thu Mar 10 01:05:58 2011 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 265543A6968 for ; Thu, 10 Mar 2011 01:05:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id opNOEH02F+QZ for ; Thu, 10 Mar 2011 01:05:57 -0800 (PST) Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) by core3.amsl.com (Postfix) with ESMTP id 2E3093A67EF for ; Thu, 10 Mar 2011 01:05:56 -0800 (PST) Received: by mail.net.in.tum.de (Postfix, from userid 81) id 6717D205695C; Thu, 10 Mar 2011 10:07:14 +0100 (CET) To: Juergen Quittek X-PHP-Originating-Script: 0:func.inc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Thu, 10 Mar 2011 10:07:14 +0100 From: Gerhard Muenz In-Reply-To: References: Message-ID: X-Sender: muenz@net.in.tum.de User-Agent: Roundcube Webmail/0.5.1 Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] Fwd: I-D Action:draft-ietf-ipfix-configuration-model-09.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 09:05:58 -0000 Hi Jürgen, I will not be in Prague. So, from my side, there is no need to discuss the yang module there. We could wait for a brief feedback from the yang doctors. Otherwise, the draft is ready for publication. Regards, Gerhard On Thu, 10 Mar 2011 03:15:49 +0000, Juergen Quittek wrote: > Hi Gerhard, > > Do you consider this draft ready for requesting publication? > Or would it be better to discuss the YANG module at Prague? > > Thanks, > > Juergen > > > Am 09.03.11 17:30 schrieb "Gerhard Muenz" unter > : > >> >> Dear all, >> >> I have submitted a new version of the configuration draft which >> addresses the comments made by Lada and Mehmet/Bernd during the >> second >> WGLC. Thanks again for your valuable feedback. >> >> There was some concern about the size of the yang module. The >> configuration could be split into Exporter and Collector >> configuration, >> or even into OP/MP, EP, and CP configuration. However, if I >> understand >> correctly, references (leafrefs) across yang modules are only >> possible >> if the source module imports the destination module. Hence, as MP >> refers >> to EP, the MP module would need to import the EP module. Similary, >> the >> CP module would need to import the EP module as well. In addition, >> all >> modules would need to import one module with common type >> definitions. >> >> All in all, it seems that we would not gain much by splitting the >> module. So, the current draft still contains a single yang module. >> >> Kind regards, >> Gerhard >> >> -------- Original Message -------- >> Subject: [IPFIX] I-D >> Action:draft-ietf-ipfix-configuration-model-09.txt >> Date: Wed, 09 Mar 2011 02:15:02 -0800 >> From: Internet-Drafts@ietf.org >> To: i-d-announce@ietf.org >> Cc: ipfix@ietf.org >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the IP Flow Information Export Working >> Group of the IETF. >> >> >> Title : Configuration Data Model for IPFIX and PSAMP >> Author(s) : G. Muenz, et al. >> Filename : draft-ietf-ipfix-configuration-model-09.txt >> Pages : 124 >> Date : 2011-03-09 >> >> This document specifies a data model for configuring and monitoring >> Selection Processes, Caches, Exporting Processes, and Collecting >> Processes of IPFIX and PSAMP compliant Monitoring Devices using the >> NETCONF protocol [RFC4741]. The data model is defined using UML >> (Unified Modeling Language) class diagrams and formally specified >> using YANG [RFC6020]. The configuration data is encoded in >> Extensible Markup Language (XML). >> >> A URL for this Internet-Draft is: >> >> > > http://www.ietf.org/internet-drafts/draft-ietf-ipfix-configuration-model-09.tx> > t >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix From bclaise@cisco.com Thu Mar 10 05:39:25 2011 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB2A73A69C2 for ; Thu, 10 Mar 2011 05:39:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.661 X-Spam-Level: X-Spam-Status: No, score=-2.661 tagged_above=-999 required=5 tests=[AWL=-0.063, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J3J5mvk1gZfd for ; Thu, 10 Mar 2011 05:39:25 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id DACF23A6971 for ; Thu, 10 Mar 2011 05:39:24 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p2ADavTE026706 for ; Thu, 10 Mar 2011 14:36:57 +0100 (CET) Received: from [10.55.43.51] (ams-bclaise-8712.cisco.com [10.55.43.51]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p2ADauoq012327 for ; Thu, 10 Mar 2011 14:36:56 +0100 (CET) Message-ID: <4D78D3F8.8000200@cisco.com> Date: Thu, 10 Mar 2011 14:36:56 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "ipfix@ietf.org" Content-Type: multipart/alternative; boundary="------------060101030005040400000307" Subject: [IPFIX] Fwd: New Version Notification for draft-claise-export-application-info-in-ipfix-01 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 13:39:26 -0000 This is a multi-part message in MIME format. --------------060101030005040400000307 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Dear all, Here is a new version of the draft, which includes: - how to handle the discrepancies between the TCP and SCTP well known ports - the introduction of application attributes such as category, sub-category, group, p2pTechnology, encryptedTechnology, and tunnelTechnology - the introduction of an Options Template Record for the Attribute Values Regards, Benoit. -------- Original Message -------- Subject: New Version Notification for draft-claise-export-application-info-in-ipfix-01 Date: Thu, 10 Mar 2011 05:23:18 -0800 (PST) From: IETF I-D Submission Tool To: bclaise@cisco.com CC: paitken@cisco.com, nirbd@cisco.com A new version of I-D, draft-claise-export-application-info-in-ipfix-01.txt has been successfully submitted by Benoit Claise and posted to the IETF repository. Filename: draft-claise-export-application-info-in-ipfix Revision: 01 Title: Export of Application Information in IPFIX Creation_date: 2011-03-09 WG ID: Independent Submission Number_of_pages: 34 Abstract: This document specifies an extension to the IPFIX information model specified in [RFC5102] to export application information. The IETF Secretariat. --------------060101030005040400000307 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Dear all,

Here is a new version of the draft, which includes:
- how to handle the discrepancies between the TCP and SCTP well known ports
- the introduction of application attributes such as category, sub-category, group, p2pTechnology, encryptedTechnology, and tunnelTechnology
- the introduction of an Options Template Record for the Attribute Values

Regards, Benoit.

-------- Original Message --------
Subject: New Version Notification for draft-claise-export-application-info-in-ipfix-01
Date: Thu, 10 Mar 2011 05:23:18 -0800 (PST)
From: IETF I-D Submission Tool <idsubmission@ietf.org>
To: bclaise@cisco.com
CC: paitken@cisco.com, nirbd@cisco.com 


A new version of I-D, draft-claise-export-application-info-in-ipfix-01.txt has been successfully submitted by Benoit Claise and posted to the IETF repository.

Filename:	 draft-claise-export-application-info-in-ipfix
Revision:	 01
Title:		 Export of Application Information in IPFIX
Creation_date:	 2011-03-09
WG ID:		 Independent Submission
Number_of_pages: 34

Abstract:
This document specifies an extension to the IPFIX information 

  model specified in [RFC5102] to export application information.
                                                                                  


The IETF Secretariat.
--------------060101030005040400000307-- From bclaise@cisco.com Mon Mar 14 00:01:54 2011 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B39B3A67FF; Mon, 14 Mar 2011 00:01:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.48 X-Spam-Level: X-Spam-Status: No, score=-2.48 tagged_above=-999 required=5 tests=[AWL=-0.237, BAYES_00=-2.599, SARE_SUB_6CONS_WORD=0.356] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7uUVNFqaCP1W; Mon, 14 Mar 2011 00:01:53 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 0EC0A3A6B07; Mon, 14 Mar 2011 00:01:52 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p2E73Fq5025014; Mon, 14 Mar 2011 08:03:15 +0100 (CET) Received: from [10.55.43.52] (ams-bclaise-8713.cisco.com [10.55.43.52]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p2E73Epn006181; Mon, 14 Mar 2011 08:03:14 +0100 (CET) Message-ID: <4D7DBDB2.7010102@cisco.com> Date: Mon, 14 Mar 2011 08:03:14 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "James M. Polk" References: <201102080311.p183BpvU025288@sj-core-2.cisco.com> <201103132048.p2DKmrP1017369@rcdn-core-2.cisco.com> In-Reply-To: <201103132048.p2DKmrP1017369@rcdn-core-2.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ipfix@ietf.org" , tsvwg Subject: Re: [IPFIX] WGLC for draft-ietf-tsvwg-sctp-strrst-09 continues X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 07:01:54 -0000 Hi James, > TSVWG > > The WG chairs have determined the WGLC for our SCTP Stream > Reconfiguration ID continues (i.e., it has not concluded at the 2 week > window) due to lack of feedback to the list. No one has commented in a > review format that they believe this ID should progress. No one has > even sent a note merely saying this ID in its present form is good to > go. That lack of any feedback is troubling and could be a sign of a > lack of interest in this ID. I'm not a transport expert so I can't comment on the technical part. However, there is a clear interest: the functionality in the draft is required. "The IPFIX export per SCTP stream", https://datatracker.ietf.org/doc/draft-ietf-ipfix-export-per-sctp-stream/ has been sitting for 8 months in the RFC editor queue, waiting for this draft. Regards, Benoit. > > The WG chairs like the idea of (and within) this draft, but we need > transport experts to tell us this, and if the ID in its present form > is good enough to implement to without those implementations having > errors or causing bad behavior in SCTP because of how the ID is > written (focusing mostly on the instructions to implementers in the ID). > > We chairs want folks to show or assert they have reviewed this ID and > give feedback to the list (and not unicast to the chairs). This ID > cannot progress without that feedback. > > James & Gorry > TSVWG chairs > > > At 10:07 PM 2/7/2011, James M. Polk wrote: >> TSVWG >> >> I am starting the WGLC for >> >> "Stream Control Transmission Protocol (SCTP) Stream Reconfiguration" >> http://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-strrst/ >> >> this is a 2 week WGLC, ending February 22nd, 2011 or when the chairs >> feel the WG has reviewed the draft and reached consensus to progress >> towards the ADs with the goal of becoming a proposed standard (PS) RFC. >> >> The chairs require substantive feedback from the WG regarding this >> draft before consensus can be called. >> >> I will be the document shepherd. >> >> James >> TSVWG chair From salvatore.dantonio@uniparthenope.it Mon Mar 14 05:14:22 2011 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF6FF3A6A68 for ; Mon, 14 Mar 2011 05:14:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.402 X-Spam-Level: ** X-Spam-Status: No, score=2.402 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, GB_I_LETTER=-2, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1.449, SARE_SPEC_REPLICA_OBFU=1.812] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vh+8lZiICS5X for ; Mon, 14 Mar 2011 05:14:09 -0700 (PDT) Received: from mail.uniparthenope.it (mail.uniparthenope.it [192.167.9.244]) by core3.amsl.com (Postfix) with ESMTP id 651113A6994 for ; Mon, 14 Mar 2011 05:14:08 -0700 (PDT) Received: from mail2.uniparthenope.it (unknown [10.1.2.108]) by mail.uniparthenope.it (Postfix) with SMTP id 6B0AE1244E; Mon, 14 Mar 2011 12:15:20 +0000 (UTC) Received: from (unknown [192.168.241.108]) by mail2.uniparthenope.it with smtp id 3eed_baa4451a_4e34_11e0_8fe1_001372515a5c; Mon, 14 Mar 2011 13:15:18 +0100 Received: from spamk.uniparthenope.it (localhost [127.0.0.1]) by spamk.uniparthenope.it (Postfix) with ESMTP id 7AEBFC42EE; Mon, 14 Mar 2011 14:13:43 +0100 (CET) Received: by spamk.uniparthenope.it (Postfix, from userid 500) id 72AEFC42F0; Mon, 14 Mar 2011 14:13:43 +0100 (CET) Received: from mail.uniparthenope.it (mail.uniparthenope.it [192.167.9.244]) by spamk.uniparthenope.it (Postfix) with ESMTP id 073C8C42EF; Mon, 14 Mar 2011 14:13:32 +0100 (CET) Received: from saldantoPC (unknown [192.168.162.11]) (Authenticated sender: salvatore.dantonio@uniparthenope.it) by mail.uniparthenope.it (Postfix) with ESMTPA id 8B5F91244E; Mon, 14 Mar 2011 13:15:07 +0100 (CET) From: "Salvatore D'Antonio" To: "'Benoit Claise'" , References: <4D5B7643.2010701@cisco.com> In-Reply-To: <4D5B7643.2010701@cisco.com> Date: Mon, 14 Mar 2011 13:15:07 +0100 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvNqQxRFuq5rWHfQ3ulbejHRulywQUjWFMg Content-Language: it Message-ID: <003101cbe241$75304380$5f90ca80$@dantonio@uniparthenope.it> Content-Type: multipart/alternative; boundary="----=_NextPart_000_0032_01CBE249.D6F4AB80" X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.42/RELEASE, bases: 20110314 #5066331, check: 20110314 clean Subject: [IPFIX] R: Flow-selection-tech: review X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 12:14:23 -0000 Messaggio multipart in formato MIME. ------=_NextPart_000_0032_01CBE249.D6F4AB80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Benoit, =20 a new version of the Internet Draft on Flow Selection has been posted. =20 Answers to your comments are in line. =20 Regards, =20 =20 Salvatore =20 Da: ipfix-bounces@ietf.org [mailto:ipfix-bounces@ietf.org] Per conto di Benoit Claise Inviato: mercoled=EC 16 febbraio 2011 08:01 A: ipfix@ietf.org Oggetto: [IPFIX] Flow-selection-tech: review =20 Dear all, I've been reviewing the draft, mainly in the context of the IPFIX = Mediation Protocol draft, to make that all the mediation related drafts are in = line: requirements (RFC 5982), framework (RFC-editor), anonymization, flow selection techniques, aggregation, and finally the protocol. Sorry if I'm late, this flow selection technique is the last one I = reviewed. The important issues start with "important" - Reference. Sometimes referred as the RFC number [RFC5475 ], and sometimes as [IPFIX-REQ ] =20 =20 Fixed. - "Flow selection reduces the resource demands for capturing, storing, exporting and post-processing flow-based measurement results." Actually, reduces the resource demands for post-processing flow-based measurement results, that's for sure. While, reduces the resource demands for capturing, storing -> it = depends: if you have to look at the all packets, hence all flows, in order to do = the flow selection (like the elephant), you don't gain much. You might want to clarify. Somehow, you have to go in the conclusions of [EsVa01] to discover this. A sentence addressing this point has been added.=20 - Terminology This document is consistent with the terminology introduced in [RFC5470 ], [RFC5475 ] and [IPFIX-REQ ]. Further some additional terms are presented which extend the terminology. =20 * Flow =20 A Flow is defined as a set of packets with common properties passing an Observation Point in the network during a certain time interval. =20 Actually "Flow" is not an additional term, as it's defined already in RFC5101. However, the definitions are not quite the same. Isn't it confusing? =20 Yes, you are right. The =93Flow=94 definition has been removed. =20 The "Flow record" definition is exactly the same as RFC5101. Why = redefined? =20 =93Flow record=94 definition removed. =20 Important point: this is the first draft in the IPFIX series that = doesn't use capitalized definitions. All IPFIX draft uses a sentence such as:=20 At the beginning of the terminology section, you might add a sentence such as: In this document, as in [RFC5101 = ] and [RFC5476 ], the first letter of each IPFIX-specific and PSAMP-specific term is capitalized along with the IPFIX Mediation-specific terms defined here. However, some sentences use the capitalization. "As an example, if an IPFIX Mediator interacts with a set of IPFIX Collectors, flow records arriving at ..." =20 The sentence has been added at the beginning of the Terminology section. =20 the "Intermediate Process" and "IPFIX Mediator" definitions should be referred from http://tools.ietf.org/html/draft-ietf-ipfix-mediators-framework-09 =20 Done =20 Important point: I believe that your definition of "Flow Selection = Process" should be a special case of the Intermediate Selection Process, which is defined as, in both http://tools.ietf.org/html/draft-ietf-ipfix-mediators-framework-09 and http://tools.ietf.org/html/draft-claise-ipfix-mediation-protocol-02: =20 Intermediate Selection Process An Intermediate Selection Process is an Intermediate Process that = selects records from a sequence based upon criteria-evaluated record values and passes only those records that match the criteria (e.g., Filtering only records from a given network to a given Collector). A new definition of =93Flow Selection Process=94 has been included in = the document which better describes the function of this process. =20 How is the IPFIX Exporter different from the Exporter specified in = RFC5101? RFC5101: Exporter =20 A device that hosts one or more Exporting Processes is termed an Exporter. Your draft: * IPFIX Exporter =20 The IPFIX exporter is a software that receives measurement data from e.g. the Metering Process and exports this data to a collector. =20 No difference. The IPFIX Exporter definition has been removed. =20 Somehow, based on the terminology section, I'm missing the link with the other drafts, such as the mediation framework. - Important: RFC 2119 language "Ideally, we would like to keep also a timestamp for the first (T_fd) and last (T_ld) not yet exported packets belonging to every discarded flow record. "=20 use MAY? =20 Right. Fixed. =20 "Another information that can be easily maintained is the number of discarding actions, along with the timestamps of the first and last action. This information SHOULD not be used by applications to re- normalize the received per flow statistics (because a flow may be discarded and created multiple times), but rather to monitor and control the performance of the implemented policy." Second sentence use SHOULD (-> btw, SHOULD NOT) So the first sentence should use MAY? =20 =20 Yes. Fixed. =20 "For this reason, flow exporting protocol specification does not include flow selection during the recording process as a mandatory function even if the information model has been designed to enable such function." =20 I could give other examples, but my point is that I don't know how to = be compliant to this standard track future RFC, from an implementation = point of view. =20 Along the same lines, which flow selection techniques in section 6 must = a compliant implementation support? =20 We are not sure with this comment. Could you please give us more inputs = to pinpoint the issue? =20 - Important: IPR Along the same line as the previous point, you refer to http://conferences.sigcomm.org/imc/2001/imw2001-papers/03.pdf in section 4.3. Flow selection during the exporting process =20 " An example of such a policy could be to export only the flow records associated to flows whose accounted traffic is below a certain threshold, or to implement a more complex mechanism such as the one described in [DuLT01a ] or [DuLT01b ]." =20 Should it be implemented or not to be compliant with that future RFC? When I spoke with Nick Duffield some years ago, there was a patent on = this. And I don't see any IPR on this draft. =20 We informed Nick Duffield and asked for an IPR statement. We have not received yet any answer from the IPR Office of AT&T.=20 =20 - Important: Section 5 doesn't refer at all to the Intermediate Process specifies in the mediation framework =20 Fixed. =20 - Important: I have now finished the section 5, and still not sure how = the flow recording process is different from the metering process. I can't find this term in the IPFIX architecture. However, we have some IEs that are defined specifically for the Flow Recording... =20 The =93Flow Recording Process=94 definition has been added to the = Terminology section. =20 - Important: why do we have "Flow recording and selection" on the = Original Exporter while we only have "Flow Selection" on the Mediator? If I look at with IE I should implement, I see: If there=20 7 . Information model for flow selection information exporting . . 14 7.1 . Meter process related (TBD1-TBD3) . . . . . . . . . . . . 16 7.2 . Flow recording process related (TBD4-TBD11) . . . . . . . 18 7.3 . Flow exporting process related (TBD12-TBD19) . . . . . . . 21 How does it translate for Mediator, which only contains "Flow Selection" according to this figure? =20 We have flow selection only during the flow export process on the = Mediator because we would like to leave the Mediator as =93light=94 as possible = and avoid having a replica of the Original Exporter, where flow selection can be applied during metering process, flow recording process, and flow export process. =20 =20 - IE naming convention. In the description, can you please have the = meaning. For example: fsMeterUnmeasPacketCountTsFirst is the concatenation of FlowSelectionMeasuredUnmeteredPacketCounterTimeStampFirst. Even after the reading, I'm not 100%. So if someone only looks at the IANA registry... For example, what is fsFrecPacketInDroppedRecsCountTsFirst, FlowSelectionFrec... unless it's FlowSelectionFlowRec... with a = capitalized R fsFrecFrecDroppedCountTsFirst, fsFrecFrecDroppedCountTsLast: why twice = Frec in the names Btw, what's the size limit for a IE name? =20 We totally changed the IE names. =20 - fsMeterUnmeasPacketCountTsFirst =20 Description: =20 Specifies the timestamp of the first packet not measured because of the use of the flow state dependent sampling. Together with the IE fsMeterUnmeasPacketCountTsLast it allows to evaluate the count of packets that were not measured because of the use of the flow sampling. =20 "measured" by who? by the Metering Process, so it should be "metered", right? Also, "by the Metering Process" should be added in the description, = right? Same remark for 7.1.* =20 Fixed. =20 - Important 7.2.6. fsFrecUnexportedFrecCount =20 Description: =20 This Information Element specifies the count of the flow records currently existing in the flow recording process containing at least one non-exported packet. =20 7.2.7. fsFrecUnexportedPacketInFrecCount =20 =20 Description: =20 This Information Element specifies the count of non-exported packets contained in flow records of the flow recording process. =20 7.2.8. fsFrecUnexportedBytesInFrecCount =20 =20 Description: =20 This Information Element specifies the count of non-exported bytes contained in flow records of the flow recording process. =20 Looking at figure 1, the Flow Recording is before the Exporting Process. So all flow records in the Flow Recording are not exported, right? What = do I miss? =20 No. Flow records in the Flow Recording Process can be selected and then exported.=20 =20 - fsExpUnexportedCount should at least contain FlowRecord (or FRec or whatever) in the name =20 Right. Fixed. =20 - Important: you have defined a new IE selectorMethod =20 Why not reuse selectorAlgorithm from RFC 5476? =20 Yes. Done =20 - Important: IPFIX IANA specifies the IE 60, ipVersion You redefined this. =20 9.6. flowIPAddressVersion =20 Description: =20 This Information Element specifies the IP version field of the packets belonging to flow records which SHOULD be considered as not eligible for removal. =20 Abstract Data Type: unsigned8 =20 Data Type Semantics: identifier =20 ElementId: 60 =20 Status: current =20 Reference: see [RFC5102 ] for = the definition of the ipVersion information element and its Id. =20 You can not do this. Same remark for flowIPv4SourceAddress, flowIPv6SourceAddress, flowIPv6DestinationAddress =20 Right. These IEs have been removed. =20 Regards, Benoit. _____ =20 Nessun virus nel messaggio. Controllato da AVG - www.avg.com Versione: 10.0.1204 / Database dei virus: 1435/3447 - Data di rilascio: 16/02/2011 ------=_NextPart_000_0032_01CBE249.D6F4AB80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Dear Benoit,

 

a new version of the Internet Draft on Flow Selection has = been posted.

 

Answers to your comments are in = line.

 

Regards,

 

 

Salvatore

 

Da: = ipfix-bounces@ietf.org [mailto:ipfix-bounces@ietf.org] Per conto di Benoit Claise
Inviato: mercoled=EC 16 febbraio 2011 08:01
A: ipfix@ietf.org
Oggetto: [IPFIX] Flow-selection-tech: = review

 

Dear all,

I've been reviewing the draft, mainly in the context of the IPFIX = Mediation Protocol draft, to make that all the mediation related drafts are in = line:
requirements (RFC 5982), framework (RFC-editor), anonymization, flow = selection techniques, aggregation, and finally the protocol.
Sorry if I'm late, this flow selection technique is the last one I = reviewed.

The important issues start with "important"

- Reference. Sometimes referred as the RFC number [RFC5475], and sometimes as [IPFIX-REQ]

 

 

Fixed.



- "Flow selection reduces the resource demands for capturing, = storing, exporting and post-processing flow-based measurement results."
Actually, reduces the resource demands for post-processing flow-based = measurement results, that's for sure.
While, reduces  the resource demands for capturing, storing -> = it depends: if you have to look at the all packets, hence all flows, in = order to do the flow selection (like the elephant), you don't gain much.
You might want to clarify. Somehow, you have to go in the conclusions of [EsVa01] to discover this.

A sentence addressing this point has been added. =


- Terminology

=A0 This document is consistent with the terminology introduced =
in
=A0=A0 [RFC5470], [RFC5475] and [IPFIX-REQ].=A0 Further some additional =
terms
=A0=A0 are presented which extend the =
terminology.
 
=A0=A0 * =
Flow
 
=A0=A0=A0=A0=A0 A =
Flow is defined as a set of packets with common =
properties
=A0=A0=A0=A0=A0 passing an Observation =
Point in the network during a certain =
time
=A0=A0=A0=A0=A0 =
interval.
 
Actually =
"Flow" is not an additional term, as it's defined already in =
RFC5101.
However, the definitions are not quite the =
same. Isn't it confusing?
 
Yes, you are right. The “Flow” definition has been =
removed.
 
The =
"Flow record" definition is exactly the same as RFC5101. Why =
redefined?
 
“Flow record” definition =
removed.
 
Importan=
t point: this is the first draft in the IPFIX series that doesn't use =
capitalized definitions.
All IPFIX draft uses a =
sentence such as: 
=A0=A0=A0At the beginning of the =
terminology section, you might add a sentence such =
as:
 =A0=A0In this document, as in [RFC5101] and [RFC5476], the first letter =
of
=A0=A0 each IPFIX-specific and PSAMP-specific =
term is capitalized along with
=A0=A0 the IPFIX =
Mediation-specific terms defined here.
However, =
some sentences use the capitalization.
=A0=A0 =
"As an example, if an IPFIX Mediator interacts with a set of =
IPFIX
=A0=A0 Collectors, flow records arriving at =
..."
 
The sentence has been added at the beginning of the Terminology =
section.
 
the =
"Intermediate Process" and "IPFIX Mediator" =
definitions should be referred from http://tools.ietf.org/html/draft-ietf-ipfix-mediators-framework-09=

 
Done
 
Important point: I believe that =
your definition of "Flow Selection Process" should be a =
special case of the Intermediate Selection Process, which is defined as, =
in both http://tools.ietf.org/html/draft-ietf-ipfix-mediators-framework-09=
 and http://tools.ietf.org/html/draft-claise-ipfix-mediation-protocol-02:=

 

Intermediate Selection Process

An Intermediate = Selection Process is an Intermediate Process that selects records from a sequence based = upon criteria-evaluated record values and passes only those records that = match the criteria (e.g., Filtering only records from a given network to a given Collector).

A new definition of “Flow Selection Process” = has been included in the document which better describes the function of this = process.

 

How is the IPFIX Exporter different from the Exporter specified in =
RFC5101?
RFC5101:
=A0=A0 =
Exporter
 
=A0=A0=A0=A0=A0=
 A device that hosts one or more Exporting Processes is termed =
an
=A0=A0=A0=A0=A0 =
Exporter.
Your draft:
=A0=A0 * =
IPFIX =
Exporter
 
=A0=A0=A0=A0=A0=
 The IPFIX exporter is a software that receives measurement =
data
=A0=A0=A0=A0=A0 from e.g. the Metering Process =
and exports this data to a
=A0=A0=A0=A0=A0 =
collector.
 
No difference. The IPFIX Exporter definition has been =
removed.
 
Somehow, based on the terminology =
section, I'm missing the link with the other drafts, such as the =
mediation framework.
- Important: RFC 2119 =
language
=A0=A0 "Ideally, we would like to =
keep also a timestamp for the first (T_fd)
=A0=A0 =
and last (T_ld) not yet exported packets belonging to every =
discarded
=A0=A0 flow record. " =

=A0=A0=A0use MAY?
 
Right. Fixed.
 
=A0=A0 "Another information =
that can be easily maintained is the number =
of
=A0=A0 discarding actions, along with the =
timestamps of the first and last
=A0=A0 action.=A0 =
This information SHOULD not be used by applications to =
re-
=A0=A0 normalize the received per flow =
statistics (because a flow may be
=A0=A0 discarded =
and created multiple times), but rather to monitor =
and
=A0=A0 control the performance of the =
implemented policy."
=A0=A0 Second sentence =
use SHOULD (-> btw, SHOULD NOT)
=A0=A0 So the =
first sentence should use MAY?=A0=A0 
 
Yes. Fixed.
 
=A0=A0 "For this reason, flow =
exporting protocol specification does
=A0=A0 not =
include flow selection during the recording process as =
a
=A0=A0 mandatory function even if the information =
model has been designed to
=A0=A0 enable such =
function."
 
=A0=A0 =
I could give other examples, but my point is that I don't know how to be =
compliant to this standard track future RFC, from an implementation =
point of view.
 
Along =
the same lines, which flow selection techniques in section 6 must a =
compliant implementation support?
 
We are not sure with this comment. Could you please give us more =
inputs to pinpoint the issue?
 
- Important: =
IPR
Along the same line as the previous point, you =
refer to ht=
tp://conferences.sigcomm.org/imc/2001/imw2001-papers/03.pdf in =
section 4.3.=A0 Flow selection during the exporting =
process
 
"=A0 An =
example of such a policy could
=A0=A0 be to export =
only the flow records associated to flows =
whose
=A0=A0 accounted traffic is below a certain =
threshold, or to implement a
=A0=A0 more complex =
mechanism such as the one described in [DuLT01a] =
or
=A0=A0 [DuLT01b]."
 =

Should it be implemented or not to be compliant with that =
future RFC?
When I spoke with Nick Duffield some =
years ago, there was a patent on this.
And I don't =
see any IPR on this draft.
 
We informed Nick Duffield and asked for an IPR statement. We have not =
received yet any answer from the IPR Office of AT&T. =

 
- Important: =
Section 5 doesn't refer at all to the Intermediate Process specifies in =
the mediation framework
 
Fixed.
 
- Important: I have now finished =
the section 5, and still not sure how the flow recording process is =
different from the metering process.
I can't find =
this term in the IPFIX architecture.
However, we =
have some IEs that are defined specifically for the Flow =
Recording...
 
The “Flow Recording Process” definition has been added to =
the Terminology =
section.
 
- =
Important: why do we have "Flow recording and selection" on =
the Original Exporter while we only have "Flow Selection" on =
the Mediator?
If I look at with IE I should =
implement, I see:
If there =

=A0=A0=A07.=A0 Information model for flow selection information =
exporting . . 14
=A0=A0=A0=A0 7.1.=A0 Meter process related (TBD1-TBD3)=A0 . . . . =
. . . . . . . . 16
=A0=A0=A0=A0 7.2.=A0 Flow recording process related =
(TBD4-TBD11)=A0 . . . . . . . 18
=A0=A0=A0=A0 7.3.=A0 Flow exporting process related (TBD12-TBD19) =
. . . . . . . 21
How does it translate for =
Mediator, which only contains "Flow Selection" according to =
this figure?
 
We have =A0flow selection only during the flow export process on the =
Mediator because we would like to leave the Mediator as =
“light” as possible and avoid having a replica of the =
Original Exporter, where flow selection can be applied during metering =
process, flow recording process, and flow export process. =
=A0
 
- IE naming =
convention. In the description, can you please have the =
meaning.
For example: =
fsMeterUnmeasPacketCountTsFirst is the concatenation of =
FlowSelectionMeasuredUnmeteredPacketCounterTimeStampFirst.
Even after the reading, I'm not 100%.
So if =
someone only looks at the IANA registry...
For =
example, what is fsFrecPacketInDroppedRecsCountTsFirst, =
FlowSelectionFrec... unless it's FlowSelectionFlowRec... with a =
capitalized R
fsFrecFrecDroppedCountTsFirst, =
fsFrecFrecDroppedCountTsLast: why twice Frec in the =
names
Btw, what's the size limit for a IE =
name?
 
We totally changed the IE =
names.
 
- =
fsMeterUnmeasPacketCountTsFirst
 
=A0=A0 =
Description:
 
=A0=A0=A0=A0=
=A0 Specifies the timestamp of the first packet not measured =
because
=A0=A0=A0=A0=A0 of the use of the flow =
state dependent sampling.=A0 Together =
with
=A0=A0=A0=A0=A0 the IE =
fsMeterUnmeasPacketCountTsLast it allows to evaluate =
the
=A0=A0=A0=A0=A0 count of packets that were not =
measured because of the use of the
=A0=A0=A0=A0=A0 =
flow =
sampling.
 
"measured=
" by who? by the Metering Process, so it should be =
"metered", right?
Also, "by the =
Metering Process" should be added in the description, =
right?
Same remark for =
7.1.*
 
Fixed.
 
- Important



7.2.6.=A0 =
fsFrecUnexportedFrecCount



 
=A0=A0 =
Description:
 
=A0=A0=A0=A0=
=A0 This Information Element specifies the count of the flow =
records
=A0=A0=A0=A0=A0 currently existing in the =
flow recording process containing =
at
=A0=A0=A0=A0=A0 least one non-exported =
packet.
 



7.2.7.=A0
fsFrecUnexportedPacketInFrecCount



 
 
=A0=A0 =
Description:
 
=A0=A0=A0=A0=
=A0 This Information Element specifies the count of =
non-exported
=A0=A0=A0=A0=A0 packets contained in =
flow records of the flow recording =
process.
 



7.2.8.=A0
fsFrecUnexportedBytesInFrecCount



 
 
=A0=A0 =
Description:
 
=A0=A0=A0=A0=
=A0 This Information Element specifies the count of non-exported =
bytes
 =A0=A0=A0=A0=A0contained in flow records of =
the flow recording =
process.
 
Looking at =
figure 1, the Flow Recording is before the Exporting =
Process.
So all flow records in the Flow Recording =
are not exported, right? What do I =
miss?
 
No. Flow records in the Flow Recording Process =
can be selected and then exported. 
 
- fsExpUnexportedCount should at =
least contain FlowRecord (or FRec or whatever) in the =
name
 
Right. =
Fixed.
 
- =
Important: you have defined a new IE =
selectorMethod=A0=A0=A0=A0=A0=A0=A0=A0=A0 
Why not =
reuse selectorAlgorithm from RFC 5476?
 
Yes. Done
 
- =
Important: IPFIX IANA specifies the IE 60, =
ipVersion
You redefined =
this.
 



9.6.=A0 =
flowIPAddressVersion



 
=A0=A0 =
Description:
 
=A0=A0=A0=A0=
=A0 This Information Element specifies the IP version field of =
the
=A0=A0=A0=A0=A0 packets belonging to flow =
records which SHOULD be considered =
as
=A0=A0=A0=A0=A0 not eligible for =
removal.
 
=A0=A0 =
Abstract Data Type: =
unsigned8
 
=A0=A0 Data =
Type Semantics: =
identifier
 
=A0=A0 =
ElementId: 60
 
=A0=A0 =
Status: current
 
=A0=A0 =
Reference: see [RFC5102] for the definition of the =
ipVersion
=A0=A0 information element and its =
Id.
 
You can not do =
this.
Same remark for flowIPv4SourceAddress, =
flowIPv6SourceAddress, =
flowIPv6DestinationAddress
 
Right. These IEs have been removed.
 



Regards, Benoit.












Nessun virus nel messaggio.

Controllato da AVG - www.avg.com

Versione: 10.0.1204 / Database dei virus: 1435/3447 - Data di rilascio:
16/02/2011
------=_NextPart_000_0032_01CBE249.D6F4AB80-- From iesg-secretary@ietf.org Mon Mar 14 07:07:15 2011 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C72613A6910; Mon, 14 Mar 2011 07:07:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.544 X-Spam-Level: X-Spam-Status: No, score=-102.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EAOVrLdS8Mc0; Mon, 14 Mar 2011 07:07:15 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 848703A6D79; Mon, 14 Mar 2011 07:07:14 -0700 (PDT) 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: 3.12 Message-ID: <20110314140714.27464.79616.idtracker@localhost> Date: Mon, 14 Mar 2011 07:07:14 -0700 Cc: Internet Architecture Board , ipfix chair , ipfix mailing list , RFC Editor Subject: [IPFIX] Document Action: 'IP Flow Anonymization Support' to Experimental RFC (draft-ietf-ipfix-anon-06.txt) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 14:07:15 -0000 The IESG has approved the following document: - 'IP Flow Anonymization Support' (draft-ietf-ipfix-anon-06.txt) as an Experimental RFC This document is the product of the IP Flow Information Export Working Group. The IESG contact persons are Dan Romascanu and Ron Bonica. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-ipfix-anon/ Technical Summary This document describes anonymisation techniques for IP flow data and the export of anonymised data using the IPFIX protocol. It categorizes common anonymisation schemes and defines the parameters needed to describe them. It provides guidelines for the implementation of anonymised data export and storage over IPFIX, and describes an information model and Options-based method for anonymisation metadata export within the IPFIX protocol or storage in IPFIX Files Working Group Summary This draft was initiated by WG members from ETH Zurich, and reviewed by other members, mostly European, who have similar research interests. Although this seems a somewhat complicated way to transmit and store anonymised data, it is believed to be a significant step towards a common way to carry metadata about how the anonymisation was done along with the data itself. Although there was considerable discussion within the working group, consensus was reached without any problems. Document Quality This is an Experimental document, intended for the Network Research and Network Security communities. It is submitted as an Experimental document as a way of encouraging multiple implementations, in order to gain experience with it. When sufficient experience will be gained with this, it mahy be brought back to the Working Group to be considered as a new Standards Track work item. Personnel Nevil Brownlee is the Document Shepherd. Dan Romascanu is the Responsible Area Director. From dromasca@avaya.com Mon Mar 14 07:10:41 2011 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E74A73A6910 for ; Mon, 14 Mar 2011 07:10:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.537 X-Spam-Level: X-Spam-Status: No, score=-102.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Vi2CKP7MLir for ; Mon, 14 Mar 2011 07:10:41 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 3CBAA3A6D8D for ; Mon, 14 Mar 2011 07:10:40 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Am4BAFMtcU2HCzI1/2dsb2JhbACYKj+NfHSkeQKZFoVhBJAM X-IronPort-AV: E=Sophos;i="4.62,316,1297054800"; d="scan'208";a="236633373" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 14 Mar 2011 10:12:02 -0400 X-IronPort-AV: E=Sophos;i="4.62,316,1297054800"; d="scan'208";a="619807021" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 14 Mar 2011 10:12:00 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 14 Mar 2011 15:11:55 +0100 Message-ID: In-Reply-To: <20110314140714.27464.79616.idtracker@localhost> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Document Action: 'IP Flow Anonymization Support' to Experimental RFC(draft-ietf-ipfix-anon-06.txt) Thread-Index: AcviUXimYVoVeWf5TteLeJNrmlw3pQAACvHA References: <20110314140714.27464.79616.idtracker@localhost> From: "Romascanu, Dan (Dan)" To: Subject: Re: [IPFIX] Document Action: 'IP Flow Anonymization Support' to Experimental RFC(draft-ietf-ipfix-anon-06.txt) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 14:10:42 -0000 Hi,=20 Thanks and Congratulations to the editors, chairs and the whole WG for reaching this milestone.=20 Regards, Dan=20 =20 > -----Original Message----- > From: ietf-announce-bounces@ietf.org=20 > [mailto:ietf-announce-bounces@ietf.org] On Behalf Of The IESG > Sent: Monday, March 14, 2011 4:07 PM > To: IETF-Announce > Cc: Internet Architecture Board; ipfix chair; ipfix mailing=20 > list; RFC Editor > Subject: Document Action: 'IP Flow Anonymization Support' to=20 > Experimental RFC(draft-ietf-ipfix-anon-06.txt) >=20 > The IESG has approved the following document: > - 'IP Flow Anonymization Support' > (draft-ietf-ipfix-anon-06.txt) as an Experimental RFC >=20 > This document is the product of the IP Flow Information=20 > Export Working Group. >=20 > The IESG contact persons are Dan Romascanu and Ron Bonica. >=20 > A URL of this Internet Draft is: > http://datatracker.ietf.org/doc/draft-ietf-ipfix-anon/ >=20 >=20 >=20 >=20 > Technical Summary >=20 > This document describes anonymisation techniques for IP=20 > flow data and > the export of anonymised data using the IPFIX protocol. It > categorizes common anonymisation schemes and defines the parameters > needed to describe them. It provides guidelines for the > implementation of anonymised data export and storage over=20 > IPFIX, and > describes an information model and Options-based method for > anonymisation metadata export within the IPFIX protocol or=20 > storage in > IPFIX Files >=20 > Working Group Summary >=20 > This draft was initiated by WG members from ETH Zurich, and > reviewed by other members, mostly European, who have=20 > similar research > interests. Although this seems a somewhat complicated way=20 > to transmit > and store anonymised data, it is believed to be a=20 > significant step towards > a common way to carry metadata about how the > anonymisation was done along with the data itself. =20 > Although there was > considerable discussion within the working group, consensus was > reached without any problems. >=20 > Document Quality >=20 > This is an Experimental document, intended for the Network=20 > Research and > Network Security communities. It is submitted as an Experimental > document as a way of encouraging multiple implementations, > in order to gain experience with it. When sufficient=20 > experience will be gained > with this, it mahy be brought back to the Working Group to=20 > be considered > as a new Standards Track work item. >=20 > Personnel >=20 > Nevil Brownlee is the Document Shepherd. Dan Romascanu is the=20 > Responsible Area Director. > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce >=20 From Internet-Drafts@ietf.org Mon Mar 14 08:30:23 2011 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40C7F3A6D26; Mon, 14 Mar 2011 08:30:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Su8NJkjfrHY; Mon, 14 Mar 2011 08:30:15 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24A0B3A6D3C; Mon, 14 Mar 2011 08:30:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110314153008.29808.74732.idtracker@localhost> Date: Mon, 14 Mar 2011 08:30:08 -0700 Cc: ipfix@ietf.org Subject: [IPFIX] I-D ACTION:draft-ietf-ipfix-flow-selection-tech-05.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 15:30:23 -0000 --NextPart A new Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Flow Information Export Working Group of the IETF. Title : Flow Selection Techniques Author(s) : L. Peluso, et al Filename : draft-ietf-ipfix-flow-selection-tech-05.txt Pages : 33 Date : 2011-03-14 Flow selection is the process of selecting a subset of flows from all flows observed at an observation point. The objective of flow selection is to reduce the effort of post-processing flow data and transferring flow records. The flow selection process can be enabled at different stages of the measurement process. It can be applied either directly after classification or at recording/exporting time by limiting the number of flows to be stored and/or exported to the collecting process. This document describes motivations for flow selection and presents flow selection techniques. It furthermore provides an information model for configuring flow selection techniques and discusses what information about a flow selection process is worth exporting through a suitable information model. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipfix-flow-selection-tech-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ipfix-flow-selection-tech-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-14082431.I-D@ietf.org> --NextPart-- From ka-cheong.poon@oracle.com Mon Mar 14 03:11:28 2011 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 286463A6C6F; Mon, 14 Mar 2011 03:11:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.249 X-Spam-Level: X-Spam-Status: No, score=-4.249 tagged_above=-999 required=5 tests=[AWL=1.994, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_6CONS_WORD=0.356] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jCGhJZf4vEvU; Mon, 14 Mar 2011 03:11:24 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id E71B83A6C08; Mon, 14 Mar 2011 03:11:20 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p2EACfVb013786 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 14 Mar 2011 10:12:43 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id p2EACeg7001989 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Mar 2011 10:12:40 GMT Received: from abhmt019.oracle.com (abhmt019.oracle.com [141.146.116.28]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p2EACd4O030562; Mon, 14 Mar 2011 05:12:39 -0500 Received: from [10.7.251.223] (/10.7.251.223) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 14 Mar 2011 03:12:38 -0700 Message-ID: <4D7DEA12.4000907@oracle.com> Date: Mon, 14 Mar 2011 18:12:34 +0800 From: Kacheong Poon User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.2.15) Gecko/20110304 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Benoit Claise References: <201102080311.p183BpvU025288@sj-core-2.cisco.com> <201103132048.p2DKmrP1017369@rcdn-core-2.cisco.com> <4D7DBDB2.7010102@cisco.com> In-Reply-To: <4D7DBDB2.7010102@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: acsmt358.oracle.com [141.146.40.158] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090206.4D7DEA19.0201,ss=1,fgs=0 X-Mailman-Approved-At: Mon, 14 Mar 2011 10:20:49 -0700 Cc: "ipfix@ietf.org" , "James M. Polk" , tsvwg Subject: Re: [IPFIX] WGLC for draft-ietf-tsvwg-sctp-strrst-09 continues X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 10:11:29 -0000 On 03/14/11 03:03 PM, Benoit Claise wrote: > I'm not a transport expert so I can't comment on the technical part. > However, there is a clear interest: the functionality in the draft is > required. "The IPFIX export per SCTP stream", > https://datatracker.ietf.org/doc/draft-ietf-ipfix-export-per-sctp-stream/ has > been sitting for 8 months in the RFC editor queue, waiting for this draft. I think only the new stream addition part is needed by IPFIX, right? Is there any IETF protocol which requires the use of SCTP SSN/TSN reset? -- K. Poon. ka-cheong.poon@oracle.com From braun@net.in.tum.de Mon Mar 14 14:21:46 2011 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8F563A6EFC for ; Mon, 14 Mar 2011 14:21:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fc-F9shHVbty for ; Mon, 14 Mar 2011 14:21:42 -0700 (PDT) Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) by core3.amsl.com (Postfix) with ESMTP id D96093A6BAC for ; Mon, 14 Mar 2011 14:21:30 -0700 (PDT) Received: from tnomrev.box (e181111215.adsl.alicedsl.de [85.181.111.215]) by mail.net.in.tum.de (Postfix) with ESMTPSA id 350F721AB4D7 for ; Mon, 14 Mar 2011 22:22:45 +0100 (CET) From: Lothar Braun Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Mon, 14 Mar 2011 22:22:43 +0100 References: <20110314211128.E38C53A6EE1@core3.amsl.com> To: IETF IPFIX Working Group Message-Id: <2EBA4F43-91DB-4A11-83BE-B4171D45C2DB@net.in.tum.de> Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [IPFIX] Fwd: New Version Notification for draft-mentz-ipfix-dtls-recommendations-02 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 21:21:46 -0000 Hi all, we posted a new version of our problem description and implementation = recommendations for IPFIX over DTLS/UDP and DTLS/SCTP. I would like to = have a short time slot (5 minutes should be sufficient) at the meeting = in Prague to talk about the problems with the DTLS support that is = required in RFC5101 for UDP and SCTP. Best regards, Lothar =20 Begin forwarded message: > From: IETF I-D Submission Tool > Date: March 14, 2011 10:11:28 PM GMT+01:00 > To: braun@net.in.tum.de > Cc: mentz@in.tum.de, muenz@net.in.tum.de > Subject: New Version Notification for = draft-mentz-ipfix-dtls-recommendations-02=20 >=20 >=20 > A new version of I-D, draft-mentz-ipfix-dtls-recommendations-02.txt = has been successfully submitted by Lothar Braun and posted to the IETF = repository. >=20 > Filename: draft-mentz-ipfix-dtls-recommendations > Revision: 02 > Title: Recommendations for Implementing IPFIX over = DTLS > Creation_date: 2011-03-14 > WG ID: Independent Submission > Number_of_pages: 13 >=20 > Abstract: > This document discusses problems and solutions regarding the > implementation of the IPFIX protocol over DTLS. It updates the > "IPFIX Implementation Guidelines" [RFC5153]. >=20 >=20 >=20 > The IETF Secretariat. >=20 >=20 -- Lothar Braun Chair for Network Architectures and Services (I8) Department of Informatics Technische Universit=E4t M=FCnchen Boltzmannstr. 3, 85748 Garching bei M=FCnchen, Germany Phone: +49 89 289-18010 Fax: +49 89 289-18033 E-mail: braun@net.in.tum.de=20 From dromasca@avaya.com Tue Mar 15 08:34:23 2011 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99B8B3A6D1F for ; Tue, 15 Mar 2011 08:34:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.541 X-Spam-Level: X-Spam-Status: No, score=-102.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kGekV6FoeTvz for ; Tue, 15 Mar 2011 08:34:22 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id BC0AB3A6C5B for ; Tue, 15 Mar 2011 08:34:22 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Am4BAFMtcU2HCzI1/2dsb2JhbACYKj+NfHSkeQKZFoVhBJAM X-IronPort-AV: E=Sophos;i="4.62,322,1297054800"; d="scan'208";a="269567295" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 15 Mar 2011 11:35:47 -0400 X-IronPort-AV: E=Sophos;i="4.62,322,1297054800"; d="scan'208";a="621083512" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 15 Mar 2011 11:35:46 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 15 Mar 2011 16:35:41 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SecDir review of draft-ietf-ipfix-structured-data-05 Thread-Index: AcvjIxHkQ4xaVoAFSzC1cau3lqzk6wAA3GSg From: "Romascanu, Dan (Dan)" To: Subject: [IPFIX] FW: SecDir review of draft-ietf-ipfix-structured-data-05 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 15:34:23 -0000 =20 Hi,=20 See the SEC-DIR report on draft-ietf-ipfix-structured-data-05.=20 Please address the issue raised in the report.=20 Thanks and Regards, Dan=20 -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of Yaron Sheffer Sent: Tuesday, March 15, 2011 9:28 AM To: iesg@ietf.org; secdir@ietf.org; draft-ietf-ipfix-structured-data.all@tools.ietf.org Subject: SecDir review of draft-ietf-ipfix-structured-data-05 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. IPFIX is a structured information model and protocol for transmitting information about data flows. This document extends the model with structured data, basically several types of lists. I have not reviewed the document in full, rather I have looked at the security aspects only. The Security Considerations refer the reader to the IPFIX protocol and data model RFCs, and I mostly agree, with one exception. I suggest to add text similar to the next paragraph: The addition of complex data types necessarily complicates the implementation of the Collector. This could easily result in new security vulnerabilities (e.g., buffer overflows); this creates additional risk in cases where either DTLS is not used, or if the Observation Point and Collector belong to different trust domains. Thanks, Yaron From acmorton@att.com Tue Mar 15 11:22:09 2011 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7EB763A6C3C; Tue, 15 Mar 2011 11:22:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.796 X-Spam-Level: X-Spam-Status: No, score=-105.796 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LOQcQgep6ffT; Tue, 15 Mar 2011 11:22:08 -0700 (PDT) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by core3.amsl.com (Postfix) with ESMTP id 848633A6B10; Tue, 15 Mar 2011 11:22:08 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-11.tower-120.messagelabs.com!1300213412!8027063!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [144.160.20.145] Received: (qmail 22702 invoked from network); 15 Mar 2011 18:23:33 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-11.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 15 Mar 2011 18:23:33 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p2FINu5g013954; Tue, 15 Mar 2011 14:23:56 -0400 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p2FINrs2013911; Tue, 15 Mar 2011 14:23:53 -0400 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id p2FINSgP010265; Tue, 15 Mar 2011 14:23:28 -0400 Received: from mailgw1.maillennium.att.com (mailgw1.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id p2FINNcY009902; Tue, 15 Mar 2011 14:23:24 -0400 Message-Id: <201103151823.p2FINNcY009902@alpd052.aldc.att.com> Received: from acmt.att.com (dn135-16-251-71.dhcpn.ugn.att.com[135.16.251.71](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20110315182323gw100e4l60e>; Tue, 15 Mar 2011 18:23:23 +0000 X-Originating-IP: [135.16.251.71] X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 15 Mar 2011 14:24:00 -0400 To: bmwg@ietf.org From: Al Morton In-Reply-To: <201102131506.p1DF6Kgc024578@alpd052.aldc.att.com> References: <201102131506.p1DF6Kgc024578@alpd052.aldc.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: ipfix@ietf.org Subject: Re: [IPFIX] [bmwg] WGLC: draft-ietf-bmwg-ipflow-meth-00 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 18:22:09 -0000 It seems that everyone has been busy, and I know I wasn't able to finish reading and commenting on this draft, so... I am extending this WGLC for 2 more weeks, ending Monday the 28th. Al bmwg chair At 11:06 AM 2/13/2011, Al Morton wrote: >BMWG, >CC: IPFIX WG, > >This message begins the first WG Last call on the draft: > >IP Flow Information Accounting and Export Benchmarking Methodology >draft-ietf-bmwg-ipflow-meth-00.txt > >A URL for this draft is: >http://tools.ietf.org/html/draft-ietf-bmwg-ipflow-meth-00 > >The Last Call will end on March 14, 2011. > >Although this is the first WGLC, we have discussed this draft >in the working group for over two years, and made many suggestions. >We have also benefited from review by folks from IPFIX WG. >I now ask folks to consider items where they commented earlier, >and make sure that the resolutions are satisfactory. > >And it's not too late to read the draft for the first time, >and provide comments based on your review. > >Please weigh-in on whether or not this Internet-Draft >should be given to the Area Directors and IESG for consideration and >publication as an Informational RFC. Send your comments >to this list and/or acmorton@att.com. > >Al >bmwg chair > > >_______________________________________________ >bmwg mailing list >bmwg@ietf.org >https://www.ietf.org/mailman/listinfo/bmwg From bclaise@cisco.com Thu Mar 17 06:42:22 2011 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 293CB3A696E; Thu, 17 Mar 2011 06:42:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.243 X-Spam-Level: X-Spam-Status: No, score=-2.243 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_6CONS_WORD=0.356] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F+Vws7M6igpK; Thu, 17 Mar 2011 06:42:19 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 69C973A68AD; Thu, 17 Mar 2011 06:42:19 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p2HDIW0e009966; Thu, 17 Mar 2011 14:18:32 +0100 (CET) Received: from [64.103.13.34] (dhcp-64-103-13-34.cisco.com [64.103.13.34]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p2HDIQ8w003548; Thu, 17 Mar 2011 14:18:27 +0100 (CET) Message-ID: <4D820A22.7050607@cisco.com> Date: Thu, 17 Mar 2011 14:18:26 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Kacheong Poon References: <201102080311.p183BpvU025288@sj-core-2.cisco.com> <201103132048.p2DKmrP1017369@rcdn-core-2.cisco.com> <4D7DBDB2.7010102@cisco.com> <4D7DEA12.4000907@oracle.com> In-Reply-To: <4D7DEA12.4000907@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ipfix@ietf.org" , "James M. Polk" , tsvwg Subject: Re: [IPFIX] WGLC for draft-ietf-tsvwg-sctp-strrst-09 continues X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2011 13:42:22 -0000 > On 03/14/11 03:03 PM, Benoit Claise wrote: > >> I'm not a transport expert so I can't comment on the technical part. >> However, there is a clear interest: the functionality in the draft is >> required. "The IPFIX export per SCTP stream", >> https://datatracker.ietf.org/doc/draft-ietf-ipfix-export-per-sctp-stream/ >> has >> been sitting for 8 months in the RFC editor queue, waiting for this >> draft. > > > I think only the new stream addition part is needed by IPFIX, right? That's right. Regards, Benoit. > Is there any IETF protocol which requires the use of SCTP SSN/TSN > reset? > > From n.brownlee@auckland.ac.nz Thu Mar 17 11:18:51 2011 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10B9E3A6A04 for ; Thu, 17 Mar 2011 11:18:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c9ufGZL+wAC2 for ; Thu, 17 Mar 2011 11:18:49 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by core3.amsl.com (Postfix) with ESMTP id 9EDE53A699E for ; Thu, 17 Mar 2011 11:18:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=n.brownlee@auckland.ac.nz; q=dns/txt; s=uoa; t=1300386019; x=1331922019; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; z=Message-ID:=20<4D8250E0.4040300@auckland.ac.nz>|Date:=20 Thu,=2017=20Mar=202011=2011:20:16=20-0700|From:=20Nevil =20Brownlee=20|MIME-Version: =201.0|To:=20IPFIX=20Working=20Group=20 |Subject:=20[IPFIX]=20DRAFT=20agenda=20for=20Prague=20IET F|Content-Transfer-Encoding:=207bit; bh=Wn7P73dsu0AmS8meYQRH8qJsxkCBzI+cOUBFUiL/9cA=; b=oyf0N5KSatCq6qGXqwxwHbigLy49NRaB97XDeU/AbFHPhFrX6j1XtlkG oRwA21Iehp89aqba/c7ZW5+eCUztGfxJvgnw3IMu4nnLljwTsDNM/je38 TFm4ZimpfZRxLLCJzAIf0klJrrlj1YJTfBzR013Us8f8Ua8QUncW2+OSs c=; X-IronPort-AV: E=Sophos;i="4.63,200,1299409200"; d="scan'208";a="51733488" X-Ironport-HAT: None - $RELAY-AUTH X-Ironport-Source: 192.172.226.50 - Outgoing - Outgoing-SSL Received: from dyn50.caida.org (HELO [192.172.226.50]) ([192.172.226.50]) by mx2-int.auckland.ac.nz with ESMTP; 18 Mar 2011 07:20:17 +1300 Message-ID: <4D8250E0.4040300@auckland.ac.nz> Date: Thu, 17 Mar 2011 11:20:16 -0700 From: Nevil Brownlee User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 MIME-Version: 1.0 To: IPFIX Working Group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPFIX] DRAFT agenda for Prague IETF X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2011 18:18:51 -0000 Hi all: Here's my updated draft of our agenda for the IPFIX meeting in Prague. Please let me know if you have changes you'd like to suggest. When it comes to 'new charter' discussions, I'd like to have brief presentations about each, so do let me know who will be presenting each. Also, please, don't forget to email me copies of your slides well before the meeting so that I can get them onto our 'Meeting Materials' page Cheers, Nevil =========================================== IP Flow Information Export WG (ipfix) Agenda for IETF #80, Beijing DRAFT-01 <<<< Wednesday, March 29, 1300-1500, Vienna room =========================================== Chairs: Juergen Quittek Nevil Brownlee AGENDA: 1. Agenda review = 5 min 2. Update from last meeting / WG Status (Nevil) = 10 min Export-per-SCTP-Stream - in queue, waiting on sctpstream-reset Mediators-Framework - approved, in RFC-EDITOR Anonymisation Support - approved, in RFC-EDITOR Config Model - new version, Juergen to do write-up Structured Data - IETF LC of -05 started 7 March PSAMP MIB - new version, Nevil will do write-up Flow Selection Techniques -05 published, Nevil will do write-up 3. Current WG drafts = 0 min All in (2) above. 4. DEMONS IPFIX Interoperability Test, = 10 min Prague, 24-25 March 2011. Breif report-back 4. What next for IPFIX? = 5 min We're now ready to consider how IPFIX should develop. This section of the agenda is intended as (the continuation of) our re-chartering discussion. For any of these we need to work out - Who is prepared to _work_ on them? - How long do we expect them to take? a) Progressing IPFIX Standards-Track RFCs to Draft Standard = 20 min - Fix errata, add clarification text, would we need anything else? - Would need inter-operation reports from several implementors. (+ report from Prague interoperation event) b) Recent drafts - draft-trammell-ipfix-ie-doctors-00 = 60 min Guidelines for Information Elements, 1 Oct 10 - draft-trammel-ipfix-a9n-02 IPFIX Aggregation, 22 Feb 11 - draft-claise-ipfix-mediation-protocol-03 Protocol for PFIX Mediation, 14 Feb 11 - draft-johnson-ipfix-mib-variable-export-00 Exporting MIB objects, 19 Oct 10 - draft-akhter-ipfix-perfmon-01 App and Network Performance measurements, 25 Oct 10 - draft-claise-export-application-info-in-ipfix-01 Export of Application Information in IPFIX, 10 Mar 11 - draft-mentz-ipfix-dtls-recommendations-02 Recommendations for Implementing IPFIX over DTLS, 14 Mar 11 5. Any Other Business = 10 min Presentation slides will be available at https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=80 (search for IPFIX in the Operations and Management Area) Participation via jabber is offered at ipfix@jabber.ietf.org -- --------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand From n.brownlee@auckland.ac.nz Fri Mar 18 10:25:47 2011 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E12E3A6990 for ; Fri, 18 Mar 2011 10:25:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x59i+hxVNMxW for ; Fri, 18 Mar 2011 10:25:46 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by core3.amsl.com (Postfix) with ESMTP id D0F8C3A698F for ; Fri, 18 Mar 2011 10:25:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=n.brownlee@auckland.ac.nz; q=dns/txt; s=uoa; t=1300469236; x=1332005236; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; z=Message-ID:=20<4D8395E7.7010604@auckland.ac.nz>|Date:=20 Fri,=2018=20Mar=202011=2010:27:03=20-0700|From:=20Nevil =20Brownlee=20|MIME-Version: =201.0|To:=20IPFIX=20list=20|Subject:=20N eed=20reviews=20of=20PSAMP=20MIB=20draft=20-03 |Content-Transfer-Encoding:=207bit; bh=dMqNvPPlLPqKmWu3gkjbyZ3qEnpISl1W1idSLl/FZbM=; b=i2dmwYR0T2ghPYs/se0i/K3G7kmRKPgykyNCoDFxlcgCjaf30/koxcuH 3iKEIfuOmxmdU7D1IylyPzl1+FSYTcigcXCRFpKDIC1m7seKYiazj8yAT o8xjIbjGPEF1vW3wHcV9yZQNbok3v/bDzp3QPhPLJM+L9VAf0+rJ4+fo0 o=; X-IronPort-AV: E=Sophos;i="4.63,206,1299409200"; d="scan'208";a="51958274" X-Ironport-HAT: None - $RELAY-AUTH X-Ironport-Source: 192.172.226.50 - Outgoing - Outgoing-SSL Received: from dyn50.caida.org (HELO [192.172.226.50]) ([192.172.226.50]) by mx2-int.auckland.ac.nz with ESMTP; 19 Mar 2011 06:27:04 +1300 Message-ID: <4D8395E7.7010604@auckland.ac.nz> Date: Fri, 18 Mar 2011 10:27:03 -0700 From: Nevil Brownlee User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 MIME-Version: 1.0 To: IPFIX list Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPFIX] Need reviews of PSAMP MIB draft -03 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 17:25:47 -0000 Hi all: The -03 version of the PSAMP MIB draft was published on 2 March, now I'm getting set to do its writeup for IESG. For that I need a few reviews; just a few lines saying "yes, it looks OK to me now" would be plenty. If I get these reviews in the next few days, I'll submit the writeup before we meet in Prague ... Cheers, Nevil -- --------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand From kashima@nttv6.net Wed Mar 23 19:33:54 2011 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F019B3A67B7 for ; Wed, 23 Mar 2011 19:33:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.577 X-Spam-Level: X-Spam-Status: No, score=-1.577 tagged_above=-999 required=5 tests=[AWL=1.022, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F+mNk0D8U7VL for ; Wed, 23 Mar 2011 19:33:53 -0700 (PDT) Received: from leo.nttv6.net (leo.nttv6.net [192.47.162.93]) by core3.amsl.com (Postfix) with ESMTP id DCDBA3A67B2 for ; Wed, 23 Mar 2011 19:33:52 -0700 (PDT) Received: from [192.168.11.254] (localhost.nttv6.net [IPv6:::1]) by leo.nttv6.net (8.14.4/8.14.3) with ESMTP id p2O2Y87R042137 for ; Thu, 24 Mar 2011 11:34:08 +0900 (JST) (envelope-from kashima@nttv6.net) Date: Thu, 24 Mar 2011 11:34:06 +0900 From: Shingo KASHIMA To: ipfix@ietf.org Message-Id: <20110324113405.DF09.1AB7FA03@nttv6.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.56.05 [ja] Subject: [IPFIX] Fwd: New Version Notification for draft-kashima-ipfix-data-link-layer-monitoring-05 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Mar 2011 02:33:54 -0000 Dear all, Here is a new version of the draft, which includes: - new information elements related to 802.1ah (MAC-in-MAC) - generic offset and observed octets Is this valuable for WG item ? I wanted to make a presentaion in Prague. But I cannot go to Prague due to huge earthquak in Japan. Sorry. Best Regards, Shingo. ----- Original Message ----- Date: Tue, 15 Mar 2011 09:59:12 +0900 From: "IETF I-D Submission Tool" Subject: New Version Notification for draft-kashima-ipfix-data-link-layer-monitoring-05 A new version of I-D, draft-kashima-ipfix-data-link-layer-monitoring-05.txt has been successfully submitted by Kensuke Nakata and posted to the IETF repository. Filename: draft-kashima-ipfix-data-link-layer-monitoring Revision: 05 Title: Information Elements for Data Link Layer Traffic Measurement Creation_date: 2011-03-15 WG ID: Independent Submission Number_of_pages: 26 Abstract: This document describes Information Elements related to data link layer. They are used by the IP Flow Information Export (IPFIX) protocol for encoding measured data link layer traffic information. The IETF Secretariat. -- Shingo KASHIMA From acmorton@att.com Thu Mar 24 08:20:15 2011 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D94F33A68EB; Thu, 24 Mar 2011 08:20:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.65 X-Spam-Level: X-Spam-Status: No, score=-105.65 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RJbWmjsKJjjC; Thu, 24 Mar 2011 08:20:15 -0700 (PDT) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by core3.amsl.com (Postfix) with ESMTP id CAAE13A68EA; Thu, 24 Mar 2011 08:20:14 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-8.tower-120.messagelabs.com!1300980108!9460394!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [144.160.20.145] Received: (qmail 17064 invoked from network); 24 Mar 2011 15:21:49 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-8.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 24 Mar 2011 15:21:49 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p2OFMB1X004130; Thu, 24 Mar 2011 11:22:12 -0400 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p2OFM60O003921; Thu, 24 Mar 2011 11:22:06 -0400 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id p2OFLfOL017599; Thu, 24 Mar 2011 11:21:41 -0400 Received: from mailgw1.maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id p2OFLZ9h017389; Thu, 24 Mar 2011 11:21:36 -0400 Message-Id: <201103241521.p2OFLZ9h017389@alpd052.aldc.att.com> Received: from acmt.att.com (martym.mt.att.com[135.16.251.71](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20110324152135gw100e4l1me>; Thu, 24 Mar 2011 15:21:35 +0000 X-Originating-IP: [135.16.251.71] X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 24 Mar 2011 11:22:13 -0400 To: bmwg@ietf.org From: Al Morton In-Reply-To: <201103151823.p2FINNcY009902@alpd052.aldc.att.com> References: <201102131506.p1DF6Kgc024578@alpd052.aldc.att.com> <201103151823.p2FINNcY009902@alpd052.aldc.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: ipfix@ietf.org Subject: Re: [IPFIX] [bmwg] WGLC: draft-ietf-bmwg-ipflow-meth-00 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Mar 2011 15:20:16 -0000 Hi Jan, I've finally completed a review of this draft; you can find my complete (many editorial) comments here: http://home.comcast.net/~acmacm/BMWG/draft-ietf-bmwg-ipflow-meth-01acm.pdf (Jan provided me an MS-word version of the *next=01* draft to base my comments on, and save us both some time. If anyone else would like the same opportunity, please let Jan know.) Main Comments/Suggestions: Added a MUST to benchmark both Forwarding Plane and Flow Monitoring plane when *both* are present in the DUT. The Reporting Formats in Appendix A are RECOMMENDED. (this is usual) Clarified Baseline RFC2544 testing. hope this helps, Al (as a participant) At 02:24 PM 3/15/2011, Al Morton wrote: >It seems that everyone has been busy, and I know I wasn't >able to finish reading and commenting on this draft, so... > >I am extending this WGLC for 2 more weeks, ending Monday the 28th. > >Al >bmwg chair > >At 11:06 AM 2/13/2011, Al Morton wrote: >>BMWG, >>CC: IPFIX WG, >> >>This message begins the first WG Last call on the draft: >> >>IP Flow Information Accounting and Export Benchmarking Methodology >>draft-ietf-bmwg-ipflow-meth-00.txt >> >>A URL for this draft is: >>http://tools.ietf.org/html/draft-ietf-bmwg-ipflow-meth-00 >> >>The Last Call will end on March 14, 2011. >> >>Although this is the first WGLC, we have discussed this draft >>in the working group for over two years, and made many suggestions. >>We have also benefited from review by folks from IPFIX WG. >>I now ask folks to consider items where they commented earlier, >>and make sure that the resolutions are satisfactory. >> >>And it's not too late to read the draft for the first time, >>and provide comments based on your review. >> >>Please weigh-in on whether or not this Internet-Draft >>should be given to the Area Directors and IESG for consideration and >>publication as an Informational RFC. Send your comments >>to this list and/or acmorton@att.com. >> >>Al >>bmwg chair From bclaise@cisco.com Sun Mar 27 07:33:51 2011 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84FFE3A6863 for ; Sun, 27 Mar 2011 07:33:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.31 X-Spam-Level: X-Spam-Status: No, score=-2.31 tagged_above=-999 required=5 tests=[AWL=-0.312, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_16=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BKj7mvB-2z8U for ; Sun, 27 Mar 2011 07:33:50 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 3696E3A67D6 for ; Sun, 27 Mar 2011 07:33:50 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p2REZQFK006414 for ; Sun, 27 Mar 2011 16:35:26 +0200 (CEST) Received: from [10.55.90.99] (dhcp-10-55-90-99.cisco.com [10.55.90.99]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p2REZPhG005435 for ; Sun, 27 Mar 2011 16:35:25 +0200 (CEST) Message-ID: <4D8F4B2D.20808@cisco.com> Date: Sun, 27 Mar 2011 16:35:25 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "ipfix@ietf.org" Content-Type: multipart/alternative; boundary="------------050904030709080000000402" Subject: [IPFIX] Draft Standard version of RFC5102 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Mar 2011 14:33:51 -0000 This is a multi-part message in MIME format. --------------050904030709080000000402 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, This list is way shorter. Next to http://www.rfc-editor.org/errata_search.php?rfc=5102, only one issue. 5.10.1. octetDeltaCount Description: The number of octets since the previous report (if any) in incoming packets for this Flow at the Observation Point. The number of octets includes IP header(s) and IP payload. Abstract Data Type: unsigned64 Data Type Semantics: deltaCounter ElementId: 1 Status: current Units: octets In the case of Ethernet II encapsulation would this byte count totalinclude the 14 bytes associated with the L2 header + L3 header + L4header + payload or just L3 header + L4 header + payload The latter is what's implemented. The spec says "packets" not "frames", but it would be a good idea to be more explicit. Note that there are multiple Count related IEs. Regards, Benoit. --------------050904030709080000000402 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all,

This list is way shorter.
Next to http://www.rfc-editor.org/errata_search.php?rfc=5102, only one issue.
5.10.1.  octetDeltaCount
   Description:
      The number of octets since the previous report (if any) in
      incoming packets for this Flow at the Observation Point.  The
      number of octets includes IP header(s) and IP payload.
   Abstract Data Type: unsigned64
   Data Type Semantics: deltaCounter
   ElementId: 1
   Status: current
   Units: octets
In the case of Ethernet II encapsulation would this byte count total include the 14 bytes associated with the L2 header + L3 header + L4 header + payload or just L3 header + L4 header + payload
The latter is what's implemented.
The spec says "packets" not "frames", but  it would be a good idea to be more explicit.

Note that there are multiple Count related IEs.

Regards, Benoit. --------------050904030709080000000402-- From trammell@tik.ee.ethz.ch Sun Mar 27 07:48:29 2011 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8068F3A6819 for ; Sun, 27 Mar 2011 07:48:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IHUP3jSXTk-R for ; Sun, 27 Mar 2011 07:48:28 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id 9E4333A67D6 for ; Sun, 27 Mar 2011 07:48:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id EDDD7D9329; Sun, 27 Mar 2011 16:50:04 +0200 (MEST) 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 Ize8a6C8T3CF; Sun, 27 Mar 2011 16:50:04 +0200 (MEST) Received: from dhcp-43c4.meeting.ietf.org (dhcp-43c4.meeting.ietf.org [130.129.67.196]) (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 86C9FD931D; Sun, 27 Mar 2011 16:50:04 +0200 (MEST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Brian Trammell In-Reply-To: <4D8F4B2D.20808@cisco.com> Date: Sun, 27 Mar 2011 16:50:05 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D8F4B2D.20808@cisco.com> To: Benoit Claise X-Mailer: Apple Mail (2.1082) Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] Draft Standard version of RFC5102 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Mar 2011 14:48:29 -0000 Hi, Benoit, I thought it was obvious (from IP headers and IP payload) that L2 and = below were not represented here. (This is also what appears to be = implemented in each of the checked implementations tested at the interop = in Prague) Cheers, Brian On Mar 27, 2011, at 4:35 PM, Benoit Claise wrote: > Dear all, >=20 > This list is way shorter. > Next to http://www.rfc-editor.org/errata_search.php?rfc=3D5102, only = one issue. > 5.10.1. octetDeltaCount >=20 > Description: > The number of octets since the previous report (if any) in > incoming packets for this Flow at the Observation Point. The > number of octets includes IP header(s) and IP payload. > Abstract Data Type: unsigned64 > Data Type Semantics: deltaCounter > ElementId: 1 > Status: current > Units: octets >=20 > In the case of Ethernet II encapsulation would this byte count total = include the 14 bytes associated with the L2 header + L3 header + L4 = header + payload or just L3 header + L4 header + payload=20 > The latter is what's implemented. > The spec says "packets" not "frames", but it would be a good idea to = be more explicit.=20 >=20 > Note that there are multiple Count related IEs. >=20 > Regards, Benoit. > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From bclaise@cisco.com Sun Mar 27 07:51:53 2011 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C35D73A6823 for ; Sun, 27 Mar 2011 07:51:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.603 X-Spam-Level: X-Spam-Status: No, score=-2.603 tagged_above=-999 required=5 tests=[AWL=-0.004, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WUomwWOWOcVa for ; Sun, 27 Mar 2011 07:51:52 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 39E313A6819 for ; Sun, 27 Mar 2011 07:51:52 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p2RErSqO007942; Sun, 27 Mar 2011 16:53:28 +0200 (CEST) Received: from [10.55.90.99] (dhcp-10-55-90-99.cisco.com [10.55.90.99]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p2RErJbj014895; Sun, 27 Mar 2011 16:53:20 +0200 (CEST) Message-ID: <4D8F4F5F.3030904@cisco.com> Date: Sun, 27 Mar 2011 16:53:19 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Brian Trammell References: <4D8F4B2D.20808@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] Draft Standard version of RFC5102 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Mar 2011 14:51:53 -0000 Hi Brian, I'm not really pushing for this one. This is what I have in my notes. Regards, Benoit. > Hi, Benoit, > > I thought it was obvious (from IP headers and IP payload) that L2 and below were not represented here. (This is also what appears to be implemented in each of the checked implementations tested at the interop in Prague) > > Cheers, > > Brian > > On Mar 27, 2011, at 4:35 PM, Benoit Claise wrote: > >> Dear all, >> >> This list is way shorter. >> Next to http://www.rfc-editor.org/errata_search.php?rfc=5102, only one issue. >> 5.10.1. octetDeltaCount >> >> Description: >> The number of octets since the previous report (if any) in >> incoming packets for this Flow at the Observation Point. The >> number of octets includes IP header(s) and IP payload. >> Abstract Data Type: unsigned64 >> Data Type Semantics: deltaCounter >> ElementId: 1 >> Status: current >> Units: octets >> >> In the case of Ethernet II encapsulation would this byte count total include the 14 bytes associated with the L2 header + L3 header + L4 header + payload or just L3 header + L4 header + payload >> The latter is what's implemented. >> The spec says "packets" not "frames", but it would be a good idea to be more explicit. >> >> Note that there are multiple Count related IEs. >> >> Regards, Benoit. >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix From bclaise@cisco.com Sun Mar 27 07:57:28 2011 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92DA23A6866 for ; Sun, 27 Mar 2011 07:57:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.603 X-Spam-Level: X-Spam-Status: No, score=-2.603 tagged_above=-999 required=5 tests=[AWL=-0.005, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YIXNt96PJMRJ for ; Sun, 27 Mar 2011 07:57:26 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id C057F3A6823 for ; Sun, 27 Mar 2011 07:57:25 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p2REQumc005649 for ; Sun, 27 Mar 2011 16:26:56 +0200 (CEST) Received: from [10.55.90.99] (dhcp-10-55-90-99.cisco.com [10.55.90.99]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p2REQpr9000745 for ; Sun, 27 Mar 2011 16:26:51 +0200 (CEST) Message-ID: <4D8F492A.6040605@cisco.com> Date: Sun, 27 Mar 2011 16:26:50 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "ipfix@ietf.org" Content-Type: multipart/alternative; boundary="------------010004050205080108000003" Subject: [IPFIX] Draft Standard version of RFC5101 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Mar 2011 14:57:28 -0000 This is a multi-part message in MIME format. --------------010004050205080108000003 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, Here is the list of things to be changed in the Draft Standard version of RFC5101. Along the years, I've been collecting (from different people a list of what could be improved in IPFIX. Many points come from discussions with Paul Aitken. Some of points below should be discussed. 1. what must be changed is obviously http://www.rfc-editor.org/errata_search.php?rfc=5101 2. the email thread http://www.ietf.org/mail-archive/web/ipfix/current/msg05652.html suggests to change the definition from "IP Traffic Flow or Flow" to "Traffic Flow or Flow", and from "IP packets" to "packets" when RFC5101 will go from Proposed Standard to Draft Standard. 3. Different Template Record management between the transport protocol (feedback from the IPFIX interop) SCTP transport If the Collecting Process receives a Template that has already been received but that has not previously been withdrawn (i.e., a Template Record from the same Exporter Observation Domain with the same Template ID received on the SCTP association), then the Collecting Process MUST shut down the association. So an identical Template Record is resent (like in UDP), the Collecting Process MUST shut down the association First problem: we don't have the same statement for TCP, which only says: If the Collecting Process receives a malformed IPFIX Message, it MUST discard the IPFIX Message and SHOULD log the error. So this is not consistent as we don't know what "malformed" means. Thinking some more about it, is this really a mistake if SCTP and TCP would behave as UDP, i.e. accept the exact same (Options) Template Record to be resent? Proposal with something such as: It's NOT RECOMMENDED that _identical _Template Record are resent in SCTP and TCP.... but it will not cause the SCTP association or TCP association to be shut down... Before applying this change, we have to double-check if there are no complications for draft-ietf-ipfix-export-per-sctp-stream-08 4. OLD: Exporting Process ID The identifier of the Exporting Process for which lack of reliability is reported. There are three Information Elements specified in [RFC5102 ] that can be used for this purpose: exporterIPv4Address, exporterIPv6Address, or exportingProcessId. This Information Element MUST be defined as a Scope Field. NEW: Exporting Process ID The identifier of the Exporting Process for which lack of reliability is reported. There are three Information Elements specified in [RFC5102 ] that can be used for this purpose: exporterIPv4Address, exporterIPv6Address, or exportingProcessId. This Information Element, _or these Information Elements if multiple are _ _needed,_ MUST be defined as a Scope Field Justification: both the address and process ID are needed to identify a specific exporter in the case of multiple exporters at the same address. 5. 10.3.6. Template Management Following a configuration change that can modify the interpretation of the Data Records (for example, a sampling rate change) a new Template ID MUST be used, and the old Template ID MUST NOT be reused until its lifetime (see Section 10.3.7) has expired. In section 10.3.7. Collecting Process, we read: The Template lifetime at the Collecting Process MUST be at least 3 times higher than the Template refresh timeout configured on the Exporting Process. In Flexible NetFlow, template refresh is in units of packets, so that template export scales with the volume of exported data. If we're no longer exporting any packets then the "3 times higher" threshold will never be reached... so the templates will never expire. eg, if we're exporting templates every 1,000 packets, then the lifetime on the collector should be 3,000 packets. Yet once we're no longer using the template, we'll be exporting 0 packets... So the RFC should specify the units, or give an alternative mechanism. 6. Section 8: If the measurement parameters change such that a new Template is required, the Template MUST be withdrawn (using a Template Withdraw Message and a new Template definition) or an unused Template ID MUST be used. Examples of the measurement changes are: a new sampling rate, a new Flow expiration process, a new filtering definition, etc. A new sampling rate etc may not require a new template at all; it may be expressed with the same template, just different data. The template belongs to the transport layer and really has nothing to do with the sampler change! Proposal: remove "a new sampling rate" 7. Section 4.3. The Exporting Process Reliability Statistics Option Template time first flow dropped The timestamp of the first Flow was dropped by the Metering Process. For this timestamp, any of the "flowStart" timestamp Information Elements flowStartMilliseconds, flowStartMicroseconds, flowStartNanoseconds, and flowStartDeltaMicroseconds can be used. time last flow dropped The timestamp of the last IP packet that was ignored by the Metering Process. For this timestamp, any of the "flowEnd" timestamp Information Elements flowEndMilliseconds, flowEndMicroseconds, flowEndNanoseconds, and flowEndDeltaMicroseconds can be used. Firstly, these definitions are inconsistent since the names and the first definition say "flow" while the second definition says "IP packet". Obviously "IP packet" != "flow" :-o Secondly, "The timestamp of the first Flow was dropped by the Metering Process." is bad English: at least it's missing "that". 8. Section 4.3. The Exporting Process Reliability Statistics Option Template These statistics where defined before we introduced the concept of Transport Session. This full section 3.4 should be re-specified for "4.3 The Transport Session Reliability Statistics Option Template" 9. Section 4.2. The Metering Process Reliability Statistics Option Template Suppose a packet cannot be classified before it's dropped. Which Metering Process (meteringProcessId) should report this? Suppose the packet pertains to several monitors. If some or all of them cannot record the packet (eg, cache full), should they all report the loss? That might look like some random number of packets had been lost, when in fact it's only one. 10. Do we want to have a new IE for the template lifetime, to be sent in an Options Template Record. Regards, Benoit. --------------010004050205080108000003 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all,

Here is the list of things to be changed in the Draft Standard version of RFC5101.
Along the years, I've been collecting (from different people a list of what could be improved in IPFIX. Many points come from discussions with Paul Aitken.

Some of points below should be discussed.

1. what must be changed is obviously http://www.rfc-editor.org/errata_search.php?rfc=5101

2. the email thread http://www.ietf.org/mail-archive/web/ipfix/current/msg05652.html suggests to change the definition from "IP Traffic Flow or Flow" to "Traffic Flow or Flow", and from "IP packets" to "packets" when RFC5101 will go from Proposed Standard to Draft Standard.

3. Different Template Record management between the transport protocol (feedback from the IPFIX interop)

SCTP transport
   If the Collecting Process receives a Template that has
   already been received but that has not previously been withdrawn
   (i.e., a Template Record from the same Exporter Observation Domain
   with the same Template ID received on the SCTP association), then the
   Collecting Process MUST shut down the association.
So an identical Template Record is resent (like in UDP), the Collecting Process MUST shut down the association
First problem: we don't have the same statement for TCP, which only says:
   If the Collecting Process receives a malformed IPFIX Message, it MUST
   discard the IPFIX Message and SHOULD log the error.
So this is not consistent as we don't know what "malformed" means.
Thinking some more about it, is this really a mistake if SCTP and TCP would behave as UDP, i.e. accept the exact same (Options) Template Record to be resent? Proposal with something such as: It's NOT RECOMMENDED that identical Template Record are resent in SCTP and TCP.... but it will not cause the SCTP association or TCP association to be shut down...
Before applying this change, we have to double-check if there are no complications for draft-ietf-ipfix-export-per-sctp-stream-08

4.

OLD:
Exporting Process ID
                        The identifier of the Exporting Process for
                        which lack of reliability is reported.  There
                        are three Information Elements specified in
                        [RFC5102] that can be used for this purpose:
                        exporterIPv4Address, exporterIPv6Address, or
                        exportingProcessId.  This Information Element
                        MUST be defined as a Scope Field.
NEW:
Exporting Process ID
                        The identifier of the Exporting Process for
                        which lack of reliability is reported.  There
                        are three Information Elements specified in
                        [RFC5102] that can be used for this purpose:
                        exporterIPv4Address, exporterIPv6Address, or
                        exportingProcessId.  This Information Element, 
                        or these Information Elements if multiple are 
                        needed, MUST be defined as a Scope Field
Justification: both the address and process ID are needed to identify a specific exporter in the case  of multiple exporters at the same address.



5.

10.3.6.  Template Management

   Following a configuration change that can modify the interpretation
   of the Data Records (for example, a sampling rate change) a new
   Template ID MUST be used, and the old Template ID MUST NOT be reused
   until its lifetime (see Section 10.3.7) has expired.

In section 10.3.7.  Collecting Process, we read:

   The Template lifetime at the Collecting Process MUST be at least 3
   times higher than the Template refresh timeout configured on the
   Exporting Process.


In Flexible NetFlow, template refresh is in units of packets, so that template export scales with the volume of exported data.
If we're no longer exporting any packets then the "3 times higher" threshold will never be reached... so the templates will never expire.
eg, if we're exporting templates every 1,000 packets, then the lifetime on the collector should be 3,000 packets. Yet once we're no longer using the template, we'll be exporting 0 packets...
So the RFC should specify the units, or give an alternative mechanism.


6.

Section 8:
   If the measurement parameters change such that a new Template is
   required, the Template MUST be withdrawn (using a Template Withdraw
   Message and a new Template definition) or an unused Template ID MUST
   be used.  Examples of the measurement changes are: a new sampling
   rate, a new Flow expiration process, a new filtering definition, etc.

A new sampling rate etc may not require a new template at all; it may be expressed with the same template, just different data. The template belongs to the transport layer and really has nothing to do with the sampler change!

Proposal: remove "a new sampling rate"


7.
Section 4.3.  The Exporting Process Reliability Statistics Option Template
   time first flow dropped
                        The timestamp of the first Flow was dropped by
                        the Metering Process.  For this timestamp, any
                        of the "flowStart" timestamp Information
                        Elements flowStartMilliseconds,
                        flowStartMicroseconds, flowStartNanoseconds, and
                        flowStartDeltaMicroseconds can be used.

   time last flow dropped
                        The timestamp of the last IP packet that was
                        ignored by the Metering Process.  For this
                        timestamp, any of the "flowEnd" timestamp
                        Information Elements flowEndMilliseconds,
                        flowEndMicroseconds, flowEndNanoseconds, and
                        flowEndDeltaMicroseconds can be used.

Firstly, these definitions are inconsistent since the names and the first definition say "flow" while the second definition says "IP packet". Obviously "IP packet" != "flow" :-o

Secondly, "The timestamp of the first Flow was dropped by the Metering Process." is bad English: at least it's missing "that".

8.
Section 4.3.  The Exporting Process Reliability Statistics Option Template
These statistics where defined before we introduced the concept of Transport Session.
 This full section 3.4 should be re-specified for "4.3 The Transport Session Reliability Statistics Option Template"


9.
Section 4.2.  The Metering Process Reliability Statistics Option Template

Suppose a packet cannot be classified before it's dropped. Which 
Metering Process (meteringProcessId) should report this?

Suppose the packet pertains to several monitors. If some or all of 
them cannot record the packet (eg, cache full), should they all report 
the loss? That might look like some random number of packets had been 
lost, when in fact it's only one.
10.

Do we want to have a new IE  for the template lifetime, to be sent in an Options Template Record.


Regards, Benoit.


--------------010004050205080108000003-- From trammell@tik.ee.ethz.ch Sun Mar 27 08:03:19 2011 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48CB33A6869 for ; Sun, 27 Mar 2011 08:03:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0FlRwNWD0Cdf for ; Sun, 27 Mar 2011 08:03:18 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id 1FAE83A6868 for ; Sun, 27 Mar 2011 08:03:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id AD2F0D931D; Sun, 27 Mar 2011 17:04:54 +0200 (MEST) 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 dMHND0NC1-Hg; Sun, 27 Mar 2011 17:04:54 +0200 (MEST) Received: from dhcp-43c4.meeting.ietf.org (dhcp-43c4.meeting.ietf.org [130.129.67.196]) (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 2FEFDD9313; Sun, 27 Mar 2011 17:04:54 +0200 (MEST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Brian Trammell In-Reply-To: <4D8F4F5F.3030904@cisco.com> Date: Sun, 27 Mar 2011 17:04:53 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D8F4B2D.20808@cisco.com> <4D8F4F5F.3030904@cisco.com> To: Benoit Claise X-Mailer: Apple Mail (2.1082) Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] Draft Standard version of RFC5102 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Mar 2011 15:03:19 -0000 Hi, Benoit, In any case, the IANA registry is canonical, in preference to 5102; any = IE errata should be fixed there first. 5102 should probably be updated = to say that the core IPFIX data model is described by IANA, and IANA = wins in case of conflict. (Something to consider here, too, is if we want something like the IE = Doctors lifecycle to be included in a 5102bis... Something to discuss = for Tuesday...) Regards, Brian On Mar 27, 2011, at 4:53 PM, Benoit Claise wrote: > Hi Brian, >=20 > I'm not really pushing for this one. This is what I have in my notes. >=20 > Regards, Benoit. >> Hi, Benoit, >>=20 >> I thought it was obvious (from IP headers and IP payload) that L2 and = below were not represented here. (This is also what appears to be = implemented in each of the checked implementations tested at the interop = in Prague) >>=20 >> Cheers, >>=20 >> Brian >>=20 >> On Mar 27, 2011, at 4:35 PM, Benoit Claise wrote: >>=20 >>> Dear all, >>>=20 >>> This list is way shorter. >>> Next to http://www.rfc-editor.org/errata_search.php?rfc=3D5102, only = one issue. >>> 5.10.1. octetDeltaCount >>>=20 >>> Description: >>> The number of octets since the previous report (if any) in >>> incoming packets for this Flow at the Observation Point. The >>> number of octets includes IP header(s) and IP payload. >>> Abstract Data Type: unsigned64 >>> Data Type Semantics: deltaCounter >>> ElementId: 1 >>> Status: current >>> Units: octets >>>=20 >>> In the case of Ethernet II encapsulation would this byte count total = include the 14 bytes associated with the L2 header + L3 header + L4 = header + payload or just L3 header + L4 header + payload >>> The latter is what's implemented. >>> The spec says "packets" not "frames", but it would be a good idea = to be more explicit. >>>=20 >>> Note that there are multiple Count related IEs. >>>=20 >>> Regards, Benoit. >>> _______________________________________________ >>> IPFIX mailing list >>> IPFIX@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipfix From lmukund@cisco.com Mon Mar 28 03:57:24 2011 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62A633A63CB for ; Mon, 28 Mar 2011 03:57:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.399 X-Spam-Level: X-Spam-Status: No, score=-9.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_37=0.6, J_CHICKENPOX_39=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sv5rJOYLfzhi for ; Mon, 28 Mar 2011 03:57:23 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id BD6CC3A63C9 for ; Mon, 28 Mar 2011 03:57:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lmukund@cisco.com; l=3787; q=dns/txt; s=iport; t=1301309940; x=1302519540; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=Ltg/8bT2/50ykBKHvXfga3hbzJC5AnLSmSFejXc/O1s=; b=mQpaQ0+0y7RvYVGloxQhzWmHlWk7iiuRnweDfx3sVmxdUME8dOPsg5/P YeWGBS4tta2Uu8wAQRvZHw0X704EBJivSVpDAwasAEjEBGJsVvZDza4+n HWytn1Ub6DSVNJlMDpATLrYgIq20uUGVGvUJfWvsw5eUo9ngVStnGxFsm g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AucAALRokE2Q/khNgWdsb2JhbACYDI0/FAEBFiYlpxSbUYVpBIU4ixk X-IronPort-AV: E=Sophos;i="4.63,253,1299456000"; d="scan'208";a="81080388" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 28 Mar 2011 10:58:24 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p2SAvxnf003009; Mon, 28 Mar 2011 10:58:23 GMT Received: from xmb-bgl-41a.cisco.com ([72.163.129.216]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 28 Mar 2011 16:28:19 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 28 Mar 2011 16:28:17 +0530 Message-ID: <061BB2F7C70CFF42BB3E8DF41D130EB903BE8531@XMB-BGL-41A.cisco.com> In-Reply-To: <20110324113405.DF09.1AB7FA03@nttv6.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPFIX] Fwd: New Version Notification fordraft-kashima-ipfix-data-link-layer-monitoring-05 Thread-Index: AcvpzC8ie7evXsyhRbmHQ1nXKBu7QADaWhLQ References: <20110324113405.DF09.1AB7FA03@nttv6.net> From: "Laxmi Mukund (lmukund)" To: "Shingo KASHIMA" , X-OriginalArrivalTime: 28 Mar 2011 10:58:19.0093 (UTC) FILETIME=[0C068850:01CBED37] Subject: Re: [IPFIX] Fwd: New Version Notification fordraft-kashima-ipfix-data-link-layer-monitoring-05 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 10:57:24 -0000 Hi Shingo San, I think this would be very useful to include in the draft. We have been working on this but didn't get to put it in a draft. Glad you could put them in here. I have some comments about the draft. 1)=20 3.6. dot1qServiceInstanceTag Maybe this could be reworded to: This Information Element, which may have 16 octets length, represents=20 the Backbone Service Instance Tag (I-TAG) Tag Control Information (TCI) field of an Ethernet frame as described in [IEEE802.1ah-2008]. It encodes the priority, drop_eligible, destination and source address. =20 2) It looks like Section 3.7 and 3.8 have got interchanged. The description and the information elements have been switched. 3) Could we include a section that would say the current and new information elements needed to export all the 802.1ah header fields like so: This is a summary of the 802.1ah fields and the new and current informational elements that would be used to represent each of the fields. <-----6---------><------6-------><--4-----><-----6--------><-----6------ --><-----6-------><---4---> +---------------+---------------+---------+---------------+------------- --+--------------+--------+ + + + + + + + + + B-DA + B-A + B TAG + I-TAG + C-DA + C-SA + C-TAG + + 1 + 2 + 3 + 4 + 5 + 6 + 7 + +---------------+---------------+---------+---------------+------------- --+--------------+--------+ 1.(Existing Element) destinationMacAddress 80 2.(Existing Element) sourceMacAddress 56 3.(Existing Element) dot1qVlanId 243, dot1qPriority 244 4.(New Element) defined in section 3.6, 3.7, 3.8 of this draft 5.(New Element) defined in section 3.9 of this draft 6.(New Element) defined in section 3.10 of this draft 7.(Existing Element) dot1qCustomerVlanId 245, dot1qCustomerPriority 246 Very sorry about what happened in Japan, it is very unfortunate. My best wishes, please take care, Thanks, Laxmi. -----Original Message----- From: ipfix-bounces@ietf.org [mailto:ipfix-bounces@ietf.org] On Behalf Of Shingo KASHIMA Sent: Thursday, March 24, 2011 8:04 AM To: ipfix@ietf.org Subject: [IPFIX] Fwd: New Version Notification fordraft-kashima-ipfix-data-link-layer-monitoring-05 Dear all, Here is a new version of the draft, which includes: - new information elements related to 802.1ah (MAC-in-MAC) - generic offset and observed octets Is this valuable for WG item ? I wanted to make a presentaion in Prague. But I cannot go to Prague due to huge earthquak in Japan. Sorry. Best Regards, Shingo. ----- Original Message ----- Date: Tue, 15 Mar 2011 09:59:12 +0900 From: "IETF I-D Submission Tool" Subject: New Version Notification for draft-kashima-ipfix-data-link-layer-monitoring-05 A new version of I-D, draft-kashima-ipfix-data-link-layer-monitoring-05.txt=20 has been successfully submitted by Kensuke Nakata and posted to the IETF repository. Filename: draft-kashima-ipfix-data-link-layer-monitoring Revision: 05 Title: Information Elements for Data Link Layer Traffic Measurement Creation_date: 2011-03-15 WG ID: Independent Submission Number_of_pages: 26 Abstract: This document describes Information Elements related to data link layer. They are used by the IP Flow Information Export (IPFIX) protocol for encoding measured data link layer traffic information. The IETF Secretariat. --=20 Shingo KASHIMA _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From dromasca@avaya.com Mon Mar 28 04:37:48 2011 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A80F3A67D7 for ; Mon, 28 Mar 2011 04:37:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.106 X-Spam-Level: X-Spam-Status: No, score=-103.106 tagged_above=-999 required=5 tests=[AWL=0.492, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aO366k-5QBdd for ; Mon, 28 Mar 2011 04:37:44 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 2F4503A67A8 for ; Mon, 28 Mar 2011 04:37:43 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvYAAFMtcU3GmAcF/2dsb2JhbACYKo47dIhcnB0CmRaCfoJjBIFtjh+JLQ X-IronPort-AV: E=Sophos;i="4.63,255,1299474000"; d="scan'208,217";a="238840819" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 28 Mar 2011 07:39:18 -0400 X-IronPort-AV: E=Sophos;i="4.63,255,1299474000"; d="scan'208,217";a="601792721" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 28 Mar 2011 07:39:17 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBED3C.BE847ADF" Date: Mon, 28 Mar 2011 13:39:05 +0200 Message-ID: In-Reply-To: <4D8F492A.6040605@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPFIX] Draft Standard version of RFC5101 Thread-Index: Acvsj5Xw7s/ogBCuTnyYg7Rf+vJ3dAAq5avg References: <4D8F492A.6040605@cisco.com> From: "Romascanu, Dan (Dan)" To: "Benoit Claise" , Subject: Re: [IPFIX] Draft Standard version of RFC5101 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 11:37:49 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBED3C.BE847ADF Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 =20 Hi, =20 When progressing from Proposed to Draft only editorial clarifications editorial changes are allowed. You can also point to portion of the specification that you would like to obsolete because the implementation experience show that they are no longer used. However, you cannot make changes that are not 100% compatible with the version of the protocol defined at Proposed. If such changes are needed the document needs to recycle at Proposed.=20 Are you sure that all the changes that you are suggesting are editorial clarifications? For example change #3, change #8 and change #10?=20 Thanks and Regards, Dan =20 ________________________________ From: ipfix-bounces@ietf.org [mailto:ipfix-bounces@ietf.org] On Behalf Of Benoit Claise Sent: Sunday, March 27, 2011 4:27 PM To: ipfix@ietf.org Subject: [IPFIX] Draft Standard version of RFC5101 =09 =09 Dear all, =09 Here is the list of things to be changed in the Draft Standard version of RFC5101. Along the years, I've been collecting (from different people a list of what could be improved in IPFIX. Many points come from discussions with Paul Aitken. =09 Some of points below should be discussed. =09 1. what must be changed is obviously http://www.rfc-editor.org/errata_search.php?rfc=3D5101 =09 2. the email thread http://www.ietf.org/mail-archive/web/ipfix/current/msg05652.html suggests to change the definition from "IP Traffic Flow or Flow" to "Traffic Flow or Flow", and from "IP packets" to "packets" when RFC5101 will go from Proposed Standard to Draft Standard. =09 3. Different Template Record management between the transport protocol (feedback from the IPFIX interop) =09 SCTP transport =09 If the Collecting Process receives a Template that has already been received but that has not previously been withdrawn (i.e., a Template Record from the same Exporter Observation Domain with the same Template ID received on the SCTP association), then the Collecting Process MUST shut down the association. =09 So an identical Template Record is resent (like in UDP), the Collecting Process MUST shut down the association First problem: we don't have the same statement for TCP, which only says: =09 If the Collecting Process receives a malformed IPFIX Message, it MUST discard the IPFIX Message and SHOULD log the error. So this is not consistent as we don't know what "malformed" means. Thinking some more about it, is this really a mistake if SCTP and TCP would behave as UDP, i.e. accept the exact same (Options) Template Record to be resent? Proposal with something such as: It's NOT RECOMMENDED that identical Template Record are resent in SCTP and TCP.... but it will not cause the SCTP association or TCP association to be shut down... Before applying this change, we have to double-check if there are no complications for draft-ietf-ipfix-export-per-sctp-stream-08 =09 4.=20 =09 OLD: =09 Exporting Process ID The identifier of the Exporting Process for which lack of reliability is reported. There are three Information Elements specified in [RFC5102 ] that can be used for this purpose: exporterIPv4Address, exporterIPv6Address, or exportingProcessId. This Information Element MUST be defined as a Scope Field. NEW: =09 Exporting Process ID The identifier of the Exporting Process for which lack of reliability is reported. There are three Information Elements specified in [RFC5102 ] that can be used for this purpose: exporterIPv4Address, exporterIPv6Address, or exportingProcessId. This Information Element,=20 or these Information Elements if multiple are=20 needed, MUST be defined as a Scope Field Justification: both the address and process ID are needed to identify a specific exporter in the case of multiple exporters at the same address. =09 =09 =09 5. =09 10.3.6. Template Management=20 =09 Following a configuration change that can modify the interpretation=20 of the Data Records (for example, a sampling rate change) a new=20 Template ID MUST be used, and the old Template ID MUST NOT be reused=20 until its lifetime (see Section 10.3.7) has expired.=20 =09 In section 10.3.7. Collecting Process, we read:=20 =09 The Template lifetime at the Collecting Process MUST be at least 3=20 times higher than the Template refresh timeout configured on the=20 Exporting Process.=20 =09 =09 In Flexible NetFlow, template refresh is in units of packets, so that template export scales with the volume of exported data.=20 If we're no longer exporting any packets then the "3 times higher" threshold will never be reached... so the templates will never expire.=20 eg, if we're exporting templates every 1,000 packets, then the lifetime on the collector should be 3,000 packets. Yet once we're no longer using the template, we'll be exporting 0 packets...=20 So the RFC should specify the units, or give an alternative mechanism.=20 =09 =09 6.=20 =09 Section 8:=20 If the measurement parameters change such that a new Template is=20 required, the Template MUST be withdrawn (using a Template Withdraw=20 Message and a new Template definition) or an unused Template ID MUST=20 be used. Examples of the measurement changes are: a new sampling=20 rate, a new Flow expiration process, a new filtering definition, etc.=20 =09 A new sampling rate etc may not require a new template at all; it may be expressed with the same template, just different data. The template belongs to the transport layer and really has nothing to do with the sampler change!=20 =09 Proposal: remove "a new sampling rate" =09 =09 7. =09 Section 4.3. The Exporting Process Reliability Statistics Option Template time first flow dropped=20 The timestamp of the first Flow was dropped by=20 the Metering Process. For this timestamp, any=20 of the "flowStart" timestamp Information Elements flowStartMilliseconds,=20 flowStartMicroseconds, flowStartNanoseconds, and=20 flowStartDeltaMicroseconds can be used.=20 =09 time last flow dropped=20 The timestamp of the last IP packet that was=20 ignored by the Metering Process. For this=20 timestamp, any of the "flowEnd" timestamp=20 Information Elements flowEndMilliseconds,=20 flowEndMicroseconds, flowEndNanoseconds, and=20 flowEndDeltaMicroseconds can be used.=20 =09 Firstly, these definitions are inconsistent since the names and the first definition say "flow" while the second definition says "IP packet". Obviously "IP packet" !=3D "flow" :-o=20 =09 Secondly, "The timestamp of the first Flow was dropped by the Metering Process." is bad English: at least it's missing "that".=20 =09 8. =09 Section 4.3. The Exporting Process Reliability Statistics Option Template These statistics where defined before we introduced the concept of Transport Session. This full section 3.4 should be re-specified for "4.3 The Transport Session Reliability Statistics Option Template" =09 =09 9. =09 Section 4.2. The Metering Process Reliability Statistics Option Template =09 Suppose a packet cannot be classified before it's dropped. Which Metering Process (meteringProcessId) should report this? =09 Suppose the packet pertains to several monitors. If some or all of=20 them cannot record the packet (eg, cache full), should they all report=20 the loss? That might look like some random number of packets had been=20 lost, when in fact it's only one. =09 =09 =09 10. =09 Do we want to have a new IE for the template lifetime, to be sent in an Options Template Record. =09 =09 Regards, Benoit. =09 =09 =09 ------_=_NextPart_001_01CBED3C.BE847ADF Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
 

Hi,

 

When progressing from Proposed to Draft only = editorial=20 clarifications editorial changes are allowed. You can also = point to=20 portion of the specification that you would like to obsolete because the = implementation experience show that they are no longer used. However, = you cannot=20 make changes that are not 100% compatible with the version of the = protocol=20 defined at Proposed. If such changes are needed the document needs to = recycle at=20 Proposed.

Are you sure that all the changes that you are = suggesting are=20 editorial clarifications? For example change #3, change #8 and change = #10?=20



Thanks and = Regards,

Dan

 

From: ipfix-bounces@ietf.org=20 [mailto:ipfix-bounces@ietf.org] On Behalf Of Benoit=20 Claise
Sent: Sunday, March 27, 2011 4:27 PM
To:=20 ipfix@ietf.org
Subject: [IPFIX] Draft Standard version of=20 RFC5101

Dear all,

Here is the list of things to be changed = in the=20 Draft Standard version of RFC5101.
Along the years, I've been = collecting=20 (from different people a list of what could be improved in IPFIX. Many = points=20 come from discussions with Paul Aitken.

Some of points below = should be=20 discussed.

1. what must be changed is obviously http://ww= w.rfc-editor.org/errata_search.php?rfc=3D5101

2.=20 the email thread http://www.ietf.org/mail-archive/web/ipfix/current/msg05652.html=20 suggests to change the definition from "IP Traffic Flow or Flow" to = "Traffic=20 Flow or Flow", and from "IP packets" to "packets" when RFC5101 will go = from=20 Proposed Standard to Draft Standard.

3. Different Template = Record=20 management between the transport protocol (feedback from the IPFIX=20 interop)

SCTP transport
   If the =
Collecting Process receives a Template that has
   already been received but that has not previously been withdrawn
   (i.e., a Template Record from the same Exporter Observation Domain
   with the same Template ID received on the SCTP association), then the
   Collecting Process MUST shut down the association.
So an identical Template Record is resent (like in UDP), the = Collecting=20 Process MUST shut down the association
First problem: we don't have = the=20 same statement for TCP, which only says:
   If =
the Collecting Process receives a malformed IPFIX Message, it MUST
   discard the IPFIX Message and SHOULD log the error.
So this is not consistent as we don't know what "malformed"=20 means.
Thinking some more about it, is this really a mistake if = SCTP and=20 TCP would behave as UDP, i.e. accept the exact same (Options) Template = Record=20 to be resent? Proposal with something such as: It's NOT RECOMMENDED = that=20 identical Template Record are resent in SCTP and TCP.... but it = will=20 not cause the SCTP association or TCP association to be shut = down...
Before=20 applying this change, we have to double-check if there are no = complications=20 for draft-ietf-ipfix-export-per-sctp-stream-08

4. =

OLD:
Exporting Process ID
                        The identifier of the Exporting Process for
                        which lack of reliability is reported.  There
                        are three Information Elements specified in
                        [RFC5102] that can be =
used for this purpose:
                        exporterIPv4Address, exporterIPv6Address, or
                        exportingProcessId.  This Information Element
                        MUST be defined as a Scope Field.
NEW:
Exporting Process ID
                        The identifier of the Exporting Process for
                        which lack of reliability is reported.  There
                        are three Information Elements specified in
                        [RFC5102] that can be =
used for this purpose:
                        exporterIPv4Address, exporterIPv6Address, or
                        exportingProcessId.  This Information Element,=20
                        or these Information Elements if multiple are =

                        needed, MUST be defined as a Scope =
Field
Justification: both the address and process ID are needed to = identify a=20 specific exporter in the case  of multiple exporters at the same=20 address.



5.

10.3.6.  Template Management=20

   Following a configuration change that can modify = the=20 interpretation
   of the Data Records (for example, a = sampling=20 rate change) a new
   Template ID MUST be used, and the = old=20 Template ID MUST NOT be reused
   until its lifetime = (see=20 Section 10.3.7) has expired.

In section 10.3.7.  = Collecting=20 Process, we read:

   The Template lifetime at the = Collecting=20 Process MUST be at least 3
   times higher than the = Template=20 refresh timeout configured on the
   Exporting Process.=20


In Flexible NetFlow, template refresh is in units of = packets, so=20 that template export scales with the volume of exported data.
If = we're no=20 longer exporting any packets then the "3 times higher" threshold will = never be=20 reached... so the templates will never expire.
eg, if we're = exporting=20 templates every 1,000 packets, then the lifetime on the collector = should be=20 3,000 packets. Yet once we're no longer using the template, we'll be = exporting=20 0 packets...
So the RFC should specify the units, or give an = alternative=20 mechanism.


6.

Section 8:
   If the=20 measurement parameters change such that a new Template is =
  =20 required, the Template MUST be withdrawn (using a Template Withdraw=20
   Message and a new Template definition) or an unused = Template=20 ID MUST
   be used.  Examples of the measurement = changes=20 are: a new sampling
   rate, a new Flow expiration = process, a=20 new filtering definition, etc.

A new sampling rate etc may not = require=20 a new template at all; it may be expressed with the same template, = just=20 different data. The template belongs to the transport layer and really = has=20 nothing to do with the sampler change!

Proposal: remove "a new = sampling rate"


7.
Section 4.3.  The =
Exporting Process Reliability Statistics Option Template
   time first flow dropped=20 =
           &nb= sp;           =20 The timestamp of the first Flow was dropped by=20 =
           &nb= sp;           =20 the Metering Process.  For this timestamp, any=20 =
           &nb= sp;           =20 of the "flowStart" timestamp Information=20 =
           &nb= sp;           =20 Elements flowStartMilliseconds,=20 =
           &nb= sp;           =20 flowStartMicroseconds, flowStartNanoseconds, and=20 =
           &nb= sp;           =20 flowStartDeltaMicroseconds can be used.

   time last = flow=20 dropped=20 =
           &nb= sp;           =20 The timestamp of the last IP packet that was=20 =
           &nb= sp;           =20 ignored by the Metering Process.  For this=20 =
           &nb= sp;           =20 timestamp, any of the "flowEnd" timestamp=20 =
           &nb= sp;           =20 Information Elements flowEndMilliseconds,=20 =
           &nb= sp;           =20 flowEndMicroseconds, flowEndNanoseconds, and=20 =
           &nb= sp;           =20 flowEndDeltaMicroseconds can be used.

Firstly, these = definitions are=20 inconsistent since the names and the first definition say "flow" while = the=20 second definition says "IP packet". Obviously "IP packet" !=3D "flow" = :-o=20

Secondly, "The timestamp of the first Flow was dropped by the = Metering=20 Process." is bad English: at least it's missing "that". =

8.
Section 4.3.  The Exporting Process =
Reliability Statistics Option Template
These=20 statistics where defined before we introduced the concept of Transport = Session.
 This full section 3.4 should be re-specified for = "4.3 The=20 Transport Session Reliability Statistics Option = Template"


9.
Section 4.2.  The =
Metering Process Reliability Statistics Option Template

Suppose a packet cannot be classified before it's dropped. Which=20
Metering Process (meteringProcessId) should report this?

Suppose the packet pertains to several monitors. If some or all of=20
them cannot record the packet (eg, cache full), should they all report=20
the loss? That might look like some random number of packets had been=20
lost, when in fact it's only one.
10.

Do we want to have a new = IE  for=20 the template lifetime, to be sent in an Options Template=20 Record.


Regards, = Benoit.


------_=_NextPart_001_01CBED3C.BE847ADF-- From trammell@tik.ee.ethz.ch Mon Mar 28 06:34:13 2011 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9638D3A6835 for ; Mon, 28 Mar 2011 06:34:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hq-62d18FqpS for ; Mon, 28 Mar 2011 06:34:12 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id 4DCC13A6818 for ; Mon, 28 Mar 2011 06:34:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 56338D9322; Mon, 28 Mar 2011 15:35:49 +0200 (MEST) 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 EXpshzgQH7VI; Mon, 28 Mar 2011 15:35:49 +0200 (MEST) Received: from dhcp-43c4.meeting.ietf.org (dhcp-43c4.meeting.ietf.org [130.129.67.196]) (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 A6603D931C; Mon, 28 Mar 2011 15:35:48 +0200 (MEST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Brian Trammell In-Reply-To: <4D8250E0.4040300@auckland.ac.nz> Date: Mon, 28 Mar 2011 15:35:46 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D8250E0.4040300@auckland.ac.nz> To: Nevil Brownlee X-Mailer: Apple Mail (2.1082) Cc: michelle.cotton@icann.org, IPFIX Working Group Subject: Re: [IPFIX] DRAFT agenda for Prague IETF X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 13:34:13 -0000 Hi, Nevil,=20 I'd like to "prebash" the agenda for tomorrow: 1. Could we swap draft-trammell-ipfix-a9n and = draft-trammell-ipfix-ie-doctors? Would like to move ie-doctors later, as = Michelle Cotton from IANA would like to attend around 14:00 to = participate in discussion on the draft. 2. It might make sense to move draft-mentz-ipfix-dtls-recommendations-02 = together with the interop report (as an "implementation experience" = subsession); the state of DTLS is the largest hole in implementability = of the proposed standard at this point... (ie-doctors slides to follow shortly after discussion with IANA) Cheers, Brian On Mar 17, 2011, at 7:20 PM, Nevil Brownlee wrote: >=20 > Hi all: >=20 > Here's my updated draft of our agenda for the IPFIX meeting in > Prague. Please let me know if you have changes you'd like to > suggest. >=20 > When it comes to 'new charter' discussions, I'd like to have > brief presentations about each, so do let me know who will > be presenting each. Also, please, don't forget to email me > copies of your slides well before the meeting so that I can > get them onto our 'Meeting Materials' page >=20 > Cheers, Nevil >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > IP Flow Information Export WG (ipfix) > Agenda for IETF #80, Beijing DRAFT-01 <<<< > Wednesday, March 29, 1300-1500, Vienna room > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Chairs: > Juergen Quittek > Nevil Brownlee >=20 > AGENDA: >=20 > 1. Agenda review =3D 5 min >=20 > 2. Update from last meeting / WG Status (Nevil) =3D 10 min > Export-per-SCTP-Stream - in queue, waiting on sctpstream-reset > Mediators-Framework - approved, in RFC-EDITOR > Anonymisation Support - approved, in RFC-EDITOR > Config Model - new version, Juergen to do write-up > Structured Data - IETF LC of -05 started 7 March > PSAMP MIB - new version, Nevil will do write-up > Flow Selection Techniques -05 published, Nevil will do write-up >=20 > 3. Current WG drafts =3D 0 min > All in (2) above. >=20 > 4. DEMONS IPFIX Interoperability Test, =3D 10 min > Prague, 24-25 March 2011. Breif report-back >=20 > 4. What next for IPFIX? =3D 5 min > We're now ready to consider how IPFIX should develop. > This section of the agenda is intended as (the continuation of) > our re-chartering discussion. > For any of these we need to work out > - Who is prepared to _work_ on them? > - How long do we expect them to take? >=20 > a) Progressing IPFIX Standards-Track RFCs to Draft Standard =3D 20 = min > - Fix errata, add clarification text, would we need > anything else? > - Would need inter-operation reports from several implementors. > (+ report from Prague interoperation event) >=20 > b) Recent drafts > - draft-trammell-ipfix-ie-doctors-00 =3D 60 = min > Guidelines for Information Elements, 1 Oct 10 >=20 > - draft-trammel-ipfix-a9n-02 > IPFIX Aggregation, 22 Feb 11 >=20 > - draft-claise-ipfix-mediation-protocol-03 > Protocol for PFIX Mediation, 14 Feb 11 >=20 > - draft-johnson-ipfix-mib-variable-export-00 > Exporting MIB objects, 19 Oct 10 >=20 > - draft-akhter-ipfix-perfmon-01 > App and Network Performance measurements, 25 Oct 10 >=20 > - draft-claise-export-application-info-in-ipfix-01 > Export of Application Information in IPFIX, 10 Mar 11 >=20 > - draft-mentz-ipfix-dtls-recommendations-02 > Recommendations for Implementing IPFIX over DTLS, 14 Mar 11 >=20 > 5. Any Other Business =3D 10 min >=20 >=20 > Presentation slides will be available at > = https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=3D80= > (search for IPFIX in the Operations and Management Area) >=20 > Participation via jabber is offered at ipfix@jabber.ietf.org >=20 > --=20 > --------------------------------------------------------------------- > Nevil Brownlee Computer Science Department | ITS > Phone: +64 9 373 7599 x88941 The University of Auckland > FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From bclaise@cisco.com Mon Mar 28 08:01:25 2011 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAA093A6A2B for ; Mon, 28 Mar 2011 08:01:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.623 X-Spam-Level: X-Spam-Status: No, score=-2.623 tagged_above=-999 required=5 tests=[AWL=-0.025, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X21iNrjoYXdf for ; Mon, 28 Mar 2011 08:01:24 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id A997B3A6A1E for ; Mon, 28 Mar 2011 08:01:22 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p2SEY4Wh018990; Mon, 28 Mar 2011 16:34:04 +0200 (CEST) Received: from [10.61.107.95] (dhcp-10-61-107-95.cisco.com [10.61.107.95]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p2SEY3v1022725; Mon, 28 Mar 2011 16:34:04 +0200 (CEST) Message-ID: <4D909C5B.5010206@cisco.com> Date: Mon, 28 Mar 2011 16:34:03 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: <4D8F492A.6040605@cisco.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------040808080107010003040707" Cc: ipfix@ietf.org Subject: Re: [IPFIX] Draft Standard version of RFC5101 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 15:01:26 -0000 This is a multi-part message in MIME format. --------------040808080107010003040707 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Dan, > > Hi, > > When progressing from Proposed to Draft only editorial > clarifications editorial changes are allowed. You can also point to > portion of the specification that you would like to obsolete because > the implementation experience show that they are no longer used. > However, you cannot make changes that are not 100% compatible with the > version of the protocol defined at Proposed. If such changes are > needed the document needs to recycle at Proposed. > > Are you sure that all the changes that you are suggesting are > editorial clarifications? For example change #3, change #8 and change > #10? > thanks for the clarification. #8 and #10, I agree with you: not editorial Regarding #3, there is a gap in the specifications. Should we address it. The proposed solution would not bring incompatibilities. Regards, Benoit. > > > Thanks and Regards, > > Dan > > > ------------------------------------------------------------------------ > *From:* ipfix-bounces@ietf.org [mailto:ipfix-bounces@ietf.org] *On > Behalf Of *Benoit Claise > *Sent:* Sunday, March 27, 2011 4:27 PM > *To:* ipfix@ietf.org > *Subject:* [IPFIX] Draft Standard version of RFC5101 > > Dear all, > > Here is the list of things to be changed in the Draft Standard > version of RFC5101. > Along the years, I've been collecting (from different people a > list of what could be improved in IPFIX. Many points come from > discussions with Paul Aitken. > > Some of points below should be discussed. > > 1. what must be changed is obviously > http://www.rfc-editor.org/errata_search.php?rfc=5101 > > 2. the email thread > http://www.ietf.org/mail-archive/web/ipfix/current/msg05652.html > suggests to change the definition from "IP Traffic Flow or Flow" > to "Traffic Flow or Flow", and from "IP packets" to "packets" when > RFC5101 will go from Proposed Standard to Draft Standard. > > 3. Different Template Record management between the transport > protocol (feedback from the IPFIX interop) > > SCTP transport > > If the Collecting Process receives a Template that has > already been received but that has not previously been withdrawn > (i.e., a Template Record from the same Exporter Observation Domain > with the same Template ID received on the SCTP association), then the > Collecting Process MUST shut down the association. > > > So an identical Template Record is resent (like in UDP), the > Collecting Process MUST shut down the association > First problem: we don't have the same statement for TCP, which > only says: > > If the Collecting Process receives a malformed IPFIX Message, it MUST > discard the IPFIX Message and SHOULD log the error. > > So this is not consistent as we don't know what "malformed" means. > Thinking some more about it, is this really a mistake if SCTP and > TCP would behave as UDP, i.e. accept the exact same (Options) > Template Record to be resent? Proposal with something such as: > It's NOT RECOMMENDED that _identical _Template Record are resent > in SCTP and TCP.... but it will not cause the SCTP association or > TCP association to be shut down... > Before applying this change, we have to double-check if there are > no complications for draft-ietf-ipfix-export-per-sctp-stream-08 > > 4. > > OLD: > > Exporting Process ID > The identifier of the Exporting Process for > which lack of reliability is reported. There > are three Information Elements specified in > [RFC5102 ] that can be used for this purpose: > exporterIPv4Address, exporterIPv6Address, or > exportingProcessId. This Information Element > MUST be defined as a Scope Field. > > NEW: > > Exporting Process ID > The identifier of the Exporting Process for > which lack of reliability is reported. There > are three Information Elements specified in > [RFC5102 ] that can be used for this purpose: > exporterIPv4Address, exporterIPv6Address, or > exportingProcessId. This Information Element, > _or these Information Elements if multiple are > _ _needed,_ MUST be defined as a Scope Field > > Justification: both the address and process ID are needed to > identify a specific exporter in the case of multiple exporters at > the same address. > > > > 5. > > 10.3.6. Template Management > > Following a configuration change that can modify the > interpretation > of the Data Records (for example, a sampling rate change) a new > Template ID MUST be used, and the old Template ID MUST NOT be > reused > until its lifetime (see Section 10.3.7) has expired. > > In section 10.3.7. Collecting Process, we read: > > The Template lifetime at the Collecting Process MUST be at least 3 > times higher than the Template refresh timeout configured on the > Exporting Process. > > > In Flexible NetFlow, template refresh is in units of packets, so > that template export scales with the volume of exported data. > If we're no longer exporting any packets then the "3 times higher" > threshold will never be reached... so the templates will never > expire. > eg, if we're exporting templates every 1,000 packets, then the > lifetime on the collector should be 3,000 packets. Yet once we're > no longer using the template, we'll be exporting 0 packets... > So the RFC should specify the units, or give an alternative > mechanism. > > > 6. > > Section 8: > If the measurement parameters change such that a new Template is > required, the Template MUST be withdrawn (using a Template > Withdraw > Message and a new Template definition) or an unused Template ID > MUST > be used. Examples of the measurement changes are: a new sampling > rate, a new Flow expiration process, a new filtering > definition, etc. > > A new sampling rate etc may not require a new template at all; it > may be expressed with the same template, just different data. The > template belongs to the transport layer and really has nothing to > do with the sampler change! > > Proposal: remove "a new sampling rate" > > > 7. > > Section 4.3. The Exporting Process Reliability Statistics Option Template > > time first flow dropped > The timestamp of the first Flow was > dropped by > the Metering Process. For this timestamp, > any > of the "flowStart" timestamp Information > Elements flowStartMilliseconds, > flowStartMicroseconds, > flowStartNanoseconds, and > flowStartDeltaMicroseconds can be used. > > time last flow dropped > The timestamp of the last IP packet that was > ignored by the Metering Process. For this > timestamp, any of the "flowEnd" timestamp > Information Elements flowEndMilliseconds, > flowEndMicroseconds, flowEndNanoseconds, and > flowEndDeltaMicroseconds can be used. > > Firstly, these definitions are inconsistent since the names and > the first definition say "flow" while the second definition says > "IP packet". Obviously "IP packet" != "flow" :-o > > Secondly, "The timestamp of the first Flow was dropped by the > Metering Process." is bad English: at least it's missing "that". > > 8. > > Section 4.3. The Exporting Process Reliability Statistics Option Template > > These statistics where defined before we introduced the concept of > Transport Session. > This full section 3.4 should be re-specified for "4.3 The > Transport Session Reliability Statistics Option Template" > > > 9. > > Section 4.2. The Metering Process Reliability Statistics Option Template > > Suppose a packet cannot be classified before it's dropped. Which > Metering Process (meteringProcessId) should report this? > > Suppose the packet pertains to several monitors. If some or all of > them cannot record the packet (eg, cache full), should they all report > the loss? That might look like some random number of packets had been > lost, when in fact it's only one. > > > > 10. > > Do we want to have a new IE for the template lifetime, to be sent > in an Options Template Record. > > > Regards, Benoit. > > --------------040808080107010003040707 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Dan,

Hi,

 

When progressing from Proposed to Draft only editorial clarifications editorial changes are allowed. You can also point to portion of the specification that you would like to obsolete because the implementation experience show that they are no longer used. However, you cannot make changes that are not 100% compatible with the version of the protocol defined at Proposed. If such changes are needed the document needs to recycle at Proposed.

Are you sure that all the changes that you are suggesting are editorial clarifications? For example change #3, change #8 and change #10?

thanks for the clarification.
#8 and #10, I agree with you: not editorial
Regarding #3, there is a gap in the specifications. Should we address it. The proposed solution would not bring incompatibilities.

Regards, Benoit.



Thanks and Regards,

Dan

 

From: ipfix-bounces@ietf.org [mailto:ipfix-bounces@ietf.org] On Behalf Of Benoit Claise
Sent: Sunday, March 27, 2011 4:27 PM
To: ipfix@ietf.org
Subject: [IPFIX] Draft Standard version of RFC5101

Dear all,

Here is the list of things to be changed in the Draft Standard version of RFC5101.
Along the years, I've been collecting (from different people a list of what could be improved in IPFIX. Many points come from discussions with Paul Aitken.

Some of points below should be discussed.

1. what must be changed is obviously http://www.rfc-editor.org/errata_search.php?rfc=5101

2. the email thread http://www.ietf.org/mail-archive/web/ipfix/current/msg05652.html suggests to change the definition from "IP Traffic Flow or Flow" to "Traffic Flow or Flow", and from "IP packets" to "packets" when RFC5101 will go from Proposed Standard to Draft Standard.

3. Different Template Record management between the transport protocol (feedback from the IPFIX interop)

SCTP transport
   If the Collecting Process receives a Template that has
   already been received but that has not previously been withdrawn
   (i.e., a Template Record from the same Exporter Observation Domain
   with the same Template ID received on the SCTP association), then the
   Collecting Process MUST shut down the association.
So an identical Template Record is resent (like in UDP), the Collecting Process MUST shut down the association
First problem: we don't have the same statement for TCP, which only says:
   If the Collecting Process receives a malformed IPFIX Message, it MUST
   discard the IPFIX Message and SHOULD log the error.
So this is not consistent as we don't know what "malformed" means.
Thinking some more about it, is this really a mistake if SCTP and TCP would behave as UDP, i.e. accept the exact same (Options) Template Record to be resent? Proposal with something such as: It's NOT RECOMMENDED that identical Template Record are resent in SCTP and TCP.... but it will not cause the SCTP association or TCP association to be shut down...
Before applying this change, we have to double-check if there are no complications for draft-ietf-ipfix-export-per-sctp-stream-08

4.

OLD:
Exporting Process ID
                        The identifier of the Exporting Process for
                        which lack of reliability is reported.  There
                        are three Information Elements specified in
                        [RFC5102] that can be used for this purpose:
                        exporterIPv4Address, exporterIPv6Address, or
                        exportingProcessId.  This Information Element
                        MUST be defined as a Scope Field.
NEW:
Exporting Process ID
                        The identifier of the Exporting Process for
                        which lack of reliability is reported.  There
                        are three Information Elements specified in
                        [RFC5102] that can be used for this purpose:
                        exporterIPv4Address, exporterIPv6Address, or
                        exportingProcessId.  This Information Element, 
                        or these Information Elements if multiple are 
                        needed, MUST be defined as a Scope Field
Justification: both the address and process ID are needed to identify a specific exporter in the case  of multiple exporters at the same address.



5.

10.3.6.  Template Management

   Following a configuration change that can modify the interpretation
   of the Data Records (for example, a sampling rate change) a new
   Template ID MUST be used, and the old Template ID MUST NOT be reused
   until its lifetime (see Section 10.3.7) has expired.

In section 10.3.7.  Collecting Process, we read:

   The Template lifetime at the Collecting Process MUST be at least 3
   times higher than the Template refresh timeout configured on the
   Exporting Process.


In Flexible NetFlow, template refresh is in units of packets, so that template export scales with the volume of exported data.
If we're no longer exporting any packets then the "3 times higher" threshold will never be reached... so the templates will never expire.
eg, if we're exporting templates every 1,000 packets, then the lifetime on the collector should be 3,000 packets. Yet once we're no longer using the template, we'll be exporting 0 packets...
So the RFC should specify the units, or give an alternative mechanism.


6.

Section 8:
   If the measurement parameters change such that a new Template is
   required, the Template MUST be withdrawn (using a Template Withdraw
   Message and a new Template definition) or an unused Template ID MUST
   be used.  Examples of the measurement changes are: a new sampling
   rate, a new Flow expiration process, a new filtering definition, etc.

A new sampling rate etc may not require a new template at all; it may be expressed with the same template, just different data. The template belongs to the transport layer and really has nothing to do with the sampler change!

Proposal: remove "a new sampling rate"


7.
Section 4.3.  The Exporting Process Reliability Statistics Option Template
   time first flow dropped
                        The timestamp of the first Flow was dropped by
                        the Metering Process.  For this timestamp, any
                        of the "flowStart" timestamp Information
                        Elements flowStartMilliseconds,
                        flowStartMicroseconds, flowStartNanoseconds, and
                        flowStartDeltaMicroseconds can be used.

   time last flow dropped
                        The timestamp of the last IP packet that was
                        ignored by the Metering Process.  For this
                        timestamp, any of the "flowEnd" timestamp
                        Information Elements flowEndMilliseconds,
                        flowEndMicroseconds, flowEndNanoseconds, and
                        flowEndDeltaMicroseconds can be used.

Firstly, these definitions are inconsistent since the names and the first definition say "flow" while the second definition says "IP packet". Obviously "IP packet" != "flow" :-o

Secondly, "The timestamp of the first Flow was dropped by the Metering Process." is bad English: at least it's missing "that".

8.
Section 4.3.  The Exporting Process Reliability Statistics Option Template
These statistics where defined before we introduced the concept of Transport Session.
 This full section 3.4 should be re-specified for "4.3 The Transport Session Reliability Statistics Option Template"


9.
Section 4.2.  The Metering Process Reliability Statistics Option Template

Suppose a packet cannot be classified before it's dropped. Which 
Metering Process (meteringProcessId) should report this?

Suppose the packet pertains to several monitors. If some or all of 
them cannot record the packet (eg, cache full), should they all report 
the loss? That might look like some random number of packets had been 
lost, when in fact it's only one.
10.

Do we want to have a new IE  for the template lifetime, to be sent in an Options Template Record.


Regards, Benoit.



--------------040808080107010003040707-- From dromasca@avaya.com Mon Mar 28 10:04:02 2011 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD07C28C121 for ; Mon, 28 Mar 2011 10:04:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.128 X-Spam-Level: X-Spam-Status: No, score=-103.128 tagged_above=-999 required=5 tests=[AWL=0.470, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MhuiOE07SH-p for ; Mon, 28 Mar 2011 10:04:00 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id BEDEB28C0FE for ; Mon, 28 Mar 2011 10:03:59 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvYAAFMtcU2HCzI1/2dsb2JhbACYKo47dIhcnB0CmRaCfoJjBIFtjh+JLQ X-IronPort-AV: E=Sophos;i="4.63,256,1299474000"; d="scan'208,217";a="271746788" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 28 Mar 2011 13:05:36 -0400 X-IronPort-AV: E=Sophos;i="4.63,256,1299474000"; d="scan'208,217";a="631994646" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 28 Mar 2011 13:05:35 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBED6A.4E8CB3FE" Date: Mon, 28 Mar 2011 19:05:14 +0200 Message-ID: In-Reply-To: <4D909C5B.5010206@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPFIX] Draft Standard version of RFC5101 Thread-Index: AcvtVj+MkFu2beemS/yDUBtmYeJJbQAE+Cjw References: <4D8F492A.6040605@cisco.com> <4D909C5B.5010206@cisco.com> From: "Romascanu, Dan (Dan)" To: "Benoit Claise" Cc: ipfix@ietf.org Subject: Re: [IPFIX] Draft Standard version of RFC5101 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 17:04:02 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBED6A.4E8CB3FE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 =20 Hi, So the question that the WG needs to decide is - are these issues important enough to justify recycling at Proposed rather than progression to Draft? Thanks and Regards, Dan =20 ________________________________ From: Benoit Claise [mailto:bclaise@cisco.com]=20 Sent: Monday, March 28, 2011 4:34 PM To: Romascanu, Dan (Dan) Cc: ipfix@ietf.org Subject: Re: [IPFIX] Draft Standard version of RFC5101 =09 =09 Hi Dan, =09 Hi, =20 When progressing from Proposed to Draft only editorial clarifications editorial changes are allowed. You can also point to portion of the specification that you would like to obsolete because the implementation experience show that they are no longer used. However, you cannot make changes that are not 100% compatible with the version of the protocol defined at Proposed. If such changes are needed the document needs to recycle at Proposed.=20 Are you sure that all the changes that you are suggesting are editorial clarifications? For example change #3, change #8 and change #10?=20 thanks for the clarification. #8 and #10, I agree with you: not editorial Regarding #3, there is a gap in the specifications. Should we address it. The proposed solution would not bring incompatibilities. =09 Regards, Benoit. =09 =09 =09 =09 Thanks and Regards, =09 Dan =09 =20 ________________________________ From: ipfix-bounces@ietf.org [mailto:ipfix-bounces@ietf.org] On Behalf Of Benoit Claise Sent: Sunday, March 27, 2011 4:27 PM To: ipfix@ietf.org Subject: [IPFIX] Draft Standard version of RFC5101 =09 =09 Dear all, =09 Here is the list of things to be changed in the Draft Standard version of RFC5101. Along the years, I've been collecting (from different people a list of what could be improved in IPFIX. Many points come from discussions with Paul Aitken. =09 Some of points below should be discussed. =09 1. what must be changed is obviously http://www.rfc-editor.org/errata_search.php?rfc=3D5101 =09 2. the email thread http://www.ietf.org/mail-archive/web/ipfix/current/msg05652.html suggests to change the definition from "IP Traffic Flow or Flow" to "Traffic Flow or Flow", and from "IP packets" to "packets" when RFC5101 will go from Proposed Standard to Draft Standard. =09 3. Different Template Record management between the transport protocol (feedback from the IPFIX interop) =09 SCTP transport =09 If the Collecting Process receives a Template that has already been received but that has not previously been withdrawn (i.e., a Template Record from the same Exporter Observation Domain with the same Template ID received on the SCTP association), then the Collecting Process MUST shut down the association. =09 So an identical Template Record is resent (like in UDP), the Collecting Process MUST shut down the association First problem: we don't have the same statement for TCP, which only says: =09 If the Collecting Process receives a malformed IPFIX Message, it MUST discard the IPFIX Message and SHOULD log the error. So this is not consistent as we don't know what "malformed" means. Thinking some more about it, is this really a mistake if SCTP and TCP would behave as UDP, i.e. accept the exact same (Options) Template Record to be resent? Proposal with something such as: It's NOT RECOMMENDED that identical Template Record are resent in SCTP and TCP.... but it will not cause the SCTP association or TCP association to be shut down... Before applying this change, we have to double-check if there are no complications for draft-ietf-ipfix-export-per-sctp-stream-08 =09 4.=20 =09 OLD: =09 Exporting Process ID The identifier of the Exporting Process for which lack of reliability is reported. There are three Information Elements specified in [RFC5102 ] that can be used for this purpose: exporterIPv4Address, exporterIPv6Address, or exportingProcessId. This Information Element MUST be defined as a Scope Field. NEW: =09 Exporting Process ID The identifier of the Exporting Process for which lack of reliability is reported. There are three Information Elements specified in [RFC5102 ] that can be used for this purpose: exporterIPv4Address, exporterIPv6Address, or exportingProcessId. This Information Element,=20 or these Information Elements if multiple are=20 needed, MUST be defined as a Scope Field Justification: both the address and process ID are needed to identify a specific exporter in the case of multiple exporters at the same address. =09 =09 =09 5. =09 10.3.6. Template Management=20 =09 Following a configuration change that can modify the interpretation=20 of the Data Records (for example, a sampling rate change) a new=20 Template ID MUST be used, and the old Template ID MUST NOT be reused=20 until its lifetime (see Section 10.3.7) has expired.=20 =09 In section 10.3.7. Collecting Process, we read: =09 The Template lifetime at the Collecting Process MUST be at least 3=20 times higher than the Template refresh timeout configured on the=20 Exporting Process.=20 =09 =09 In Flexible NetFlow, template refresh is in units of packets, so that template export scales with the volume of exported data.=20 If we're no longer exporting any packets then the "3 times higher" threshold will never be reached... so the templates will never expire.=20 eg, if we're exporting templates every 1,000 packets, then the lifetime on the collector should be 3,000 packets. Yet once we're no longer using the template, we'll be exporting 0 packets... So the RFC should specify the units, or give an alternative mechanism.=20 =09 =09 6.=20 =09 Section 8:=20 If the measurement parameters change such that a new Template is=20 required, the Template MUST be withdrawn (using a Template Withdraw=20 Message and a new Template definition) or an unused Template ID MUST=20 be used. Examples of the measurement changes are: a new sampling=20 rate, a new Flow expiration process, a new filtering definition, etc.=20 =09 A new sampling rate etc may not require a new template at all; it may be expressed with the same template, just different data. The template belongs to the transport layer and really has nothing to do with the sampler change!=20 =09 Proposal: remove "a new sampling rate" =09 =09 7. =09 Section 4.3. The Exporting Process Reliability Statistics Option Template time first flow dropped=20 The timestamp of the first Flow was dropped by=20 the Metering Process. For this timestamp, any=20 of the "flowStart" timestamp Information=20 Elements flowStartMilliseconds,=20 flowStartMicroseconds, flowStartNanoseconds, and=20 =09 flowStartDeltaMicroseconds can be used.=20 =09 time last flow dropped=20 The timestamp of the last IP packet that was=20 ignored by the Metering Process. For this=20 timestamp, any of the "flowEnd" timestamp=20 Information Elements flowEndMilliseconds,=20 flowEndMicroseconds, flowEndNanoseconds, and=20 flowEndDeltaMicroseconds can be used.=20 =09 Firstly, these definitions are inconsistent since the names and the first definition say "flow" while the second definition says "IP packet". Obviously "IP packet" !=3D "flow" :-o=20 =09 Secondly, "The timestamp of the first Flow was dropped by the Metering Process." is bad English: at least it's missing "that".=20 =09 8. =09 Section 4.3. The Exporting Process Reliability Statistics Option Template These statistics where defined before we introduced the concept of Transport Session. This full section 3.4 should be re-specified for "4.3 The Transport Session Reliability Statistics Option Template" =09 =09 9. =09 Section 4.2. The Metering Process Reliability Statistics Option Template =09 Suppose a packet cannot be classified before it's dropped. Which=20 Metering Process (meteringProcessId) should report this? =09 Suppose the packet pertains to several monitors. If some or all of=20 them cannot record the packet (eg, cache full), should they all report=20 the loss? That might look like some random number of packets had been=20 lost, when in fact it's only one. =09 =09 =09 10. =09 Do we want to have a new IE for the template lifetime, to be sent in an Options Template Record. =09 =09 Regards, Benoit. =09 =09 =09 ------_=_NextPart_001_01CBED6A.4E8CB3FE Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
 

Hi,

So = the question=20 that the WG needs to decide is - are these issues important enough to = justify=20 recycling at Proposed rather than progression to = Draft?


Thanks and=20 Regards,

Dan

 

From: Benoit Claise = [mailto:bclaise@cisco.com]=20
Sent: Monday, March 28, 2011 4:34 PM
To: = Romascanu, Dan=20 (Dan)
Cc: ipfix@ietf.org
Subject: Re: [IPFIX] = Draft=20 Standard version of RFC5101

Hi Dan,

Hi,

 

When progressing from Proposed to Draft = only=20 editorial clarifications editorial changes are allowed. = You can=20 also point to portion of the specification that you would like to = obsolete=20 because the implementation experience show that they are no longer = used.=20 However, you cannot make changes that are not 100% compatible with = the=20 version of the protocol defined at Proposed. If such changes are = needed the=20 document needs to recycle at Proposed.

Are you sure = that all the=20 changes that you are suggesting are editorial clarifications? For = example=20 change #3, change #8 and change #10? =

thanks for=20 the clarification.
#8 and #10, I agree with you: not = editorial
Regarding=20 #3, there is a gap in the specifications. Should we address it. The = proposed=20 solution would not bring incompatibilities.

Regards, = Benoit.



Thanks and=20 Regards,

Dan

 

From: ipfix-bounces@ietf.org = [mailto:ipfix-bounces@ietf.org]= =20 On Behalf Of Benoit Claise
Sent: Sunday, March = 27, 2011=20 4:27 PM
To: ipfix@ietf.org
Subject: = [IPFIX]=20 Draft Standard version of RFC5101

Dear=20 all,

Here is the list of things to be changed in the Draft = Standard=20 version of RFC5101.
Along the years, I've been collecting (from = different people a list of what could be improved in IPFIX. Many = points=20 come from discussions with Paul Aitken.

Some of points = below should=20 be discussed.

1. what must be changed is obviously http://www.rfc-editor.org/errata_search.php?rfc=3D= 5101

2.=20 the email thread http://www.ietf.org/mail-archive/web/ipfix/curre= nt/msg05652.html=20 suggests to change the definition from "IP Traffic Flow or Flow" = to=20 "Traffic Flow or Flow", and from "IP packets" to "packets" when = RFC5101=20 will go from Proposed Standard to Draft Standard.

3. = Different=20 Template Record management between the transport protocol = (feedback from=20 the IPFIX interop)

SCTP transport
  =
 If the Collecting Process receives a Template that has
   already been received but that has not previously been withdrawn
   (i.e., a Template Record from the same Exporter Observation Domain
   with the same Template ID received on the SCTP association), then the
   Collecting Process MUST shut down the association.
So an identical Template Record is resent (like in UDP), the=20 Collecting Process MUST shut down the association
First = problem: we=20 don't have the same statement for TCP, which only says:
   If the Collecting Process receives a malformed IPFIX =
Message, it MUST
   discard the IPFIX Message and SHOULD log the error.
So this is not consistent as we don't know what "malformed"=20 means.
Thinking some more about it, is this really a mistake if = SCTP=20 and TCP would behave as UDP, i.e. accept the exact same (Options) = Template=20 Record to be resent? Proposal with something such as: It's NOT = RECOMMENDED=20 that identical Template Record are resent in SCTP and = TCP.... but=20 it will not cause the SCTP association or TCP association to be = shut=20 down...
Before applying this change, we have to double-check if = there=20 are no complications for=20 draft-ietf-ipfix-export-per-sctp-stream-08

4. =

OLD:
Exporting Process ID
                        The identifier of the Exporting Process for
                        which lack of reliability is reported.  There
                        are three Information Elements specified in
                        [RFC5102] that can be used for this purpose:
                        exporterIPv4Address, exporterIPv6Address, or
                        exportingProcessId.  This Information Element
                        MUST be defined as a Scope Field.
NEW:
Exporting Process ID
                        The identifier of the Exporting Process for
                        which lack of reliability is reported.  There
                        are three Information Elements specified in
                        [RFC5102] that can be used for this purpose:
                        exporterIPv4Address, exporterIPv6Address, or
                        exportingProcessId.  This Information Element,=20
                        or these Information Elements if multiple are =

                        needed, MUST be defined as a Scope =
Field
Justification: both the address and process ID are needed to=20 identify a specific exporter in the case  of multiple = exporters at=20 the same address.



5.

10.3.6.  Template=20 Management

   Following a configuration change = that can=20 modify the interpretation
   of the Data Records = (for=20 example, a sampling rate change) a new
   Template = ID MUST=20 be used, and the old Template ID MUST NOT be reused =
   until=20 its lifetime (see Section 10.3.7) has expired.

In section=20 10.3.7.  Collecting Process, we read:

   = The=20 Template lifetime at the Collecting Process MUST be at least 3=20
   times higher than the Template refresh timeout = configured=20 on the
   Exporting Process.


In Flexible = NetFlow, template refresh is in units of packets, so that template = export=20 scales with the volume of exported data.
If we're no longer = exporting=20 any packets then the "3 times higher" threshold will never be = reached...=20 so the templates will never expire.
eg, if we're exporting = templates=20 every 1,000 packets, then the lifetime on the collector should be = 3,000=20 packets. Yet once we're no longer using the template, we'll be = exporting 0=20 packets...
So the RFC should specify the units, or give an = alternative=20 mechanism.


6.

Section 8:
   If = the=20 measurement parameters change such that a new Template is =
  =20 required, the Template MUST be withdrawn (using a Template = Withdraw=20
   Message and a new Template definition) or an = unused=20 Template ID MUST
   be used.  Examples of the=20 measurement changes are: a new sampling
   rate, a = new Flow=20 expiration process, a new filtering definition, etc.

A new = sampling rate etc may not require a new template at all; it may be = expressed with the same template, just different data. The = template=20 belongs to the transport layer and really has nothing to do with = the=20 sampler change!

Proposal: remove "a new sampling=20 rate"


7.
Section 4.3.  The =
Exporting Process Reliability Statistics Option Template
   time first flow dropped=20 =
           &nb= sp;           =20 The timestamp of the first Flow was dropped by=20 =
           &nb= sp;           =20 the Metering Process.  For this timestamp, any=20 =
           &nb= sp;           =20 of the "flowStart" timestamp Information=20 =
           &nb= sp;           =20 Elements flowStartMilliseconds,=20 =
           &nb= sp;           =20 flowStartMicroseconds, flowStartNanoseconds, and=20 =
           &nb= sp;           =20 flowStartDeltaMicroseconds can be used.

   time = last=20 flow dropped=20 =
           &nb= sp;           =20 The timestamp of the last IP packet that was=20 =
           &nb= sp;           =20 ignored by the Metering Process.  For this=20 =
           &nb= sp;           =20 timestamp, any of the "flowEnd" timestamp=20 =
           &nb= sp;           =20 Information Elements flowEndMilliseconds,=20 =
           &nb= sp;           =20 flowEndMicroseconds, flowEndNanoseconds, and=20 =
           &nb= sp;           =20 flowEndDeltaMicroseconds can be used.

Firstly, these = definitions=20 are inconsistent since the names and the first definition say = "flow" while=20 the second definition says "IP packet". Obviously "IP packet" !=3D = "flow"=20 :-o

Secondly, "The timestamp of the first Flow was dropped = by the=20 Metering Process." is bad English: at least it's missing "that".=20

8.
Section 4.3.  The Exporting =
Process Reliability Statistics Option Template
These=20 statistics where defined before we introduced the concept of = Transport=20 Session.
 This full section 3.4 should be re-specified for = "4.3=20 The Transport Session Reliability Statistics Option=20 Template"


9.
Section 4.2.  The =
Metering Process Reliability Statistics Option Template

Suppose a packet cannot be classified before it's dropped. Which=20
Metering Process (meteringProcessId) should report this?

Suppose the packet pertains to several monitors. If some or all of=20
them cannot record the packet (eg, cache full), should they all report=20
the loss? That might look like some random number of packets had been=20
lost, when in fact it's only one.
10.

Do we want to have a new = IE =20 for the template lifetime, to be sent in an Options Template=20 Record.


Regards,=20 Benoit.



------_=_NextPart_001_01CBED6A.4E8CB3FE-- From n.brownlee@auckland.ac.nz Mon Mar 28 23:28:31 2011 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 650783A6802 for ; Mon, 28 Mar 2011 23:28:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HJTGlRStSVFA for ; Mon, 28 Mar 2011 23:28:29 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by core3.amsl.com (Postfix) with ESMTP id C35823A67E7 for ; Mon, 28 Mar 2011 23:28:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=n.brownlee@auckland.ac.nz; q=dns/txt; s=uoa; t=1301380207; x=1332916207; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; z=Message-ID:=20<4D917C5F.3060007@auckland.ac.nz>|Date:=20 Mon,=2028=20Mar=202011=2023:29:51=20-0700|From:=20Nevil =20Brownlee=20|MIME-Version: =201.0|To:=20IPFIX=20list=20|Subject:=20T oday's=20meeting:=20revised=20agenda=20on=20Meeting=20Mat erials=20page|Content-Transfer-Encoding:=207bit; bh=L/kl9Ts0M/d+S5uOLpVdD6vzuY/G+0PhTl44KKuVnss=; b=LP0gU2I22W6bpt/rfkPxlWX2QI4LkDxMkvG+Wq9IGZd+nlBC3TDmJqdE 8mY6x6ZGZ/yGVEpusY+752+9O907yRxlG+CKD+IcU2Q/yD0T1jEO2IA8x YwWpPIK+4A1u/3HtlT+aAdKCk3e9mk++G4qoISSLmrZNZxMt69gIFQ6b8 c=; X-IronPort-AV: E=Sophos;i="4.63,260,1299409200"; d="scan'208";a="53800091" X-Ironport-HAT: None - $RELAY-AUTH X-Ironport-Source: 130.129.18.11 - Outgoing - Outgoing-SSL Received: from dhcp-120b.meeting.ietf.org (HELO [130.129.18.11]) ([130.129.18.11]) by mx2-int.auckland.ac.nz with ESMTP; 29 Mar 2011 19:29:58 +1300 Message-ID: <4D917C5F.3060007@auckland.ac.nz> Date: Mon, 28 Mar 2011 23:29:51 -0700 From: Nevil Brownlee User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 MIME-Version: 1.0 To: IPFIX list Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPFIX] Today's meeting: revised agenda on Meeting Materials page X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 06:28:31 -0000 Hi all: I've just put the latest version of our agenda for this afternooon on the Meeting Materials page. If you wish to present at the meeting, do please email your slides *now* so that I can get them onto Meeting Materials in time for remote (jabber) participants to see them. Cheers, Nevil -- --------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand From paitken@cisco.com Tue Mar 29 06:00:45 2011 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D32473A67B3 for ; Tue, 29 Mar 2011 06:00:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fGm4dipAcx1D for ; Tue, 29 Mar 2011 06:00:44 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 106AA3A6452 for ; Tue, 29 Mar 2011 06:00:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paitken@cisco.com; l=560; q=dns/txt; s=iport; t=1301403742; x=1302613342; h=message-id:date:from:mime-version:to:cc:subject: content-transfer-encoding; bh=6gQf7fblbXVHEL30eu/I2mkaYGhR/5t7XfiVIaUMYo4=; b=DHY3tlmG29ZYtDzm9Tbaveg+ZM+vKquhDznv9ZcYVEZQlpCoCJZ9DcAz 3l9bSyj2L66rfvdzNMnCWO5Gvxgni3yMzywhp6WxhkZT2FpLHeH2PJUdC 5aBUy+iEkF7x2IHnuJe7fOlSkQlPpSp6JxuSGiJu3mQtJN20pvC+fc+Ti Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmoEAAvYkU2Q/khLgWdsb2JhbAClTBQBARYmJahfnECFagSNAoNU X-IronPort-AV: E=Sophos;i="4.63,262,1299456000"; d="scan'208";a="23634514" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 29 Mar 2011 13:02:21 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p2TD2Lci006858; Tue, 29 Mar 2011 13:02:21 GMT Received: from [10.61.104.19] (dhcp-10-61-104-19.cisco.com [10.61.104.19]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id p2TD2KU15599; Tue, 29 Mar 2011 14:02:20 +0100 (BST) Message-ID: <4D91D859.6050407@cisco.com> Date: Tue, 29 Mar 2011 14:02:17 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: Brian Trammell Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF IPFIX Working Group Subject: [IPFIX] modifying existing IEs X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 13:00:45 -0000 Brian, You talked about modifying existing IEs. Suppose an IE modification doesn't break existing collectors. However, existing collectors don't know about the modification. eg, an additional value in an enumerated IE. How do we determine what level of support a particular IPFIX device provides for that IE? eg, if I say my EP supports IE.nnn, and you say your collector does - yet they may not be 100% interoperable. Do we need version control at the individual element level, so we can discuss "version n" of IE.nnn ? Thanks, P. From trammell@tik.ee.ethz.ch Tue Mar 29 08:33:54 2011 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 671443A68F7 for ; Tue, 29 Mar 2011 08:33:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z8SjKuZAQlDh for ; Tue, 29 Mar 2011 08:33:53 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id 7B2DB3A687E for ; Tue, 29 Mar 2011 08:33:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id B5B22D9328; Tue, 29 Mar 2011 17:35:30 +0200 (MEST) 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 VUbbVgMNq7Kq; Tue, 29 Mar 2011 17:35:30 +0200 (MEST) Received: from dhcp-678b.meeting.ietf.org (unknown [130.129.103.139]) (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 62E8BD9320; Tue, 29 Mar 2011 17:35:30 +0200 (MEST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Brian Trammell In-Reply-To: <4D91D859.6050407@cisco.com> Date: Tue, 29 Mar 2011 17:34:33 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D91D859.6050407@cisco.com> To: Paul Aitken X-Mailer: Apple Mail (2.1082) Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] modifying existing IEs X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 15:33:54 -0000 Hi, Paul, This was a point on the open issues slide, but was trying to speed = through things today so it got missed... So, do we need IE versions? In my opinion, yes: otherwise we can't = change "future reserved" values in flags or code table IEs. I'd suggest = a new column in the registry, initialized to 0 for existing IEs. If = these are essentially code tables linked to subregistries, then the = subregistries should probably have version numbers themselves. A second question: what about an IANA Registry version - a serial number = incremented by one on each modification, deprecation, or addition? The = case for this is less clear for me. Thoughts? Best regards, Brian On Mar 29, 2011, at 3:02 PM, Paul Aitken wrote: > Brian, >=20 > You talked about modifying existing IEs. >=20 > Suppose an IE modification doesn't break existing collectors. > However, existing collectors don't know about the modification. >=20 > eg, an additional value in an enumerated IE. >=20 > How do we determine what level of support a particular IPFIX device = provides for that IE? > eg, if I say my EP supports IE.nnn, and you say your collector does - = yet they may not be 100% interoperable. >=20 > Do we need version control at the individual element level, so we can = discuss "version n" of IE.nnn ? >=20 > Thanks, > P. From paitken@cisco.com Tue Mar 29 09:32:45 2011 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 271263A695D for ; Tue, 29 Mar 2011 09:32:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3-sN5UM8VyZK for ; Tue, 29 Mar 2011 09:32:44 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 7336B3A6A4E for ; Tue, 29 Mar 2011 09:32:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paitken@cisco.com; l=4998; q=dns/txt; s=iport; t=1301416462; x=1302626062; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=EbVHAbMM2BLZXbyh7IthxZhuD2ruCOuLsDSM98o6uO8=; b=iga1cYBcPLegPq/fP25wEllKgXhlL/H3+u1RfMPyU27VgSciM6vuNcS8 iXDwtjBf900nrkfy2BkjHc2XN3qLsGdFjAtYEYRoDuAh5K3lDegyEUO4o /bXQT2n3arStaYj5sI+e52X+OoGXkQuuNRz4awCn/1Z/r/g4aedLU62hw A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmoEAOIJkk2Q/khMgWdsb2JhbAClThQBARYmJYh5nwycW4VqBI0Cg1Q X-IronPort-AV: E=Sophos;i="4.63,263,1299456000"; d="scan'208,217";a="81332427" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 29 Mar 2011 16:34:21 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p2TGYGqt021274; Tue, 29 Mar 2011 16:34:16 GMT Received: from [10.61.104.19] (dhcp-10-61-104-19.cisco.com [10.61.104.19]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id p2TGYFU07198; Tue, 29 Mar 2011 17:34:15 +0100 (BST) Message-ID: <4D920A05.5020103@cisco.com> Date: Tue, 29 Mar 2011 17:34:13 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: Brian Trammell References: <4D91D859.6050407@cisco.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090009050202010702020501" Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] modifying existing IEs X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 16:32:45 -0000 This is a multi-part message in MIME format. --------------090009050202010702020501 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Brian, > This was a point on the open issues slide, but was trying to speed > through things today so it got missed... > > So, do we need IE versions? In my opinion, yes: otherwise we can't > change "future reserved" values in flags or code table IEs. We can, though there won't be any reference point for us to indicate exactly what we support. > I'd suggest a new column in the registry, initialized to 0 for > existing IEs. If these are essentially code tables linked to > subregistries, then the subregistries should probably have version > numbers themselves. OK. > A second question: what about an IANA Registry version - a serial > number incremented by one on each modification, deprecation, or > addition? The case for this is less clear for me. Agreed: if I add export of a new IE, or add new values in an existing IE, thus creating a new registry version, then I'd be obliged to bring all my exports up to date in order to comply with the version I just made. That may not be necessary, desirable or even possible. P. > On Mar 29, 2011, at 3:02 PM, Paul Aitken wrote: > > > Brian, > > > > You talked about modifying existing IEs. > > > > Suppose an IE modification doesn't break existing collectors. > > However, existing collectors don't know about the modification. > > > > eg, an additional value in an enumerated IE. > > > > How do we determine what level of support a particular IPFIX device > > provides for that IE? eg, if I say my EP supports IE.nnn, and you > > say your collector does - yet they may not be 100% interoperable. > > > > Do we need version control at the individual element level, so we > > can discuss "version n" of IE.nnn ? > > > > Thanks, P. > --------------090009050202010702020501 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Brian,

> This was a point on the open issues slide, but was trying to speed
> through things today so it got missed...
>
> So, do we need IE versions? In my opinion, yes: otherwise we can't
> change "future reserved" values in flags or code table IEs.

We can, though there won't be any reference point for us to indicate exactly what we support.


> I'd suggest a new column in the registry, initialized to 0 for
> existing IEs. If these are essentially code tables linked to
> subregistries, then the subregistries should probably have version
> numbers themselves.

OK.


> A second question: what about an IANA Registry version - a serial
> number incremented by one on each modification, deprecation, or
> addition? The case for this is less clear for me.

Agreed:  if I add export of a new IE, or add new values in an existing IE, thus creating a new registry version,
then I'd be obliged to bring all my exports up to date in order to comply with the version I just made.

That may not be necessary, desirable or even possible.

P.

 
> On Mar 29, 2011, at 3:02 PM, Paul Aitken wrote:
>
>> Brian,
>>
>> You talked about modifying existing IEs.
>>
>> Suppose an IE modification doesn't break existing collectors.
>> However, existing collectors don't know about the modification.
>>
>> eg, an additional value in an enumerated IE.
>>
>> How do we determine what level of support a particular IPFIX device
>> provides for that IE? eg, if I say my EP supports IE.nnn, and you
>> say your collector does - yet they may not be 100% interoperable.
>>
>> Do we need version control at the individual element level, so we
>> can discuss "version n" of IE.nnn ?
>>
>> Thanks, P.
>


--------------090009050202010702020501-- From paitken@cisco.com Tue Mar 29 09:32:45 2011 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F0053A6A4E for ; Tue, 29 Mar 2011 09:32:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.998 X-Spam-Level: X-Spam-Status: No, score=-9.998 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uDevjS6h+Bq1 for ; Tue, 29 Mar 2011 09:32:43 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 5F6D63A6A4A for ; Tue, 29 Mar 2011 09:32:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paitken@cisco.com; l=4998; q=dns/txt; s=iport; t=1301416462; x=1302626062; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=BZf49JpO71VN18wzyWFr2+hKPgZAAcgj+VI4oy8GdyQ=; b=VICDLJVDoB/5RwbeiL1iyZ7HEEDQCYcOGE/ikbT5HbNJgNzrFfkLoZkW qlJeEnVUZHKYA6/hTfVK233DtO1ZF6fzG4ZDFaO6q67So4mpnUQkdusWG Nh0mxkkW7VQJddxLJJJKM6lFzWGbhY0mhqoi6C4MC2+FOZii/Ps+gERKn U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmoEACIJkk2Q/khNgWdsb2JhbAClThQBARYmJYh5nwicWYVqBI0Cg1Q X-IronPort-AV: E=Sophos;i="4.63,263,1299456000"; d="scan'208,217";a="23665062" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 29 Mar 2011 16:34:21 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p2TGYKma024603; Tue, 29 Mar 2011 16:34:20 GMT Received: from [10.61.104.19] (dhcp-10-61-104-19.cisco.com [10.61.104.19]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id p2TGYJU07202; Tue, 29 Mar 2011 17:34:19 +0100 (BST) Message-ID: <4D920A09.6020003@cisco.com> Date: Tue, 29 Mar 2011 17:34:17 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: Brian Trammell References: <4D91D859.6050407@cisco.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------010500080403040302070100" Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] modifying existing IEs X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 16:32:45 -0000 This is a multi-part message in MIME format. --------------010500080403040302070100 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Brian, > This was a point on the open issues slide, but was trying to speed > through things today so it got missed... > > So, do we need IE versions? In my opinion, yes: otherwise we can't > change "future reserved" values in flags or code table IEs. We can, though there won't be any reference point for us to indicate exactly what we support. > I'd suggest a new column in the registry, initialized to 0 for > existing IEs. If these are essentially code tables linked to > subregistries, then the subregistries should probably have version > numbers themselves. OK. > A second question: what about an IANA Registry version - a serial > number incremented by one on each modification, deprecation, or > addition? The case for this is less clear for me. Agreed: if I add export of a new IE, or add new values in an existing IE, thus creating a new registry version, then I'd be obliged to bring all my exports up to date in order to comply with the version I just made. That may not be necessary, desirable or even possible. P. > On Mar 29, 2011, at 3:02 PM, Paul Aitken wrote: > > > Brian, > > > > You talked about modifying existing IEs. > > > > Suppose an IE modification doesn't break existing collectors. > > However, existing collectors don't know about the modification. > > > > eg, an additional value in an enumerated IE. > > > > How do we determine what level of support a particular IPFIX device > > provides for that IE? eg, if I say my EP supports IE.nnn, and you > > say your collector does - yet they may not be 100% interoperable. > > > > Do we need version control at the individual element level, so we > > can discuss "version n" of IE.nnn ? > > > > Thanks, P. > --------------010500080403040302070100 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Brian,

> This was a point on the open issues slide, but was trying to speed
> through things today so it got missed...
>
> So, do we need IE versions? In my opinion, yes: otherwise we can't
> change "future reserved" values in flags or code table IEs.

We can, though there won't be any reference point for us to indicate exactly what we support.


> I'd suggest a new column in the registry, initialized to 0 for
> existing IEs. If these are essentially code tables linked to
> subregistries, then the subregistries should probably have version
> numbers themselves.

OK.


> A second question: what about an IANA Registry version - a serial
> number incremented by one on each modification, deprecation, or
> addition? The case for this is less clear for me.

Agreed:  if I add export of a new IE, or add new values in an existing IE, thus creating a new registry version,
then I'd be obliged to bring all my exports up to date in order to comply with the version I just made.

That may not be necessary, desirable or even possible.

P.

 
> On Mar 29, 2011, at 3:02 PM, Paul Aitken wrote:
>
>> Brian,
>>
>> You talked about modifying existing IEs.
>>
>> Suppose an IE modification doesn't break existing collectors.
>> However, existing collectors don't know about the modification.
>>
>> eg, an additional value in an enumerated IE.
>>
>> How do we determine what level of support a particular IPFIX device
>> provides for that IE? eg, if I say my EP supports IE.nnn, and you
>> say your collector does - yet they may not be 100% interoperable.
>>
>> Do we need version control at the individual element level, so we
>> can discuss "version n" of IE.nnn ?
>>
>> Thanks, P.
>


--------------010500080403040302070100-- From trammell@tik.ee.ethz.ch Wed Mar 30 01:19:06 2011 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E383A28C0CF for ; Wed, 30 Mar 2011 01:19:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vNy+oyDSmAxH for ; Wed, 30 Mar 2011 01:19:06 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id 043A928C0CE for ; Wed, 30 Mar 2011 01:19:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 59FD4D9330; Wed, 30 Mar 2011 10:20:44 +0200 (MEST) 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 KvFVkASyX1Cq; Wed, 30 Mar 2011 10:20:44 +0200 (MEST) Received: from dhcp-63a5.meeting.ietf.org (dhcp-63a5.meeting.ietf.org [130.129.99.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 EE5A3D9325; Wed, 30 Mar 2011 10:20:43 +0200 (MEST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Brian Trammell In-Reply-To: <4D920A05.5020103@cisco.com> Date: Wed, 30 Mar 2011 10:20:39 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D91D859.6050407@cisco.com> <4D920A05.5020103@cisco.com> To: Paul Aitken X-Mailer: Apple Mail (2.1082) Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] modifying existing IEs X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 08:19:07 -0000 Hi, Paul, a couple of points inline... On Mar 29, 2011, at 6:34 PM, Paul Aitken wrote: > Brian, >=20 > > This was a point on the open > issues slide, but was trying to speed >=20 >=20 > > through things today so it got missed... >=20 >=20 > >=20 >=20 >=20 > > So, do we need IE versions? In my opinion, yes: otherwise we > can't >=20 >=20 > > change "future reserved" values in flags or code table IEs. >=20 >=20 > We can, though there won't be any reference point for us to indicate = exactly what we support. Unless the registry contains _every_ version of each IE. But then there = would still be no _runtime_ support for this...=20 >=20 > > I'd suggest a new column in the > registry, initialized to 0 for >=20 >=20 > > existing IEs. If these are essentially code tables linked to >=20 >=20 > > subregistries, then the subregistries should probably have > version >=20 >=20 > > numbers themselves. >=20 >=20 > OK. >=20 >=20 > > A second question: what about > an IANA Registry version - a serial >=20 >=20 > > number incremented by one on each modification, deprecation, > or >=20 >=20 > > addition? The case for this is less clear for me. >=20 >=20 > Agreed: if I add export of a new IE, or add new values in an existing = IE, thus creating a new registry version, > then I'd be obliged to bring all my exports up to date in order to = comply with the version I just made. >=20 > That may not be necessary, desirable or even possible. Hm. Good point. Okay, so the consensus of two would be "versioned IEs, = versioned subregistries referenced by IEs, no versioned registry"... Cheers, Brian From n.brownlee@auckland.ac.nz Thu Mar 31 02:24:06 2011 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0034728C250 for ; Thu, 31 Mar 2011 02:24:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m8EyhYhX3HYP for ; Thu, 31 Mar 2011 02:24:02 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by core3.amsl.com (Postfix) with ESMTP id 9EE1A28C1FC for ; Thu, 31 Mar 2011 02:22:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=n.brownlee@auckland.ac.nz; q=dns/txt; s=uoa; t=1301563474; x=1333099474; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; z=Message-ID:=20<4D94481E.6080605@auckland.ac.nz>|Date:=20 Thu,=2031=20Mar=202011=2002:23:42=20-0700|From:=20Nevil =20Brownlee=20|MIME-Version: =201.0|To:=20IPFIX=20list=20|Subject:=20D RAFT=20IPFIX=20minutes=20from=20IETF=2080 |Content-Transfer-Encoding:=207bit; bh=ZrrTdmbaBqssDKK2cJeknh8FMl0Om1t8ZLPq3Qn7A7U=; b=Q9Oadmm25Co7ceCoOrqPdeF52bssA4qBdE+vICiuTbf6cOMPbxpfucZM 6q8kZPlkx8Lu+x451cMiD0bkAUz4hElluVKi2ID5BjamGNrQtWZuZSI4X SEQL5F5kBWuUXHWP/Fx6+0aC0dQofUgla65NMSsONUBLYCQlMRtWvAZCi A=; X-IronPort-AV: E=Sophos;i="4.63,274,1299409200"; d="scan'208";a="54432622" X-Ironport-HAT: None - $RELAY-AUTH X-Ironport-Source: 130.129.18.11 - Outgoing - Outgoing-SSL Received: from dhcp-120b.meeting.ietf.org (HELO [130.129.18.11]) ([130.129.18.11]) by mx2-int.auckland.ac.nz with ESMTP; 31 Mar 2011 22:23:45 +1300 Message-ID: <4D94481E.6080605@auckland.ac.nz> Date: Thu, 31 Mar 2011 02:23:42 -0700 From: Nevil Brownlee User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 MIME-Version: 1.0 To: IPFIX list Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPFIX] DRAFT IPFIX minutes from IETF 80 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 09:24:06 -0000 Hi all: Here are my draft minutes for Tuesday's meeting; they include my summary of the alternatives from our 'Draft Standards?' discussion. Please send me any corrections, changes, etc as soon as possible. Minutes of the IPFIX meeting at IETF 80 About 36 people present Scribes: Cyndi Mills & Nevil Brownlee Nevil Brownlee presented current WG document status. Three documents completed since IETF 79 (Export-per-SCTP-stream, Mediators Framework and Anonymisation Support), one with IESG (Structured Data). We have received comments on the IPFIX Configuration Model draft from the YANG Doctors, and have been carefully considered. Juergen will do its write-up. The PSAMP MIB has been revised to use the UnsiUnsigned64TC and Float64TC Textual Conventions from other MIBs. Nevil will do its write-up. The remaining work item, Flow Selection, is under review, and will be discussed further on the IPFIX list. Brian Trammell presented a report on the 'DEMONS IPFIX Interoperability Test,' held in Prague, 24-25 March. This was the fourth such event for IPFIX, with eight implementations (4 exporters, 3 collectors) being tested. Interoperation was complete for UDP, less so for TCP; for SCTP it was dependent on the SCTP implementations used. Quite a few issues came to light (see the slides), many were fixed during the event. Several people commented on SCTP implementation issues, suggesting that perhaps "template handling is needlessly complicated in the (IPFIX) protocol." Dan Romascanu (our AD) asked for an Interoperation Report, Brian says he has one written as an Internet Draft. Lothar Braun presented Recommendations for Implementing IPFIX over DTLS/UDP. DTLS is mandatory for IPFIX over UDP and SCTP, but using it is difficult because IPFIX traffic is unidirectional, but DTLS requires shared state. Discussion centred on IPFIX's need for a heartbeat to detect collector failures, and whether IPFIX should do its own heartbeat. Lothar's recommendations could fit in a revision of IPFIX Implementation Guidelines. Juergen lead a discussion on whether we should work on moving some of the IPFIX standards from Proposed to Draft. Dan explained that to do so any changes would need to be editorial, not technical. There was considerable discussion, the main points being: 1. There are many errata for 5101 and 5102, it would be good to have a new draft that does that, along with some more explanatory (editorial) text where needed 2. If we move 5101 and 5102 to Draft, any changes - however small - would need to be a new version of the IPFIX protocol. Doing that could lead to confusion among IPFIX implementors and users 3. An alternative approach would be to work on a new draft (which implemented small changes that did not affect interoperation, for example adding detail where there are gaps in 5101) as a Standards Track successor to 5101. Once that had been published as an RFC for some time, we could work on moving it to Draft; that should be possible in a reasonably short time. 4. Other things that could be considered: IPFIX heartbeat provision (we need to consider how long it will take TSVWG to complete the DTLS Heartbeat Extension), change canonical transport to TCP, ... ? 5. Another possibility is to make a new "all about IPFIX" document; there was only weak consensus for this The meeting reached consensus for (3, rather than 2), we will discuss this further on the IPFIX list. Five drafts were presented as candidates (in addition to the 'Standards upgrade') for an IPFIX re-chartering. Brian Trammell presented 'IPFIX Intermediate Aggregation,' this drew strong consensus as a new WG item. Brian presented the 'IE Doctors' draft, pointing out that this draft "lays out the ground rules for developing new IPFIX Information Elements, and clarifies how the IE Registry process works." Michelle Cotton (IANA) commented that other working groups, e.g. DNS, have similar processes to those in this draft; we need to be clear about whether we're proposing "approval by IE-Doctors," or changes to "expert review" (which we have now). Dan commented that to set up a team of IE Doctors, we need AD approval, and must keep IESG informed. Paul Aitken asked (via jabber), whether an IE could be reviewed and not made public until the product is shipped? Dan replied "we have a body of experience to say that this should be an exception and not the rule." There was clear consensus for adopting this as a WG item, with one person expressing strong dissent. We will discuss this further on the list - the issues here are a. Should we develop an 'IE Guidelines' draft? b. Do we want to have an 'IE Doctors' team (with IESG overview), an expanded group of IE Expert reviewers, or what? Benoit Claise presented the 'IPFIX Mediation protocol' draft, now at version -03. There was clear consensus for adopting this. Benoit presented 'Exporting MIB variables using IPFIX.' A spirited discussion of how Odis should be referred to in the IPFIX protocol. There was stronger consensus for this than against it. Again, discussion of this will continue on the list. Benoit presented 'Exporting Application Information,' prompting considerable discussion. Steven Campbell commented that "vendor-specific labels for layer-7 mapping is difficult. However, the way to discover layer 7 (behavioral, DPI) could be standardized." Benoit said he wasn't proposing this as a WG item, however anyone interested should continue discussing this topic on the list. The meeting finished at 1459. -- --------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand From braun@net.in.tum.de Thu Mar 31 05:10:35 2011 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0BEB3A6B33 for ; Thu, 31 Mar 2011 05:10:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.071 X-Spam-Level: X-Spam-Status: No, score=-2.071 tagged_above=-999 required=5 tests=[AWL=0.178, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kMJv+bW6qwE2 for ; Thu, 31 Mar 2011 05:10:34 -0700 (PDT) Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) by core3.amsl.com (Postfix) with ESMTP id 728A33A6B0E for ; Thu, 31 Mar 2011 05:10:34 -0700 (PDT) Received: from dhcp-9227.meeting.ietf.org (dhcp-9227.meeting.ietf.org [130.129.10.39]) by mail.net.in.tum.de (Postfix) with ESMTPSA id 84F37208C748 for ; Thu, 31 Mar 2011 14:12:12 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1084) From: Lothar Braun In-Reply-To: <4D94481E.6080605@auckland.ac.nz> Date: Thu, 31 Mar 2011 14:12:12 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <48D83410-4F22-4B90-9BE2-C7CB9DC3189B@net.in.tum.de> References: <4D94481E.6080605@auckland.ac.nz> To: IPFIX list X-Mailer: Apple Mail (2.1084) Subject: Re: [IPFIX] DRAFT IPFIX minutes from IETF 80 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 12:10:36 -0000 Hi,=20 On Mar 31, 2011, at 11:23 AM, Nevil Brownlee wrote: > Hi all: >=20 > Here are my draft minutes for Tuesday's meeting; they include my > summary of the alternatives from our 'Draft Standards?' discussion. >=20 > Please send me any corrections, changes, etc as soon as possible. >=20 > Minutes of the IPFIX meeting at IETF 80 > About 36 people present > Scribes: Cyndi Mills & Nevil Brownlee >=20 > Nevil Brownlee presented current WG document status. Three documents > completed since IETF 79 (Export-per-SCTP-stream, Mediators Framework > and Anonymisation Support), one with IESG (Structured Data). We have > received comments on the IPFIX Configuration Model draft from the YANG > Doctors, and have been carefully considered. Juergen will do its > write-up. The PSAMP MIB has been revised to use the UnsiUnsigned64TC > and Float64TC Textual Conventions from other MIBs. Nevil will do its > write-up. The remaining work item, Flow Selection, is under review, > and will be discussed further on the IPFIX list. >=20 > Brian Trammell presented a report on the 'DEMONS IPFIX > Interoperability Test,' held in Prague, 24-25 March. This was the > fourth such event for IPFIX, with eight implementations (4 exporters, > 3 collectors) being tested. Interoperation was complete for UDP, > less so for TCP; for SCTP it was dependent on the SCTP > implementations used. Quite a few issues came to light (see the > slides), many were fixed during the event. > Several people commented on SCTP implementation issues, suggesting > that perhaps "template handling is needlessly complicated in the > (IPFIX) protocol." Dan Romascanu (our AD) asked for an Interoperation > Report, Brian says he has one written as an Internet Draft. >=20 > Lothar Braun presented Recommendations for Implementing IPFIX over > DTLS/UDP. DTLS is mandatory for IPFIX over UDP and SCTP, but using > it is difficult because IPFIX traffic is unidirectional, but DTLS > requires shared state. Discussion centred on IPFIX's need for a > heartbeat to detect collector failures, and whether IPFIX should do > its own heartbeat. Lothar's recommendations could fit in a revision > of IPFIX Implementation Guidelines. >=20 > Juergen lead a discussion on whether we should work on moving some of > the IPFIX standards from Proposed to Draft. Dan explained that to > do so any changes would need to be editorial, not technical. There > was considerable discussion, the main points being: > 1. There are many errata for 5101 and 5102, it would be good to have a > new draft that does that, along with some more explanatory > (editorial) text where needed > 2. If we move 5101 and 5102 to Draft, any changes - however small - > would need to be a new version of the IPFIX protocol. Doing that > could lead to confusion among IPFIX implementors and users > 3. An alternative approach would be to work on a new draft (which > implemented small changes that did not affect interoperation, for > example adding detail where there are gaps in 5101) as a Standards > Track successor to 5101. Once that had been published as an RFC > for some time, we could work on moving it to Draft; that should be > possible in a reasonably short time. > 4. Other things that could be considered: IPFIX heartbeat provision > (we need to consider how long it will take TSVWG to complete the > DTLS Heartbeat Extension), change canonical transport to TCP, ... ? I've been to the TLS WG meeting and checked upon the status and future = plans of the DTLS heartbeat draft. The draft has been adopted as a = working group document quite some time ago, which I completely missed. TLS chairs were confident that it would not take very long to move it to = PS. According to them, the document is in quite good shape, and could soon = progress to WGLC after a review from the transport area has been = received. > 5. Another possibility is to make a new "all about IPFIX" document; > there was only weak consensus for this > The meeting reached consensus for (3, rather than 2), we will discuss > this further on the IPFIX list. >=20 > Five drafts were presented as candidates (in addition to the = 'Standards > upgrade') for an IPFIX re-chartering. >=20 > Brian Trammell presented 'IPFIX Intermediate Aggregation,' this drew > strong consensus as a new WG item. >=20 > Brian presented the 'IE Doctors' draft, pointing out that this draft > "lays out the ground rules for developing new IPFIX Information > Elements, and clarifies how the IE Registry process works." Michelle > Cotton (IANA) commented that other working groups, e.g. DNS, have > similar processes to those in this draft; we need to be clear about > whether we're proposing "approval by IE-Doctors," or changes to > "expert review" (which we have now). Dan commented that to set up a > team of IE Doctors, we need AD approval, and must keep IESG informed. > Paul Aitken asked (via jabber), whether an IE could be reviewed and > not made public until the product is shipped? Dan replied "we have a > body of experience to say that this should be an exception and not the > rule." There was clear consensus for adopting this as a WG item, > with one person expressing strong dissent. We will discuss this > further on the list - the issues here are > a. Should we develop an 'IE Guidelines' draft? > b. Do we want to have an 'IE Doctors' team (with IESG overview), > an expanded group of IE Expert reviewers, or what? >=20 > Benoit Claise presented the 'IPFIX Mediation protocol' draft, now at > version -03. There was clear consensus for adopting this. >=20 > Benoit presented 'Exporting MIB variables using IPFIX.' A spirited > discussion of how Odis should be referred to in the IPFIX protocol. > There was stronger consensus for this than against it. Again, > discussion of this will continue on the list. >=20 > Benoit presented 'Exporting Application Information,' prompting > considerable discussion. Steven Campbell commented that > "vendor-specific labels for layer-7 mapping is difficult. However, the > way to discover layer 7 (behavioral, DPI) could be standardized." > Benoit said he wasn't proposing this as a WG item, however anyone > interested should continue discussing this topic on the list. >=20 > The meeting finished at 1459. >=20 > --=20 > --------------------------------------------------------------------- > Nevil Brownlee Computer Science Department | ITS > Phone: +64 9 373 7599 x88941 The University of Auckland > FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand >=20 > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix -- Lothar Braun Chair for Network Architectures and Services (I8) Department of Informatics Technische Universit=E4t M=FCnchen Boltzmannstr. 3, 85748 Garching bei M=FCnchen, Germany Phone: +49 89 289-18010 Fax: +49 89 289-18033 E-mail: braun@net.in.tum.de=20 From inacio@cert.org Thu Mar 31 07:42:57 2011 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6DA03A6B24 for ; Thu, 31 Mar 2011 07:42:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_53=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 71QNcUTGtmoG for ; Thu, 31 Mar 2011 07:42:56 -0700 (PDT) Received: from plainfield.sei.cmu.edu (plainfield.sei.cmu.edu [192.58.107.45]) by core3.amsl.com (Postfix) with ESMTP id 90DB83A6B10 for ; Thu, 31 Mar 2011 07:42:56 -0700 (PDT) Received: from timber.sei.cmu.edu (timber.sei.cmu.edu [10.64.21.23]) by plainfield.sei.cmu.edu (8.13.8/8.13.8/1294) with ESMTP id p2VEiZDF019765 for ; Thu, 31 Mar 2011 10:44:35 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1301582675; bh=u8dztvmUP8vD4ofZogdkjWf4g+Ednw79YW/XBv2JAhk=; h=From:To:Date:Subject:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version:Sender:Reply-To:Cc: In-Reply-To:References; b=UIsO6J1lPk0reKHZQWH2EzO+jTDb5Gx+1irr+ZQKPep/SRLXFFqeXTxlE3I0/fs2R AinK5ZofT+5xEclwkcvHWKifUzXuLu3LePrPcCndU4CkBI/Gy4GK7kqj/+XVy/B7Z3 ytnwMpQ9VyyiK1zQO+HXL/+nb5ZbVSOEhV+4lDSU= Received: from owa.sei.cmu.edu (tyranus.sei.cmu.edu [10.64.28.15]) by timber.sei.cmu.edu (8.13.8/8.13.8/1348) with ESMTP id p2VEiZ7F014091 for ; Thu, 31 Mar 2011 10:44:35 -0400 Received: from EXCHANGE.sei.cmu.edu ([10.64.28.13]) by tyranus.sei.cmu.edu ([10.64.28.15]) with mapi; Thu, 31 Mar 2011 10:44:35 -0400 From: Chris Inacio To: "ipfix@ietf.org" Date: Thu, 31 Mar 2011 10:44:34 -0400 Thread-Topic: some comments on IANA IPFIX XML Thread-Index: AcvvsieH3Sg7zs85R5WCp5kQc15aiA== Message-ID: <3D5C83BC-E710-44FB-8D18-66FD1BF75437@cert.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [IPFIX] some comments on IANA IPFIX XML X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 14:42:57 -0000 The way IANA specifies the IPFIX registry for IE's is a little twisted. First, I can't validate the XML. I can get the ipfix.xml and the ipfix.xsd= , but it is wrapped in "registry" elements, which are not described in ipfi= x.xsd (presumably they are defined somewhere in IANA for use across their r= egistries.) Another little nit about registries: There are 2 registries in the ipfix.x= ml. The first one describes the broad rules about IE's (0 is reserved, 1-= 127 is reserved for NetFlow v9 compatibility (with expert review), and 128-= 32767 are for new (with expert review)). The second one is a list of the I= E's. Registry elements _can_ contain created on and modified on dates. Un= fortunately, in the ipfix.xml file, the first registry entry does contain t= he created and modified on dates, while the second one (with the actual ele= ments) doesn't contain any created on/updated on time stamps. So they are = time stamping the wrong record in the official registry. It would be really great to wrap the record entries (defined in ipfix.xsd, = each record represents an IE,) within another record which records a PEN - = so that people can publish their PEN's in a standard way. The current record definition allows marking up an IE with a "status" field= . The possible entries for status are: current, deprecated, obsolete. It = would be really cool to also have "transitioned", and then a pointer to ano= ther registry. Along with that, I would want to time stamp the IE's separa= tely, and to put in a pointer to the transitioned to location. This would = allow me to put something wrapped in my PEN in a standard way, propose it t= o IANA, get it moved, and then reuse that IE number in my space in the futu= re. I would need to leave the record in my IE XML forever, assuming collec= tor operators might not delete the corresponding records "for a really long= time." Collectors would then be required to use the time stamps in the fl= ow records to resolve IE's correctly. Is that more complicated? Absolutel= y. But it does make IE's a lot more portable between everyone, and people = can then reuse IE's. Thoughts, comments? Chris From andrewf@plixer.com Thu Mar 31 08:03:01 2011 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0141A3A67FC for ; Thu, 31 Mar 2011 08:03:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_53=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SiS8VUMtEf6M for ; Thu, 31 Mar 2011 08:03:00 -0700 (PDT) Received: from smtp.plixer.com (smtp.plixer.com [66.186.184.193]) by core3.amsl.com (Postfix) with ESMTP id 3276428C0FA for ; Thu, 31 Mar 2011 08:03:00 -0700 (PDT) Received: from [10.1.15.20] ([66.186.184.173]) by smtp.plixer.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 31 Mar 2011 11:04:39 -0400 Message-ID: <4D949807.2000503@plixer.com> Date: Thu, 31 Mar 2011 11:04:39 -0400 From: Andrew Feren User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15pre) Gecko/20110207 Lightning/1.0b2 Shredder/3.1.9pre MIME-Version: 1.0 To: ipfix@ietf.org References: <3D5C83BC-E710-44FB-8D18-66FD1BF75437@cert.org> In-Reply-To: <3D5C83BC-E710-44FB-8D18-66FD1BF75437@cert.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Mar 2011 15:04:39.0370 (UTC) FILETIME=[F4FF12A0:01CBEFB4] Subject: Re: [IPFIX] some comments on IANA IPFIX XML X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 15:03:01 -0000 On 03/31/2011 10:44 AM, Chris Inacio wrote: > It would be really great to wrap the record entries (defined in ipfix.xsd, each record represents an IE,) within another record which records a PEN - so that people can publish their PEN's in a standard way. This would be great. A registry of all the info elements above 37,768 that have been taken by vendors trying to extend v9 would be nice too. On a related note... Is anyone implementing rfc5610? -Andrew From trammell@tik.ee.ethz.ch Thu Mar 31 09:39:25 2011 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE93F3A6A33 for ; Thu, 31 Mar 2011 09:39:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.556 X-Spam-Level: X-Spam-Status: No, score=-6.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2MCboym73mvL for ; Thu, 31 Mar 2011 09:39:24 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id 581B33A6844 for ; Thu, 31 Mar 2011 09:39:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 9CDABD9381; Thu, 31 Mar 2011 18:41:02 +0200 (MEST) 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 f3zZmiSObjoy; Thu, 31 Mar 2011 18:41:01 +0200 (MEST) Received: from dhcp-43c4.meeting.ietf.org (dhcp-43c4.meeting.ietf.org [130.129.67.196]) (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 21328D9360; Thu, 31 Mar 2011 18:41:01 +0200 (MEST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Brian Trammell In-Reply-To: <4D94481E.6080605@auckland.ac.nz> Date: Thu, 31 Mar 2011 18:40:58 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <745A438B-855F-4659-AB36-B11D6B95213B@tik.ee.ethz.ch> References: <4D94481E.6080605@auckland.ac.nz> To: Nevil Brownlee X-Mailer: Apple Mail (2.1082) Cc: IPFIX list Subject: Re: [IPFIX] DRAFT IPFIX minutes from IETF 80 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 16:39:25 -0000 Hi, Nevil, Minor comments, below. On Mar 31, 2011, at 11:23 AM, Nevil Brownlee wrote: >=20 > Hi all: >=20 > Here are my draft minutes for Tuesday's meeting; they include my > summary of the alternatives from our 'Draft Standards?' discussion. >=20 > Please send me any corrections, changes, etc as soon as possible. >=20 > Minutes of the IPFIX meeting at IETF 80 > About 36 people present > Scribes: Cyndi Mills & Nevil Brownlee >=20 > Nevil Brownlee presented current WG document status. Three documents > completed since IETF 79 (Export-per-SCTP-stream, Mediators Framework > and Anonymisation Support), one with IESG (Structured Data). We have > received comments on the IPFIX Configuration Model draft from the YANG > Doctors, and have been carefully considered. Juergen will do its > write-up. The PSAMP MIB has been revised to use the UnsiUnsigned64TC > and Float64TC Textual Conventions from other MIBs. Nevil will do its > write-up. The remaining work item, Flow Selection, is under review, > and will be discussed further on the IPFIX list. >=20 > Brian Trammell presented a report on the 'DEMONS IPFIX > Interoperability Test,' held in Prague, 24-25 March. This was the > fourth such event for IPFIX, with eight implementations (4 exporters, > 3 collectors) being tested. Interoperation was complete for UDP, > less so for TCP; for SCTP it was dependent on the SCTP > implementations used. Quite a few issues came to light (see the > slides), many were fixed during the event. > Several people commented on SCTP implementation issues, suggesting > that perhaps "template handling is needlessly complicated in the > (IPFIX) protocol." =20 The guidance regarding the complexity of template handling comes from = the fact that nobody implemented template withdrawal or template number = reuse, not from SCTP implementation issues. > Dan Romascanu (our AD) asked for an Interoperation > Report, Brian says he has one written as an Internet Draft. On review, the Internet-Draft format of what I have does not meet the = form or content of an Implementation Report. I'll do this, but will take = a bit longer. > Lothar Braun presented Recommendations for Implementing IPFIX over > DTLS/UDP. DTLS is mandatory for IPFIX over UDP and SCTP, but using > it is difficult because IPFIX traffic is unidirectional, but DTLS > requires shared state. Discussion centred on IPFIX's need for a > heartbeat to detect collector failures, and whether IPFIX should do > its own heartbeat. Lothar's recommendations could fit in a revision > of IPFIX Implementation Guidelines. >=20 > Juergen lead a discussion on whether we should work on moving some of > the IPFIX standards from Proposed to Draft. Dan explained that to > do so any changes would need to be editorial, not technical. There > was considerable discussion, the main points being: > 1. There are many errata for 5101 and 5102, it would be good to have a > new draft that does that, along with some more explanatory > (editorial) text where needed > 2. If we move 5101 and 5102 to Draft, any changes - however small - > would need to be a new version of the IPFIX protocol. Doing that > could lead to confusion among IPFIX implementors and users > 3. An alternative approach would be to work on a new draft (which > implemented small changes that did not affect interoperation, for > example adding detail where there are gaps in 5101) as a Standards > Track successor to 5101. Once that had been published as an RFC > for some time, we could work on moving it to Draft; that should be > possible in a reasonably short time. > 4. Other things that could be considered: IPFIX heartbeat provision > (we need to consider how long it will take TSVWG to complete the > DTLS Heartbeat Extension), change canonical transport to TCP, ... ? > 5. Another possibility is to make a new "all about IPFIX" document; > there was only weak consensus for this > The meeting reached consensus for (3, rather than 2), we will discuss > this further on the IPFIX list. >=20 > Five drafts were presented as candidates (in addition to the = 'Standards > upgrade') for an IPFIX re-chartering. >=20 > Brian Trammell presented 'IPFIX Intermediate Aggregation,' this drew > strong consensus as a new WG item. "Exporting Aggregated Flow Data with IPFIX", "the aggregation draft", or = simply "a9n". > Brian presented the 'IE Doctors' draft, pointing out that this draft > "lays out the ground rules for developing new IPFIX Information > Elements, and clarifies how the IE Registry process works." Michelle > Cotton (IANA) commented that other working groups, e.g. DNS, have > similar processes to those in this draft; we need to be clear about > whether we're proposing "approval by IE-Doctors," or changes to > "expert review" (which we have now). Dan commented that to set up a > team of IE Doctors, we need AD approval, and must keep IESG informed. > Paul Aitken asked (via jabber), whether an IE could be reviewed and > not made public until the product is shipped? Dan replied "we have a > body of experience to say that this should be an exception and not the > rule." There was clear consensus for adopting this as a WG item, > with one person expressing strong dissent. We will discuss this > further on the list - the issues here are > a. Should we develop an 'IE Guidelines' draft? > b. Do we want to have an 'IE Doctors' team (with IESG overview), > an expanded group of IE Expert reviewers, or what? >=20 > Benoit Claise presented the 'IPFIX Mediation protocol' draft, now at > version -03. There was clear consensus for adopting this. >=20 > Benoit presented 'Exporting MIB variables using IPFIX.' A spirited > discussion of how Odis should be referred to in the IPFIX protocol. > There was stronger consensus for this than against it. Again, > discussion of this will continue on the list. >=20 > Benoit presented 'Exporting Application Information,' prompting > considerable discussion. Steven Campbell commented that > "vendor-specific labels for layer-7 mapping is difficult. However, the > way to discover layer 7 (behavioral, DPI) could be standardized." > Benoit said he wasn't proposing this as a WG item, however anyone > interested should continue discussing this topic on the list. >=20 > The meeting finished at 1459. >=20 > --=20 > --------------------------------------------------------------------- > Nevil Brownlee Computer Science Department | ITS > Phone: +64 9 373 7599 x88941 The University of Auckland > FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand >=20 > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From trammell@tik.ee.ethz.ch Thu Mar 31 10:13:58 2011 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3AE383A6A79 for ; Thu, 31 Mar 2011 10:13:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.262 X-Spam-Level: X-Spam-Status: No, score=-6.262 tagged_above=-999 required=5 tests=[AWL=-0.263, BAYES_00=-2.599, J_CHICKENPOX_53=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2hVxbxDm+02X for ; Thu, 31 Mar 2011 10:13:57 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id 0BFEF3A6A63 for ; Thu, 31 Mar 2011 10:13:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id C440DD934F; Thu, 31 Mar 2011 19:15:35 +0200 (MEST) 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 9MFifI6OaBiq; Thu, 31 Mar 2011 19:15:35 +0200 (MEST) Received: from dhcp-43c4.meeting.ietf.org (dhcp-43c4.meeting.ietf.org [130.129.67.196]) (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 6D129D9327; Thu, 31 Mar 2011 19:15:35 +0200 (MEST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Brian Trammell In-Reply-To: <4D949807.2000503@plixer.com> Date: Thu, 31 Mar 2011 19:15:34 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <31D0F166-112B-4BD4-98F7-7AE09BE2F4FE@tik.ee.ethz.ch> References: <3D5C83BC-E710-44FB-8D18-66FD1BF75437@cert.org> <4D949807.2000503@plixer.com> To: Andrew Feren X-Mailer: Apple Mail (2.1082) Cc: ipfix@ietf.org Subject: Re: [IPFIX] some comments on IANA IPFIX XML X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 17:13:58 -0000 hi, Andrew, all, On Mar 31, 2011, at 5:04 PM, Andrew Feren wrote: > On 03/31/2011 10:44 AM, Chris Inacio wrote: >> It would be really great to wrap the record entries (defined in = ipfix.xsd, each record represents an IE,) within another record which = records a PEN - so that people can publish their PEN's in a standard = way. > This would be great. A registry of all the info elements above 37,768 = that have been taken by vendors trying to extend v9 would be nice too. It's up to each enterprise, of course, to determine which, whether, and = how to make information about their enterprise-specific IEs (esIEs) = available. I know that YAF's IEs (including esIEs) exported in PEN 6871 = are documented on a manpage = (http://tools.netsa.cert.org/yaf/yaf.html#OUTPUT), for example. FWIW, IANA's schema does have an element for describing = esIEs. Though the xsl that makes their webpage doesn't appear to use it. > On a related note... Is anyone implementing rfc5610? There will be scantily-documented initial support for this in the = working revision of ripfix, which requires some API interaction to make = it work. I'll release this as soon as I track down the last bugs in UDP = export. > -Andrew > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From inacio@cert.org Thu Mar 31 10:39:06 2011 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9E333A6B38 for ; Thu, 31 Mar 2011 10:39:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_53=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wpxIHlBjjFk6 for ; Thu, 31 Mar 2011 10:39:05 -0700 (PDT) Received: from shetland.sei.cmu.edu (shetland.sei.cmu.edu [192.58.107.44]) by core3.amsl.com (Postfix) with ESMTP id BB5453A6A33 for ; Thu, 31 Mar 2011 10:39:05 -0700 (PDT) Received: from timber.sei.cmu.edu (timber.sei.cmu.edu [10.64.21.23]) by shetland.sei.cmu.edu (8.13.8/8.13.8/1294) with ESMTP id p2VHeiLC003581; Thu, 31 Mar 2011 13:40:44 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1301593244; bh=nxcqmMH2e0f0Na8/nqzImUaBzztbF4rZBwEc39PtaAY=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version:Sender: Reply-To; b=colyiulBKLbn805dg0H+yvcmc9y5OHLBzqHNM79aSbLcHU5uRBDD1HOfXU0/jaJAD jIRiBJuMqYmDcaDeKgiERikKoNjfAlpEAUp6wm43Ut7eiLO/xiS7wihPJp2f8j3cO3 wm5idqxxsa4mVoUJJP/2WBVso64VXlOCPjVd1kVg= Received: from owa.sei.cmu.edu (tyranus.sei.cmu.edu [10.64.28.15]) by timber.sei.cmu.edu (8.13.8/8.13.8/1348) with ESMTP id p2VHeiPo000369; Thu, 31 Mar 2011 13:40:44 -0400 Received: from EXCHANGE.sei.cmu.edu ([10.64.28.13]) by tyranus.sei.cmu.edu ([10.64.28.15]) with mapi; Thu, 31 Mar 2011 13:40:43 -0400 From: Chris Inacio To: Brian Trammell , Andrew Feren Date: Thu, 31 Mar 2011 13:36:51 -0400 Thread-Topic: [IPFIX] some comments on IANA IPFIX XML Thread-Index: Acvvx0aAi/50e5VAQvKY1JN+P1P11AAAvFLU Message-ID: References: <3D5C83BC-E710-44FB-8D18-66FD1BF75437@cert.org> <4D949807.2000503@plixer.com>, <31D0F166-112B-4BD4-98F7-7AE09BE2F4FE@tik.ee.ethz.ch> In-Reply-To: <31D0F166-112B-4BD4-98F7-7AE09BE2F4FE@tik.ee.ethz.ch> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] some comments on IANA IPFIX XML X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 17:39:07 -0000 ________________________________________ From: ipfix-bounces@ietf.org [ipfix-bounces@ietf.org] On Behalf Of Brian Tr= ammell [trammell@tik.ee.ethz.ch] Sent: Thursday, March 31, 2011 1:15 PM To: Andrew Feren Cc: ipfix@ietf.org Subject: Re: [IPFIX] some comments on IANA IPFIX XML hi, Andrew, all, On Mar 31, 2011, at 5:04 PM, Andrew Feren wrote: > On 03/31/2011 10:44 AM, Chris Inacio wrote: >> It would be really great to wrap the record entries (defined in ipfix.xs= d, each record represents an IE,) within another record which records a PEN= - so that people can publish their PEN's in a standard way. > This would be great. A registry of all the info elements above 37,768 th= at have been taken by vendors trying to extend v9 would be nice too. It's up to each enterprise, of course, to determine which, whether, and how= to make information about their enterprise-specific IEs (esIEs) available.= I know that YAF's IEs (including esIEs) exported in PEN 6871 are documente= d on a manpage (http://tools.netsa.cert.org/yaf/yaf.html#OUTPUT), for examp= le. FWIW, IANA's schema does have an element for describing esIE= s. Though the xsl that makes their webpage doesn't appear to use it. > On a related note... Is anyone implementing rfc5610? There will be scantily-documented initial support for this in the working r= evision of ripfix, which requires some API interaction to make it work. I'l= l release this as soon as I track down the last bugs in UDP export. I'm not sure I'm willing to commit to adding 5610 support, because I'm not = sure if it solves problems. (I know it doesn't solve any problems for me, = but that's not shocking, I build my own EP & CP - but at least I give them = away :) ) That said though, it's not clear to me how to use the 5610 data to be able = to restructure my backend storage on the fly. I mean it's nice to have, bu= t if I've been operating my CP for 6 months, and then I get these 5610 mess= ages, I don't see a model currently where I can reconfigure my storage engi= ne (whatever that may be) to adapt. If you have a slower collection rate, = and want to display the data, or normalize to some other defined format (to= a SIEM or something) then I can see the use. So maybe I should implement = it to support mediators? > -Andrew > _______________________________________________ > 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 muenz@net.in.tum.de Thu Mar 31 12:57:16 2011 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B93D928C101 for ; Thu, 31 Mar 2011 12:57:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pLeElooF-9k1 for ; Thu, 31 Mar 2011 12:57:16 -0700 (PDT) Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) by core3.amsl.com (Postfix) with ESMTP id 1E32328C0FB for ; Thu, 31 Mar 2011 12:57:15 -0700 (PDT) Received: from [192.168.1.151] (ppp-88-217-22-180.dynamic.mnet-online.de [88.217.22.180]) by mail.net.in.tum.de (Postfix) with ESMTPSA id 21603210FF8A; Thu, 31 Mar 2011 21:58:46 +0200 (CEST) Message-ID: <4D94DCCB.7090304@net.in.tum.de> Date: Thu, 31 Mar 2011 21:58:03 +0200 From: Gerhard Muenz User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Brian Trammell References: <4D94481E.6080605@auckland.ac.nz> <745A438B-855F-4659-AB36-B11D6B95213B@tik.ee.ethz.ch> In-Reply-To: <745A438B-855F-4659-AB36-B11D6B95213B@tik.ee.ethz.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPFIX list Subject: Re: [IPFIX] DRAFT IPFIX minutes from IETF 80 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 19:57:16 -0000 Brian, >> Brian Trammell presented a report on the 'DEMONS IPFIX >> Interoperability Test,' held in Prague, 24-25 March. This was the >> fourth such event for IPFIX, with eight implementations (4 >> exporters, 3 collectors) being tested. Interoperation was complete >> for UDP, less so for TCP; for SCTP it was dependent on the SCTP >> implementations used. Quite a few issues came to light (see the >> slides), many were fixed during the event. Several people commented >> on SCTP implementation issues, suggesting that perhaps "template >> handling is needlessly complicated in the (IPFIX) protocol." > > The guidance regarding the complexity of template handling comes from > the fact that nobody implemented template withdrawal or template > number reuse, not from SCTP implementation issues. That does not seem to be true. Vermont sends Template withdrawal messages and reuses Template IDs if you trigger an appropriate reconfiguration at runtime. Maybe this was just not tested at the interop event. Regards, Gerhard From bclaise@cisco.com Thu Mar 31 14:38:55 2011 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD88728C10C for ; Thu, 31 Mar 2011 14:38:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.623 X-Spam-Level: X-Spam-Status: No, score=-2.623 tagged_above=-999 required=5 tests=[AWL=-0.024, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I1nfWxL9vgHk for ; Thu, 31 Mar 2011 14:38:54 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 94CC428C0EC for ; Thu, 31 Mar 2011 14:38:53 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p2VLeWvT027086; Thu, 31 Mar 2011 23:40:32 +0200 (CEST) Received: from [10.55.84.187] (dhcp-10-55-84-187.cisco.com [10.55.84.187]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p2VLeVdl024749; Thu, 31 Mar 2011 23:40:31 +0200 (CEST) Message-ID: <4D94F4CE.70509@cisco.com> Date: Thu, 31 Mar 2011 23:40:30 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Lothar Braun References: <4D94481E.6080605@auckland.ac.nz> <48D83410-4F22-4B90-9BE2-C7CB9DC3189B@net.in.tum.de> In-Reply-To: <48D83410-4F22-4B90-9BE2-C7CB9DC3189B@net.in.tum.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: IPFIX list Subject: Re: [IPFIX] DRAFT IPFIX minutes from IETF 80 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 21:38:55 -0000 Hi Lothar, > Hi, > > On Mar 31, 2011, at 11:23 AM, Nevil Brownlee wrote: >> Hi all: >> >> Here are my draft minutes for Tuesday's meeting; they include my >> summary of the alternatives from our 'Draft Standards?' discussion. >> >> Please send me any corrections, changes, etc as soon as possible. >> >> Minutes of the IPFIX meeting at IETF 80 >> About 36 people present >> Scribes: Cyndi Mills& Nevil Brownlee >> >> Nevil Brownlee presented current WG document status. Three documents >> completed since IETF 79 (Export-per-SCTP-stream, Mediators Framework >> and Anonymisation Support), one with IESG (Structured Data). We have >> received comments on the IPFIX Configuration Model draft from the YANG >> Doctors, and have been carefully considered. Juergen will do its >> write-up. The PSAMP MIB has been revised to use the UnsiUnsigned64TC >> and Float64TC Textual Conventions from other MIBs. Nevil will do its >> write-up. The remaining work item, Flow Selection, is under review, >> and will be discussed further on the IPFIX list. >> >> Brian Trammell presented a report on the 'DEMONS IPFIX >> Interoperability Test,' held in Prague, 24-25 March. This was the >> fourth such event for IPFIX, with eight implementations (4 exporters, >> 3 collectors) being tested. Interoperation was complete for UDP, >> less so for TCP; for SCTP it was dependent on the SCTP >> implementations used. Quite a few issues came to light (see the >> slides), many were fixed during the event. >> Several people commented on SCTP implementation issues, suggesting >> that perhaps "template handling is needlessly complicated in the >> (IPFIX) protocol." Dan Romascanu (our AD) asked for an Interoperation >> Report, Brian says he has one written as an Internet Draft. >> >> Lothar Braun presented Recommendations for Implementing IPFIX over >> DTLS/UDP. DTLS is mandatory for IPFIX over UDP and SCTP, but using >> it is difficult because IPFIX traffic is unidirectional, but DTLS >> requires shared state. Discussion centred on IPFIX's need for a >> heartbeat to detect collector failures, and whether IPFIX should do >> its own heartbeat. Lothar's recommendations could fit in a revision >> of IPFIX Implementation Guidelines. >> >> Juergen lead a discussion on whether we should work on moving some of >> the IPFIX standards from Proposed to Draft. Dan explained that to >> do so any changes would need to be editorial, not technical. There >> was considerable discussion, the main points being: >> 1. There are many errata for 5101 and 5102, it would be good to have a >> new draft that does that, along with some more explanatory >> (editorial) text where needed >> 2. If we move 5101 and 5102 to Draft, any changes - however small - >> would need to be a new version of the IPFIX protocol. Doing that >> could lead to confusion among IPFIX implementors and users >> 3. An alternative approach would be to work on a new draft (which >> implemented small changes that did not affect interoperation, for >> example adding detail where there are gaps in 5101) as a Standards >> Track successor to 5101. Once that had been published as an RFC >> for some time, we could work on moving it to Draft; that should be >> possible in a reasonably short time. >> 4. Other things that could be considered: IPFIX heartbeat provision >> (we need to consider how long it will take TSVWG to complete the >> DTLS Heartbeat Extension), change canonical transport to TCP, ... ? > I've been to the TLS WG meeting Any update on draft-ietf-tsvwg-sctp-strrst-09.txt? Regards, Benoit. > and checked upon the status and future plans of the DTLS heartbeat draft. The draft has been adopted as a working group document quite some time ago, which I completely missed. > > TLS chairs were confident that it would not take very long to move it to PS. > According to them, the document is in quite good shape, and could soon progress to WGLC after a review from the transport area has been received. > >> 5. Another possibility is to make a new "all about IPFIX" document; >> there was only weak consensus for this >> The meeting reached consensus for (3, rather than 2), we will discuss >> this further on the IPFIX list. >> >> Five drafts were presented as candidates (in addition to the 'Standards >> upgrade') for an IPFIX re-chartering. >> >> Brian Trammell presented 'IPFIX Intermediate Aggregation,' this drew >> strong consensus as a new WG item. >> >> Brian presented the 'IE Doctors' draft, pointing out that this draft >> "lays out the ground rules for developing new IPFIX Information >> Elements, and clarifies how the IE Registry process works." Michelle >> Cotton (IANA) commented that other working groups, e.g. DNS, have >> similar processes to those in this draft; we need to be clear about >> whether we're proposing "approval by IE-Doctors," or changes to >> "expert review" (which we have now). Dan commented that to set up a >> team of IE Doctors, we need AD approval, and must keep IESG informed. >> Paul Aitken asked (via jabber), whether an IE could be reviewed and >> not made public until the product is shipped? Dan replied "we have a >> body of experience to say that this should be an exception and not the >> rule." There was clear consensus for adopting this as a WG item, >> with one person expressing strong dissent. We will discuss this >> further on the list - the issues here are >> a. Should we develop an 'IE Guidelines' draft? >> b. Do we want to have an 'IE Doctors' team (with IESG overview), >> an expanded group of IE Expert reviewers, or what? >> >> Benoit Claise presented the 'IPFIX Mediation protocol' draft, now at >> version -03. There was clear consensus for adopting this. >> >> Benoit presented 'Exporting MIB variables using IPFIX.' A spirited >> discussion of how Odis should be referred to in the IPFIX protocol. >> There was stronger consensus for this than against it. Again, >> discussion of this will continue on the list. >> >> Benoit presented 'Exporting Application Information,' prompting >> considerable discussion. Steven Campbell commented that >> "vendor-specific labels for layer-7 mapping is difficult. However, the >> way to discover layer 7 (behavioral, DPI) could be standardized." >> Benoit said he wasn't proposing this as a WG item, however anyone >> interested should continue discussing this topic on the list. >> >> The meeting finished at 1459. >> >> -- >> --------------------------------------------------------------------- >> Nevil Brownlee Computer Science Department | ITS >> Phone: +64 9 373 7599 x88941 The University of Auckland >> FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand >> >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix > -- > Lothar Braun > Chair for Network Architectures and Services (I8) > Department of Informatics > Technische Universität München > Boltzmannstr. 3, 85748 Garching bei München, Germany > Phone: +49 89 289-18010 Fax: +49 89 289-18033 > E-mail: braun@net.in.tum.de > > > > > > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix