Re: [IPFIX] IPFIX at IETF 89, London

Nevil Brownlee <n.brownlee@auckland.ac.nz> Mon, 10 February 2014 21:01 UTC

Return-Path: <n.brownlee@auckland.ac.nz>
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 3B7DC1A0509 for <ipfix@ietfa.amsl.com>; Mon, 10 Feb 2014 13:01:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.549
X-Spam-Level:
X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.548, 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 XRy6YqkK9snr for <ipfix@ietfa.amsl.com>; Mon, 10 Feb 2014 13:01:21 -0800 (PST)
Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) by ietfa.amsl.com (Postfix) with ESMTP id 805DF1A0811 for <ipfix@ietf.org>; Mon, 10 Feb 2014 13:01:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1392066081; x=1423602081; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=5Molvf72GTgXiv9ZDqIc1wV4HF5kgB3OkuTwvx8K5mo=; b=Pv+UfUa5irBWTAxnQRbSSzjvnpAYyDZdQdyYZ1NT4GSm6EdKpz4TWIM2 25PyLmU7RmvAMAgb71955B1gmtmSxtkmKmvkHNq4tIqhr/2KXsLhCPcR9 BPZyCDXqIQUD4C9AMj5YepUNRJd1mUYnnEd1alKQTHZCXSHjDqjkjFF3A o=;
X-IronPort-AV: E=Sophos;i="4.95,819,1384254000"; d="scan'208";a="233685445"
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; 11 Feb 2014 10:01:18 +1300
Message-ID: <52F93E1D.4030601@auckland.ac.nz>
Date: Tue, 11 Feb 2014 10:01:17 +1300
From: Nevil Brownlee <n.brownlee@auckland.ac.nz>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: Brian Trammell <trammell@tik.ee.ethz.ch>, Paul Aitken <paitken@cisco.com>
References: <52EF4E92.3040906@auckland.ac.nz> <52EF71FA.3090005@cisco.com> <52F80BCA.2030408@auckland.ac.nz> <52F8AAB5.5050604@cisco.com> <0705D07E-6FB1-4BB7-8AD7-8A38656CDB93@tik.ee.ethz.ch>
In-Reply-To: <0705D07E-6FB1-4BB7-8AD7-8A38656CDB93@tik.ee.ethz.ch>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
Cc: "ipfix-ads@tools.ietf.org" <ipfix-ads@tools.ietf.org>, IPFIX Working Group <ipfix@ietf.org>, "ipfix-chairs@tools.ietf.org" <ipfix-chairs@tools.ietf.org>
Subject: Re: [IPFIX] IPFIX at IETF 89, London
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, 10 Feb 2014 21:01:25 -0000

Hi again Paul, Andrew and IPFIXers:

First, oops, I confused the publication year of your two drafts,
sorry about that.

Second, thanks for the news on the MIB Variables draft.  I realise
that we're all deadline-driven, but having draft updates only close
to the IETF meeting deadlines makes me nervous about the energy level
in the WG - which is why I didn't think there was much point in having
a WG meeting in London.

That said, I agree with Brian (below), the remaining question is how
best to proceed with your two drafts.  At this stage, I suggest that
  - We need to get the MIB variables draft submitted to IESG (or at
      least clearly on the path to submission), so as to comple our
      current charter.
  - Having done that, we can explore the question of whether the WG
      can take on any new drafts.

Had the MIB Variables draft update been published back in, say, January
this year, things would have looked a lot different now, sigh.

Cheers, Nevil


On 11/02/14 4:31 AM, Brian Trammell wrote:
> There are a couple of questions here: (1) do we close / lay dormant / recharter the working group (and what do we do with these two drafts)? and (2) do we have a meeting in London?
>
>  From my point of view I can say that both drafts are important, have clearly had a good deal of discussion, and are probably at this point of a quality that they could be adopted as WG items. We had an idea in Vancouver that further work could be AD sponsored if the IPFIX WG closed. Recent experience in trying to AD sponsor other IPFIX-related drafts were not appreciated by the IESG, so I don’t think that’s an option for these two. OPSAWG would be an option, but only if we definitively close IPFIX (otherwise the question is “why not recharter IPFIX”).
>
> Separate is the meeting-in-London question. At least here I can say I will not attend the currently-scheduled IPFIX meeting in London as it conflicts with a BoF I’m co-chairing; we’ve already tried to de-conflict this with no luck.
>
> Cheers,
>
> Brian
>
> On 10 Feb 2014, at 11:32, Paul Aitken <paitken@cisco.com> wrote:
>
>> Nevil,
>>
>>> Hi Paul, Andrew and IPFIXers:
>>>
>>> Looking back at the IPFIX minutes for IETF-88 (Vancouver), we
>>> said that "the WG will close when the current charter items are
>>> complete."  The only remaining charter item is the MIB Variable
>>> Export draft, current version is -03, 21 Oct 2013.  It's
>>> disappointing that we haven't seen a revision of that draft in 2014;
>>> when we have a new version, we should be able to start its WGLC.
>>
>> We're working on the next version.
>>
>>
>>> Paul and Andrew were the only two who responded to my 2 Feb email.
>>> Neither of the the two drafts they mentioned have been updated
>>> since January 2014,
>>
>> Oh come on Nevil! One's dated Dec 27th, the other Dec 31st. How fresh do they need to be?
>>
>> So I have these two drafts which I believe are important to IPFIX, and an independent second-opinion concurs. How can these drafts be progressed?
>>
>>
>>> and there's been no discussion of them on the IPFIX list.
>>
>> I've presented these ideas in previous WG meetings, where the consensus was to wait for the next re-charter.
>> I'm sure they've been discussed on-list too.
>>
>>
>> P.
>>
>>
>>> The same goes for the Cisco IEs draft, current version -09, 15 Jan 2014.
>>>
>>> Therefore, IPFIX will not hold a formal meeting in London, I'll
>>> inform the secretariat that we're cancelling the IPFIX meeting.
>>>
>>> Going forward from this ...
>>>
>>> - of course we can have an informal get-together of IPFIX people
>>>   in London - any volunteers to organise such a gathering?
>>>
>>> - the IPFIX mailing list will remain open for quite some time,
>>>   please use it to discuss anything relevant to IPFIX
>>>
>>> Cheers, Nevil
>>>
>>>
>>> On 3/02/14 11:39 PM, Paul Aitken wrote:
>>>> Nevil,
>>>>
>>>> I updated a couple of drafts. If the WG is to close, then I'll be
>>>> looking for a new home for these, because this is important work which
>>>> does need addressed:
>>>>
>>>>
>>>> aitken-ipfix-equivalent-ies
>>>> <http://tools.ietf.org/html/draft-aitken-ipfix-equivalent-ies>
>>>>
>>>>     This document specifies a method for an Exporter to inform a
>>>>     Collector of equivalence between different Information Elements, so
>>>>     that the Collecting Process can understand the equivalence and be
>>>>     enabled to process data across a change of Information Elements,
>>>>     which allows a seamless transition from Enterprise-specific to
>>>>     IANA-standard elements.
>>>>
>>>> aitken-ipfix-unobserved-fields
>>>> <http://tools.ietf.org/html/draft-aitken-ipfix-unobserved-fields>
>>>>
>>>>     This draft discusses several methods for reporting when fields are
>>>>     unavailable, reviews the advantages and disadvantage of each, and
>>>>     recommends methods which should be used.
>>>>     Cisco has already implemented some of the mechanisms in this draft.
>>>>
>>>>
>>>> P.

-- 
---------------------------------------------------------------------
  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