From j.schoenwaelder@jacobs-university.de Sun Nov 3 11:00:35 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96ACA21E8092 for ; Sun, 3 Nov 2013 11:00:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.071 X-Spam-Level: X-Spam-Status: No, score=-102.071 tagged_above=-999 required=5 tests=[AWL=-1.122, BAYES_00=-2.599, HELO_EQ_DE=0.35, MANGLED_LOAN=2.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mHZhjUCyRRcn for ; Sun, 3 Nov 2013 11:00:29 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id B9D8921F9DD6 for ; Sun, 3 Nov 2013 11:00:24 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id DD7532006F; Sun, 3 Nov 2013 20:00:23 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id vXKaqnr6mPHU; Sun, 3 Nov 2013 20:00:23 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5404F2004F; Sun, 3 Nov 2013 20:00:23 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id BE66B2927C23; Sun, 3 Nov 2013 20:00:17 +0100 (CET) Date: Sun, 3 Nov 2013 20:00:17 +0100 From: Juergen Schoenwaelder To: ipfix@ietf.org Message-ID: <20131103190017.GA74417@elstar.local> Mail-Followup-To: ipfix@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [IPFIX] js review of draft-ietf-ipfix-mib-variable-export-03 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Nov 2013 19:00:35 -0000 Hi, there was no time before the I-D cutoff to review the -03 version and hence I am sending my comments straight to the list (even though I am likely the one to act on some of them). But this may be useful input for the WG meeting later this week. /js - You can't write 'indexed MIBs' or 'indexed MIB object. You probably mean 'columnar objects'? This is the term used in RFC 2578. We should in general check that this document uses RFC 2578 terms. I am also not sure about the usage of phrases such as "MIB Indexing". I guess I have to go through the doc and carefully mark all phrases that may need rewriting. (A phrase like 'the MIB' does not work either, it is the MIB module but often you really mean the object definition in RFC 2578 sense.) - The I-D talks about a number of new information elements that are defined later and initially when you read from the beginning, the solution remains relatively unclear for quite some time. What is missing is perhaps a simple right at the beginning that makes things clear for the reader. - In the enumeration in section 5.2, I suggest to inline the explanations rather than having the explanation below. - Figure 4 helps getting an overview (but perhaps a bit late). But you seem to make the assumption that there is a fixed # of mibObjectValues mapping to the same fixed number of mibFieldOptions. This may be fine - I am just noting this (and if correct it might be good to spell it out). - What about ordering requirements? I assume no lexicographic ordering needed when MIB data is moved via IPFIX? - What about instead using mibObjectValue you use mibObjectValue (mibObjectValueCounter32, mibObjectValueCounter64, ...)? Since there is a limited number of base types, you can also benefit from knowing the length in many cases without having to have the corresponding mibFieldOption. But then, if you need a mibFieldOption anyway, the current design makes sense. - I have trouble to understand Figure 6 and Figure 7. - I do not fully understand mibIndexList in section 5.3.5. I assume Figure 10 is a Data Record? Should the caption be "Format of a mibFieldOption Data Record for a Columnar Object"? But even then, I think there should have been a corresponding template record example before. Oh no, this is an option template for a columnar object. So the caption should be "MIB Field Option Template Format for a Columnar Object". - I think mibName should be renamed to mibModuleName. - Should the mibContextIdentifier not go into mibFieldOption Template? If so, should the text in 5.4 be more specific? - Second paragraph in section 6.1 I think is not needed. - It seems the example in 6.1 does not match the new templates etc?? - Is section 6.3 really needed? The only important sentence is this: This example stresses that, even though the OID cpmCPUTotal1minRev is enterprise-specific, the E bit for the mibObjectValue and mibObjectIdentifier is set to "0" since the "mibObjectValue" and "mibObjectIdentifier" Information Element is not enterprise-specific. This should be generalized and written down where the normative text is of the mibObjectValue and mibObjectIdentifier definitions, e.g. The E bit of the mibObjectValue or mibObjectIdentifier Information Elements is set to "0" since they are not enterprise-specific. This holds true even if the data carried inside the mibObjectValue or mibObjectIdentifier may be enterprise specific. - Section 6.4 talks about multiple indexes. This is confusing. RFC 2578 calls this indexed by multiple objects. I do not know how to read "index 2 is not an index of index 1". - Is Figure 22 a "Options Template Set"? I expected this to be a Template Set... - Should ipIfStatsIPVersion not be InetVersion in Figure 24? - I have not fully understood the mibIndexList - the example in 6.4 did not fully help either. - Am I correct that the example in 6.4 is supposed to show the value of ipIfStatsInForwDatagrams (10000 and 20000) for ip4 and ip6 on interface 10? If so, note that InetVersion encodes IPv4 using '1' and IPv6 using '2'. In any case, showing how a data record is encoded is very useful but requires some textual explanation. - Section 6.6. has not been updated? Otherwise, I do not understand what mibIndexString is here. I assume this is outdated text. I guess the same applies to section 6.8. - Why do we talk about IPFIX transports in section 8? All this should be pretty agnostic to the choice of the transport, no? - I think there needs to be some more explicit text saying that the security administrator must make sure that IPFIX export of MIB objects does not cause a hole into the SNMP access control configuration. (Some SNMP hardliners might even say that IPFIX should access data through the SNMP access control subsystem, in which case there would need to be proper parameters such as a (securityName, securityModel, securityLevel) tuple... - Section 11.2 says "the MIB OID" which is ambiguous at best. It should probably be "the OID of a MIB object" or even better "the OID assigned to the MIB object definition". - Is it really useful to encode OIDs as strings? SNMP uses a binary BER encoding which is more compact (but less human readable). - Do we still need mibIndexString? Is this just an additional add-on? - Section 11.2.5: Description of mibObjectName: RFC 2578 calls this a descriptor. Perhaps use this text: The name (called a descriptor in RFC 2578) of an object type definition. - Section 11.2.6 Description of mibObjectDescription. Perhaps use this text: The value of the DESCRIPTION clause of an object type definition. - Section 11.2.7: This should be SMIv2 (a superset of SMIv1). Since you include Integer32 and Gauge32, do you expect that type to be reported that SNMP uses on the wire or the type that is acting as a base type in a MIB object definition? In a MIB module, I can define something to use Integer32, on the wire it is always INTEGER. Same for Gauge32. - Section 11.2.8: Are you talking about using the content of the SYNTAX clause of an object type definition or a subset of it? Note that the SYNTAX clause may contain refinements and enumerations. - Section 11.2.10: An SNMP context is a type of a contextEngineID and a contextName. See section 3.3 of RFC 3411. What exactly does the mibContextIdentifier contain? Note that the contextName defaults to an empty string for the common case of the default context. To follow the SNMP architecture correctly, you would still have to explain which contextEngineID your data belongs to. - Section 11.2.11: As said before, this should be called mibModuleName and the description should be "The name of an SMIv2 MIB module". /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Sun Nov 3 11:05:23 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A16021E80C4 for ; Sun, 3 Nov 2013 11:05:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.891 X-Spam-Level: X-Spam-Status: No, score=-102.891 tagged_above=-999 required=5 tests=[AWL=-0.242, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ulbeMqxKiXzK for ; Sun, 3 Nov 2013 11:05:18 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 1890721E8092 for ; Sun, 3 Nov 2013 11:05:16 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5EAD32006F; Sun, 3 Nov 2013 20:05:15 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id QqUoCjCFKSvK; Sun, 3 Nov 2013 20:05:15 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D9AE820077; Sun, 3 Nov 2013 20:05:14 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 0DBDA2927C79; Sun, 3 Nov 2013 20:05:10 +0100 (CET) Date: Sun, 3 Nov 2013 20:05:10 +0100 From: Juergen Schoenwaelder To: Brian Trammell Message-ID: <20131103190509.GB74417@elstar.local> Mail-Followup-To: Brian Trammell , IPFIX Working Group References: <52732439.50206@tik.ee.ethz.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52732439.50206@tik.ee.ethz.ch> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: IPFIX Working Group Subject: Re: [IPFIX] Initial review of draft-ietf-ipfix-mib-variable-export-03 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Nov 2013 19:05:23 -0000 On Fri, Nov 01, 2013 at 04:47:05AM +0100, Brian Trammell wrote: > > (3) Clarifying and SNMP-naif question on 11.2.2 mibObjectIdentifier: it > seems from the examples that the intention is that the OID will be > encoded in the document as a Unicode string of digits and "." > characters? Is this the way OIDs are encoded in SNMP? The encoding of > fundamentally binary data in strings is not very IPFIXish (7013 section > 4.2 para 6), and I kind of expected these to be encoded as octetarrays > of unsigned integers of a specified size, or something similar. However, > if encoding-as-string is how things are done on the wire in SNMP, it's > the right thing to do here too (7013 section 4.5). The same comment > applies to 11.2.4. > SNMP uses ASN.1/BER and this gives you are much more compact encoding of OIDs (but this is of course a much less human/programmer friendly representation). > IpAddress -> ipv4Address (side question: how do you do V6 with SNMP?) The IPv6 address types are an OCTET STRING on the wire (not a tagged type anymore). > (7) In 11.2.10 mibContextIdentifier: is a context identifier similar to > an object identifier? Then it should be defined similar to 11.2.2 -- it > doesn't need a new ADT. No, an SNMP context is actually a more complex thing, namely a tuple of an snmpContextEngineID and an snmpContextName. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From andrewf@plixer.com Sun Nov 3 16:15:14 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1695B11E825D for ; Sun, 3 Nov 2013 16:15:14 -0800 (PST) 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_37=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dt2Sl+2AWoiH for ; Sun, 3 Nov 2013 16:15:08 -0800 (PST) Received: from mx1.plixer.com (mx1.plixer.com [64.140.243.154]) by ietfa.amsl.com (Postfix) with ESMTP id E8C5711E825C for ; Sun, 3 Nov 2013 16:14:56 -0800 (PST) Received: from [31.133.176.195] (31.133.176.195) by mx1.plixer.com (10.1.5.1) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sun, 3 Nov 2013 19:14:55 -0500 Message-ID: <5276E6FD.2080306@plixer.com> Date: Sun, 3 Nov 2013 16:14:53 -0800 From: Andrew Feren User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: References: <52732439.50206@tik.ee.ethz.ch> <20131103190509.GB74417@elstar.local> In-Reply-To: <20131103190509.GB74417@elstar.local> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Subject: Re: [IPFIX] Initial review of draft-ietf-ipfix-mib-variable-export-03 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 00:15:14 -0000 On 11/03/2013 11:05 AM, Juergen Schoenwaelder wrote: > On Fri, Nov 01, 2013 at 04:47:05AM +0100, Brian Trammell wrote: >> (3) Clarifying and SNMP-naif question on 11.2.2 mibObjectIdentifier: it >> seems from the examples that the intention is that the OID will be >> encoded in the document as a Unicode string of digits and "." >> characters? Is this the way OIDs are encoded in SNMP? The encoding of >> fundamentally binary data in strings is not very IPFIXish (7013 section >> 4.2 para 6), and I kind of expected these to be encoded as octetarrays >> of unsigned integers of a specified size, or something similar. However, >> if encoding-as-string is how things are done on the wire in SNMP, it's >> the right thing to do here too (7013 section 4.5). The same comment >> applies to 11.2.4. >> > SNMP uses ASN.1/BER and this gives you are much more compact encoding > of OIDs (but this is of course a much less human/programmer friendly > representation). So, would a simple octetArray like Brian asked about make sense? I'm still not sure. >> IpAddress -> ipv4Address (side question: how do you do V6 with SNMP?) > The IPv6 address types are an OCTET STRING on the wire (not a tagged > type anymore). I've occasionally wondered if an ipAddress type (varlen 4 or 16 octets) would be useful in IPFIX. -Andrew From j.schoenwaelder@jacobs-university.de Sun Nov 3 17:12:59 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F42021E809D for ; Sun, 3 Nov 2013 17:12:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.885 X-Spam-Level: X-Spam-Status: No, score=-102.885 tagged_above=-999 required=5 tests=[AWL=-0.236, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uHMbTCmjzc1U for ; Sun, 3 Nov 2013 17:12:54 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 89ED721E8120 for ; Sun, 3 Nov 2013 17:12:52 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id E756920075; Mon, 4 Nov 2013 02:12:49 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id VnzgC-0SO6WF; Mon, 4 Nov 2013 02:12:49 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9C3792006F; Mon, 4 Nov 2013 02:12:44 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 271032928691; Mon, 4 Nov 2013 02:12:38 +0100 (CET) Date: Mon, 4 Nov 2013 02:12:38 +0100 From: Juergen Schoenwaelder To: Andrew Feren Message-ID: <20131104011238.GA75287@elstar.local> Mail-Followup-To: Andrew Feren , ipfix@ietf.org References: <52732439.50206@tik.ee.ethz.ch> <20131103190509.GB74417@elstar.local> <5276E6FD.2080306@plixer.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5276E6FD.2080306@plixer.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: ipfix@ietf.org Subject: Re: [IPFIX] Initial review of draft-ietf-ipfix-mib-variable-export-03 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 01:12:59 -0000 On Sun, Nov 03, 2013 at 04:14:53PM -0800, Andrew Feren wrote: > On 11/03/2013 11:05 AM, Juergen Schoenwaelder wrote: > > On Fri, Nov 01, 2013 at 04:47:05AM +0100, Brian Trammell wrote: > >> (3) Clarifying and SNMP-naif question on 11.2.2 mibObjectIdentifier: it > >> seems from the examples that the intention is that the OID will be > >> encoded in the document as a Unicode string of digits and "." > >> characters? Is this the way OIDs are encoded in SNMP? The encoding of > >> fundamentally binary data in strings is not very IPFIXish (7013 section > >> 4.2 para 6), and I kind of expected these to be encoded as octetarrays > >> of unsigned integers of a specified size, or something similar. However, > >> if encoding-as-string is how things are done on the wire in SNMP, it's > >> the right thing to do here too (7013 section 4.5). The same comment > >> applies to 11.2.4. > >> > > SNMP uses ASN.1/BER and this gives you are much more compact encoding > > of OIDs (but this is of course a much less human/programmer friendly > > representation). > > So, would a simple octetArray like Brian asked about make sense? I'm > still not sure. Not sure exactly what Brian proposed but a sub-identifier can be up to 32-bit long. > >> IpAddress -> ipv4Address (side question: how do you do V6 with SNMP?) > > The IPv6 address types are an OCTET STRING on the wire (not a tagged > > type anymore). > > I've occasionally wondered if an ipAddress type (varlen 4 or 16 octets) > would be useful in IPFIX. Maybe it is but surely this is not how SNMP represents data; the InetAddress textual convention actually can carry zone indexes and hence the assumption 4 or 16 octets may not hold true in general. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From paitken@cisco.com Mon Nov 4 03:36:43 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 058E411E8104 for ; Mon, 4 Nov 2013 03:36:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.949 X-Spam-Level: X-Spam-Status: No, score=-8.949 tagged_above=-999 required=5 tests=[AWL=1.650, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PmQZYxScshns for ; Mon, 4 Nov 2013 03:36:37 -0800 (PST) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id E184F11E8133 for ; Mon, 4 Nov 2013 03:36:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=378; q=dns/txt; s=iport; t=1383564995; x=1384774595; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=PoIHif9KesBHsy/j8e1XpQ3TSN5mcKCADf1rBFteKjA=; b=cz1KkMYnBnkVDVZnxC/3StCALqIvc7mdwts/r+AobQMBy9tr7gJK5Dd8 m/2XQb/KftKlOEwcd7MTRIR9ZgY24rVUmrW5zxI0ayijwCnH2CcHLI0gr sM+syD1FNEOqrbNdgKmfYuCSdVitFDklnEYhV27XTf3t5bBRDiq2atF1X s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAISFd1KQ/khM/2dsb2JhbABZDoJ5wD4KgSYWdIIlAQEBAwE4QAEFCwsOExYPCQMCAQIBRQYBDAEHAQGHdwa+HY9YB4QuA5gKhj2LTIJnPw X-IronPort-AV: E=Sophos;i="4.93,631,1378857600"; d="scan'208";a="19235403" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-4.cisco.com with ESMTP; 04 Nov 2013 11:36:34 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id rA4BaR5b016682 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Nov 2013 11:36:29 GMT Received: from [10.61.97.243] (dhcp-10-61-97-243.cisco.com [10.61.97.243]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id rA4BaHjq025890; Mon, 4 Nov 2013 11:36:23 GMT Message-ID: <527786AC.5060503@cisco.com> Date: Mon, 04 Nov 2013 11:36:12 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Nevil Brownlee , IPFIX Working Group References: <52708AA1.3060107@auckland.ac.nz> In-Reply-To: <52708AA1.3060107@auckland.ac.nz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ipfix-ads@tools.ietf.org" , "ipfix-chairs@tools.ietf.org" Subject: Re: [IPFIX] IETF-88 (Vancouver) agenda X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 11:36:43 -0000 Nevil, > Since 18 October, when I sent out the agenda for the IPFIX session in > Vancouver, no-one has asked for any agenda changes. I just found that the WG meeting is scheduled for 5.30 - 6.30pm this Thursday. That's 1.30 - 2.30am here, and 2.30 - 3.30am in Europe where most of the WG attendees are based. I object! That's a ridiculous meeting time. P. From internet-drafts@ietf.org Mon Nov 4 05:07:32 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1411921E8168; Mon, 4 Nov 2013 05:07:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.568 X-Spam-Level: X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b0jR9H6OxZgR; Mon, 4 Nov 2013 05:07:31 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EE6011E81C3; Mon, 4 Nov 2013 05:07:18 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.82 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131104130718.10097.9955.idtracker@ietfa.amsl.com> Date: Mon, 04 Nov 2013 05:07:18 -0800 Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action: draft-ietf-ipfix-data-link-layer-monitoring-07.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 13:07:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IP Flow Information Export Working Group = of the IETF. Title : Information Elements for Data Link Layer Traffic Measure= ment Author(s) : Shingo Kashima Atsushi Kobayashi Paul Aitken Filename : draft-ietf-ipfix-data-link-layer-monitoring-07.txt Pages : 34 Date : 2013-11-04 Abstract: This document describes Information Elements related to the data link layer. They are used by the IP Flow Information Export (IPFIX) protocol for encoding measured data link layer traffic information. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipfix-data-link-layer-monitoring There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ipfix-data-link-layer-monitoring-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipfix-data-link-layer-monitor= ing-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From paitken@cisco.com Mon Nov 4 05:28:52 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0F4411E81C3 for ; Mon, 4 Nov 2013 05:28:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.361 X-Spam-Level: X-Spam-Status: No, score=-9.361 tagged_above=-999 required=5 tests=[AWL=1.237, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zodyswycZZjC for ; Mon, 4 Nov 2013 05:28:47 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 2A54411E81DA for ; Mon, 4 Nov 2013 05:28:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8184; q=dns/txt; s=iport; t=1383571725; x=1384781325; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=KdxM9AQfRTUCi91H8j8A3azJICoQ4tgHkeFelJD5XeI=; b=NtGqXUhTZBHO2IdxYbr8XKz9Z+wUPJC1y34nFuWm6PDaVbgvyyzy2KOm U05xl7AJxyIYHOFwtGCC1kCRPgSyyxSlACkO/N33R0GoGn/cJBLKh/HBi nHfXJZWcFv6awiddjkU7MaDUFIhF+YEBcBdJFS7LD3BlFccZPX2JiNqMS E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFAH6fd1KQ/khR/2dsb2JhbABZgwc4iTi2WIEnFnSCJQEBAQQBAQFrCgEQCxgJFg8JAwIBAgEVMBMBBQIBAQWHeA2+F49YBwmEJQOYCoEvhQ6LTIMm X-IronPort-AV: E=Sophos;i="4.93,632,1378857600"; d="scan'208,217";a="161365897" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 04 Nov 2013 13:28:42 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id rA4DSbWb011770 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Nov 2013 13:28:38 GMT Received: from [10.61.97.243] (dhcp-10-61-97-243.cisco.com [10.61.97.243]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id rA4DSZbx002911; Mon, 4 Nov 2013 13:28:36 GMT Message-ID: <5277A0FE.8020000@cisco.com> Date: Mon, 04 Nov 2013 13:28:30 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: ipfix@ietf.org References: <20131104130718.10097.9955.idtracker@ietfa.amsl.com> In-Reply-To: <20131104130718.10097.9955.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------070201090106030501030004" Cc: Ben Campbell Subject: Re: [IPFIX] I-D Action: draft-ietf-ipfix-data-link-layer-monitoring-07.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 13:28:52 -0000 This is a multi-part message in MIME format. --------------070201090106030501030004 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear IPFIXers, This is a minor update to address the issues reported by Ben Campbell in his Gen-ART review. Specifically: * changed the 3rd paragraph of the intro to clarify that: ... the PSAMP Information Model [RFC5477] and the IPFIX Information Model [RFC7011] don't yet contain enough Information Elements related to data link layer, * corrected 3.2.18. droppedL2OctetTotalCount to define a total counter rather than a delta counter: Description: The total number of octets in observed layer 2 packets (including the layer 2 header) that were dropped by packet treatment since the (re-)initialization of the Metering Process. * I also took the opportunity to make some small formatting changes to Figures 1, 2, and 3 in section 6, to avoid idnits complaining that Figure 3 is overly wide, and to keep Figures 1 and 2 in sync. * One issue remains from Ben's review: It looks like this draft updates at least RFC5477. If so, this should be indicated in the header and in the abstract. Our view is that IANA's IPFIX registry is now the ultimate reference, so we don't constantly have to be referring back to old RFCs in each new draft. TBD. P. On 04/11/2013 13:07, internet-drafts@ietf.org wrote: > 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 : Information Elements for Data Link Layer Traffic Measurement > Author(s) : Shingo Kashima > Atsushi Kobayashi > Paul Aitken > Filename : draft-ietf-ipfix-data-link-layer-monitoring-07.txt > Pages : 34 > Date : 2013-11-04 > > Abstract: > This document describes Information Elements related to the data link > layer. They are used by the IP Flow Information Export (IPFIX) > protocol for encoding measured data link layer traffic information. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ipfix-data-link-layer-monitoring > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-ipfix-data-link-layer-monitoring-07 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-ipfix-data-link-layer-monitoring-07 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix --------------070201090106030501030004 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Dear IPFIXers,

This is a minor update to address the issues reported by Ben Campbell in his Gen-ART review.

Specifically:

* changed the 3rd paragraph of the intro to clarify that:

   ... the PSAMP
   Information Model [RFC5477] and the IPFIX Information Model [RFC7011]
   don't yet contain enough Information Elements related to data link
   layer,

* corrected 3.2.18.  droppedL2OctetTotalCount to define a total counter rather than a delta counter:

   Description:

      The total number of octets in observed layer 2 packets (including
      the layer 2 header) that were dropped by packet treatment since
      the (re-)initialization of the Metering Process.
* I also took the opportunity to make some small formatting changes to Figures 1, 2, and 3 in section 6, to avoid idnits complaining that Figure 3 is overly wide, and to keep Figures 1 and 2 in sync.


* One issue remains from Ben's review:

It looks like this draft updates at least RFC5477. If so, this should be indicated in the header and in the abstract.

Our view is that IANA's IPFIX registry is now the ultimate reference, so we don't constantly have to be referring back to old RFCs in each new draft.

TBD.

P.


On 04/11/2013 13:07, internet-drafts@ietf.org wrote:
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           : Information Elements for Data Link Layer Traffic Measurement
	Author(s)       : Shingo Kashima
                          Atsushi Kobayashi
                          Paul Aitken
	Filename        : draft-ietf-ipfix-data-link-layer-monitoring-07.txt
	Pages           : 34
	Date            : 2013-11-04

Abstract:
   This document describes Information Elements related to the data link
   layer.  They are used by the IP Flow Information Export (IPFIX)
   protocol for encoding measured data link layer traffic information.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ipfix-data-link-layer-monitoring

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-ipfix-data-link-layer-monitoring-07

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-ipfix-data-link-layer-monitoring-07


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

--------------070201090106030501030004-- From bclaise@cisco.com Tue Nov 5 05:56:52 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA4B411E8198 for ; Tue, 5 Nov 2013 05:56:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.426 X-Spam-Level: X-Spam-Status: No, score=-10.426 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d9ObKdRI+2NY for ; Tue, 5 Nov 2013 05:56:48 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 0AF7111E80EC for ; Tue, 5 Nov 2013 05:56:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10474; q=dns/txt; s=iport; t=1383659808; x=1384869408; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=Yb5fMT4mQqyYJT/bEqnruV1IS9So90rOrVUroXrp9l4=; b=fGA1iTq6Bmg+Q0dGI0CR3dAUkROyFkHlgyt5bKyhtxDINpBv91rlWJM9 tsQ1cLTYC7Ea43JxrXiQvV6ZPGAa6086vZpMKVqvHpq0bD2d4IwylFW1t 4zEOCH0+TcM5jLzr7u00VyjlR22D7/WHBLkPR3p3EuF9Py1e6X/rlFWag I=; X-IronPort-AV: E=Sophos;i="4.93,640,1378857600"; d="scan'208,217";a="94108460" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 05 Nov 2013 13:56:47 +0000 Received: from [10.21.81.48] (sjc-vpn4-304.cisco.com [10.21.81.48]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id rA5DujrS030992; Tue, 5 Nov 2013 13:56:45 GMT Message-ID: <5278F91D.80609@cisco.com> Date: Tue, 05 Nov 2013 05:56:45 -0800 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Paul Aitken References: <20131104130718.10097.9955.idtracker@ietfa.amsl.com> <5277A0FE.8020000@cisco.com> In-Reply-To: <5277A0FE.8020000@cisco.com> Content-Type: multipart/alternative; boundary="------------010603060402080407000208" Cc: Ben Campbell , ipfix@ietf.org Subject: Re: [IPFIX] I-D Action: draft-ietf-ipfix-data-link-layer-monitoring-07.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 13:56:53 -0000 This is a multi-part message in MIME format. --------------010603060402080407000208 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 4/11/2013 05:28, Paul Aitken wrote: > Dear IPFIXers, > > This is a minor update to address the issues reported by Ben Campbell > in his Gen-ART review. > > Specifically: > > * changed the 3rd paragraph of the intro to clarify that: > > ... the PSAMP > Information Model [RFC5477] and the IPFIX Information Model [RFC7011] > don't yet contain enough Information Elements related to data link > layer, > > * corrected 3.2.18. droppedL2OctetTotalCount to define a total > counter rather than a delta counter: > > Description: > > The total number of octets in observed layer 2 packets (including > the layer 2 header) that were dropped by packet treatment since > the (re-)initialization of the Metering Process. > > * I also took the opportunity to make some small formatting changes to > Figures 1, 2, and 3 in section 6, to avoid idnits complaining that > Figure 3 is overly wide, and to keep Figures 1 and 2 in sync. > > > * One issue remains from Ben's review: > > It looks like this draft updates at least RFC5477. If so, this should be indicated in the header and in the abstract. > > > Our view is that IANA's IPFIX registry is now the ultimate reference, > so we don't constantly have to be referring back to old RFCs in each > new draft. That makes sense since RFC 7012 mentions that IANA registry is now THE reference The IANA "IPFIX Information Elements" registry [IANA-IPFIX] is the current complete reference for IPFIX Information Elements. The IE-doctors collectively agreed that updating the OLD is not needed, and they will consistently apply this rule for future IEs I thought I would let the IPFIX community know. Regards, Benoit > > TBD. > > P. > > > On 04/11/2013 13:07, internet-drafts@ietf.org wrote: >> 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 : Information Elements for Data Link Layer Traffic Measurement >> Author(s) : Shingo Kashima >> Atsushi Kobayashi >> Paul Aitken >> Filename : draft-ietf-ipfix-data-link-layer-monitoring-07.txt >> Pages : 34 >> Date : 2013-11-04 >> >> Abstract: >> This document describes Information Elements related to the data link >> layer. They are used by the IP Flow Information Export (IPFIX) >> protocol for encoding measured data link layer traffic information. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-ipfix-data-link-layer-monitoring >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-ipfix-data-link-layer-monitoring-07 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-ipfix-data-link-layer-monitoring-07 >> >> >> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> 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 --------------010603060402080407000208 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 4/11/2013 05:28, Paul Aitken wrote:
Dear IPFIXers,

This is a minor update to address the issues reported by Ben Campbell in his Gen-ART review.

Specifically:

* changed the 3rd paragraph of the intro to clarify that:

   ... the PSAMP
   Information Model [RFC5477] and the IPFIX Information Model [RFC7011]
   don't yet contain enough Information Elements related to data link
   layer,

* corrected 3.2.18.  droppedL2OctetTotalCount to define a total counter rather than a delta counter:

   Description:

      The total number of octets in observed layer 2 packets (including
      the layer 2 header) that were dropped by packet treatment since
      the (re-)initialization of the Metering Process.
* I also took the opportunity to make some small formatting changes to Figures 1, 2, and 3 in section 6, to avoid idnits complaining that Figure 3 is overly wide, and to keep Figures 1 and 2 in sync.


* One issue remains from Ben's review:

It looks like this draft updates at least RFC5477. If so, this should be indicated in the header and in the abstract.

Our view is that IANA's IPFIX registry is now the ultimate reference, so we don't constantly have to be referring back to old RFCs in each new draft.

That makes sense since RFC 7012 mentions that IANA registry is now THE reference

   The IANA "IPFIX Information Elements" registry [IANA-IPFIX] is the
   current complete reference for IPFIX Information Elements.

The IE-doctors collectively agreed that updating the OLD is not needed, and they will consistently apply this rule for future IEs
I thought I would let the IPFIX community know.

Regards, Benoit

TBD.

P.


On 04/11/2013 13:07, internet-drafts@ietf.org wrote:
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           : Information Elements for Data Link Layer Traffic Measurement
	Author(s)       : Shingo Kashima
                          Atsushi Kobayashi
                          Paul Aitken
	Filename        : draft-ietf-ipfix-data-link-layer-monitoring-07.txt
	Pages           : 34
	Date            : 2013-11-04

Abstract:
   This document describes Information Elements related to the data link
   layer.  They are used by the IP Flow Information Export (IPFIX)
   protocol for encoding measured data link layer traffic information.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ipfix-data-link-layer-monitoring

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-ipfix-data-link-layer-monitoring-07

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-ipfix-data-link-layer-monitoring-07


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
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

--------------010603060402080407000208-- From paitken@cisco.com Tue Nov 5 06:52:15 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56BD921E8297 for ; Tue, 5 Nov 2013 06:52:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ASTkUmE2xOkM for ; Tue, 5 Nov 2013 06:52:09 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 9D41821E830F for ; Tue, 5 Nov 2013 06:52:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=521; q=dns/txt; s=iport; t=1383663127; x=1384872727; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=vw2m8+b1ZHEPqr3DNxM4SqZxeby3MSYmzRVicgBQrNY=; b=MOAxmKt4Dy9T/R6JF4yghqkPoxfP1LyJGIy2i1CjO4QumiSg8/cq4wJx N5F9nUXoRdIpch+Y7IilOvrNPyPBw6XoyVoKPl8YiVQan3sx26MC4PYZi yLtrvxoQ05tksc0uLeiX1stBSoiLzD82kpS3y65b8mEtKrNold73GdpjY Q=; X-IronPort-AV: E=Sophos;i="4.93,640,1378857600"; d="scan'208";a="161416677" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 05 Nov 2013 14:52:06 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id rA5EpxTN012033 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 Nov 2013 14:52:01 GMT Received: from [144.254.153.23] (dhcp-144-254-153-23.cisco.com [144.254.153.23]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id rA5EpwiZ012919; Tue, 5 Nov 2013 14:51:59 GMT Message-ID: <52790609.2040008@cisco.com> Date: Tue, 05 Nov 2013 14:51:53 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: ipfix@ietf.org References: <20131104130718.10097.9955.idtracker@ietfa.amsl.com> <5277A0FE.8020000@cisco.com> <5278F91D.80609@cisco.com> In-Reply-To: <5278F91D.80609@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ben Campbell Subject: Re: [IPFIX] I-D Action: draft-ietf-ipfix-data-link-layer-monitoring-07.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 14:52:15 -0000 Benoit Claise wrote: >> Our view is that IANA's IPFIX registry is now the ultimate reference, >> so we don't constantly have to be referring back to old RFCs in each >> new draft. > That makes sense since RFC 7012 mentions that IANA registry is now THE > reference For the record, IANA's IPFIX registry MUST be the reference because 20% of the Information Elements in the registry are not defined in any RFC. So if you only refer to RFCs, you will be missing 20% of the Information Elements. P. From andrewf@plixer.com Thu Nov 7 06:13:03 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE27011E819C for ; Thu, 7 Nov 2013 06:13:03 -0800 (PST) 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_37=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 34udzNt89UE5 for ; Thu, 7 Nov 2013 06:12:57 -0800 (PST) Received: from mx1.plixer.com (mx1.plixer.com [64.140.243.154]) by ietfa.amsl.com (Postfix) with ESMTP id A667C11E81C1 for ; Thu, 7 Nov 2013 06:12:56 -0800 (PST) Received: from [192.168.4.40] (199.91.80.194) by mx1.plixer.com (10.1.5.1) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 7 Nov 2013 09:12:55 -0500 Message-ID: <527B9FE5.8090208@plixer.com> Date: Thu, 7 Nov 2013 06:12:53 -0800 From: Andrew Feren User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: References: <52732439.50206@tik.ee.ethz.ch> <20131103190509.GB74417@elstar.local> <5276E6FD.2080306@plixer.com> <20131104011238.GA75287@elstar.local> In-Reply-To: <20131104011238.GA75287@elstar.local> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Subject: Re: [IPFIX] Initial review of draft-ietf-ipfix-mib-variable-export-03 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 14:13:03 -0000 On 11/03/2013 05:12 PM, Juergen Schoenwaelder wrote: > On Sun, Nov 03, 2013 at 04:14:53PM -0800, Andrew Feren wrote: >> On 11/03/2013 11:05 AM, Juergen Schoenwaelder wrote: >>> On Fri, Nov 01, 2013 at 04:47:05AM +0100, Brian Trammell wrote: >>>> (3) Clarifying and SNMP-naif question on 11.2.2 mibObjectIdentifier: it >>>> seems from the examples that the intention is that the OID will be >>>> encoded in the document as a Unicode string of digits and "." >>>> characters? Is this the way OIDs are encoded in SNMP? The encoding of >>>> fundamentally binary data in strings is not very IPFIXish (7013 section >>>> 4.2 para 6), and I kind of expected these to be encoded as octetarrays >>>> of unsigned integers of a specified size, or something similar. However, >>>> if encoding-as-string is how things are done on the wire in SNMP, it's >>>> the right thing to do here too (7013 section 4.5). The same comment >>>> applies to 11.2.4. >>>> >>> SNMP uses ASN.1/BER and this gives you are much more compact encoding >>> of OIDs (but this is of course a much less human/programmer friendly >>> representation). >> So, would a simple octetArray like Brian asked about make sense? I'm >> still not sure. > Not sure exactly what Brian proposed but a sub-identifier can be up to > 32-bit long. OK. I need to give this some thought, but perhaps a string is better. >>>> IpAddress -> ipv4Address (side question: how do you do V6 with SNMP?) >>> The IPv6 address types are an OCTET STRING on the wire (not a tagged >>> type anymore). >> I've occasionally wondered if an ipAddress type (varlen 4 or 16 octets) >> would be useful in IPFIX. > Maybe it is but surely this is not how SNMP represents data; the > InetAddress textual convention actually can carry zone indexes and > hence the assumption 4 or 16 octets may not hold true in general. Perhaps the details of my example were too narrow, but my question remains. Actually, reading Juergen's comment I went looking for the InetAddress textual convention and was reminded that some textual conventions denote structure which we will need to represent. Even looking at a simpler textual convention like InetPortNumber which is just a name for a unsigned16 I'm not sure what I should do with that if sent using IPFIX. Is that: sourceTransportPort destinationTransportPort collectorTransportPort exporterTransportPort postNAPTSourceTransportPort postNAPTDestinationTransportPort Perhaps it is possible to use other info in the various MIBs to map an InetPortNumber appropriately, but I'll need to do some more looking to really know. Juergen, just out of curiousity... What exactly is the "zone index" in the InetAddress? I read some words in RFC3291, still wasn't clear how that is used. -Andrew From j.schoenwaelder@jacobs-university.de Thu Nov 7 06:37:04 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0C9221E81D3 for ; Thu, 7 Nov 2013 06:37:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.187 X-Spam-Level: X-Spam-Status: No, score=-103.187 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O4ma41rtHdnC for ; Thu, 7 Nov 2013 06:36:57 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id D52D921E81BE for ; Thu, 7 Nov 2013 06:36:55 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id D9A762009A; Thu, 7 Nov 2013 15:36:54 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id wTIMGFDiXJSN; Thu, 7 Nov 2013 15:36:54 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 71EC520095; Thu, 7 Nov 2013 15:36:54 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 10E0B2930DCA; Thu, 7 Nov 2013 15:36:48 +0100 (CET) Date: Thu, 7 Nov 2013 15:36:48 +0100 From: Juergen Schoenwaelder To: Andrew Feren Message-ID: <20131107143648.GA87616@elstar.local> Mail-Followup-To: Andrew Feren , ipfix@ietf.org References: <52732439.50206@tik.ee.ethz.ch> <20131103190509.GB74417@elstar.local> <5276E6FD.2080306@plixer.com> <20131104011238.GA75287@elstar.local> <527B9FE5.8090208@plixer.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <527B9FE5.8090208@plixer.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: ipfix@ietf.org Subject: Re: [IPFIX] Initial review of draft-ietf-ipfix-mib-variable-export-03 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 14:37:04 -0000 On Thu, Nov 07, 2013 at 06:12:53AM -0800, Andrew Feren wrote: > Actually, reading Juergen's comment I went looking for the InetAddress > textual convention and was reminded that some textual conventions denote > structure which we will need to represent. Even looking at a simpler > textual convention like InetPortNumber which is just a name for a > unsigned16 I'm not sure what I should do with that if sent using IPFIX. > Is that: > sourceTransportPort > destinationTransportPort > collectorTransportPort > exporterTransportPort > postNAPTSourceTransportPort > postNAPTDestinationTransportPort > > Perhaps it is possible to use other info in the various MIBs to map an > InetPortNumber appropriately, but I'll need to do some more looking to > really know. I think you can't do such a mapping. The textual convention InetPortNumber does not define what the port number represents. And there is nothing machine readable which allows a machine to decide whether a specific usage of InetPortNumber maps to those IPFIX information elements. In general, you may not want to make IE specific mappings since there are tons of MIB objects and data types out there. > Juergen, just out of curiousity... What exactly is the "zone index" in > the InetAddress? I read some words in RFC3291, still wasn't clear how > that is used. Details in RFC 4007. In short, if you have scoped addresses such as link local addresses, then you need additional information to disambiguate them and this is called a zone index. An example from the command line: inet6 fe80::217:f2ff:fed0:4c82%en0 prefixlen 64 scopeid 0x6 The %en0 is the zone index. It can be represented as a name or numerically as an ifIndex value. The InetAddress TCs use the numeric representation. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From cmcdowal@cisco.com Thu Nov 7 10:02:19 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CDB321E814A for ; Thu, 7 Nov 2013 10:02:18 -0800 (PST) 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_37=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WJ7sY6VW9kqq for ; Thu, 7 Nov 2013 10:02:10 -0800 (PST) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id B119C21E8148 for ; Thu, 7 Nov 2013 10:02:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8928; q=dns/txt; s=iport; t=1383847329; x=1385056929; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=orJ14kSuc9vCoxLm7YCNHoj1si1T8W5QZTMxWpUyznU=; b=PcLan7bBdYAMAn8s7TC9abRkGLtd/LW5Js1u5pjAMWSN5ifaU1Dw9UrP raYPM8j0LwR3or1/XFeRS4uij8F1v1GO1wzsuQ/tVRRHUCBWx26tXqAeT /LRfroTXr9Zr7+H5IBnSG6XKEnif5tB15bHYxF/r0b2BjcaXfE0utZ2WD Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYFAI7Ue1KQ/khL/2dsb2JhbABagwc4v2GBJRZ0giUBAQEDAQEBASQRLwcKBgsLGAkWDwkDAgECARUwBgEMBgIBAYd3Bg28WASPYIQwA5Qsg2CGPYtNgyY8 X-IronPort-AV: E=Sophos;i="4.93,653,1378857600"; d="scan'208";a="18861020" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-3.cisco.com with ESMTP; 07 Nov 2013 18:02:07 +0000 Received: from [10.61.171.39] ([10.61.171.39]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id rA7I21WB032609; Thu, 7 Nov 2013 18:02:03 GMT Message-ID: <527BD599.7060808@cisco.com> Date: Thu, 07 Nov 2013 18:02:01 +0000 From: Colin McDowall User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: ipfix@ietf.org, Brian Trammell References: <52732439.50206@tik.ee.ethz.ch> In-Reply-To: <52732439.50206@tik.ee.ethz.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [IPFIX] Initial review of draft-ietf-ipfix-mib-variable-export-03 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 18:02:19 -0000 Hi Brian, Thanks for the review see replies inline on some of your points: On 01/11/2013 03:47, Brian Trammell wrote: > Greetings, all, > > I've had a quick look at the present (-03) revision of the MIB Variable > Export draft. The document still needs at least one revision before it's > complete, as noted in its Open Issues section. I'll do a full review > after the open issues are handled. Agreed this document is still a work in progress. > > But the fundamental change in this revision -- moving to an Options > Template based mechanism for binding OIDs to templates -- looks good, > and seems to be the right way to move this work forward. > > I should note I still have no real understanding of how indexing works > in SNMP, despite having made an effort a couple of times now, and this > document makes it seem even more complicated than I thought it was. That > having been said, after having how often are indexes in SNMP used to > bind values to things we'd think of as flow keys in IPFIX? Does it make > sense to try to repurpose flowKeyIndicator here? This seems to be the > case in Section 6.4, but maybe I'm latching on to irrelevant details in > the example. The complexity that still remains is an attempt to allow existing keys in a data record to be used to index into the columns of data. The other option is to just export an extra 'string' in the data record if there are no key fields that can be used. That is what mibIndexString is for. I'll need to look into using a similar method to flowKeyIndicator. And see if there is a clearer way to do the indexing/explain it. Using a bit flag to mark the fields indexing a mibObjectValue would also be more efficient than giving a list of indexes into a template. What you wouldn't be able to specify is the ordering that might be different than the order of the fields in the template. > > I have quite a few issues with the specifics of the mechanism and the > document itself. Since the details of the mechanism are described by the > IEs used in the options templates, I started in the IANA Considerations > section: > > (1) Section 11.1 doesn't make any sense and should be removed. Unless > I've missed something fundamental, nothing else in the document suggests > that new Abstract Data Types are necessary for this mechanism to work. > If I have missed something fundamental, the mechanism should be > redefined such than new Abstract Data Types are not necessary. I don't think we need to have new Abstract Data Types to make the mechanism work. We would only need new ADTs if we are actually adding extra snmp types. > > (2) Usage of Data Type Semantics throughout section 11.2 is not > consistent with RFC 7012; non-numeric data types do not take Data Type > Semantics, as the semantics are inherent to the Abstract Data Type. > Noted. > (3) Clarifying and SNMP-naif question on 11.2.2 mibObjectIdentifier: it > seems from the examples that the intention is that the OID will be > encoded in the document as a Unicode string of digits and "." > characters? Is this the way OIDs are encoded in SNMP? The encoding of > fundamentally binary data in strings is not very IPFIXish (7013 section > 4.2 para 6), and I kind of expected these to be encoded as octetarrays > of unsigned integers of a specified size, or something similar. However, > if encoding-as-string is how things are done on the wire in SNMP, it's > the right thing to do here too (7013 section 4.5). The same comment > applies to 11.2.4. > This is carried over from the previous versions of the draft so I'm not sure about the background on the choice. I agree that encoding the mibObjectIdentifier in the same format as SNMP might be ideal as we would have a complete definition in another RFC. Sending the OID as a string is 'simpler' but potentially wasteful. On the other hand a lot of the sub-identifiers are short and would be more efficient as a single character than a 32bit number. Note that this string is only being sent once for each mib field. The records using mib objects are not exporting any extra strings. > (4) In 11.2.3 mibIndexList: the underlying data type of the elements of > the list encoded in the octetArray is missing from the description - are > these unsigned8s or unsigned16s? The encoding of internal structure > which doesn't come from some external protocol in an octetArray violates > 7013 section 4.2. It seems like what you really want here is an > Information Element that is an instance of a basicList ADT with a > constraint in the description that states that only > informationElementIndex IEs are allowed as content. I did consider writing this using the basicList structured data that might be clearer. We also discussed that if the type of the fields and the elements never changes it seems wasteful in the simple case of a single index. Defining a single mibIndex field and a basicList mibIndexList field might be the best compromise. I haven't fully groked '7013 section 4.2' - I'll go and reread it. > > (5) Also on 11.2.3 and 11.2.4, see comment above on using > flowKeyIndicator instead, if indeed that suggestion makes any sense. > We might still want the definition in mibIndexString 11.2.4 as that allows indexing in a different manner. > (6) In 11.2.7 mibObjectBaseSyntax, I think the question "should there be > 11 different IEs, one of each of the above types, rather than a single > mibObjectValue?" is definitely worth considering, as it would allow > faster handling at CPs based on the base syntax without having to decode > the base syntax from the options template. That was my thinking by requiring the basesyntax field - and having that information in the data template is probably worth having the extra fields. Also aside from having to decode the options template the cp needs to have access to the correct mib to work out the base data type for the field. Depending on the implementation the correct mib might be missing or require a network lookup. While the OID/ ObjectIdentifier provides enough information in theory to understand the field it might take some 'work' - providing the base syntax or encoding the base type in the IE is a nice compromise - the CP can store/display the values nicely and always lookup the MIB later. > Not being a SNMP geek, I don't understand why you need 11 here. I included all 11 base 'types' in the baseSyntax as I didn't understand the nuiances of the differences. It also made it simpler when mapping from the definitions of mib objects. > Reduced length encoding and mappings to IPFIX ADTs and semantics suggest > the following seven mappings to IPFIX IEs would suffice: > > OCTET STRING and Opaque -> octetArray > INTEGER and Integer32 -> signed64 (with RLE) / quantity > Counter32 and Counter64 -> signed64 (with RLE) / totalCounter > Gauge32 and Unsigned32 -> unsigned64 (with RLE) / quantity > IpAddress -> ipv4Address (side question: how do you do V6 with SNMP?) > TimeTicks -> dateTimeSeconds (for IPFIX Epoch) > OBJECT IDENTIFIER -> see 11.2.2 > > There are some mismatches between base syntaxes and IPFIX data types > which it might be necessary to address. Yes I don't think we want to lose any type information when exporting mib data types via ipfix. I don't see any problem with using RLE though. > If keeping SNMP Counter > semantics is important (it seems like it might be), > it might make sense to add an snmpCounter Data Type Semantics. The minimum and maximum > values for a gauge can be bound to the gauge with > informationElementRangeBegin and informationElementRangeEnd from RFC 5610. > > Doing this would obviate the need for the mibObjectBaseSyntax, no? Yes the cp would know the basic data for the field even without having access to the mib so it wouldn't need to be in the mibOption. The only required field would be the mibObjectIdentifier, which is nicer. > > (7) In 11.2.10 mibContextIdentifier: is a context identifier similar to > an object identifier? Then it should be defined similar to 11.2.2 -- it > doesn't need a new ADT. > > Editorial commentary (not exhaustive -- I'll wait 'til the open issues > are fixed before doing a full review): > > (8) Section 5.1.2 "Minimum Required MIB Object Fields" is hard to > visually scan -- I had to look over it several times before I understood > that the things in the list are _optional_ while the things buried in > the first paragraph are required. Suggest using list formatting for all. Agree, if we can simplify to one required field this can all be made clearer as well. Thanks, colin > > Best regards, > > Brian > > > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix > From andrewf@plixer.com Thu Nov 7 10:21:14 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD13C11E81E6 for ; Thu, 7 Nov 2013 10:21:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1hCo6qj4SZMX for ; Thu, 7 Nov 2013 10:21:10 -0800 (PST) Received: from mx1.plixer.com (mx1.plixer.com [64.140.243.154]) by ietfa.amsl.com (Postfix) with ESMTP id 71C0F11E8280 for ; Thu, 7 Nov 2013 10:19:59 -0800 (PST) Received: from [192.168.6.174] (199.91.80.194) by mx1.plixer.com (10.1.5.1) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 7 Nov 2013 13:19:58 -0500 Message-ID: <527BD9CC.3030805@plixer.com> Date: Thu, 7 Nov 2013 10:19:56 -0800 From: Andrew Feren User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Paul Aitken , IETF IPFIX Working Group References: <20131021215848.32561.19089.idtracker@ietfa.amsl.com> <52665509.7010908@cisco.com> In-Reply-To: <52665509.7010908@cisco.com> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Subject: Re: [IPFIX] draft-ietf-ipfix-mib-variable-export-03 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 18:21:14 -0000 Hi Paul and Colin, This draft is quite clever and headed in the right direction. I am confused by Figure 14 with a "Set ID = ??" Is this left from the earlier version? I like the goal of On 10/22/2013 03:35 AM, Paul Aitken wrote: > Dear IPFIX experts, > > We've rewritten the IPFIX MIB export draft to use regular IPFIX option templates rather than extended field specifiers. > > We'd appreciate your feedback whether this seems about right. Honestly I kind of liked the original export method, but I have been mostly convinced that there is some benefit to this new method. Mostly that it at least allows existing collectors to use known IEs and get some data while ignoring SNMP elements until the work is done to fully implement collection of SNMP data over IPFIX. This fits with the stated goal to "augmented [an existing Template Record] with some MIB variables whose index was already present in the Template Record as an IPFIX Information Element". Although this draft also allows more than that so how much practical use the backwards compatibility is will likely depend on exactly what is ultimately exported. The collector has to do a bit of correlation of different pieces to get there, but in the end I get a template with specific IEs. This aligns nicely with how regular templates work. > Also your feedback on two TBD issues in the text: > > 1. Should there be a single "mibObjectValue" IE, combined with a "mibObjectBaseSyntax" IE to define the type? > Or, should there be multiple "value" IEs, one per RFC 2578 type (eg, mibObjectIntegerValue, mibObjectIpAddressValue, ...) ? I think having multiple value IEs (one per data type) is nice, but I'm not sure it is strictly necessary. At least not if this draft is fully implemented. As I noted above, once all the templates are correlated the collector should know the type of each element unambiguously. That said I think my personal bias is still for one value / type. I suspect that will simplify some things once I dive in and try implementing any of this. > > 2. Should we consolidate the RFC 2578 ObjectSyntax with the RFC5610 / [IANA- DATATYPES] types? I think yes. > > Thanks, > Paul and Colin. > > > -------- Original Message -------- > Subject: [Sender: ipfix-bounces@ietf.org] [IPFIX] I-D Action: draft-ietf-ipfix-mib-variable-export-03.txt > Date: Mon, 21 Oct 2013 14:58:48 -0700 > 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 : Exporting MIB Variables using the IPFIX Protocol > Author(s) : Paul Aitken > Benoit Claise > Colin McDowall > Juergen Schoenwaelder > Filename : draft-ietf-ipfix-mib-variable-export-03.txt > Pages : 56 > Date : 2013-10-21 > > Abstract: > This document specifies a way to complement IPFIX Data Records with > Management Information Base (MIB) objects, avoiding the need to > define new IPFIX Information Elements for existing Management > Information Base objects that are already fully specified. > > An IPFIX Option Template and method are specified, which are used to > export the extra information required to fully describe Simple > Network Management Protocol (SNMP) MIB Objects. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ipfix-mib-variable-export > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-ipfix-mib-variable-export-03 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-ipfix-mib-variable-export-03 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > 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 j.schoenwaelder@jacobs-university.de Thu Nov 7 10:28:48 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FA8A11E81B4 for ; Thu, 7 Nov 2013 10:28:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.191 X-Spam-Level: X-Spam-Status: No, score=-103.191 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jdmP6f0b2WX4 for ; Thu, 7 Nov 2013 10:28:43 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id DA76411E825C for ; Thu, 7 Nov 2013 10:28:15 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 45795200AF; Thu, 7 Nov 2013 19:28:15 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id pJtsxgbnh0tp; Thu, 7 Nov 2013 19:28:15 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C56E7200AE; Thu, 7 Nov 2013 19:28:14 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 1625C29319AE; Thu, 7 Nov 2013 19:28:09 +0100 (CET) Date: Thu, 7 Nov 2013 19:28:09 +0100 From: Juergen Schoenwaelder To: Colin McDowall Message-ID: <20131107182809.GA89146@elstar.local> Mail-Followup-To: Colin McDowall , ipfix@ietf.org, Brian Trammell References: <52732439.50206@tik.ee.ethz.ch> <527BD599.7060808@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <527BD599.7060808@cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: ipfix@ietf.org Subject: Re: [IPFIX] Initial review of draft-ietf-ipfix-mib-variable-export-03 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 18:28:49 -0000 On Thu, Nov 07, 2013 at 06:02:01PM +0000, Colin McDowall wrote: > > >(3) Clarifying and SNMP-naif question on 11.2.2 mibObjectIdentifier: it > >seems from the examples that the intention is that the OID will be > >encoded in the document as a Unicode string of digits and "." > >characters? Is this the way OIDs are encoded in SNMP? The encoding of > >fundamentally binary data in strings is not very IPFIXish (7013 section > >4.2 para 6), and I kind of expected these to be encoded as octetarrays > >of unsigned integers of a specified size, or something similar. However, > >if encoding-as-string is how things are done on the wire in SNMP, it's > >the right thing to do here too (7013 section 4.5). The same comment > >applies to 11.2.4. > > > > This is carried over from the previous versions of the draft so I'm > not sure about the background on the choice. > > I agree that encoding the mibObjectIdentifier in the same format as > SNMP might be ideal as we would have a complete definition in > another RFC. > > Sending the OID as a string is 'simpler' but potentially > wasteful. On the other hand a lot of the sub-identifiers are short > and would be more efficient as a single character than a 32bit > number. Once again, each sub-identifier (except the first two) can be an unsigned32 number. SNMP uses BER encoding and using BER encoding, smaller numbers need less space. For most of the small sub-identifiers (range 0-127), you only need one octet in BER and there are no separators (hence they will be about 50% of the length of a string representation). For larger sub-identifier, the savings may be even more significant (but they are less frequent, although private OIDs usually have at least one larger sub-identifier, the enterprise ID, except for those companies that got a private number very early). Bottom line: If you care about efficiency on the wire, use BER encoding of the OIDs. If efficiency is not much of a concern since these OIDs only show up rarely, a string encoding may be easier for implementors. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From cmcdowal@cisco.com Thu Nov 7 13:15:59 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1A9121E8194 for ; Thu, 7 Nov 2013 13:15:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ja5TK5jxQlfZ for ; Thu, 7 Nov 2013 13:15:54 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 557E221E8188 for ; Thu, 7 Nov 2013 13:15:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2922; q=dns/txt; s=iport; t=1383858954; x=1385068554; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=sOz1eGmTvHW7H9D9u3axSptQdZ/1xqFpRsIUiMkbPE4=; b=FF8s5jD8qbOkHEKQkbaVY0l2Uoib7IAQP4iNjuaJ5GXn6em9GJ3TPavR W9hyqMh/cABPPFnz0AB30hXA6agVAbKeBerm78d0JhKjOoGdX+RJhwn/S B0q/zHz8lGWF55DZYeYC/0iNWJamILIJCNh0vsgidxj04hslcTFS6WDbl I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAPoBfFKQ/khM/2dsb2JhbABagwe9HoJ7gSYWdIIlAQEBAwE4LxEBEAsOCgkWDwkDAgECAUUGDQEHAQGHdwa9Do9ZB4QwA5gMhj2LTYMmPA X-IronPort-AV: E=Sophos;i="4.93,654,1378857600"; d="scan'208";a="87988924" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 07 Nov 2013 21:15:53 +0000 Received: from [10.61.171.39] ([10.61.171.39]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id rA7LFlOD010715; Thu, 7 Nov 2013 21:15:48 GMT Message-ID: <527C0303.4030100@cisco.com> Date: Thu, 07 Nov 2013 21:15:47 +0000 From: Colin McDowall User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Juergen Schoenwaelder References: <52732439.50206@tik.ee.ethz.ch> <527BD599.7060808@cisco.com> <20131107182809.GA89146@elstar.local> In-Reply-To: <20131107182809.GA89146@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ipfix@ietf.org Subject: Re: [IPFIX] Initial review of draft-ietf-ipfix-mib-variable-export-03 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 21:16:00 -0000 On 07/11/2013 18:28, Juergen Schoenwaelder wrote: > On Thu, Nov 07, 2013 at 06:02:01PM +0000, Colin McDowall wrote: >> >>> (3) Clarifying and SNMP-naif question on 11.2.2 mibObjectIdentifier: it >>> seems from the examples that the intention is that the OID will be >>> encoded in the document as a Unicode string of digits and "." >>> characters? Is this the way OIDs are encoded in SNMP? The encoding of >>> fundamentally binary data in strings is not very IPFIXish (7013 section >>> 4.2 para 6), and I kind of expected these to be encoded as octetarrays >>> of unsigned integers of a specified size, or something similar. However, >>> if encoding-as-string is how things are done on the wire in SNMP, it's >>> the right thing to do here too (7013 section 4.5). The same comment >>> applies to 11.2.4. >>> >> >> This is carried over from the previous versions of the draft so I'm >> not sure about the background on the choice. >> >> I agree that encoding the mibObjectIdentifier in the same format as >> SNMP might be ideal as we would have a complete definition in >> another RFC. >> >> Sending the OID as a string is 'simpler' but potentially >> wasteful. On the other hand a lot of the sub-identifiers are short >> and would be more efficient as a single character than a 32bit >> number. > > Once again, each sub-identifier (except the first two) can be an > unsigned32 number. SNMP uses BER encoding and using BER encoding, > smaller numbers need less space. For most of the small sub-identifiers > (range 0-127), you only need one octet in BER and there are no > separators (hence they will be about 50% of the length of a string > representation). For larger sub-identifier, the savings may be even > more significant (but they are less frequent, although private OIDs > usually have at least one larger sub-identifier, the enterprise ID, > except for those companies that got a private number very early). Ok, I think I'm understanding you now. I'll experiment with the format. > > Bottom line: If you care about efficiency on the wire, use BER > encoding of the OIDs. If efficiency is not much of a concern since > these OIDs only show up rarely, a string encoding may be easier for > implementors. Sounds like BER might be the better choice. A string encoding may be easier for some implementors but might require translation into a string if any OIDs being exported are already stored internally with a BER encoding. I'm thinking more of the case where the value of a mibObject is itself an OID. Exporting the value is more likely to be a straight copy into the export packet if it is in the same format. The encoding is already a standard and there are library implementations of the BER encoding. Also anything extracting values out of an existing MIB implementation will probably already have support. Thanks, colin > > /js > From j.schoenwaelder@jacobs-university.de Thu Nov 7 13:43:33 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AF7211E8101 for ; Thu, 7 Nov 2013 13:43:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.193 X-Spam-Level: X-Spam-Status: No, score=-103.193 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zl8t7E4p6Top for ; Thu, 7 Nov 2013 13:43:27 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id B315F11E8264 for ; Thu, 7 Nov 2013 13:42:54 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0A6D7200AC; Thu, 7 Nov 2013 22:42:54 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 7MWzBFKvJhCT; Thu, 7 Nov 2013 22:42:53 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8B778200A9; Thu, 7 Nov 2013 22:42:53 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id B2F272931F98; Thu, 7 Nov 2013 22:42:47 +0100 (CET) Date: Thu, 7 Nov 2013 22:42:46 +0100 From: Juergen Schoenwaelder To: Colin McDowall Message-ID: <20131107214245.GA89766@elstar.local> Mail-Followup-To: Colin McDowall , ipfix@ietf.org, Brian Trammell References: <52732439.50206@tik.ee.ethz.ch> <527BD599.7060808@cisco.com> <20131107182809.GA89146@elstar.local> <527C0303.4030100@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <527C0303.4030100@cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: ipfix@ietf.org Subject: Re: [IPFIX] Initial review of draft-ietf-ipfix-mib-variable-export-03 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 21:43:33 -0000 On Thu, Nov 07, 2013 at 09:15:47PM +0000, Colin McDowall wrote: > > A string encoding may be easier for some implementors but might > require translation into a string if any OIDs being exported are > already stored internally with a BER encoding. I'm thinking more of > the case where the value of a mibObject is itself an OID. > OIDs as values are rare and even then it is an implementation choice whether they are stored internally BER encoded. > The encoding is already a standard and there are library > implementations of the BER encoding. Also anything extracting > values out of an existing MIB implementation will probably already > have support. Yes, for the exporter this should not be an issue at all. For something processing collected IPFIX records, BER encoded OIDs may be a bit more fun. That said, it should be possible to write a fairly simple piece of C code to go into an appendix in case people think it is hard to figure out how this works. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From n.brownlee@auckland.ac.nz Thu Nov 7 22:02:33 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8653E11E811A for ; Thu, 7 Nov 2013 22:02:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wN8jhnU1oHmd for ; Thu, 7 Nov 2013 22:02:20 -0800 (PST) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) by ietfa.amsl.com (Postfix) with ESMTP id B5EF811E8158 for ; Thu, 7 Nov 2013 22:02:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1383890540; x=1415426540; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=ViV5mKAYyQ1I/haaRb6oYs8CQyqSYEFJz9If/MXmcTA=; b=q32FeUKwcbQyJnzuP3JovrJRHwX5czfqj/u2ysxakDFyK645j0uEI59R AB8SMSJTvbc3eXqmsNDpUFu4HFW9nTYBdkFsCDKb1+iFr/6mYJrSPTXzs bEHG3ReE/Azziv0ISydX8dAKt1YQlDxemBPMEAawIjbcQUKepUBoAM7P0 I=; X-IronPort-AV: E=Sophos;i="4.93,658,1378814400"; d="scan'208";a="221861083" X-Ironport-HAT: None - $RELAY-AUTH X-Ironport-Source: 64.114.24.114 - Outgoing - Outgoing-SSL Received: from unknown (HELO [142.131.17.14]) ([64.114.24.114]) by mx2-int.auckland.ac.nz with ESMTP; 08 Nov 2013 19:02:16 +1300 Message-ID: <527C7E66.4010406@auckland.ac.nz> Date: Fri, 08 Nov 2013 19:02:14 +1300 From: Nevil Brownlee User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 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 minutes of IPFIX meeting in Vancouver X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 06:02:33 -0000 Hi all: Here are the draft minutes. As always, please email corrections and comments to me (or to the list). Cheers, Nevil Minutes of the IPFIX meeting at IETF 88 in Vancouver About 22 people present, plus some on jabber Scribes: Nevil Brownlee and Chris Innacio Jabber Scribe: Brian Trammell Meeting chair: Nevil Brownlee Nevil opened the meeting, and gave the IPFIX status update: - Internet Standard RFCs published since last meeting: 7011 = 5101bis, 7012 = 5102bis, 7013 = IE Doctors 7014 = Flow Selection Techniques, 7015 = IPFIX Aggregation - Other WG drafts in process Link Layer IEs - on IESG telechat 21 Nov Mediation Protocol - IETF LC completed, new version needed - AD-sponsored draft trammell-ipfix-tcpcontrolbits-revision - IANA waiting on IE Doctors Nevil presented Paul Aitken's slides on the MIB Variable Export draft: - There have been several good reviews on the latest verision - One particular problem discussed is that SNMP's type system is not a good match for IPFIX's type system - The authors will produce a new version, taking account of all the feedback - Benoit, Brian and Juergen will review that version Next Steps for IPFIX - The meeting discussed the various drafts that have been presented at IPFIX meetings over about the last 12 months. - Several of these can be AD-sponsored: draft-yourtchenko-cisco-ies (Joel) draft-trammell-ipfix-text-adt (Benoit) - Others need more work: Enterprise IEs draft-aitken-ipfix-equivalent-ies draft-inacio-ipfix-penie-00 These offer two solutions to the problem of managing Enterprise IEs. A single solution is needed. Unobserved Fields draft-aitken-ipfix-unobserved-fields - Summary: . The chairs propose to close the WG when the current charter items are completed. Other drafts may be AD-sponsored. . The mailing list will be kept open for IPFIX-related discussions . New work could be handled in the opsarea wg. Other Business - IE Doctors. Benoit proposed adding Andrew Ferren to the IE Doctors. Feedback on that is welcome on the list. There was no Other Business. The meeting finished at 1800 -- --------------------------------------------------------------------- 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 ben@nostrum.com Tue Nov 19 13:17:14 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 894EF1ADF4B; Tue, 19 Nov 2013 13:17:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.036 X-Spam-Level: X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RPGW8GAx5XwT; Tue, 19 Nov 2013 13:17:13 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 564D21AE150; Tue, 19 Nov 2013 13:17:13 -0800 (PST) Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id rAJLH4SI052101 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 19 Nov 2013 15:17:06 -0600 (CST) (envelope-from ben@nostrum.com) From: Ben Campbell Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 19 Nov 2013 15:17:03 -0600 Message-Id: <9F0317F4-CAC5-49C7-89C8-199FA2B78DF0@nostrum.com> To: draft-ietf-ipfix-data-link-layer-monitoring.all@tools.ietf.org, ipfix@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) X-Mailer: Apple Mail (2.1822) Received-SPF: pass (shaman.nostrum.com: 173.172.146.58 is authenticated by a trusted mechanism) X-Mailman-Approved-At: Tue, 19 Nov 2013 13:18:54 -0800 Cc: "gen-art@ietf.org Team \(gen-art@ietf.org\)" Subject: [IPFIX] Gen-ART Telechat Review of draft-ietf-ipfix-data-link-layer-monitoring-07 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Nov 2013 21:17:14 -0000 I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at < http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-ipfix-data-link-layer-monitoring-07 Reviewer: Ben Campbell Review Date: 2013-11-19 IESG Telechat date: 2013-11-21 Summary: This draft is essentially ready for publication as a standards = track RFC. However, there is one issue that I unfortunately missed in my = last call review of version 06 that should be considered prior to = publication. Major issues: None Minor issues: There's a normative downref to RFC 2804, which is informational. That = seems a really odd draft for a normative reference. There may be = precedent, as I note that RFC 5477, referenced here for security = considerations, does the same thing. I apologize for bringing this up = this late in the process--I missed it in my earlier review at last call. As I understand it the context is that certain data elements can include = payload octets. This is subject to the security considerations in 5477, = which basically say don't include too much, because of guidance from = 2804. But my reading of 2804 does not give specific guidance things like = how much payload one can capture before it becomes too much. I think the simplest solution would be to keep the reference to the 5477 = security considerations, and reiterate that this model is not intended = for gross capture of payloads, perhaps with an _informative_ reference = to 2804. Nits/editorial comments: None= From bclaise@cisco.com Thu Nov 21 03:45:55 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4A821ADFA8; Thu, 21 Nov 2013 03:45:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.026 X-Spam-Level: X-Spam-Status: No, score=-10.026 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JIb-cRPxJ71V; Thu, 21 Nov 2013 03:45:53 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id BF64C1ACC89; Thu, 21 Nov 2013 03:45:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1932; q=dns/txt; s=iport; t=1385034346; x=1386243946; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=Qc+ZAnx340mgYJFQ9Yl/gMH+XEg1G4OAn1xayvlbBho=; b=f0FC1QefOjzgNuoTfnom1UyZYTXoFxD5EmbqDx89JljW6uABvBy27/Jm 9G0mmVpCakv2MiBn2YX6JLyBmLt60Hpx7RA9mDxg+BYXOgwFQeYCKZhLs wqmSAHZpM6wXXrxYEAZDNtQf0cNSLPi3a8z3kzZHBpZOa5b4X9zS7+G8J M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah0FAHXvjVKQ/khN/2dsb2JhbABZgwc4vU+BHxZ0giUBAQEDAThAARALFA0WDwkDAgECAUUGAQwBBwEBF4dgBg3Ac40WglUHhDIDmBKBMIUSi06DKTs X-IronPort-AV: E=Sophos;i="4.93,743,1378857600"; d="scan'208";a="363534" Received: from ams-core-4.cisco.com ([144.254.72.77]) by aer-iport-2.cisco.com with ESMTP; 21 Nov 2013 11:45:45 +0000 Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id rALBjd9s026247; Thu, 21 Nov 2013 11:45:40 GMT Message-ID: <528DF263.3010908@cisco.com> Date: Thu, 21 Nov 2013 12:45:39 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Ben Campbell , draft-ietf-ipfix-data-link-layer-monitoring.all@tools.ietf.org, ipfix@ietf.org References: <9F0317F4-CAC5-49C7-89C8-199FA2B78DF0@nostrum.com> In-Reply-To: <9F0317F4-CAC5-49C7-89C8-199FA2B78DF0@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "gen-art@ietf.org Team \(gen-art@ietf.org\)" Subject: Re: [IPFIX] Gen-ART Telechat Review of draft-ietf-ipfix-data-link-layer-monitoring-07 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2013 11:45:55 -0000 Hi Ben, Thanks for your review. See in-line. > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at > < http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. > > Please wait for direction from your document shepherd > or AD before posting a new version of the draft. > > Document: draft-ietf-ipfix-data-link-layer-monitoring-07 > Reviewer: Ben Campbell > Review Date: 2013-11-19 > IESG Telechat date: 2013-11-21 > > Summary: This draft is essentially ready for publication as a standards track RFC. However, there is one issue that I unfortunately missed in my last call review of version 06 that should be considered prior to publication. > > Major issues: > > None > > Minor issues: > > There's a normative downref to RFC 2804, which is informational. That seems a really odd draft for a normative reference. There may be precedent, as I note that RFC 5477, referenced here for security considerations, does the same thing. Actually RFC 5477 uses an informative reference to RFC 2804. > I apologize for bringing this up this late in the process--I missed it in my earlier review at last call. > > As I understand it the context is that certain data elements can include payload octets. This is subject to the security considerations in 5477, which basically say don't include too much, because of guidance from 2804. But my reading of 2804 does not give specific guidance things like how much payload one can capture before it becomes too much. > > I think the simplest solution would be to keep the reference to the 5477 security considerations, and reiterate that this model is not intended for gross capture of payloads, perhaps with an _informative_ reference to 2804. The informative reference would be in line with RFC 5477. So yes. Not sure if we need the reiteration. Regards, Benoit > > Nits/editorial comments: > > None. > From paitken@cisco.com Thu Nov 21 06:21:41 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 289BD1AE172; Thu, 21 Nov 2013 06:21:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.026 X-Spam-Level: X-Spam-Status: No, score=-10.026 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lRVPwN7VfdfP; Thu, 21 Nov 2013 06:21:39 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id CD8CF1AE180; Thu, 21 Nov 2013 06:21:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1800; q=dns/txt; s=iport; t=1385043692; x=1386253292; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=l3Kvaa+KXS9JbrrSiWjv7xXkcBVrdWDkeO2CyFYKGRU=; b=j51geSeu0i180rByu5JaPvICr4QFZ7ePebKNnDx66VeBO3GV2+HNP9Pg UPnIWQPHXsYMWnjPnLC3haWPAWkRJHt5Tp5BUUekshd5K7xXJJuepzD+c UTzLONvx9MLsTxGxd6NCSN37t4VzoALdfz2tcA04rPIbDna668VRv6+5t 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhkFAKoVjlKQ/khM/2dsb2JhbABZgwc4vVKBIhZ0giUBAQEEOEABEAsUBAkWDwkDAgECAUUGAQwBBwEBF4dmDcEMF40WglUHhDIDmBKBMIUSi06DKA X-IronPort-AV: E=Sophos;i="4.93,744,1378857600"; d="scan'208";a="371162" Received: from ams-core-3.cisco.com ([144.254.72.76]) by aer-iport-2.cisco.com with ESMTP; 21 Nov 2013 14:21:31 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id rALELP3M001189 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Nov 2013 14:21:27 GMT Received: from [10.61.102.55] (dhcp-10-61-102-55.cisco.com [10.61.102.55]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id rALELNNu018400; Thu, 21 Nov 2013 14:21:24 GMT Message-ID: <528E16DE.7090704@cisco.com> Date: Thu, 21 Nov 2013 14:21:18 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Ben Campbell , draft-ietf-ipfix-data-link-layer-monitoring.all@tools.ietf.org, ipfix@ietf.org References: <9F0317F4-CAC5-49C7-89C8-199FA2B78DF0@nostrum.com> In-Reply-To: <9F0317F4-CAC5-49C7-89C8-199FA2B78DF0@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "gen-art@ietf.org Team \(gen-art@ietf.org\)" Subject: Re: [IPFIX] Gen-ART Telechat Review of draft-ietf-ipfix-data-link-layer-monitoring-07 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2013 14:21:41 -0000 Thanks Ben, we'll move 2804 to an informative reference. P. On 19/11/2013 21:17, Ben Campbell wrote: > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at > < http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. > > Please wait for direction from your document shepherd > or AD before posting a new version of the draft. > > Document: draft-ietf-ipfix-data-link-layer-monitoring-07 > Reviewer: Ben Campbell > Review Date: 2013-11-19 > IESG Telechat date: 2013-11-21 > > Summary: This draft is essentially ready for publication as a standards track RFC. However, there is one issue that I unfortunately missed in my last call review of version 06 that should be considered prior to publication. > > Major issues: > > None > > Minor issues: > > There's a normative downref to RFC 2804, which is informational. That seems a really odd draft for a normative reference. There may be precedent, as I note that RFC 5477, referenced here for security considerations, does the same thing. I apologize for bringing this up this late in the process--I missed it in my earlier review at last call. > > As I understand it the context is that certain data elements can include payload octets. This is subject to the security considerations in 5477, which basically say don't include too much, because of guidance from 2804. But my reading of 2804 does not give specific guidance things like how much payload one can capture before it becomes too much. > > I think the simplest solution would be to keep the reference to the 5477 security considerations, and reiterate that this model is not intended for gross capture of payloads, perhaps with an _informative_ reference to 2804. > > Nits/editorial comments: > > None From ben@nostrum.com Thu Nov 21 08:18:17 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C1081ADF88; Thu, 21 Nov 2013 08:18:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.036 X-Spam-Level: X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4duv1Szuz8EO; Thu, 21 Nov 2013 08:18:15 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 738BA1ADF65; Thu, 21 Nov 2013 08:18:15 -0800 (PST) Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id rALGI2ds067290 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 21 Nov 2013 10:18:03 -0600 (CST) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ben Campbell In-Reply-To: <528DF263.3010908@cisco.com> Date: Thu, 21 Nov 2013 10:18:02 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9F0317F4-CAC5-49C7-89C8-199FA2B78DF0@nostrum.com> <528DF263.3010908@cisco.com> To: Benoit Claise X-Mailer: Apple Mail (2.1822) Received-SPF: pass (shaman.nostrum.com: 173.172.146.58 is authenticated by a trusted mechanism) X-Mailman-Approved-At: Thu, 21 Nov 2013 12:13:05 -0800 Cc: "gen-art@ietf.org Team \(gen-art@ietf.org\)" , draft-ietf-ipfix-data-link-layer-monitoring.all@tools.ietf.org, ipfix@ietf.org Subject: Re: [IPFIX] Gen-ART Telechat Review of draft-ietf-ipfix-data-link-layer-monitoring-07 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2013 16:18:17 -0000 On Nov 21, 2013, at 5:45 AM, Benoit Claise wrote: > Hi Ben, >=20 > Thanks for your review. > See in-line. >> I am the assigned Gen-ART reviewer for this draft. For background on >> Gen-ART, please see the FAQ at >> < http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. >>=20 >> Please wait for direction from your document shepherd >> or AD before posting a new version of the draft. >>=20 >> Document: draft-ietf-ipfix-data-link-layer-monitoring-07 >> Reviewer: Ben Campbell >> Review Date: 2013-11-19 >> IESG Telechat date: 2013-11-21 >>=20 >> Summary: This draft is essentially ready for publication as a = standards track RFC. However, there is one issue that I unfortunately = missed in my last call review of version 06 that should be considered = prior to publication. >>=20 >> Major issues: >>=20 >> None >>=20 >> Minor issues: >>=20 >> There's a normative downref to RFC 2804, which is informational. That = seems a really odd draft for a normative reference. There may be = precedent, as I note that RFC 5477, referenced here for security = considerations, does the same thing. > Actually RFC 5477 uses an informative reference to RFC 2804. Oops sorry, missed that. But it does cite 2804 in the same context (i.e. = capture payload octets, subject to [RFC 2804] >> I apologize for bringing this up this late in the process--I missed = it in my earlier review at last call. >>=20 >> As I understand it the context is that certain data elements can = include payload octets. This is subject to the security considerations = in 5477, which basically say don't include too much, because of guidance = from 2804. But my reading of 2804 does not give specific guidance things = like how much payload one can capture before it becomes too much. >>=20 >> I think the simplest solution would be to keep the reference to the = 5477 security considerations, and reiterate that this model is not = intended for gross capture of payloads, perhaps with an _informative_ = reference to 2804. > The informative reference would be in line with RFC 5477. So yes. > Not sure if we need the reiteration. I think a sentence or two would save the reader from having to flip back = and forth between docs. But it's not a big deal one way or ahother. Thanks! Ben.= From internet-drafts@ietf.org Mon Nov 25 22:41:51 2013 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CE2F1AE186; Mon, 25 Nov 2013 22:41:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EhS2zAmgbWhO; Mon, 25 Nov 2013 22:41:49 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E2DF51AC3FA; Mon, 25 Nov 2013 22:41:49 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131126064149.9700.83136.idtracker@ietfa.amsl.com> Date: Mon, 25 Nov 2013 22:41:49 -0800 Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action: draft-ietf-ipfix-mediation-protocol-08.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Nov 2013 06:41:51 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IP Flow Information Export Working Group = of the IETF. Title : Operation of the IP Flow Information Export (IPFIX) Prot= ocol on IPFIX Mediators Author(s) : Benoit Claise Atsushi Kobayashi Brian Trammell Filename : draft-ietf-ipfix-mediation-protocol-08.txt Pages : 29 Date : 2013-11-25 Abstract: This document specifies the operation of the IP Flow Information Export (IPFIX) protocol specific to IPFIX Mediators, including Template and Observation Point management, timing considerations, and other Mediator-specific concerns. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipfix-mediation-protocol There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ipfix-mediation-protocol-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipfix-mediation-protocol-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/