From trammell@tik.ee.ethz.ch Wed Oct 2 02:11:40 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 05B6421E82DB for ; Wed, 2 Oct 2013 02:11:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qvxcZgxsXvnI for ; Wed, 2 Oct 2013 02:11:29 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 6E56321F9CAC for ; Wed, 2 Oct 2013 02:08:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 44841D930D; Wed, 2 Oct 2013 11:08:14 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id pt5zi7IHh03N; Wed, 2 Oct 2013 11:08:14 +0200 (MEST) Received: from [10.0.27.100] (cust-integra-122-165.antanet.ch [80.75.122.165]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id CEC2DD9300; Wed, 2 Oct 2013 11:08:13 +0200 (MEST) Content-Type: multipart/signed; boundary="Apple-Mail=_3E139589-AB47-4D1C-B5E6-E872A9594003"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Brian Trammell In-Reply-To: <5220B1A5.5090001@plixer.com> Date: Wed, 2 Oct 2013 11:08:13 +0200 Message-Id: <40457B0A-6D41-4DA0-8F99-3D1879EB54F1@tik.ee.ethz.ch> References: <5202C647.5030204@auckland.ac.nz> <521C1DC8.2070102@auckland.ac.nz> <5220B1A5.5090001@plixer.com> To: Andrew Feren X-Mailer: Apple Mail (2.1510) Cc: IPFIX Working Group Subject: Re: [IPFIX] WG Last call for draft-ietf-ipfix-mediation-protocol-06.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: Wed, 02 Oct 2013 09:11:40 -0000 --Apple-Mail=_3E139589-AB47-4D1C-B5E6-E872A9594003 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, Andrew, Apologies for letting this one sail by unanswered, and many thanks for = the review. Comments thereon inline. On Aug 30, 2013, at 4:52 PM, Andrew Feren wrote: > Hi Nevil, all, >=20 > I missed last call, but as no one else has posted anything here are my = comments. >=20 > First, I think something like this document is needed, but I'd prefer = the language to be a bit more general in a number of places. I also = have a number of specific issues. This has been an extremely difficult document to write for exactly this = reason -- we have tried to be as general as possible, but too general = and the document says nothing, while too specific and it's unclear if = the section is to have general applicability. > An IPFIX Mediator converts a record stream to IPFIX and a record = stream can be "IPFIX Data Records or any other format", but other than = those points in the Terminology section this document seems to assume = IPFIX input. >=20 > For example: > Original Exporter: An Original Exporter is an IPFIX Device that > hosts the Observation Points where the metered IP packets are > observed. >=20 > I have a need for something very much like originalExporterIPv4Address = except that my data source(s) fall under that "any other format" = umbrella and are not IPFIX devices. I'd prefer to see = originalSenderIPv4Address (or some such) rather than an IE for each = non-IPFIX source. I actually think that the "original exporter" concept can be extended to = "the place I got this data from, regardless of how"; I'd be in favor of = striking IPFIX Device from the definition. Note: there may be effects on = already registered IEs here, will have to check. > If there is a need to know that the original source was IPFIX or = something else I'd prefer an additional IE for originalSenderFormat. = Probably with a registry of known formats. I don't have a use case for = this IE at the moment, but perhaps there is a need. Why would there be?=20 For archival purposes, it might be useful to have metadata about the = protocols/representations in order to make judgements based on design = characteristics/design flaws therein; however, if you're _really_ = getting into storing archival information, you need implementation = details and patchlevels. A complete data provenance framework for IPFIX = would be an interesting problem to tackle if we had a few spare years, = but I think we're pretty firmly in diminishing returns territory here. > In section 3 "Note that the format is compatible > with the IPFIX Message Header defined in > [I-D.ietf-ipfix-protocol-rfc5101bis], with some field definitions > (for the example, the Export Time) updated in the context of the > IPFIX Mediator." >=20 > I don't like this at all. Does an exporter send IPFIX or something = compatible with IPFIX? The philosophical question: is there something compatible with IPFIX = that is not IPFIX? Though in terms of wording, "interoperable with" may = be better. Actually, there are a couple of problems with this paragraph = on review. Your replacement text below is a definite improvement. > For example Export Time "MAY use the export time received from the = incoming Transport Session". I think I understand the motivation behind = this, but at the collector I have no way to know which export time is = being used. How do I know if the time applies to the original or = mediator? =20 Why do you care? The only use for Export Time is as a basetime for the = delta timestamps (which themselves are not recommended in cases where = mediators apply, see Section 7 paragraph 2) and for template action = sequencing (as in Section 8.2 of RFC 7011). I guess it could also be = useful to display to the operator for debugging the infrastructure. Any = other assumptions based on Export Time are not covered by the warranty. = :) > I'd rather not see this exception unless someone can explain how it is = useful. >=20 > The text for sequence number doesn't match 5101bis. More generally I = think it is confusing to include all that copy paste text in this = document. I'd rather see a reference to 5101bis followed by a list of = special circumstances. >=20 > Something like > The format of the IPFIX Message Header as exported by an IPFIX > Mediator is the same as [RFC5102bis]. >=20 > See Section 4.1 for special considerations for Observation Domain > management while passing unmodified templates through an IPFIX > Mediator, and Section 5 for guidelines for preservation of > original Observation Domain information at an IPFIX Mediator. Yep, this is good; will take it into a new rev. > That makes it obvious what is special or different(*shudder*) relative = to IPFIX. Again, the changes here are not a problem from an interoperability = standpoint. You shouldn't be relying on any assumptions about export = time beyond the guarantees in 7011 section 8.2, or on _any_ information = about the Observation Domain other than it's the root scope for options = and template IDs. > Section 4.1 and 4.3 discuss two situations when a Mediator MUST NOT = reorder and fields in a record. Additionally, if an IE occurs more than = once in a template that order also MUST NOT be modified. I would think = that this situation should also be treated similarly to unknown IEs = either resend all or none. >=20 > 4.2 starts with "The second case". I'm not entirely sure what was = first. >=20 > In section 4.3 >=20 > " Depending on application requirements, Mediators which do not > generate new Records SHOULD re-export values for unknown Information > Elements, whether enterprise-specific Information Elements or > Information Elements in the IPFIX Information Element registry > [iana-ipfix-assignments]. added since the Mediator was implemented = or > updated." >=20 > That sentence seems a bit long and complicated. At the very least I = think the '.' before added needs to be removed. =20 Yep. > Although I'd prefer to simplify it. I think it is enough to state = that "An IE is considered unknown if its data type and semantics are not = known to the Mediator." Trying to list the reasons it might not be = known just complicates things IMO. Also yep. Thanks. > I didn't fully grok Section 5, but "[RFC6313] MUST be used" bothers = me. The intention here is MAY export, if export MUST 6313. The language = should be clearer about that. > Mostly because from a collector perspective I really don't like 6313 = at all and subTemplateMultiList in particular. Is 6313 really the only = way to export this data? Why? Well, you could have a template with multiple instances of an OP = identifier, or multiple records scoped with options, neither of which is = pretty. Whether I think it's more or less pretty than 6313 I'll leave as = an exercise to the reader. The problem isn't the complexity of 6313, = though, it's the complexity of the underlying measurement surface. = Encoding it differently won't make that complexity go away. On the other hand, it's unclear that given arbitrarily complex semantics = that a collector can or should do anything with this _other_ than simply = stick it on disk somewhere for subsequent human interpretation. > Section 7 timing constraints refers to relative timestamps as = "difficult to manage". I think "impossible to manage" is closer to the = mark. A collector can get sysUpTime from a v9 header. For IPFIX I'm no = sure where I get sysUpTime from. Perhaps there needs to be a = requirement for Mediators converting v9 to IPFIX to translate relative = times to absolute times. Most of the time, yes. There are simple cases, and again, we're trying = to be as general as we can while still having something to say. Will spin out a -07 revision in the next couple of days with the edits = here. Again, many thanks for the review! Cheers, Brian > Better late than never I guess, > -Andrew >=20 > On 08/26/2013 11:32 PM, Nevil Brownlee wrote: >>=20 >> Hi all: >>=20 >> This WGLC has finished, with no comments at all on the list. >> I need at least a few "looks OK to me" or "I can live with that" >> responses before I can put together its Shepherd writeup! >>=20 >> Cheers, Nevil >>=20 >>=20 >> On 8/08/13 10:12 AM, Nevil Brownlee wrote: >>>=20 >>> Hi all: >>>=20 >>> The -06 version of IPFIX Mediation Protocol was published last week, >>> now it's time for its WG Last Call. >>>=20 >>> The WGLC starts now, and will run until Friday, 23 August. >>>=20 >>> Please read the draft and send your comments/suggestions to the = list. >>> Actual reviews of the draft would be much appreciated, but a brief >>> comment saying "I read it, it's fine" is useful too! >>>=20 >>> Cheers, Nevil >>=20 >=20 > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix --Apple-Mail=_3E139589-AB47-4D1C-B5E6-E872A9594003 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJSS+J9AAoJENt3nsOmbNJcNXUIANCD7QjJ1wZGuprSJvlt1KB6 ubR05vc6v8dgBAHfO/Gr2iBKMeeQShy4w4EYmg8oKXX9v0+ojFnnYXj2WzWAzzd7 Ixnm/xuepC506n/l+177w4m8raiEkO3VPvEHnkhvy+g8AY2tSP+2DAKIjV/2nJp2 XlQLJWQic8Uz2xUhzkzyxtA54NXiVIf65SVCbhMaqaPDfOG4rmho1xNak4RNFoBZ tkAuorScUrPz1TZkQRIJ4XqI+QyR1ux/si/hM5yraF4EyczB2uTIFNzViCMSrTBH Adt/WETNZN7dttaQuu4o2AQU4v89lDoO4OQoSkpauJpveRP4nL4cAz0a2pPSBwM= =QU+V -----END PGP SIGNATURE----- --Apple-Mail=_3E139589-AB47-4D1C-B5E6-E872A9594003-- From internet-drafts@ietf.org Fri Oct 4 07:31:51 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 B5A8021F9C3A; Fri, 4 Oct 2013 07:31:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.542 X-Spam-Level: X-Spam-Status: No, score=-102.542 tagged_above=-999 required=5 tests=[AWL=0.058, 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 ejZsPO1uwKiD; Fri, 4 Oct 2013 07:31:44 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 63DF721F9DA9; Fri, 4 Oct 2013 07:28:11 -0700 (PDT) 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.80 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131004142811.12797.72727.idtracker@ietfa.amsl.com> Date: Fri, 04 Oct 2013 07:28:11 -0700 Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action: draft-ietf-ipfix-mediation-protocol-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: Fri, 04 Oct 2013 14:31: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-07.txt Pages : 28 Date : 2013-10-04 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-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipfix-mediation-protocol-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 n.brownlee@auckland.ac.nz Sun Oct 6 19:56:18 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 69DEC21E8137 for ; Sun, 6 Oct 2013 19:56:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 SU2x5DOIkmYN for ; Sun, 6 Oct 2013 19:56:13 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) by ietfa.amsl.com (Postfix) with ESMTP id 960C621E811F for ; Sun, 6 Oct 2013 19:56:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1381114565; x=1412650565; h=message-id:date:from:mime-version:to:cc:subject: content-transfer-encoding; bh=aaGfUXzEygnxMjqWByXPKgMZsrbGYFNa47JK1XfwUdo=; b=ueAKfkyZJ+3bEaCeElxqHXDis3mf/bLgmf8jZJhEhyUDoVIq6Zg61Rk8 lb7OH9KpVbOqnCqHNw0Hd9U6aBLohELKOyZKZRXg4aWCa2Yqgq2p63999 tn/ri3oGuY4QbbR/XZw8diHBNEQ+lImLJTxPswlter/00CQS14ilq3H21 Q=; X-IronPort-AV: E=Sophos;i="4.90,1047,1371038400"; d="scan'208";a="216243054" X-Ironport-HAT: UNIVERSITY - $RELAY-THROTTLE X-Ironport-Source: 130.216.38.131 - Outgoing - Outgoing-SSL Received: from nevil-laptop1.sfac.auckland.ac.nz (HELO [130.216.38.131]) ([130.216.38.131]) by mx2-int.auckland.ac.nz with ESMTP; 07 Oct 2013 15:56:01 +1300 Message-ID: <525222C0.8090807@auckland.ac.nz> Date: Mon, 07 Oct 2013 15:56:00 +1300 From: Nevil Brownlee User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "ipfix-ads@tools.ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPFIX Working Group Subject: [IPFIX] Write-=up submitted for mediation-protocol-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, 07 Oct 2013 02:56:18 -0000 Hi Joel and Benoit: I've put the write-up for "Operation of the IP Flow Information Export (IPFIX) Protocol on IPFIX Mediators" on its Tracker page. Please start it on its path through IESG. Cheers, Nevil -- --------------------------------------------------------------------- Nevil Brownlee Computer Science Department Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand From bclaise@cisco.com Mon Oct 7 05:24:12 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 BA71E21E81C6 for ; Mon, 7 Oct 2013 05:24:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.556 X-Spam-Level: X-Spam-Status: No, score=-10.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 IrBa-g+oIbd5 for ; Mon, 7 Oct 2013 05:24:07 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 6531421E8090 for ; Mon, 7 Oct 2013 05:24:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=981; q=dns/txt; s=iport; t=1381148647; x=1382358247; h=message-id:date:from:mime-version:to:cc:subject: content-transfer-encoding; bh=RiESrX2mONLXUrN5/R/W6tI3dCI46EI39f2FVaZgmOo=; b=ZY12xb9AlnkSbUkdQLj+5XhyKTGe0Xs2MZU1R0ZYpe6VvgUyOwRIGuy+ rehhFD+LJEP/P9Xu0qUkkXGfrPGxlrNmbmrSt2w9bW1ghVpb/Gj2Z7hoX /9DhT65BaCwRxI+cLoPoACJXldUMwcIwBIdN1eqmrAByDfrjE3gR7Mugk o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiEFAIOmUlKQ/khR/2dsb2JhbABZgwe/LIJ5gR0WdIJkQAE8FhgDAgECAVgBBwEBiAK7AI9RHYQNA5gBhjaLSoMmOg X-IronPort-AV: E=Sophos;i="4.90,1050,1371081600"; d="scan'208";a="87235136" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 07 Oct 2013 12:24:06 +0000 Received: from [10.61.194.168] ([10.61.194.168]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r97CO1AE027827; Mon, 7 Oct 2013 12:24:03 GMT Message-ID: <5252A7E1.7090700@cisco.com> Date: Mon, 07 Oct 2013 14:24:01 +0200 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: draft-trammell-ipfix-tcpcontrolbits-revision@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ipfix@ietf.org" Subject: [IPFIX] AD review: draft-trammell-ipfix-tcpcontrolbits-revision-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, 07 Oct 2013 12:24:12 -0000 Dear all, I accepted to AD sponsor this document. Here is my review. Do we need to say "update RFC 5102"? Not sure myself. On one side, we update an IE specified in RFC 5102 On the other side, RFC 7012 says that the registry is THE reference. Personally, I would have gone with the update path. Anyway, not a blocking factor to progress the document. I will check with IANA. OLD: IANA will update the definition of the tcpControlBits Information Element in the the IANA IPFIX Information Element Registry [IANA-IPFIX] to reflect the changes in Section 2 above. NEW: IANA updates the definition of the tcpControlBits Information Element in the the IANA IPFIX Information Element Registry [IANA-IPFIX] to reflect the changes in Section 2 above. There are a couple of nits, specifically because RFC 7011, 7012, 7013 have been published. Please post a new version, and I'll progress the document. Regards, Benoit From trammell@tik.ee.ethz.ch Mon Oct 7 08:08:24 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 1BA3111E8152 for ; Mon, 7 Oct 2013 08:08:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 LYMnhJWw47tv for ; Mon, 7 Oct 2013 08:08:17 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 73FA511E814C for ; Mon, 7 Oct 2013 08:08:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 79A62D9317; Mon, 7 Oct 2013 17:08:03 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id fH8v61YmWrLw; Mon, 7 Oct 2013 17:08:03 +0200 (MEST) Received: from pb-10243.ethz.ch (pb-10243.ethz.ch [82.130.102.152]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 3558ED9305; Mon, 7 Oct 2013 17:08:03 +0200 (MEST) Content-Type: multipart/signed; boundary="Apple-Mail=_63E6A466-31DA-4DAC-A69F-A0CB56DDD57D"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Brian Trammell In-Reply-To: <5252A7E1.7090700@cisco.com> Date: Mon, 7 Oct 2013 17:08:02 +0200 Message-Id: <94B46726-CA74-4340-BAF8-25A49C0F266F@tik.ee.ethz.ch> References: <5252A7E1.7090700@cisco.com> To: Benoit Claise X-Mailer: Apple Mail (2.1510) Cc: draft-trammell-ipfix-tcpcontrolbits-revision@tools.ietf.org, "ipfix@ietf.org" Subject: Re: [IPFIX] AD review: draft-trammell-ipfix-tcpcontrolbits-revision-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, 07 Oct 2013 15:08:24 -0000 --Apple-Mail=_63E6A466-31DA-4DAC-A69F-A0CB56DDD57D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii hi Benoit, Thanks; comments inline... On 7 Oct 2013, at 14:24 , Benoit Claise wrote: > Dear all, >=20 > I accepted to AD sponsor this document. >=20 > Here is my review. >=20 > Do we need to say "update RFC 5102"? Not sure myself. > On one side, we update an IE specified in RFC 5102 > On the other side, RFC 7012 says that the registry is THE reference. Given that, there's no need to update 5102; I've changed the abstract to = make this a bit more clear: This document revises the tcpControlBits IPFIX Information Element as = originally defined in=20 [RFC5102] to reflect changes to the TCP Flags header field since = [RFC0793]. ^^ added "as originally defined" to make it clear that 5102 is the = source, not the authority. The change does replace revision 0 of the IE in the registry with = revision 1; I'll change the IANA Considerations section to make this = more explicit, too. > Personally, I would have gone with the update path. > Anyway, not a blocking factor to progress the document. I will check = with IANA. >=20 > OLD: >=20 > IANA will update the definition of the tcpControlBits Information > Element in the the IANA IPFIX Information Element Registry > [IANA-IPFIX] to reflect the changes in Section 2 above. >=20 > NEW: >=20 > IANA updates the definition of the tcpControlBits Information > Element in the the IANA IPFIX Information Element Registry > [IANA-IPFIX] to reflect the changes in Section 2 above. Changed to past-tense instead. >=20 > There are a couple of nits, specifically because RFC 7011, 7012, 7013 = have been published. Fixed the references. > Please post a new version, and I'll progress the document. Will do shortly. Cheers, Brian --Apple-Mail=_63E6A466-31DA-4DAC-A69F-A0CB56DDD57D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJSUs5SAAoJENt3nsOmbNJcIOoIAM2jamjHfDr1B/07iUdgfNeR J1+qRMhct9bZ7cfC6HCWOfyrjwoKVubBAsiJuMRl47vPfj6fBiYkenqKFQLcW+y4 Ylo/BpG76cyyqwAtwlHxoeoC0nZ3EPKjauTu5w+cGkQvDQslUzVJtTFDp9CEGXxC k58weIL83vD3SSe9yWxdhjuROXZYhNU8h0FKyG1KolzvMAShAwvydZJxRJlWZrLP OCdpYwKBPHM8TvHw8yNOQX6UEb7DlJQl9q7kyouPMPoOOpps1QZP6wNX3fjR9Sh7 5gyjwk+iQDkSP005mgVkljN441cbm1LzfrFRoYbMBvGyP2/9Rf1dBOYxJclU0c8= =i+vH -----END PGP SIGNATURE----- --Apple-Mail=_63E6A466-31DA-4DAC-A69F-A0CB56DDD57D-- From bclaise@cisco.com Mon Oct 7 09:09:16 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 EB29D21E8093 for ; Mon, 7 Oct 2013 09:09:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.557 X-Spam-Level: X-Spam-Status: No, score=-10.557 tagged_above=-999 required=5 tests=[AWL=0.042, 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 ywGQO-OjKUZ3 for ; Mon, 7 Oct 2013 09:09:10 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id B8F7521E80B6 for ; Mon, 7 Oct 2013 09:09:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2063; q=dns/txt; s=iport; t=1381162147; x=1382371747; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=UmHqt3UiRDhP0CmI7HGrKu4ZFHNv3Ttcm9QDSM/VMUk=; b=DVc1fjJS8872fCIdVMhBT3PxCufkITNccv9/R3IvshQzfSAS8YkM5B+J oRx/O4TARa6+P/0hWZ4NJQS7C3qkiTMzFk6Nt2n8orWwu6tTgH62p+QR+ 3Q4HiL3DmY4VWoqibr7hMToRhslz+i4zi93KwT2PAkkGQiSCDrpeh3A3g U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFAP7aUlKQ/khM/2dsb2JhbABZgwfCJIEeFnSCJQEBAQQ4QAEQCxgJFg8JAwIBAgFFBg0BBQIBAYgCulyPUQeEIwOYAYY2i0qDJjo X-IronPort-AV: E=Sophos;i="4.93,872,1378857600"; d="scan'208";a="18115207" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-3.cisco.com with ESMTP; 07 Oct 2013 16:09:03 +0000 Received: from [10.61.194.168] ([10.61.194.168]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r97G8vuP025195; Mon, 7 Oct 2013 16:08:59 GMT Message-ID: <5252DC99.4000403@cisco.com> Date: Mon, 07 Oct 2013 18:08:57 +0200 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: Brian Trammell References: <5252A7E1.7090700@cisco.com> <94B46726-CA74-4340-BAF8-25A49C0F266F@tik.ee.ethz.ch> In-Reply-To: <94B46726-CA74-4340-BAF8-25A49C0F266F@tik.ee.ethz.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-trammell-ipfix-tcpcontrolbits-revision@tools.ietf.org, "ipfix@ietf.org" Subject: Re: [IPFIX] AD review: draft-trammell-ipfix-tcpcontrolbits-revision-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, 07 Oct 2013 16:09:16 -0000 Hi Brian, > hi Benoit, > > Thanks; comments inline... > > On 7 Oct 2013, at 14:24 , Benoit Claise wrote: > >> Dear all, >> >> I accepted to AD sponsor this document. >> >> Here is my review. >> >> Do we need to say "update RFC 5102"? Not sure myself. >> On one side, we update an IE specified in RFC 5102 >> On the other side, RFC 7012 says that the registry is THE reference. > Given that, there's no need to update 5102; I've changed the abstract to make this a bit more clear: > > This document revises the tcpControlBits IPFIX Information Element as originally defined in > [RFC5102] to reflect changes to the TCP Flags header field since [RFC0793]. > ^^ > added "as originally defined" to make it clear that 5102 is the source, not the authority. > > The change does replace revision 0 of the IE in the registry with revision 1 "The change does replace revision 0 of the IE in the registry with revision 1" does the job for me. > ; I'll change the IANA Considerations section to make this more explicit, too. Ok; > >> Personally, I would have gone with the update path. >> Anyway, not a blocking factor to progress the document. I will check with IANA. >> >> OLD: >> >> IANA will update the definition of the tcpControlBits Information >> Element in the the IANA IPFIX Information Element Registry >> [IANA-IPFIX] to reflect the changes in Section 2 above. >> >> NEW: >> >> IANA updates the definition of the tcpControlBits Information >> Element in the the IANA IPFIX Information Element Registry >> [IANA-IPFIX] to reflect the changes in Section 2 above. > Changed to past-tense instead. good. > >> There are a couple of nits, specifically because RFC 7011, 7012, 7013 have been published. > Fixed the references. > >> Please post a new version, and I'll progress the document. > Will do shortly. Great. I'll progress the document from there. Regards, Benoit > > Cheers, > > Brian From bclaise@cisco.com Mon Oct 7 14:16:16 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 06B3E11E8171 for ; Mon, 7 Oct 2013 14:16:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ty2HN3PDeetH for ; Mon, 7 Oct 2013 14:15:57 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 8B4C711E816F for ; Mon, 7 Oct 2013 14:15:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=701; q=dns/txt; s=iport; t=1381180557; x=1382390157; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=lgb3bN1w0E27iYIs7fjRvkXxQ3GIRQ7zxSwOLukIW3k=; b=Uj81LdXcH0BLFDWHMcjMM8CfeKbjKLhx4nI7C6usPU8COQzp+Za3F8N0 R4J1qKJnhqf41QIL0a0/koESQ3bqEmxrk77ESKJvbfybzEM5DCdGbNZPw 56hbl3zZrhIKZLgYlI8mOzwx9fugDLYiy/BmG+sZChsZqHoJF+SqeVnEO 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjEGAB0kU1KrRDoG/2dsb2JhbABZgwc4g3qwe4x+gSMWbQeCJgEBBCMVPwERCxoCBRYLAgIJAwIBAgFFBg0IAQEFh3wNqH2SLoEpji+CaoE5A5gBgS+FB4tKgWaBQDo X-IronPort-AV: E=Sophos;i="4.90,1051,1371081600"; d="scan'208";a="94150693" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 07 Oct 2013 21:15:55 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r97LFrqu027632 for ; Mon, 7 Oct 2013 21:15:54 GMT Message-ID: <52532489.9040708@cisco.com> Date: Mon, 07 Oct 2013 23:15:53 +0200 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: "ipfix@ietf.org" References: <20131007195101.30013.49419.idtracker@ietfa.amsl.com> In-Reply-To: <20131007195101.30013.49419.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [IPFIX] New Version Notification - draft-trammell-ipfix-tcpcontrolbits-revision-04.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, 07 Oct 2013 21:16:16 -0000 Dear all, The IETF LC has been requested. Regards, Benoit > A new version (-04) has been submitted for draft-trammell-ipfix-tcpcontrolbits-revision: > http://www.ietf.org/internet-drafts/draft-trammell-ipfix-tcpcontrolbits-revision-04.txt > > > The IETF datatracker page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-trammell-ipfix-tcpcontrolbits-revision/ > > Diff from previous version: > http://www.ietf.org/rfcdiff?url2=draft-trammell-ipfix-tcpcontrolbits-revision-04 > > 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. > > IETF Secretariat. > > . > From bclaise@cisco.com Mon Oct 7 15:04:00 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 6A28F21E815B for ; Mon, 7 Oct 2013 15:04:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.565 X-Spam-Level: X-Spam-Status: No, score=-10.565 tagged_above=-999 required=5 tests=[AWL=0.034, 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 zB8KgnIOkpmQ for ; Mon, 7 Oct 2013 15:03:55 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 7649A11E813A for ; Mon, 7 Oct 2013 15:03:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=325; q=dns/txt; s=iport; t=1381183435; x=1382393035; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=UORYBJOnBYkyVw/DmG858xWNTr8RsSDomSG0a4Z3GRA=; b=eK47QIr+pjkq2AitWP1xFsoJzDURulA6Sw9nwiTSc4vX6Y9VX0ULHhQL e6qRO0ZjRdx4Q4UtzVEzAt/nQWc99vMvkXy8AskuijXhRy3whN7YmYORU Qur2luK6g/v/uf88FHzTQf66phTyw8gy6ljv6+EXt/W/jfkWgUEAkI29X s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsIFANQuU1KQ/khN/2dsb2JhbABZgwc4wWkBgSsWbQeCUxFAPRYYAwIBAgFLDQgBARiHagyZeKE4k3sDmAGBL4UHi0qDJjo X-IronPort-AV: E=Sophos;i="4.93,872,1378857600"; d="scan'208";a="18120818" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-3.cisco.com with ESMTP; 07 Oct 2013 22:03:54 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r97M3nQ8021261 for ; Mon, 7 Oct 2013 22:03:51 GMT Message-ID: <52532FC5.7030506@cisco.com> Date: Tue, 08 Oct 2013 00:03:49 +0200 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: "ipfix@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPFIX] IPFIX tutorial under the training tab in the IPFIX wiki 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, 07 Oct 2013 22:04:00 -0000 Dear all, From http://datatracker.ietf.org/wg/ipfix/charter/ -> Tools WG page -> Training tab Alternatively, directly go to http://trac.tools.ietf.org/wg/ipfix/trac/wiki/TrainingMaterials You will find a home for training material related to the WG charter, developed at the IETF. Regards, Benoit From n.brownlee@auckland.ac.nz Mon Oct 7 19:32:00 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 9BA8611E8170 for ; Mon, 7 Oct 2013 19:32:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 Fl65tYN1YPR5 for ; Mon, 7 Oct 2013 19:31:56 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) by ietfa.amsl.com (Postfix) with ESMTP id 35B0D11E8162 for ; Mon, 7 Oct 2013 19:31:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1381199516; x=1412735516; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=qOI6bSRmA/SH9/0EJSPQ7G59HdJlOHUge63rGdqo8AM=; b=FcCLAyItaftS5fCKbi+CsjMUQJc4hU9BcFKvzZ/l8kkroe/hx41+TevE yyovzSsYKwhbQF60CEjOOyCIR/dVgZpWhk6u4LQHl6/BmI69i8fOxtv0E QA6JRpz80WYMG1xmh1T/Rm5NaQ493/nKuRDuZxWQZzNryR1hoGUSlO0yr M=; X-IronPort-AV: E=Sophos;i="4.90,1053,1371038400"; d="scan'208";a="216468494" X-Ironport-HAT: UNIVERSITY - $RELAY-THROTTLE X-Ironport-Source: 130.216.38.131 - Outgoing - Outgoing-SSL Received: from nevil-laptop1.sfac.auckland.ac.nz (HELO [130.216.38.131]) ([130.216.38.131]) by mx2-int.auckland.ac.nz with ESMTP; 08 Oct 2013 15:31:50 +1300 Message-ID: <52536E95.5080905@auckland.ac.nz> Date: Tue, 08 Oct 2013 15:31:49 +1300 From: Nevil Brownlee User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: IPFIX Working Group References: <52527773.9020400@cisco.com> In-Reply-To: <52527773.9020400@cisco.com> X-Forwarded-Message-Id: <52527773.9020400@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPFIX] Fwd: Fwd: NOMCOM 2013 - Second Call for Nominations - two weeks left 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, 08 Oct 2013 02:32:00 -0000 -------- Original Message -------- Subject: Fwd: NOMCOM 2013 - Second Call for Nominations - two weeks left Resent-To: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , Date: Mon, 7 Oct 2013 10:57:23 +0200 From: Benoit Claise To: ops-chairs@tools.ietf.org Please forward to your WGs. Regards, Benoit -------- Original Message -------- Subject: NOMCOM 2013 - Second Call for Nominations - two weeks left Date: Fri, 4 Oct 2013 10:31:49 -0700 From: NomCom Chair 2013 Reply-To: , , , <"2013 To: IETF Announcement List CC: IETF Discuss List Nominations for the IESG, IAB, and IAOC are due to the Nomcom by Friday, 18 October, 2013. Is there someone you work with at IETF who has leadership potential and a growing track record? Please read the Nomcom call for nominations and consider nominating her or him. Or several folks! Deadline for nominations is October 18. Nominate soon to give your nominee(s) plenty time to fill in the questionnaire. Information about the desired expertise for positions is here: https://datatracker.ietf.org/nomcom/2013/expertise Lots more, including which positions are open, how to make a nomination, and how to send us your feedback on the desired expertise, follows. IETFers, let's hear from you! Make nominations, accept nominations! If you have any questions about the process, feel free to get in touch with me. Best regards, Allison for the Nomcom Allison Mankin Nomcom Chair 2013-14 ----- The Info You Need for Nominating ----- The 2013-14 Nominating Committee (Nomcom) is seeking nominations from now until October 18, 2013. The open positions being considered by this year's Nomcom can be found later in this section, and also on this year's Nomcom website: https://datatracker.ietf.org/nomcom/2013/ Nominations may be made by selecting the Nominate link at the top of the Nomcom 2013 home page, or by visiting the following URL: https://datatracker.ietf.org/nomcom/2013/nominate/ Note that nominations made using the web tool require an ietf.org datatracker account. You can create a datatracker ietf.org account if you don't have one already by visiting the following URL: https://datatracker.ietf.org/accounts/create/ Nominations may also be made by email to nomcom13 at ietf.org. If you nominate by email, please include the word "Nominate" in the Subject and indicate in the email who is being nominated, their email address (to confirm acceptance of the nomination), and the position for which you are making the nomination. If you use email, please use a separate email for each person you nominate, and for each position (if you are nominating one person for multiple positions). Self-nomination is welcome! No need to be shy. Nomcom 2013-14 will follow the policy for "Open Disclosure of Willing Nominees" described in RFC 5680. As stated in RFC 5680: "The list of nominees willing to be considered for positions under review in the current Nomcom cycle is not confidential". Willing nominees for each position will be listed in a publicly accessible way - anyone with a datatracker account may access the lists. In all other ways, the confidentiality requirements of RFC 3777/BCP10 remain in effect. All feedback and all Nomcom deliberations will remain confidential and will not be disclosed. In order to ensure time to collect sufficient community feedback about each of the willing nominees, nominations must be received by the Nomcom on or before October 18, 2013. Please submit your nominations as early as possible for the sake of your nominees, as we've set the questionnaire submission deadline for October 25, 2013. The list of people and posts whose terms end with the March 2014 IETF meeting, and thus the positions for which we are accepting nominations: IAOC Chris Griffiths IAB Bernard Aboba Marc Blanchet Ross Callon Eliot Lear Hannes Tschofenig IESG Barry Leiba (Applications) Brian Haberman (Internet) Benoit Claise (Operations and Management) Gonzalo Camarillo (RAI) Stewart Bryant (Routing) Sean Turner (Security) Martin Stiemerling (Transport) Please be resourceful in identifying possible candidates for these positions, as developing our talent is a very crucial requirement for the IETF. Also, please give serious consideration to accepting nominations you receive. The summaries of the desired expertise for the positions, developed by the respective bodies, are found at: https://datatracker.ietf.org/nomcom/2013/expertise/ In addition to nominations, the Nomcom seeks community input on the positions themselves. We need and welcome the community's views and input on the jobs within each organization. If you have ideas on the positions' responsibilities (more, less, different), please let us know. You can send us email about this to nomcom13 at ietf.org, and we will use this feedback actively. Thank you for your help in nominating a great pool of strong and interesting nominees! . From internet-drafts@ietf.org Wed Oct 9 04:13: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 3575921E813F; Wed, 9 Oct 2013 04:13:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.573 X-Spam-Level: X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.027, 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 h66K+51AHg8p; Wed, 9 Oct 2013 04:13:13 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EF5F21E812F; Wed, 9 Oct 2013 04:13:13 -0700 (PDT) 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.80.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131009111313.11449.94941.idtracker@ietfa.amsl.com> Date: Wed, 09 Oct 2013 04:13:13 -0700 Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action: draft-ietf-ipfix-data-link-layer-monitoring-05.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: Wed, 09 Oct 2013 11:13:14 -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-05.txt Pages : 34 Date : 2013-10-09 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-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipfix-data-link-layer-monitor= ing-05 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 Wed Oct 9 04:19:10 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 AA42221E8149 for ; Wed, 9 Oct 2013 04:19:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[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 4Z4jBQTu8cE9 for ; Wed, 9 Oct 2013 04:19:05 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 5602D21E813D for ; Wed, 9 Oct 2013 04:19:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2156; q=dns/txt; s=iport; t=1381317545; x=1382527145; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=z++J5fStTNX/1UYm0fue4q3B3vU+22WfJWszNT87P3k=; b=eh0OUPxJTVSp3v03uijzGMZOdIgzdDwAn+VL8kl4bNU+IvTaVoCwJbVW pr6z5Ep80j4n6l+vzciQkWyD35MydAQM7H4MmM2xZ9ct7w1SDmiAmDFDm Fy+Qq8awwZEvONMtwbG1qmnpy3GRL3n19WlkzSCyfbbqzLBe7s6Jh0I8T w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAMU6VVKQ/khR/2dsb2JhbABagwc4wgOBIBZ0giUBAQEEAQEBNTYKEQsYCRYPCQMCAQIBFTATBgIBAQWHfQy4Zo9MFoQNA5gDgS+FCItKgyU X-IronPort-AV: E=Sophos;i="4.90,1062,1371081600"; d="scan'208";a="160483172" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 09 Oct 2013 11:19:01 +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 r99BIu2i007853 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 9 Oct 2013 11:18:58 GMT Received: from [144.254.153.55] (dhcp-144-254-153-55.cisco.com [144.254.153.55]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r99BIuLl006410 for ; Wed, 9 Oct 2013 12:18:56 +0100 (BST) Message-ID: <52553BA0.5000607@cisco.com> Date: Wed, 09 Oct 2013 12:18:56 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: ipfix@ietf.org References: <20131009111313.11449.94941.idtracker@ietfa.amsl.com> In-Reply-To: <20131009111313.11449.94941.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [IPFIX] draft-ietf-ipfix-data-link-layer-monitoring-05.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: Wed, 09 Oct 2013 11:19:10 -0000 Dear All, I've just posted draft-ietf-ipfix-data-link-layer-monitoring-05. Differences from -04 are minor: * Kobayashi is now listed as Editor. * Re-ordered the new field definitions so related fields are grouped more logically. * Changed dataLinkFrameType semantics to "flags" so that multiple observations can be OR'd together. * Several language improvements and typos fixed. * Renumbered all the TBDnn to remove gaps. * Formatting improvements in section 6. * Added IREF to IANA/IPFIX registry. Thanks, P. On 09/10/13 12:13, 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-05.txt > Pages : 34 > Date : 2013-10-09 > > 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-05 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-ipfix-data-link-layer-monitoring-05 > > > 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 From internet-drafts@ietf.org Wed Oct 9 04:40:00 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 F048E21F9FB1; Wed, 9 Oct 2013 04:39:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.573 X-Spam-Level: X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.027, 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 kc+ceNE+VKtk; Wed, 9 Oct 2013 04:39:59 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D835D21F9FF1; Wed, 9 Oct 2013 04:39:57 -0700 (PDT) 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.80.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131009113957.11449.54712.idtracker@ietfa.amsl.com> Date: Wed, 09 Oct 2013 04:39:57 -0700 Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action: draft-ietf-ipfix-data-link-layer-monitoring-06.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: Wed, 09 Oct 2013 11:40:00 -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-06.txt Pages : 34 Date : 2013-10-09 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-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipfix-data-link-layer-monitor= ing-06 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 andrewf@plixer.com Wed Oct 9 09:44:09 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 3989211E81A5 for ; Wed, 9 Oct 2013 09:44:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WEtoIK0C0c8Z for ; Wed, 9 Oct 2013 09:44:05 -0700 (PDT) Received: from mx1.plixer.com (mx1.plixer.com [64.140.243.154]) by ietfa.amsl.com (Postfix) with ESMTP id 3A87A11E81A0 for ; Wed, 9 Oct 2013 09:43:47 -0700 (PDT) Received: from [10.12.1.53] (64.140.243.154) by mx1.plixer.com (10.1.5.1) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 9 Oct 2013 12:43:45 -0400 Message-ID: <525587C8.1030604@plixer.com> Date: Wed, 9 Oct 2013 12:43:52 -0400 From: Andrew Feren User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: References: <20131004142811.12797.72727.idtracker@ietfa.amsl.com> In-Reply-To: <20131004142811.12797.72727.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Subject: Re: [IPFIX] I-D Action: draft-ietf-ipfix-mediation-protocol-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: Wed, 09 Oct 2013 16:44:09 -0000 Hi Benoit, Atsushi, and Brian, I have a few additional comments and questions. I like the clarification of the Original Exporter text. I'm not in love with including "Exporter" in the name. I think I'd prefer Original Data Source. If, for example, I write a mediator to pull SNMP values to export with IPFIX the term Original Exporter feels a little forced. But I can live with the current name. There is one other weird corner case for "4.1.1. Template Mapping and Information Element Ordering". If the same IE occurs multiple times. It might make sense to reorder other IEs, but the relative order of the *data* for the identical IEs should be maintained. Obviously the order identical IEs in the template doesn't really matter. I think I'm OK leaving this out, but is it worth noting that v9 IEs >= 32768 need special handling? On rereading I have some questions about option templates and scope. If an option template received by a mediator contains details scoped to an exporterIPv[46]Address to further describe a data element. How does the post mediator collector connect this information back together? SrcA exports Option template { scope=exporterIPv4Address='SrcA', scope=someId=1 someName="Fred", someDescription="Wilma's Husband" } Data { IE1 .. IEn = data1 .. datan someId=1 } SrcB exports Option template { scope=exporterIPv4Address='SrcA', scope=someId=1 someName="Barney", someDescription="Betty's Husband" } Data { IE1 .. IEn = data1 .. datan someId=1 } What does the Mediator export? Could the Mediator make a different decison if it has only seen the data templates? What happens when the Options Template is first seen? -Andrew On 10/04/2013 10:28 AM, 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 : Operation of the IP Flow Information Export (IPFIX) Protocol on IPFIX Mediators > Author(s) : Benoit Claise > Atsushi Kobayashi > Brian Trammell > Filename : draft-ietf-ipfix-mediation-protocol-07.txt > Pages : 28 > Date : 2013-10-04 > > 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-07 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-ipfix-mediation-protocol-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 From n.brownlee@auckland.ac.nz Wed Oct 9 11:54:29 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 5CDDB21E8181 for ; Wed, 9 Oct 2013 11:54:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 8nKyvzhynRhM for ; Wed, 9 Oct 2013 11:54:25 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) by ietfa.amsl.com (Postfix) with ESMTP id D542721E818E for ; Wed, 9 Oct 2013 11:54:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1381344858; x=1412880858; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=RE4raDeppLk1ECsHwbGvxVT0mDIP3riuFpfhQt2InhE=; b=eT1iscxqYibnNc0CnPWPyB9mZaGmEUEDGhIljEeoDmpXnKOHn9t60hgD F7P6/JZM0VeD3lDV+zHVHaTHGzcy7hGvyj/RzXdZI5SlFBQMab2E90XA+ jPubbUSNG2Xw7ty8kxFFV4pq0NQheEk60pX21ZbicOtUgaABe/FX24emL s=; X-IronPort-AV: E=Sophos;i="4.90,1065,1371038400"; d="scan'208";a="216738300" X-Ironport-HAT: None - $RELAY-AUTH X-Ironport-Source: 121.98.105.173 - Outgoing - Outgoing-SSL Received: from 121-98-105-173.bng1.tvc.orcon.net.nz (HELO [192.168.0.4]) ([121.98.105.173]) by mx2-int.auckland.ac.nz with ESMTP; 10 Oct 2013 07:54:14 +1300 Message-ID: <5255A655.50605@auckland.ac.nz> Date: Thu, 10 Oct 2013 07:54:13 +1300 From: Nevil Brownlee User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: IPFIX list Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPFIX] Link-layer IEs draft submitted to IESG 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: Wed, 09 Oct 2013 18:54:29 -0000 Hi all: Here's the write-up for our link-layer IEs draft, which I've just submitted. Cheers, Nevil Write-up for: draft-ietf-ipfix-data-link-layer-monitoring-06 Information Elements for Data Link Layer Traffic Measurement === 1. Summary === Document shepherd: Nevil Brownlee Responsible Area Director: Benoit Claise This document describes Information Elements (IEs) related to data link layer. They are used by the IP Flow Information Export (IPFIX) protocol for encoding measured data link layer traffic information. The document is intended to be a Proposed Standard. It describes, in detail, a set of Information Elements describing link-layer objects. These will be particularly to service providers who use Wide-Area Ethernet or Virtual Ethernet technologies. === 2. Review and Consensus === This draft's -00 version was published in July 2012. Two of its authors were from a large Japanese provider who needed to monitor and report on link-layer performance. Since then it has received ongoing low-activity-level discussion on the IPFIX list. It has also been discussed at each IETF meeting since then; alas, the WG has always considered this as low-priority work. Its WGLC was run in October 2012; we realised at that point that we needed someone from IEEE 802.1 to check that our Ethernet IEs were correct in their descriptions of the IEEE-defined technologies. Pat Thaler, IEEE liaison for IETF, has helped develop this document since then, she confirms that the IEEE-related IEs are correct in their descriptions. It has been carefully reviewed by Paul Aitken and Brian Trammell, both pointed out issues; these have been addressed in successive versions. Overall I believe that there is clear consensus within the WG for this draft. === 3. Intellectual Property === No IPR disclosures have been made directly on this draft, IPR on it has not been discussed in the WG. Two of the authors have stated that their direct, personal knowledge of any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79. The third author, Shingo Kashima, has not responded to my email requests for this confirmation. === 4. Other Points === This document has no downward references. Its IANA Considerations clearly state what IANA is being asked to do, i.e. add 25 new IPFIX Information Elements to the IPFIX Information Element Registry. These have been discussed at IETF meetings with all four of the IE-Doctors present. It also describes two existing IEs: 312, dataLinkFrameSize and 315, dataLinkFrameSection. These are already in the Information Element Registry - they're listed here so that all the link-layer IEs are described in a single RFC. The ID-nits checker has a few other complaints; the RFC Editor will fix those. Overall, I believe that this draft is ready for publication as an RFC. -- --------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand From bclaise@cisco.com Wed Oct 9 13:41:12 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 0DC3B21F9B07 for ; Wed, 9 Oct 2013 13:41:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.567 X-Spam-Level: X-Spam-Status: No, score=-10.567 tagged_above=-999 required=5 tests=[AWL=0.032, 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 1zKsJ9UBbWGb for ; Wed, 9 Oct 2013 13:41:06 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 7194B21F9B66 for ; Wed, 9 Oct 2013 13:40:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3224; q=dns/txt; s=iport; t=1381351256; x=1382560856; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=NZZ4Nz+tKOv3P0WoL4uTvw2Df1YFvQgk5ZvQ9oRJTCY=; b=RbYYD+5jS5cfTsgA/MXjaH1bSgiITBVnEbL9XgdJgaK11y+uM3GAny5u 2prQMFZL5hXua/D+KAXxpSkfYqL1T/klOAWBYLZb2zI9cBC0vLXcqGzJz 50NW5KKXXkTeid6X3FjF+elpLFZ1lnoWZP4y/qCDYBk5UPwxzZzV//Y8X k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AisFAIK+VVKQ/khL/2dsb2JhbABaDoJ5wkGBHxZ0giYBAQQ4QAEQCw4TFg8JAwIBAgFFBg0BBwEBiAK5AY1xgSEzB4QjA5gDhjeLSoJlQTo X-IronPort-AV: E=Sophos;i="4.90,1066,1371081600"; d="scan'208";a="160504330" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 09 Oct 2013 20:40:54 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r99KeohN014577; Wed, 9 Oct 2013 20:40:51 GMT Message-ID: <5255BF52.5090101@cisco.com> Date: Wed, 09 Oct 2013 22:40:50 +0200 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: Nevil Brownlee References: <5255A655.50605@auckland.ac.nz> In-Reply-To: <5255A655.50605@auckland.ac.nz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPFIX list Subject: Re: [IPFIX] Link-layer IEs draft submitted to IESG 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: Wed, 09 Oct 2013 20:41:12 -0000 Dear all, I reviewed the document, and this document is in good shape. Therefore, its state is now "Last Call Requested" Regards, Benoit > > Hi all: > > Here's the write-up for our link-layer IEs draft, which I've just > submitted. > > Cheers, Nevil > > Write-up for: > draft-ietf-ipfix-data-link-layer-monitoring-06 > Information Elements for Data Link Layer Traffic Measurement > > === 1. Summary === > > Document shepherd: Nevil Brownlee > Responsible Area Director: Benoit Claise > > This document describes Information Elements (IEs) related to data > link layer. They are used by the IP Flow Information Export (IPFIX) > protocol for encoding measured data link layer traffic information. > > The document is intended to be a Proposed Standard. It describes, > in detail, a set of Information Elements describing link-layer > objects. These will be particularly to service providers who use > Wide-Area Ethernet or Virtual Ethernet technologies. > > === 2. Review and Consensus === > > This draft's -00 version was published in July 2012. Two of its > authors were from a large Japanese provider who needed to monitor and > report on link-layer performance. Since then it has received ongoing > low-activity-level discussion on the IPFIX list. It has also been > discussed at each IETF meeting since then; alas, the WG has always > considered this as low-priority work. > > Its WGLC was run in October 2012; we realised at that point that we > needed someone from IEEE 802.1 to check that our Ethernet IEs were > correct in their descriptions of the IEEE-defined technologies. > Pat Thaler, IEEE liaison for IETF, has helped develop this document > since then, she confirms that the IEEE-related IEs are correct in > their descriptions. > > It has been carefully reviewed by Paul Aitken and Brian Trammell, > both pointed out issues; these have been addressed in successive > versions. > > Overall I believe that there is clear consensus within the WG for > this draft. > > === 3. Intellectual Property === > > No IPR disclosures have been made directly on this draft, IPR > on it has not been discussed in the WG. > > Two of the authors have stated that their direct, personal > knowledge of any IPR related to this document has already been > disclosed, in conformance with BCPs 78 and 79. > The third author, Shingo Kashima, has not responded to my email > requests for this confirmation. > > === 4. Other Points === > > This document has no downward references. > > Its IANA Considerations clearly state what IANA is being asked > to do, i.e. add 25 new IPFIX Information Elements to the > IPFIX Information Element Registry. These have been discussed > at IETF meetings with all four of the IE-Doctors present. > > It also describes two existing IEs: 312, dataLinkFrameSize and > 315, dataLinkFrameSection. These are already in the Information > Element Registry - they're listed here so that all the link-layer > IEs are described in a single RFC. > > The ID-nits checker has a few other complaints; the RFC Editor will > fix those. > > Overall, I believe that this draft is ready for publication as > an RFC. > From iesg-secretary@ietf.org Wed Oct 9 13:54:18 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 0D2FD21E81B9; Wed, 9 Oct 2013 13:54:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.382 X-Spam-Level: X-Spam-Status: No, score=-102.382 tagged_above=-999 required=5 tests=[AWL=0.218, 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 niIQiqYGgB17; Wed, 9 Oct 2013 13:54:16 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ADFF921E81A1; Wed, 9 Oct 2013 13:54:14 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p1 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20131009205414.15919.92345.idtracker@ietfa.amsl.com> Date: Wed, 09 Oct 2013 13:54:14 -0700 Cc: ipfix@ietf.org Subject: [IPFIX] Last Call: (Information Elements for Data Link Layer Traffic Measurement) to Proposed Standard X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Reply-To: ietf@ietf.org List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 20:54:19 -0000 The IESG has received a request from the IP Flow Information Export WG (ipfix) to consider the following document: - 'Information Elements for Data Link Layer Traffic Measurement' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-10-23. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. 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 file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-ipfix-data-link-layer-monitoring/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-ipfix-data-link-layer-monitoring/ballot/ No IPR declarations have been submitted directly on this I-D. From iesg-secretary@ietf.org Fri Oct 11 15:13:58 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 B297921E812E; Fri, 11 Oct 2013 15:13:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.428 X-Spam-Level: X-Spam-Status: No, score=-102.428 tagged_above=-999 required=5 tests=[AWL=0.172, 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 RK9EX5PxhDCr; Fri, 11 Oct 2013 15:13:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D73021E8087; Fri, 11 Oct 2013 15:13:55 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p2 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20131011221355.16052.32038.idtracker@ietfa.amsl.com> Date: Fri, 11 Oct 2013 15:13:55 -0700 Cc: ipfix@ietf.org Subject: [IPFIX] Last Call: (Operation of the IP Flow Information Export (IPFIX) Protocol on IPFIX Mediators) to Proposed Standard X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Reply-To: ietf@ietf.org List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Oct 2013 22:13:58 -0000 The IESG has received a request from the IP Flow Information Export WG (ipfix) to consider the following document: - 'Operation of the IP Flow Information Export (IPFIX) Protocol on IPFIX Mediators' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-10-25. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. 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 file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-ipfix-mediation-protocol/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-ipfix-mediation-protocol/ballot/ No IPR declarations have been submitted directly on this I-D. From n.brownlee@auckland.ac.nz Mon Oct 14 19:12:11 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 C447E11E8167 for ; Mon, 14 Oct 2013 19:12:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 kOHcLSlVRza4 for ; Mon, 14 Oct 2013 19:12:07 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) by ietfa.amsl.com (Postfix) with ESMTP id 7B0F611E8155 for ; Mon, 14 Oct 2013 19:12:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1381803127; x=1413339127; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=4nGRCI+iPBwIVMHvQRVmWoyC8dcCdqiwpaJL7dzuZOQ=; b=FYlEpTrvdsNqfkX93EhgRFDs04wQsWV5Ze9INGuYh/ovH1pa7zYYQSy6 azRCgVZ6IzZY3Yv1bjkD5cPYZ3Z7WafyTejOTgst4h5tr6IFKFa7VWbeL 4LcsLqOEiUdQSxtvJEfO5+KAav83sH9bZoCflUI86WjK0u8AolTetXonh A=; X-IronPort-AV: E=Sophos;i="4.93,496,1378814400"; d="txt'?scan'208";a="217548162" X-Ironport-HAT: UNIVERSITY - $RELAY-THROTTLE X-Ironport-Source: 130.216.38.131 - Outgoing - Outgoing-SSL Received: from nevil-laptop1.sfac.auckland.ac.nz (HELO [130.216.38.131]) ([130.216.38.131]) by mx2-int.auckland.ac.nz with ESMTP; 15 Oct 2013 15:12:05 +1300 Message-ID: <525CA474.2000107@auckland.ac.nz> Date: Tue, 15 Oct 2013 15:12:04 +1300 From: Nevil Brownlee User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: IPFIX Working Group References: <525BBA54.5050500@cs.aau.dk> In-Reply-To: <525BBA54.5050500@cs.aau.dk> X-Forwarded-Message-Id: <525BBA54.5050500@cs.aau.dk> Content-Type: multipart/mixed; boundary="------------010403000409090006080603" Subject: [IPFIX] Fwd: deadline extension of the special issue 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, 15 Oct 2013 02:12:11 -0000 This is a multi-part message in MIME format. --------------010403000409090006080603 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Hi all: FYI; if you're considering submitting to this special issue on 'flow-based network management,' you have a little longer to do so :-) Cheers, Nevil > -------- Original Message -------- > Subject: deadline extension of the special issue > Date: Mon, 14 Oct 2013 11:33:08 +0200 > From: Ramin Sadre > To: Nevil Brownlee > > Hi Nevil, > > We are extending the deadline for the IJNM special issue for > flow-based approaches to October 31 (virtually all authors asked for > an extension). Could you please send again the attached CFP to the > IPFIX mailing list? > > Best, > Ramin --------------010403000409090006080603 Content-Type: text/plain; charset=UTF-8; name="cfp_v1.4.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="cfp_v1.4.txt" [Deadline extension. We apologize for multiple copies.] A PDF version of this call can be downloaded at: http://people.cs.aau.dk/rsadre/ijnm/sp_cfp.pdf CALL FOR PAPERS Special Issue of the International Journal on Network Management (IJNM): "Flow-based Approaches in Network Management: Recent Advances and Future Trends" Submission Deadline: October 31, 2013 (extended) Publication: June, 2014 Scope of the Special Issue The continuous increase of line speeds and loads in modern computer networks has considerably stimulated the usage of aggregation-based monitoring techniques for network management in the past years. Amongst those, flow-based approaches have become extremely popular among researchers and operators due to the wide availability of hardware and software flow exporters and their quasi-standardized exporting formats, such as Netflow or IPFIX. While flow-based monitoring was originally used in simple diagnosing and accounting tasks, researchers are now proposing flow-based approaches for a wide range of application fields, such as intrusion detection, traffic classification, and resource management. New environments, such as Clouds or Software Defined Networks, demand for new flow-based solutions for their monitoring and management. Furthermore, we observe more and more attempts to close the gap between packet-based and flow-based monitoring. As the latter was originally proposed as an efficient and feasible alternative to deep packet inspection in high-speed networks, the most recent flow exporters allow enriching the exported flow data with application-layer information. It can be expected that this will lead to new approaches and solutions for network management problems. The goal of this Special Issue is to present innovative flow-based approaches and solutions for network management tasks as well as new methods and technologies for the generation, processing and analysis of flow information. Therefore, this Special Issue of the International Journal on Network Management covers ongoing research on the usage of flow-based approaches, on the design and implementation of flow monitoring devices and infrastructures, and on the emerging trends in flow-based technologies and applications. Tutorial-style articles in these fields are also solicited, if they provide a structured introduction and a clear overview of state-of-the-art technologies, mechanisms, or architectures, and newly emerging challenges as well as problems. Areas of Interest Contributions in the following areas are of specific interest, but not limited to: * Flow-Based Accounting * Flow-Based Intrusion and Anomaly Detection * Flow-Based Problem Diagnosis * Flow-Based Traffic Classification * Flow-Based Monitoring of Applications and Services * Usage of Flow Monitoring in Cloud Environments * Flow-based Monitoring for Bandwidth Allocation * Visualization of Flow Data * Characterization of Network Traffic on Flow Level * Hybrid Packet-Flow-Based Approaches * Efficient Storage and Analysis of Flow Data * Design and Implementation of Flow Monitoring Equipment and Infrastructures * Future Trends in Flow Monitoring * Interaction between IPFIX and SDN * Special-purpose management scenarios Submission Guidelines Authors should submit their papers in PDF format only to http://mc.manuscriptcentral.com/nem The paper submission should not exceed 20 pages (double-space). Author instructions are available at http://onlinelibrary.wiley.com/journal/10.1002/%28ISSN%291099-1190/homepage/ForAuthors.html and the respective LaTeX template can be found at http://onlinelibrary.wiley.com/journal/10.1002/%28ISSN%291099-1190/homepage/latex_class_file.htm All submissions will be peer-reviewed. In case of an acceptance, the final and camera-ready version has to take into account comments of reviewers and needs to follow the template's requirements. Important Deadlines Submission Deadline: October 31, 2013 (extended) Notification of Acceptance: February 15, 2014 Final Version: March 15, 2014 Publication: June 1, 2014 Submissions to http://mc.manuscriptcentral.com/nem in PDF only. Guest Editors Ramin Sadre, Aalborg University, Denmark Anna Sperotto, University of Twente, Netherlands Nevil Brownlee, The University of Auckland, New Zealand Rick Hofstede, University of Twente, Netherlands --------------010403000409090006080603-- From trammell@tik.ee.ethz.ch Tue Oct 15 23:10:09 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 56A1811E8232 for ; Tue, 15 Oct 2013 23:10:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 kYrCRQRVPx-0 for ; Tue, 15 Oct 2013 23:10:04 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id A73E411E8249 for ; Tue, 15 Oct 2013 23:09:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 08CFED9302 for ; Wed, 16 Oct 2013 08:09:54 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id q+O45m0bBVoA for ; Wed, 16 Oct 2013 08:09:53 +0200 (MEST) Received: from [10.0.27.100] (cust-integra-122-165.antanet.ch [80.75.122.165]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id BC5C4D9300 for ; Wed, 16 Oct 2013 08:09:53 +0200 (MEST) From: Brian Trammell Content-Type: multipart/signed; boundary="Apple-Mail=_7F05DE85-AD33-4BE3-BDCC-5E74C5581792"; protocol="application/pgp-signature"; micalg=pgp-sha512 Message-Id: <9A37CC23-13B4-43F0-BC8C-E5B32E13ACF8@tik.ee.ethz.ch> Date: Wed, 16 Oct 2013 08:09:53 +0200 To: "ipfix@ietf.org Group" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Subject: [IPFIX] TRAC 2014 Call for Papers 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: Wed, 16 Oct 2013 06:10:09 -0000 --Apple-Mail=_7F05DE85-AD33-4BE3-BDCC-5E74C5581792 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Greetings, all, The following might be of interest to those of you with with an interest = in passive network measurement; for the rest of you, apologies for the = spam! Many thanks, best regards, Brian CALL FOR PAPERS TRAC 2014 -- 5th International Workshop on TRaffic Analysis and = Characterization Technically Sponsored by IEEE and FP7-mPlane 4-8 August 2014 -- Nicosia, CYPRUS -- http://trac2014.ftw.at/ SCOPE The continued evolution of the Internet is characterized by dramatic = changes in=20 the way users behave, interact with and use the network. Today's = Internet content=20 and applications are increasingly delivered by ever larger content = delivery=20 networks (CDNs) and cloud infrastructures. Other changes in the Internet, such as the explosion of mobile traffic = and the=20 growing deployment of encryption (e.g. HTTPS Everywhere) demand new = approaches=20 for characterizing and analyzing network traffic. Malicious and abusive = traffic=20 continues to evolve as well, and techniques for detection must evolve in = kind. The fifth edition of the TRAC workshop continues to serve as a forum for = scientists=20 and engineers in academia and industry to exchange and discuss their = experiences=20 and research results about all aspects of traffic classification, = characterization,=20 and analysis. TOPICS The workshop is soliciting high quality papers discussing original and = innovative=20 experimental activities, unpublished and not currently submitted for = publication=20 elsewhere, on topics including (but not limited) to the following: * Traffic analysis and characterization algorithms and techniques * Detection, analysis, and classification of network anomalies * Platforms for on-line, real-time traffic analysis and characterization * Evaluation of traffic classification and analysis techniques * Data-reduction techniques for traffic analysis and visualization * Privacy-preservation in traffic analysis, classification, and = characterization * Effects of anonymization on traffic analysis, classification, and = characterization * Identification and classification of encrypted traffic * Advanced algorithms for deep packet inspection * Post-DPI approaches for traffic classification * Applications of traffic analysis to network security * Traffic analysis studies on operational networks and large-scale = traffic data sets * Applications of traffic analysis to network operations and management * Ultra-high rate (10 - 100Gbit) traffic analysis, classification, and = characterization * Analysis and characterization of mobile and wireless traffic * Forwarding-plane support for network measurement and analysis SUBMISSIONS Prospective authors are invited to submit their papers using the EDAS = system.=20 Submitted papers must be no longer than six (6) IEEE style pages = including results,=20 figures and references. Papers will be reviewed by the standard = reviewing procedure.=20 Accepted papers will be published on the IEEE Xplore Digital Library IMPORTANT DATES Paper submission: January 15, 2014=20 Notifications: March 15, 2014=20 Camera-ready: April 1, 2014=20 ORGANIZING COMMITTEE Workshop Chairs: * Pedro Casas (FTW Vienna Research Center, Austria) * Brian Trammell (ETH Zurich, Switzerland) Honorary Chairs: * Christian Callegari (University of Pisa, Italy) * Sandrine Vaton (TELECOM Bretagne, France) --Apple-Mail=_7F05DE85-AD33-4BE3-BDCC-5E74C5581792 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJSXi2xAAoJENt3nsOmbNJcKXoH/28/VBhIHVHKjZ+SsDq6Y7/X KXeKUpXK6AC+SrINNufDSYDPXOZWNMKlAtFOi5xKRyTWiRC2bMeeRRK3UyBg5UPU m1oaFw4ETyjLhYra5PBGQrpzPTWDNZ8Ze4ysap81fkF32V2qwQG71PIJutvcT30A fqTyx/pbgb5sLqRAjCk89jZ0m81GwsAg1dSSdcuTobwFwVF/bBNQSsz+OBqoPKD6 BrhKggrGoRj8tUULjUvAhXrd0kvBjfIgp/EFnhbAXoO82LCBMBz6Je2JOdZ0Eket WZpkgsS4f8P6p99ekC8VGKIYcK5N+/zWqGDCw8t//uLicwPEYPTUXGRUtjPVXC4= =iU1d -----END PGP SIGNATURE----- --Apple-Mail=_7F05DE85-AD33-4BE3-BDCC-5E74C5581792-- From n.brownlee@auckland.ac.nz Thu Oct 17 18:46: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 C3C8811E81A3 for ; Thu, 17 Oct 2013 18:46:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 q8MJVD6EMZJ5 for ; Thu, 17 Oct 2013 18:46:48 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) by ietfa.amsl.com (Postfix) with ESMTP id 10F6011E813D for ; Thu, 17 Oct 2013 18:46:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1382060798; x=1413596798; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=semR2nsa9gkmMYx9aEHFM6dtcapZxThEu+AfTuwjXfs=; b=I4/+CQhrTb1e0ZSF4pziwSQczN0EVlaWv4ESt/Uc8Kxw5iawostSfPKY XchRW6jMXSmuKsNB9hi9gszrlvYY4GBvQjA2+/Gjg6RC+38Btryam3xa/ MC/HG20iiIFYsrfCi6HJbDUw4+SJhzJk557wOWm3ICJYr05D0TVNEcWek I=; X-IronPort-AV: E=Sophos;i="4.93,518,1378814400"; d="scan'208";a="218152807" X-Ironport-HAT: UNIVERSITY - $RELAY-THROTTLE X-Ironport-Source: 130.216.38.131 - Outgoing - Outgoing-SSL Received: from nevil-laptop1.sfac.auckland.ac.nz (HELO [130.216.38.131]) ([130.216.38.131]) by mx2-int.auckland.ac.nz with ESMTP; 18 Oct 2013 14:46:36 +1300 Message-ID: <526092FB.6000809@auckland.ac.nz> Date: Fri, 18 Oct 2013 14:46:35 +1300 From: Nevil Brownlee User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: IPFIX Working Group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPFIX] Agenda for IETF 88, Vancouver (first draft) 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, 18 Oct 2013 01:46:52 -0000 Hi all: Here's the first draft of our agenda. Please send me any changes/improvements/etc. If you have drafts you would like to present, let me know about those too. At this stage we have only one WG draft left to finish, 'Exporting MIB Variables.' If we want to recharter, we - need to agree on a small set of drafts - be sure that there a at least three to five people who agree to work on each draft. Cheers, Nevil ================================================== IP Flow Information Export WG (ipfix) Agenda for IETF 88, Vancouver (agenda-00) Thursday, 7 November 2013, 1730-1830, Georgia A ================================================== Chairs: Juergen Quittek Nevil Brownlee AGENDA: 1. Agenda review = 5 min 2. Update from last meeting / WG Status (Nevil) = 10 min RFCs published since last meeting: 7011 = 5102bis 7012 = 5102bis 7013 = IE Doctors 7014 = Flow Selection Techniques 7015 = IPFIX Aggregation WG drafts submitted Link Layer IEs IETF LC ends 23 Oct Mediation Protocol IETF LC ends 25 Oct AD-sponsored draft trammell-ipfix-tcpcontrolbits-revision-04 IETF LC ends 4 Nov 3. Current charter work items = 10 min c) Exporting MIB objects (Paul Aitken) draft-ipfix-mib-variable-export-02, 25 Feb 13 Tracker thinks this is draft-johnson-ipfix-mib-variable-export No change since last meeting 4. Next steps for IPFIX = a) Should we declare success and close the WG? b) What drafts should we consider next for the WG? 5. Other drafts (if time permits) = 6. Any Other Business Presentation slides will be available at https://datatracker.ietf.org/meeting/88/materials.html (search for IPFIX in the Operations and Management Area) Participation via jabber is offered at ipfix@jabber.ietf.org and via Meetecho, http://ietf88.conf.meetecho.com/index.php/Web_Client -- --------------------------------------------------------------------- Nevil Brownlee Computer Science Department Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand From internet-drafts@ietf.org Mon Oct 21 14:58: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 2D8FD11E862E; Mon, 21 Oct 2013 14:58:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.031, 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 uXiAYSITmIpl; Mon, 21 Oct 2013 14:58:51 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 92BC011E86E1; Mon, 21 Oct 2013 14:58:48 -0700 (PDT) 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.80.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131021215848.32561.19089.idtracker@ietfa.amsl.com> Date: Mon, 21 Oct 2013 14:58:48 -0700 Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action: draft-ietf-ipfix-mib-variable-export-03.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, 21 Oct 2013 21:58:52 -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 : 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=3Ddraft-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/ From paitken@cisco.com Tue Oct 22 03:36:05 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 B1AF311E8362 for ; Tue, 22 Oct 2013 03:36:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 tngi8iQcwQ5N for ; Tue, 22 Oct 2013 03:36:00 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id EE43311E8117 for ; Tue, 22 Oct 2013 03:35:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7856; q=dns/txt; s=iport; t=1382438160; x=1383647760; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=QZ5aWoF+x24+kMBPpyydl/Bl5gGFUTwA2xYLvhnlmmo=; b=kKrErAZA8/OHdu+3deXoePOxghnFdvnDeyeaBYLuG25Wuus0YmlRszT3 ZKhZlRCKn3TGwdnS+t/0MN1MCgjZAEXW5qkQNbNhKShVHcRsUDXBwq4Zs 3Ms3lAVhjWKHk/JLqJsXZrTCxsDUWS1z7iPW7iSMLquimdl1QxQY3bN3z o=; X-IronPort-AV: E=Sophos;i="4.93,547,1378857600"; d="scan'208,217";a="18447159" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-3.cisco.com with ESMTP; 22 Oct 2013 10:35:59 +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 r9MAZrT8027199 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Oct 2013 10:35:55 GMT Received: from [144.254.153.55] (dhcp-144-254-153-55.cisco.com [144.254.153.55]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r9MAZq4Q024633; Tue, 22 Oct 2013 11:35:52 +0100 (BST) Message-ID: <52665509.7010908@cisco.com> Date: Tue, 22 Oct 2013 11:35:53 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: IETF IPFIX Working Group References: <20131021215848.32561.19089.idtracker@ietfa.amsl.com> In-Reply-To: <20131021215848.32561.19089.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20131021215848.32561.19089.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------090600070602070907090101" Subject: [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: Tue, 22 Oct 2013 10:36:05 -0000 This is a multi-part message in MIME format. --------------090600070602070907090101 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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. 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, ...) ? 2. Should we consolidate the RFC 2578 ObjectSyntax with the RFC5610 / [IANA- DATATYPES] types? 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 --------------090600070602070907090101 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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.

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, ...) ?

2. Should we consolidate the RFC 2578 ObjectSyntax with the RFC5610 / [IANA- DATATYPES] types?

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


--------------090600070602070907090101-- From wwwrun@rfc-editor.org Sat Oct 26 10:53:54 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 EBC7311E8107; Sat, 26 Oct 2013 10:53:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.438 X-Spam-Level: X-Spam-Status: No, score=-102.438 tagged_above=-999 required=5 tests=[AWL=0.162, 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 bGBbvxvGjLm1; Sat, 26 Oct 2013 10:53:53 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id EB93621F9FB9; Sat, 26 Oct 2013 10:53:53 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 93AD3726001; Sat, 26 Oct 2013 10:45:06 -0700 (PDT) To: bortzmeyer@nic.fr, bclaise@cisco.com, trammell@tik.ee.ethz.ch, paitken@cisco.com From: RFC Errata System Message-Id: <20131026174506.93AD3726001@rfc-editor.org> Date: Sat, 26 Oct 2013 10:45:06 -0700 (PDT) Cc: iesg@ietf.org, ipfix@ietf.org, rfc-editor@rfc-editor.org Subject: [IPFIX] [Errata Held for Document Update] RFC7011 (3732) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Oct 2013 17:53:55 -0000 The following errata report has been held for document update for RFC7011, "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7011&eid=3732 -------------------------------------- Status: Held for Document Update Type: Editorial Reported by: Stéphane Bortzmeyer Date Reported: 2013-09-21 Held by: Benoit Claise (IESG) Section: 1.1 Original Text ------------- A new Section 5.2 has been added to address wraparound of these timestamp data types after they overflow in the years 2032-2038. Corrected Text -------------- A new Section 5.2 has been added to address wraparound of these timestamp data types after they overflow. Notes ----- Since dateTimeSeconds is encoded in an _unsigned_ integer, it will wraparound in 2106 (as written correctly in section 5.2), not 2038. -------------------------------------- RFC7011 (draft-ietf-ipfix-protocol-rfc5101bis-10) -------------------------------------- Title : Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information Publication Date : September 2013 Author(s) : B. Claise, Ed., B. Trammell, Ed., P. Aitken Category : INTERNET STANDARD Source : IP Flow Information Export Area : Operations and Management Stream : IETF Verifying Party : IESG From n.brownlee@auckland.ac.nz Tue Oct 29 21:27:34 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 758EA11E8318 for ; Tue, 29 Oct 2013 21:27:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 g7zJtGX3aT3R for ; Tue, 29 Oct 2013 21:27:29 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) by ietfa.amsl.com (Postfix) with ESMTP id 8C96B11E8205 for ; Tue, 29 Oct 2013 21:27:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1383107238; x=1414643238; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=wOVh7hmyLqT7sPu/x6hX+NEj7fF+cXSF+dZ8pCQyf+M=; b=ntWHaryUzDvmraeTd4Dur9KtppsyNIE+LMBMQ5yDLr800TnSCP2S1Yq5 plM03h++cg2ue1WTqE9Xx756kAa9Z+FgnEB23QnnWsuUI5u5/DcoS17UU zsk6zKKxC5/ncj0n7qRxxJ9SP22gkVfgL6SFb7IQaQeDVx762io5dIQLt 8=; X-IronPort-AV: E=Sophos;i="4.93,598,1378814400"; d="scan'208";a="220484206" X-Ironport-HAT: UNIVERSITY - $RELAY-THROTTLE X-Ironport-Source: 130.216.38.131 - Outgoing - Outgoing-SSL Received: from nevil-laptop1.sfac.auckland.ac.nz (HELO [130.216.38.131]) ([130.216.38.131]) by mx2-int.auckland.ac.nz with ESMTP; 30 Oct 2013 17:27:14 +1300 Message-ID: <52708AA1.3060107@auckland.ac.nz> Date: Wed, 30 Oct 2013 17:27:13 +1300 From: Nevil Brownlee User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; 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] 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: Wed, 30 Oct 2013 04:27:34 -0000 Hi all: Since 18 October, when I sent out the agenda for the IPFIX session in Vancouver, no-one has asked for any agenda changes. Juergen and I have since had our usual pre-meeting chat with Benoit (our AD); we propose to close the wg as soon as the MIB Variable Export draft is finished, or at the London meeting in March next year. Going forward, if a document requests new IEs, that should be done by sending a request directly to IANA or by developing a draft in the WG that has the relevant experience. Cheers, Nevil -- --------------------------------------------------------------------- Nevil Brownlee Computer Science Department Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand From trammell@tik.ee.ethz.ch Thu Oct 31 20:47:29 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 1730521E8141 for ; Thu, 31 Oct 2013 20:47:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.118 X-Spam-Level: X-Spam-Status: No, score=-6.118 tagged_above=-999 required=5 tests=[AWL=-0.119, BAYES_00=-2.599, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_MED=-4] 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 hPhW5EjRDhin for ; Thu, 31 Oct 2013 20:47:23 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 16FE721F9FB1 for ; Thu, 31 Oct 2013 20:47:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 3F472D9303 for ; Fri, 1 Nov 2013 04:47:14 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id IgpdNgUqrglA for ; Fri, 1 Nov 2013 04:47:14 +0100 (MET) Received: from thaleia.local (cust-integra-122-165.antanet.ch [80.75.122.165]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id DFDC3D9300 for ; Fri, 1 Nov 2013 04:47:13 +0100 (MET) Message-ID: <52732439.50206@tik.ee.ethz.ch> Date: Fri, 01 Nov 2013 04:47:05 +0100 From: Brian Trammell User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: IPFIX Working Group X-Enigmail-Version: 1.2.3 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig1971A0B76A5D53CC369A51C1" Subject: [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: Fri, 01 Nov 2013 03:47:29 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig1971A0B76A5D53CC369A51C1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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. 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. 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. (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. (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. (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. (5) Also on 11.2.3 and 11.2.4, see comment above on using flowKeyIndicator instead, if indeed that suggestion makes any sense. (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. Not being a SNMP geek, I don't understand why you need 11 here. 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. 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= =2E Doing this would obviate the need for the mibObjectBaseSyntax, no? (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. Best regards, Brian --------------enig1971A0B76A5D53CC369A51C1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - https://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBCgAGBQJScyRAAAoJENt3nsOmbNJcJbwH/AtRmOCzoLodIkNozaKKdQd5 FlcFu7Al2ikbLar5SOLfaNt+UevIAJSkFt1w9QC4ZygdCAN7Qhc6gSHCYmuZ+XOu GxUKmAfa/59g0oAQpuyw/oJBk4i39lXkFbn7Ifi2GEKoipjZMkYmYlPvmx/BZ0O0 Rai9gBYkBTrXMZcO9h4AYB5lq6N2abhKc6P3fQhjpXNPkiafMMA71uUPWodlwoaK 5rheS+o9sYdlgs3jgmMS0IsF9192Twzw93uBVQNIFubmYIa/cB2dg199VCfywmO2 C1Q1wWZZtxfFaLt9mp4UQZ6HxXuEyB+e/immODhDj68zi88zAjpjr+P0H2c4fA0= =bG7i -----END PGP SIGNATURE----- --------------enig1971A0B76A5D53CC369A51C1--