Re: [IPFIX] Winding down the ipfix working group.

Brian Trammell <ietf@trammell.ch> Mon, 15 December 2014 11:28 UTC

Return-Path: <ietf@trammell.ch>
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6969A1A1AEC for <ipfix@ietfa.amsl.com>; Mon, 15 Dec 2014 03:28:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c9wD4rMCJSDc for <ipfix@ietfa.amsl.com>; Mon, 15 Dec 2014 03:28:05 -0800 (PST)
Received: from trammell.ch (trammell1.nine.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 6D34D1A1AC1 for <ipfix@ietf.org>; Mon, 15 Dec 2014 03:28:05 -0800 (PST)
Received: from [IPv6:2001:67c:10ec:2a49:8000::108d] (unknown [IPv6:2001:67c:10ec:2a49:8000::108d]) by trammell.ch (Postfix) with ESMTPSA id DC2661A0272; Mon, 15 Dec 2014 12:27:33 +0100 (CET)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
From: Brian Trammell <ietf@trammell.ch>
In-Reply-To: <23B7BE54EACBED43957AB709C564F7B701853E214C@EMEA-EXCH01.corp.brocade.com>
Date: Mon, 15 Dec 2014 12:27:33 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <D20EA193-9171-4696-9FB0-A4A8E5C3B15D@trammell.ch>
References: <5435D840.1090108@bogus.com> <5487A31D.5040304@bogus.com> <548B4AA0.4000905@bogus.com> <CABwmyRo985=hrkAsGPTXxFbkE-2cC88btQDmK1kP0+YVAe18Qw@mail.gmail.com> <23B7BE54EACBED43957AB709C564F7B701853E1EC5@EMEA-EXCH01.corp.brocade.com> <A98CA95F-7638-45BD-B87D-209F3EDF1982@trammell.ch> <23B7BE54EACBED43957AB709C564F7B701853E214C@EMEA-EXCH01.corp.brocade.com>
To: Paul Aitken <paitken@Brocade.com>
X-Mailer: Apple Mail (2.1993)
Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/E65_EMtsDAHkY7UtZbrZQaZufbY
Cc: "joelja@gmail.com" <joelja@gmail.com>, "ipfix@ietf.org" <ipfix@ietf.org>, "ipfix-chairs@tools.ietf.org" <ipfix-chairs@tools.ietf.org>
Subject: Re: [IPFIX] Winding down the ipfix working group.
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IPFIX WG discussion list <ipfix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipfix>, <mailto:ipfix-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipfix/>
List-Post: <mailto:ipfix@ietf.org>
List-Help: <mailto:ipfix-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipfix>, <mailto:ipfix-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Dec 2014 11:28:08 -0000

> On 15 Dec 2014, at 12:22, Paul Aitken <paitken@Brocade.com> wrote:
> 
> Brian, please see inline...
> 
> Thanks,
> P.
> 
> 
>> -----Original Message-----
>> From: Brian Trammell [mailto:ietf@trammell.ch]
>> Sent: 13 December 2014 21:32
>> To: Paul Aitken
>> Cc: ipfix@ietf.org; joelja@gmail.com; ipfix-chairs@tools.ietf.org
>> Subject: Re: [IPFIX] Winding down the ipfix working group.
>> 
>> hi Paul, all,
>> 
>> AFAIC, I sent in my review on 15 August 2014, edits were made 26 Oct, I
>> followed up 27 Oct. The *document* is basically good to go, I see that there are
>> a couple of outstanding questions from Paul's 30 Oct message; sorry for missing
>> these...
>> 
>>>>>> What the mechanism in the document should _not_ be used for is to
>>>>>> expand the IPFIX information model to also include the contents of all the
>>>>>> various MIBs, such that SMI IEs could be used alongside IPFIX IEs to export
>>>>>> information from non-SNMP sources of data. Otherwise we've created Yet
>>>>>> Another Representation for lots of common IEs already in the IPFIX IE registry,
>>>>>> which would significantly complicate the comparison and combination of data
>>>>>> at collectors. The document needs to make this explicit, either in section 1 or 2.
>>>>> The mechanism _can_ be used like that.
>>>> Can be, yes. Is it the express intention of the authors of the draft to do so?
>>> 
>>> Authors aside, what does the WG want? Ultimately the goal is to avoid
>>> creating new IPFIX IEs for each MIB that needs exported. Does that require
>>> considering MIBs as part of the info model?
>> 
>> So I've thought about this a bit and I *think* we agree here: this mechanism
>> exists so that things which are already in MIBs can be exported via IPFIX without
>> having to define new IEs.
> 
> Exactly.
> 
> 
>> Personally, I'd be happy if we didn't start deprecating things already in the native
>> registry in favor of things in MIBs,
> 
> Agreed; this document does not deprecate any existing IEs.
> 
> - which means there are now two ways of exporting some things (as IE and as MIB). Collectors should already have architectures which understand this equivalence (effectively a presentation layer) since there are already some equivalent (duplicate) IEs (Andrew Feren had a list), and the list will surely grow as enterprise-specific IEs are transitioned to IANA. So I consider this to be a pre-existing issue which was not introduced by this document.

Okay, now I get your point. Agreed.

> Therefore I don't see a need to document the existing IE / MIB equivalences in the document. Please shout if you disagree.

At this point I'm happy to leave this as an article for future work should anyone want to pick it up and run with it.

Let's ship it and declare victory (pending Juergen's SNMP-and-MIB-expert review). :)

Cheers,

Brian

>> and if the IE Doctors don't tell someone who
>> wants an IE that they can't have it because it's in MIB X.
> 
> I think it'll be on a case-by-case basis. Hopefully they'll encourage the use of MIB export. However if the use case involves exporting lots of other IEs and no other MIBs, then a new IE would seem justified for simplicity.
> Remember that the point of the draft is to avoid overloading the IANA registry with new IEs which are equivalent to existing MIBs.
> 
> 
>> I don't believe it's necessary to write any of that down though.
> 
> +1
> 
> 
>>>>> Expressed another way, we've already created duplication; now we have to live with it.
>>>> Actually this seems to be closer to "we've already created duplication, so we can happily create more," which seems dangerous for sustainable interop.
>>> 
>>> What change, if any, would you like to see in the draft?
>> 
>> 
>> As long as it's clear that the mechanism is intended to glue MIBs to IPFIX, none.
> 
> Great, thanks!
> 
> P.
> 
> 
>> 
>> Cheers,
>> 
>> Brian
>> 
>> On 13 Dec 2014, at 00:13, Paul Aitken <paitken@Brocade.com> wrote:
>> 
>>> Joel, All,
>>> 
>>> I'm waiting for WG review of draft-ietf-ipfix-mib-variable-export-07
>>> -principally from Brian Trammell and Juergen Schoenwaelder.
>>> 
>>> P.
>>> 
>>> 
>>> From: joel jaeggli <joelja@bogus.com>
>>> Date: 12 December 2014 at 20:05
>>> Subject: [IPFIX] Winding down the ipfix working group.
>>> To: IPFIX Working Group <ipfix@ietf.org>
>>> Cc: "ipfix-chairs@tools.ietf.org" <ipfix-chairs@tools.ietf.org>
>>> 
>>> 
>>> 
>>> Greetings,
>>> 
>>> The chairs and my co-AD and I have decided it's time to window down
>>> the ipfix working group. Our major milestones are completed and we
>>> should be pleased with the results.
>>> 
>>> We have one remaining active document
>>> 
>>> draft-ietf-ipfix-mib-variable-export
>>> 
>>> which I will be happy to AD sponsor. Barring significant commentary to
>>> contrary I will close the working-group on friday december 19th and we
>>> will retain the mailing list for some time after that.
>>> 
>>> Thanks and congratulations.
>>> Joel
>>> 
>>> 
>>> _______________________________________________
>>> IPFIX mailing list
>>> IPFIX@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ipfix
>>> 
>>> 
>>> _______________________________________________
>>> IPFIX mailing list
>>> IPFIX@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ipfix