From n.brownlee@auckland.ac.nz Mon Feb 3 00:09:03 2014 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42A401A0170 for ; Mon, 3 Feb 2014 00:09:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.164 X-Spam-Level: X-Spam-Status: No, score=0.164 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.535, 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 WXbBjp9JLFeM for ; Mon, 3 Feb 2014 00:09:00 -0800 (PST) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) by ietfa.amsl.com (Postfix) with ESMTP id 83B201A0082 for ; Mon, 3 Feb 2014 00:08:58 -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=1391414937; x=1422950937; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=owL0+vWxJtJJcsPFLWzJSTqyZwu4ghP0C+yYZe/9rdw=; b=IIF51QdQbDa62+Oo+c2kXyqSs8Lv1eXOlApiswuu9dSn4I1c8/AmKVeF l0H753x/9po4WzzDpCC/TNyCLG5mO8js8qUHy0PuV93iwXk/wsvWPLQXY uPeMQX1EJrun+PKywg3HIHQIBQCuZO6H+RVGMYR2K0vMpbKZq3YSr1Y6c Q=; X-IronPort-AV: E=Sophos;i="4.95,771,1384254000"; d="scan'208";a="232525131" X-Ironport-HAT: None - $RELAY-AUTH X-Ironport-Source: 121.99.93.148 - Outgoing - Outgoing-SSL Received: from 121-99-93-148.bng1.tvc.orcon.net.nz (HELO [192.168.0.4]) ([121.99.93.148]) by mx2-int.auckland.ac.nz with ESMTP; 03 Feb 2014 21:08:53 +1300 Message-ID: <52EF4E92.3040906@auckland.ac.nz> Date: Mon, 03 Feb 2014 21:08:50 +1300 From: Nevil Brownlee User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: IPFIX list Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2014 08:09:03 -0000 Hi IPFIXers: Back when session scheduling for IETF 89 started, I requested a slot for IPFIX, "just in case." Since then the Link-Layer Attributes and Mediation Protocol drafts have been sent to the RFC Editor, and the text-adt draft is in WGLC. We expect a new revision of the MIB Variable export draft shortly, so that would be the only agenda item for London. I feel that version can be reviewed and discussed on the IPFIX list, so we don't now need to have a formal IPFIX meeting in London. If you believe that a meeting is needed, please email the list telling us what that is, and why we need meeting time for it. If I don't see such email(s) within the next week, we'll cancel the meeting. Cheers, Nevil -- --------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand From paitken@cisco.com Mon Feb 3 06:13:29 2014 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52C2D1A01D1 for ; Mon, 3 Feb 2014 06:13:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.729 X-Spam-Level: X-Spam-Status: No, score=-8.729 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, TRACKER_ID=1.306, USER_IN_DEF_DKIM_WL=-7.5] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xVPp-OCdyTRf for ; Mon, 3 Feb 2014 06:13:27 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id 4B3281A02B2 for ; Mon, 3 Feb 2014 02:39:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5135; q=dns/txt; s=iport; t=1391423998; x=1392633598; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=J2pyhNTQi1LMIgxah2P/oBi7PcV7L8h7rYqAxBbeXdo=; b=FpNcHRqYdoS9fP6DCgtsIsvbhqhRcKrlohiy38eON4G7mPS0cezqu5HX 9eswKFu9NswXWACi30cDNyC5CBxoff4ovmIgv9t04pYSgBBGvFNB7gIfY DbqjuDhy1lJHXZ/UR7ANQABxYDBk07AxArwIf58ak23gKzZrMldLYOaNn k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFANFw71KQ/khR/2dsb2JhbABZDoJ+OIk1tTqBBRZ0giUBAQEEeBELBAoKCRYPCQMCAQIBRQYBDAgBAYgBDcwCF44nDgMBV4Q4BJgqgTKFFotZgm4/gXE X-IronPort-AV: E=Sophos;i="4.95,771,1384300800"; d="scan'208,217";a="3912133" Received: from ams-core-1.cisco.com ([144.254.72.81]) by aer-iport-2.cisco.com with ESMTP; 03 Feb 2014 10:39:56 +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 s13AduGj031178 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Feb 2014 10:39:56 GMT Received: from [10.61.106.22] (dhcp-10-61-106-22.cisco.com [10.61.106.22]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id s13AdsAh002266; Mon, 3 Feb 2014 10:39:55 GMT Message-ID: <52EF71FA.3090005@cisco.com> Date: Mon, 03 Feb 2014 10:39:54 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Nevil Brownlee , IPFIX list References: <52EF4E92.3040906@auckland.ac.nz> In-Reply-To: <52EF4E92.3040906@auckland.ac.nz> Content-Type: multipart/alternative; boundary="------------020808050803050101090108" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2014 14:13:29 -0000 This is a multi-part message in MIME format. --------------020808050803050101090108 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 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 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. On 03/02/2014 08:08, Nevil Brownlee wrote: > > Hi IPFIXers: > > Back when session scheduling for IETF 89 started, I requested a > slot for IPFIX, "just in case." > > Since then the Link-Layer Attributes and Mediation Protocol drafts > have been sent to the RFC Editor, and the text-adt draft is in WGLC. > > We expect a new revision of the MIB Variable export draft shortly, > so that would be the only agenda item for London. I feel that > version can be reviewed and discussed on the IPFIX list, so we > don't now need to have a formal IPFIX meeting in London. > > If you believe that a meeting is needed, please email the list > telling us what that is, and why we need meeting time for it. > If I don't see such email(s) within the next week, we'll cancel > the meeting. > > Cheers, Nevil > --------------020808050803050101090108 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
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

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

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.


On 03/02/2014 08:08, Nevil Brownlee wrote:

Hi IPFIXers:

Back when session scheduling for IETF 89 started, I requested a
slot for IPFIX, "just in case."

Since then the Link-Layer Attributes and Mediation Protocol drafts
have been sent to the RFC Editor, and the text-adt draft is in WGLC.

We expect a new revision of the MIB Variable export draft shortly,
so that would be the only agenda item for London.  I feel that
version can be reviewed and discussed on the IPFIX list, so we
don't now need to have a formal IPFIX meeting in London.

If you believe that a meeting is needed, please email the list
telling us what that is, and why we need meeting time for it.
If I don't see such email(s) within the next week, we'll cancel
the meeting.

Cheers, Nevil


--------------020808050803050101090108-- From andrewf@plixer.com Mon Feb 3 07:40:13 2014 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1180A1A0115 for ; Mon, 3 Feb 2014 07:40:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.128 X-Spam-Level: X-Spam-Status: No, score=-1.128 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535, TRACKER_ID=1.306] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ud594BRfKBo for ; Mon, 3 Feb 2014 07:40:11 -0800 (PST) Received: from mx1.plixer.com (mx1.plixer.com [64.140.243.154]) by ietfa.amsl.com (Postfix) with ESMTP id D5A8C1A0032 for ; Mon, 3 Feb 2014 07:40:10 -0800 (PST) Received: from [10.1.14.85] (64.140.243.154) by mx1.plixer.com (10.1.5.1) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 3 Feb 2014 10:40:09 -0500 Message-ID: <52EFB85A.3070409@plixer.com> Date: Mon, 3 Feb 2014 10:40:10 -0500 From: Andrew Feren User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Paul Aitken , Nevil Brownlee , IPFIX list References: <52EF4E92.3040906@auckland.ac.nz> <52EF71FA.3090005@cisco.com> In-Reply-To: <52EF71FA.3090005@cisco.com> Content-Type: multipart/alternative; boundary="------------010806080707070506010309" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2014 15:40:13 -0000 --------------010806080707070506010309 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Hi All, +1. Those drafts need to be addressed. -Andrew On 02/03/2014 05:39 AM, 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 > > > 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 > > > 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. > > > On 03/02/2014 08:08, Nevil Brownlee wrote: >> >> Hi IPFIXers: >> >> Back when session scheduling for IETF 89 started, I requested a >> slot for IPFIX, "just in case." >> >> Since then the Link-Layer Attributes and Mediation Protocol drafts >> have been sent to the RFC Editor, and the text-adt draft is in WGLC. >> >> We expect a new revision of the MIB Variable export draft shortly, >> so that would be the only agenda item for London. I feel that >> version can be reviewed and discussed on the IPFIX list, so we >> don't now need to have a formal IPFIX meeting in London. >> >> If you believe that a meeting is needed, please email the list >> telling us what that is, and why we need meeting time for it. >> If I don't see such email(s) within the next week, we'll cancel >> the meeting. >> >> Cheers, Nevil >> > > > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix --------------010806080707070506010309 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit
Hi All,

+1.  Those drafts need to be addressed.

-Andrew

On 02/03/2014 05:39 AM, 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

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

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.


On 03/02/2014 08:08, Nevil Brownlee wrote:

Hi IPFIXers:

Back when session scheduling for IETF 89 started, I requested a
slot for IPFIX, "just in case."

Since then the Link-Layer Attributes and Mediation Protocol drafts
have been sent to the RFC Editor, and the text-adt draft is in WGLC.

We expect a new revision of the MIB Variable export draft shortly,
so that would be the only agenda item for London.  I feel that
version can be reviewed and discussed on the IPFIX list, so we
don't now need to have a formal IPFIX meeting in London.

If you believe that a meeting is needed, please email the list
telling us what that is, and why we need meeting time for it.
If I don't see such email(s) within the next week, we'll cancel
the meeting.

Cheers, Nevil 




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

--------------010806080707070506010309-- From trammell@tik.ee.ethz.ch Wed Feb 5 00:06:07 2014 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A27491A0063 for ; Wed, 5 Feb 2014 00:06:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.735 X-Spam-Level: X-Spam-Status: No, score=-4.735 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535] 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 7m5QBhh_BAMI for ; Wed, 5 Feb 2014 00:06:03 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 588AF1A00A5 for ; Wed, 5 Feb 2014 00:06:03 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 6ED19D9302; Wed, 5 Feb 2014 09:06:02 +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 es3-s4ur0lZG; Wed, 5 Feb 2014 09:06:02 +0100 (MET) 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 15CBDD9300; Wed, 5 Feb 2014 09:06:00 +0100 (MET) Content-Type: multipart/signed; boundary="Apple-Mail=_4793966F-A0DA-4245-9A6A-02E789E5F94C"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Brian Trammell In-Reply-To: <52D40156.400@cisco.com> Date: Wed, 5 Feb 2014 09:06:00 +0100 Message-Id: <95475E31-4D58-4ACC-8466-93558A378055@tik.ee.ethz.ch> References: <20131230151331.29E9F7FC393@rfc-editor.org> <52C19DF7.4050501@plixer.com> <52C232EB.30802@cisco.com>, <535E38C8-A1C0-4FD5-991C-D9A132D97923@tik.ee.ethz.ch> <0BEF0D66-E9DB-40E7-A2E4-ABCBCA5634CB@cisco.com> <52C2BC12.6090108@tik.ee.ethz.ch> <52C55358.5060402@cisco.com> <52C6A8F9.7070706@cisco.com> <52C6E376.2060304@cisco.com> <52D40156.400@cisco.com> To: Benoit Claise X-Mailer: Apple Mail (2.1827) Cc: "joelja@bogus.com Jaeggli" , RFC Errata System , Nevil Brownlee , "ipfix@ietf.org Group" Subject: Re: [IPFIX] [Technical Errata Reported] RFC7012 (3852) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 08:06:07 -0000 --Apple-Mail=_4793966F-A0DA-4245-9A6A-02E789E5F94C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 hi Benoit, this fell off my queue but I'm picking it back up; will file an updated = erratum today. Cheers, Brian On 13 Jan 2014, at 16:08, Benoit Claise wrote: > Brian, Stewart, >=20 > Can you please let me know what's the latest conclusion on this = errata, and update the errata accordingly. >=20 > Regards, Benoit >> On 03/01/2014 15:39, Brian Trammell wrote: >>> Hi Stewart, >>>=20 >>> On 03 Jan 2014, at 13:11, Stewart Bryant wrote: >>>=20 >>>>>=20 >>>>> So each instance of an IE of an ADT can take a value, and that = value exists separate from its encoding. 7011 and 7012 together combine = to make an unambiguous mapping between the two possible in IPFIX. >>>>=20 >>>> I think the key is the last sentence, and so long as we make that = clear we are good. >>>>=20 >>>> Maybe some text of the form "relative to the defined epoch" would = sort it out. At least >>>> that would remind the reader that they needs to know rather than = assume the epoch. >>>=20 >>> This may seem like a tiny little nit to pick, but we thought a = _whole lot_ about this when moving the epochs out of 5102bis, and I = still think the reasons therefor are valid. I=92d ask you to reconsider = insisting on timestamps as relative to a fixed epoch. I=92d rather state = instead something like "it is the responsibility of the encoding to = ensure that each representation has an unambiguous mapping to a moment = in time (e.g. relative to a defined epoch)." >>=20 >> If you are proposing that text, that would work for me.=20 >>>=20 >>> Otherwise we go down the calendar rathole very, very quickly, and = we=92ve tried very hard not to do that. Indeed, one can define any time = representation as relative to some epoch, more or less fuzzily. However, = back to our ISO 8601 example, one can indeed interpret =932014-01-03 = 10:00:00 UTC=94 as a fixed number of years, months, days, hours, and so = on from the implicit epoch 0001-01-01 00:00:00 UTC. One would be wrong, = given variability in Julian-Gregorian calendar transitions, policies for = accounting/ignoring leap seconds, and all those other assumptions one = has to make when turning a human-readable timestamp (our =93ideal=94 = value) to some notion of the moment in time it references. >>>=20 >>> I submit that these differences are largely irrelevant on the = timescales and for the types of comparisons in event timing =97 whether = network management related or not =97 that the IPFIX information model = is likely to be applied to. But if we bake fixed-epoch references into = the information model we=92re forced to care about them regardless. >> No, I am fine with the IM not baking in the epoch, now I understand = the approach, and the with the other changes that tell the reader that = they moved. However, I think you do need to help the reader understand = the importance of understanding the of the epoch (and now you remind me = the discontinuities). The above sentence will do this. >>=20 >> Stewart >>=20 >>>=20 >>> Thanks, cheers, >>>=20 >>> Brian >>>=20 >>>>>> We may need a call to work though this and another issue >>>>>> I am about to raise on the IPFIX list. >>>>>>=20 >>>>>> - Stewart >>>>>>=20 >>>>>>=20 >>>>>> On 31/12/2013 12:44, Brian Trammell wrote: >>>>>>> hi Stewart, >>>>>>>=20 >>>>>>> Stewart Bryant (stbryant) wrote: >>>>>>>=20 >>>>>>>> Certainly something is needed. I was thinking of using IPFIX as = an information gathering method in a radio context, and went to look at = the definition of the types and could not find the epoch, or even a = reference to the epoch. Now part of the problem (which was my fault) was = that I did not notice at the time that the elements were defined by the = obsolete RFC5102 and went straight to the new RFC. However having the = definitions in an obsolete RFC also seems problematic, since it puts the = IEs in a strange state. Since RFC 7012 replaces RFC5102 and includes the = definitions you would expect the definition in RFC7012 to replace the = definition in RFC5102, but those definitions are, as I explained = incomplete. >>>>>>>>=20 >>>>>>> This is intentional. See below. >>>>>>>=20 >>>>>>>=20 >>>>>>>> I need to look at this some more when I get back to work, but I = am now also concerned that if the epoch can change, the definition of = the existing IEs is now unreliable. >>>>>>>>=20 >>>>>>> The definition of the existing IEs is based upon the definition = of the >>>>>>> ADT itself in 7012 as well as the definition of the ADT = representation >>>>>>> within the IPFIX protocol in 7011. It is not the intention that = reading >>>>>>> 7012 tells you how to encode IEs for use with IPFIX; that's what = section >>>>>>> 6.1 of 7011 is for. >>>>>>>=20 >>>>>>>=20 >>>>>>>> You will notice in the errata that I did suggest that an = alternative resolution would be to include a reference to the epoch = text. >>>>>>>>=20 >>>>>>> The point is that the ADT _explicitly_ does not have a binding = to an >>>>>>> epoch, as epochs are only necessary when using integral = representations >>>>>>> of timestamps. IPFIX's representations for these ADTs are = integral, but >>>>>>> bindings to other representations need not be (see, for example, >>>>>>> draft-trammell-ipfix-text-adt, which recommends ISO8601-style = timestamps >>>>>>> for textual representations of IE values). >>>>>>>=20 >>>>>>> I'd suggest instead somehow expanding the present text in 7012 = to >>>>>>> reiterate that if you're using IPFIX, the representations of the = ADTs >>>>>>> are in 7011: >>>>>>>=20 >>>>>>> OLD para 2 sec 3.1 7012: >>>>>>>=20 >>>>>>> The current encodings of these data types for use with the = IPFIX >>>>>>> protocol are defined in [RFC7011]; encodings allowing the use = of the >>>>>>> IPFIX Information Elements [IANA-IPFIX] with other protocols = may be >>>>>>> defined in the future by referencing this document. >>>>>>>=20 >>>>>>> NEW para 2 sec 3.1 7012: >>>>>>>=20 >>>>>>> The abstract data type definitions in this section are = intended >>>>>>> only to define the values which can be taken by Information >>>>>>> Elements of each type. The encodings of these data types for >>>>>>> use with the IPFIX protocol are defined in Section 6.1 of >>>>>>> [RFC7011]; encodings allowing the use of the IPFIX = Information >>>>>>> Elements [IANA-IPFIX] with other protocols may be defined in = the >>>>>>> future by referencing this document. >>>>>>>=20 >>>>>>> Best regards, >>>>>>>=20 >>>>>>> Brian >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>> Stewart >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Sent from my iPad >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>> On 31 Dec 2013, at 08:50, "Brian Trammell" = >>>>>>>>> wrote: >>>>>>>>>=20 >>>>>>>>> hi Paul, all, >>>>>>>>>=20 >>>>>>>>> +n. >>>>>>>>>=20 >>>>>>>>> The separation between ADTs and ADT encoding between 7012 and = 7011 was explicit and purposeful. Specifically, we do _not_ want to = exclude other representations of the IPFIX Information Model from being = based upon other encodings of these ADTs, whether ISO 8601 (which either = has no epoch or epoch 0000-00-00 00:00 UTC, depending on how you count), = NTP (1904), Julian day based counting, etc, etc, etc=85 >>>>>>>>>=20 >>>>>>>>> If there is confusion on this point, I=92d suggest adding more = explanatory text on this point to Paragraph 2 of the front matter to = section 3.1. But as is, I emphatically recommend rejection of this = reported erratum. >>>>>>>>>=20 >>>>>>>>> Best regards, >>>>>>>>>=20 >>>>>>>>> Brian >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> On 31 Dec 2013, at 03:58, Paul Aitken >>>>>>>>>> wrote: >>>>>>>>>>=20 >>>>>>>>>> +1 >>>>>>>>>>=20 >>>>>>>>>> If anyone was going to raise an errata on this, it would have = been me ;-) >>>>>>>>>>=20 >>>>>>>>>> I've pointed this issue out before, probably more than once - = and have been encouraged to read RFC 3444. >>>>>>>>>>=20 >>>>>>>>>> P. >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>> On 30/12/2013 09:23, Andrew Feren wrote: >>>>>>>>>>> The encoding for the time data types is specified RFC 7011 = Sections >>>>>>>>>>> 6.1.7 through 6.1.10. >>>>>>>>>>>=20 >>>>>>>>>>> -Andrew >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>> On 12/30/2013 10:13 AM, RFC Errata System wrote: >>>>>>>>>>>> The following errata report has been submitted for RFC7012, >>>>>>>>>>>> "Information Model for IP Flow Information Export (IPFIX)". >>>>>>>>>>>>=20 >>>>>>>>>>>> -------------------------------------- >>>>>>>>>>>> You may review the report below and at: >>>>>>>>>>>>=20 >>>>>>>>>>>> = http://www.rfc-editor.org/errata_search.php?rfc=3D7012&eid=3D3852 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> -------------------------------------- >>>>>>>>>>>> Type: Technical >>>>>>>>>>>> Reported by: Stewart Bryant=20 >>>>>>>>>>>> >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> Section: 3.1.15-17 >>>>>>>>>>>>=20 >>>>>>>>>>>> Original Text >>>>>>>>>>>> ------------- >>>>>>>>>>>> 3.1.15. dateTimeSeconds >>>>>>>>>>>>=20 >>>>>>>>>>>> The type "dateTimeSeconds" represents a time value = expressed with >>>>>>>>>>>> second-level precision. >>>>>>>>>>>>=20 >>>>>>>>>>>> 3.1.16. dateTimeMilliseconds >>>>>>>>>>>>=20 >>>>>>>>>>>> The type "dateTimeMilliseconds" represents a time value = expressed >>>>>>>>>>>> with millisecond-level precision. >>>>>>>>>>>>=20 >>>>>>>>>>>> 3.1.17. dateTimeMicroseconds >>>>>>>>>>>>=20 >>>>>>>>>>>> The type "dateTimeMicroseconds" represents a time value = expressed >>>>>>>>>>>> with microsecond-level precision. >>>>>>>>>>>>=20 >>>>>>>>>>>> 3.1.18. dateTimeNanoseconds >>>>>>>>>>>>=20 >>>>>>>>>>>> The type "dateTimeNanoseconds" represents a time value = expressed with >>>>>>>>>>>> nanosecond-level precision. >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> Corrected Text >>>>>>>>>>>> -------------- >>>>>>>>>>>> 3.1.15. dateTimeSeconds >>>>>>>>>>>>=20 >>>>>>>>>>>> The type "dateTimeSeconds" represents a time value in = units of >>>>>>>>>>>> seconds based on coordinated universal time (UTC). The = choice of an >>>>>>>>>>>> epoch, for example, 00:00 UTC, January 1, 1970, is left = to >>>>>>>>>>>> corresponding encoding specifications for this type, for = example, the >>>>>>>>>>>> IPFIX protocol specification. Leap seconds are excluded. = Note that >>>>>>>>>>>> transformation of values might be required between = different >>>>>>>>>>>> encodings if different epoch values are used. >>>>>>>>>>>>=20 >>>>>>>>>>>> 3.1.16. dateTimeMilliseconds >>>>>>>>>>>>=20 >>>>>>>>>>>> The type "dateTimeMilliseconds" represents a time value = in units of >>>>>>>>>>>> milliseconds based on coordinated universal time (UTC). = The choice >>>>>>>>>>>> of an epoch, for example, 00:00 UTC, January 1, 1970, is = left to >>>>>>>>>>>> corresponding encoding specifications for this type, for = example, the >>>>>>>>>>>> IPFIX protocol specification. Leap seconds are excluded. = Note that >>>>>>>>>>>> transformation of values might be required between = different >>>>>>>>>>>> encodings if different epoch values are used. >>>>>>>>>>>>=20 >>>>>>>>>>>> 3.1.17. dateTimeMicroseconds >>>>>>>>>>>>=20 >>>>>>>>>>>> The type "dateTimeMicroseconds" represents a time value = in units of >>>>>>>>>>>> microseconds based on coordinated universal time (UTC). = The choice >>>>>>>>>>>> of an epoch, for example, 00:00 UTC, January 1, 1970, is = left to >>>>>>>>>>>> corresponding encoding specifications for this type, for = example, the >>>>>>>>>>>> IPFIX protocol specification. Leap seconds are excluded. = Note that >>>>>>>>>>>> transformation of values might be required between = different >>>>>>>>>>>> encodings if different epoch values are used. >>>>>>>>>>>>=20 >>>>>>>>>>>> 3.1.18. dateTimeNanoseconds >>>>>>>>>>>>=20 >>>>>>>>>>>> The type "dateTimeNanoseconds" represents a time value in = units of >>>>>>>>>>>> nanoseconds based on coordinated universal time (UTC). = The choice of >>>>>>>>>>>> an epoch, for example, 00:00 UTC, January 1, 1970, is = left to >>>>>>>>>>>> corresponding encoding specifications for this type, for = example, the >>>>>>>>>>>> IPFIX protocol specification. Leap seconds are excluded. = Note that >>>>>>>>>>>> transformation of values might be required between = different >>>>>>>>>>>> encodings if different epoch values are used. >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> Notes >>>>>>>>>>>> ----- >>>>>>>>>>>> Although section 1.1 says : - "Definitions of timestamp = data types have been clarified." The edited text has removed the epoch = definition, and this does not seem to have been incorporated elsewhere = in the RFC. >>>>>>>>>>>>=20 >>>>>>>>>>>> Without a specified epoch, there is no unique definition of = the timestamps. >>>>>>>>>>>>=20 >>>>>>>>>>>> My proposal above is to revert to the RFC5102 definitions. = RFC7102 is intended to be backwards compatible with RFC5102 and thus the = definitions need to be technically identical. Alternatively, if the text = is now included elsewhere in RFC7012 or in another RFC, it would be = helpful to the reader to provide a reference to the epoch definition in = an editorial update to dateTimeX definitions in RFC7102. >>>>>>>>>>>>=20 >>>>>>>>>>>> Instructions: >>>>>>>>>>>> ------------- >>>>>>>>>>>> This errata is currently posted as "Reported". If = necessary, please >>>>>>>>>>>> use "Reply All" to discuss whether it should be verified or >>>>>>>>>>>> rejected. When a decision is reached, the verifying party = (IESG) >>>>>>>>>>>> can log in to change the status and edit the report, if = necessary. >>>>>>>>>>>>=20 >>>>>>>>>>>> -------------------------------------- >>>>>>>>>>>> RFC7012 (draft-ietf-ipfix-information-model-rfc5102bis-10) >>>>>>>>>>>> -------------------------------------- >>>>>>>>>>>> Title : Information Model for IP Flow = Information Export (IPFIX) >>>>>>>>>>>> Publication Date : September 2013 >>>>>>>>>>>> Author(s) : B. Claise, Ed., B. Trammell, Ed. >>>>>>>>>>>> Category : PROPOSED STANDARD >>>>>>>>>>>> Source : IP Flow Information Export >>>>>>>>>>>> Area : Operations and Management >>>>>>>>>>>> Stream : IETF >>>>>>>>>>>> Verifying Party : IESG >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> IPFIX mailing list >>>>>>>>>>>>=20 >>>>>>>>>>>> IPFIX@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/ipfix >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> IPFIX mailing list >>>>>>>>>>>=20 >>>>>>>>>>> IPFIX@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/ipfix >>>>>>>>> _______________________________________________ >>>>>>>>> IPFIX mailing list >>>>>>>>>=20 >>>>>>>>> IPFIX@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/ipfix >>>>>>=20 >>>>>>=20 >>>>>> --=20 >>>>>> For corporate legal information go to: >>>>>>=20 >>>>>>=20 >>>>>> = http://www.cisco.com/web/about/doing_business/legal/cri/index.html >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>=20 >>>>=20 >>>>=20 >>>> --=20 >>>> For corporate legal information go to: >>>>=20 >>>>=20 >>>> http://www.cisco.com/web/about/doing_business/legal/cri/index.html >>>>=20 >>>>=20 >>>>=20 >>>=20 >>=20 >>=20 >> --=20 >> For corporate legal information go to: >>=20 >>=20 >> http://www.cisco.com/web/about/doing_business/legal/cri/index.html >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> IPFIX mailing list >>=20 >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix >=20 --Apple-Mail=_4793966F-A0DA-4245-9A6A-02E789E5F94C 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 iQEcBAEBCgAGBQJS8fDoAAoJENt3nsOmbNJc/q0IAMvm+B9hEDAxprsVsx99sVfG vE92CIS0on8PrCcVZeP4jLnFe4WPl0PwA4tDUYS4wb9OHq3UcICF9H3X5z6vDFXU vGJ4kLjWu1AHonceWOhLz2WxmnoHmkJIEFb7e6o8OicelvuaIDU3kzdD9o00Y3BM Y9c/M/j3ZNr1a+jfI8ciX5Zagjr5ooaLOW1NQend0uTkIzRsr/VsbAlEC5U7dVFF hJkn5FpIdh0nwmfKgHIls7qY7w3Vaua5iSQaI3No2jJPUbl+hyK18Qn63U04K7lb 6e+1WIMIKaK5MuL5eFHyJkoQwv7L2hf1SVMGC9jmqapa9hyHLUHyLzvWVWAfUaA= =1bqv -----END PGP SIGNATURE----- --Apple-Mail=_4793966F-A0DA-4245-9A6A-02E789E5F94C-- From wwwrun@rfc-editor.org Wed Feb 5 00:14:52 2014 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECA341A00A6 for ; Wed, 5 Feb 2014 00:14:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.953 X-Spam-Level: X-Spam-Status: No, score=0.953 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.793, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JWeo0wgYqXRC for ; Wed, 5 Feb 2014 00:14:51 -0800 (PST) Received: from rfc-editor.org (unknown [IPv6:2607:f170:8000:1500::d3]) by ietfa.amsl.com (Postfix) with ESMTP id CC2F01A009E for ; Wed, 5 Feb 2014 00:14:51 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 692BA7FC393; Wed, 5 Feb 2014 00:14:49 -0800 (PST) To: bclaise@cisco.com, trammell@tik.ee.ethz.ch, bclaise@cisco.com, joelja@bogus.com, n.brownlee@auckland.ac.nz, quittek@neclab.eu From: RFC Errata System Message-Id: <20140205081449.692BA7FC393@rfc-editor.org> Date: Wed, 5 Feb 2014 00:14:49 -0800 (PST) Cc: rfc-editor@rfc-editor.org, ipfix@ietf.org Subject: [IPFIX] [Technical Errata Reported] RFC7012 (3881) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 08:14:53 -0000 The following errata report has been submitted for RFC7012, "Information Model for IP Flow Information Export (IPFIX)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7012&eid=3881 -------------------------------------- Type: Technical Reported by: Brian Trammell Section: 3.1 Original Text ------------- The current encodings of these data types for use with the IPFIX protocol are defined in [RFC7011]; encodings allowing the use of the IPFIX Information Elements [IANA-IPFIX] with other protocols may be defined in the future by referencing this document. Corrected Text -------------- The abstract data type definitions in this section are intended only to define the values which can be taken by Information Elements of each type. The encodings of these data types for use with the IPFIX protocol are defined in Section 6.1 of [RFC7011]; encodings allowing the use of the IPFIX Information Elements [IANA-IPFIX] with other protocols may be defined in the future by referencing this document. Note that for timestamp encodings (sections 3.1.15 - 3.1.18), it is the responsibility of the encoding to ensure that each representation has an unambiguous mapping to a moment in time (e.g. relative to a defined epoch). Notes ----- The separation of epoch selection between ADT and encoding in 7011 and 7012 (as compared to 5101 and 5102, which they obsolete, respectively) led to it being unclear that timestamp ADTs require a fixed reference epoch for interpretation. This change clarifies the point, replacing Errata ID 3852. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC7012 (draft-ietf-ipfix-information-model-rfc5102bis-10) -------------------------------------- Title : Information Model for IP Flow Information Export (IPFIX) Publication Date : September 2013 Author(s) : B. Claise, Ed., B. Trammell, Ed. Category : PROPOSED STANDARD Source : IP Flow Information Export Area : Operations and Management Stream : IETF Verifying Party : IESG From trammell@tik.ee.ethz.ch Wed Feb 5 00:16:07 2014 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8C051A00A6 for ; Wed, 5 Feb 2014 00:16:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.735 X-Spam-Level: X-Spam-Status: No, score=-4.735 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535] 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 mwC4uOfQv4lK for ; Wed, 5 Feb 2014 00:16:04 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 820771A009E for ; Wed, 5 Feb 2014 00:16:03 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 7D5D1D9302; Wed, 5 Feb 2014 09:16:02 +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 ulOlQOT8J6HQ; Wed, 5 Feb 2014 09:16:02 +0100 (MET) 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 7A790D9300; Wed, 5 Feb 2014 09:16:01 +0100 (MET) Content-Type: multipart/signed; boundary="Apple-Mail=_87809E5E-C9E1-4F8B-8A04-383809B80D13"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Brian Trammell In-Reply-To: <95475E31-4D58-4ACC-8466-93558A378055@tik.ee.ethz.ch> Date: Wed, 5 Feb 2014 09:15:59 +0100 Message-Id: <7F1E2356-7C03-4058-8627-2DF1C30844C4@tik.ee.ethz.ch> References: <20131230151331.29E9F7FC393@rfc-editor.org> <52C19DF7.4050501@plixer.com> <52C232EB.30802@cisco.com>, <535E38C8-A1C0-4FD5-991C-D9A132D97923@tik.ee.ethz.ch> <0BEF0D66-E9DB-40E7-A2E4-ABCBCA5634CB@cisco.com> <52C2BC12.6090108@tik.ee.ethz.ch> <52C55358.5060402@cisco.com> <52C6A8F9.7070706@cisco.com> <52C6E376.2060304@cisco.com> <52D40156.400@cisco.com> <95475E31-4D58-4ACC-8466-93558A378055@tik.ee.ethz.ch> To: Benoit Claise X-Mailer: Apple Mail (2.1827) Cc: "joelja@bogus.com Jaeggli" , Nevil Brownlee , "ipfix@ietf.org Group" , RFC Errata System Subject: Re: [IPFIX] [Technical Errata Reported] RFC7012 (3852) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 08:16:07 -0000 --Apple-Mail=_87809E5E-C9E1-4F8B-8A04-383809B80D13 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 hi Benoit, Done, errata 3881. I recommend rejecting 3852 (with a pointer to this = one). Cheers, Brian On 05 Feb 2014, at 09:06, Brian Trammell = wrote: > hi Benoit, >=20 > this fell off my queue but I'm picking it back up; will file an = updated erratum today. >=20 > Cheers, >=20 > Brian >=20 > On 13 Jan 2014, at 16:08, Benoit Claise wrote: >=20 >> Brian, Stewart, >>=20 >> Can you please let me know what's the latest conclusion on this = errata, and update the errata accordingly. >>=20 >> Regards, Benoit >>> On 03/01/2014 15:39, Brian Trammell wrote: >>>> Hi Stewart, >>>>=20 >>>> On 03 Jan 2014, at 13:11, Stewart Bryant = wrote: >>>>=20 >>>>>>=20 >>>>>> So each instance of an IE of an ADT can take a value, and that = value exists separate from its encoding. 7011 and 7012 together combine = to make an unambiguous mapping between the two possible in IPFIX. >>>>>=20 >>>>> I think the key is the last sentence, and so long as we make that = clear we are good. >>>>>=20 >>>>> Maybe some text of the form "relative to the defined epoch" would = sort it out. At least >>>>> that would remind the reader that they needs to know rather than = assume the epoch. >>>>=20 >>>> This may seem like a tiny little nit to pick, but we thought a = _whole lot_ about this when moving the epochs out of 5102bis, and I = still think the reasons therefor are valid. I=92d ask you to reconsider = insisting on timestamps as relative to a fixed epoch. I=92d rather state = instead something like "it is the responsibility of the encoding to = ensure that each representation has an unambiguous mapping to a moment = in time (e.g. relative to a defined epoch)." >>>=20 >>> If you are proposing that text, that would work for me.=20 >>>>=20 >>>> Otherwise we go down the calendar rathole very, very quickly, and = we=92ve tried very hard not to do that. Indeed, one can define any time = representation as relative to some epoch, more or less fuzzily. However, = back to our ISO 8601 example, one can indeed interpret =932014-01-03 = 10:00:00 UTC=94 as a fixed number of years, months, days, hours, and so = on from the implicit epoch 0001-01-01 00:00:00 UTC. One would be wrong, = given variability in Julian-Gregorian calendar transitions, policies for = accounting/ignoring leap seconds, and all those other assumptions one = has to make when turning a human-readable timestamp (our =93ideal=94 = value) to some notion of the moment in time it references. >>>>=20 >>>> I submit that these differences are largely irrelevant on the = timescales and for the types of comparisons in event timing =97 whether = network management related or not =97 that the IPFIX information model = is likely to be applied to. But if we bake fixed-epoch references into = the information model we=92re forced to care about them regardless. >>> No, I am fine with the IM not baking in the epoch, now I understand = the approach, and the with the other changes that tell the reader that = they moved. However, I think you do need to help the reader understand = the importance of understanding the of the epoch (and now you remind me = the discontinuities). The above sentence will do this. >>>=20 >>> Stewart >>>=20 >>>>=20 >>>> Thanks, cheers, >>>>=20 >>>> Brian >>>>=20 >>>>>>> We may need a call to work though this and another issue >>>>>>> I am about to raise on the IPFIX list. >>>>>>>=20 >>>>>>> - Stewart >>>>>>>=20 >>>>>>>=20 >>>>>>> On 31/12/2013 12:44, Brian Trammell wrote: >>>>>>>> hi Stewart, >>>>>>>>=20 >>>>>>>> Stewart Bryant (stbryant) wrote: >>>>>>>>=20 >>>>>>>>> Certainly something is needed. I was thinking of using IPFIX = as an information gathering method in a radio context, and went to look = at the definition of the types and could not find the epoch, or even a = reference to the epoch. Now part of the problem (which was my fault) was = that I did not notice at the time that the elements were defined by the = obsolete RFC5102 and went straight to the new RFC. However having the = definitions in an obsolete RFC also seems problematic, since it puts the = IEs in a strange state. Since RFC 7012 replaces RFC5102 and includes the = definitions you would expect the definition in RFC7012 to replace the = definition in RFC5102, but those definitions are, as I explained = incomplete. >>>>>>>>>=20 >>>>>>>> This is intentional. See below. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>> I need to look at this some more when I get back to work, but = I am now also concerned that if the epoch can change, the definition of = the existing IEs is now unreliable. >>>>>>>>>=20 >>>>>>>> The definition of the existing IEs is based upon the definition = of the >>>>>>>> ADT itself in 7012 as well as the definition of the ADT = representation >>>>>>>> within the IPFIX protocol in 7011. It is not the intention that = reading >>>>>>>> 7012 tells you how to encode IEs for use with IPFIX; that's = what section >>>>>>>> 6.1 of 7011 is for. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>> You will notice in the errata that I did suggest that an = alternative resolution would be to include a reference to the epoch = text. >>>>>>>>>=20 >>>>>>>> The point is that the ADT _explicitly_ does not have a binding = to an >>>>>>>> epoch, as epochs are only necessary when using integral = representations >>>>>>>> of timestamps. IPFIX's representations for these ADTs are = integral, but >>>>>>>> bindings to other representations need not be (see, for = example, >>>>>>>> draft-trammell-ipfix-text-adt, which recommends ISO8601-style = timestamps >>>>>>>> for textual representations of IE values). >>>>>>>>=20 >>>>>>>> I'd suggest instead somehow expanding the present text in 7012 = to >>>>>>>> reiterate that if you're using IPFIX, the representations of = the ADTs >>>>>>>> are in 7011: >>>>>>>>=20 >>>>>>>> OLD para 2 sec 3.1 7012: >>>>>>>>=20 >>>>>>>> The current encodings of these data types for use with the = IPFIX >>>>>>>> protocol are defined in [RFC7011]; encodings allowing the use = of the >>>>>>>> IPFIX Information Elements [IANA-IPFIX] with other protocols = may be >>>>>>>> defined in the future by referencing this document. >>>>>>>>=20 >>>>>>>> NEW para 2 sec 3.1 7012: >>>>>>>>=20 >>>>>>>> The abstract data type definitions in this section are = intended >>>>>>>> only to define the values which can be taken by Information >>>>>>>> Elements of each type. The encodings of these data types for >>>>>>>> use with the IPFIX protocol are defined in Section 6.1 of >>>>>>>> [RFC7011]; encodings allowing the use of the IPFIX = Information >>>>>>>> Elements [IANA-IPFIX] with other protocols may be defined in = the >>>>>>>> future by referencing this document. >>>>>>>>=20 >>>>>>>> Best regards, >>>>>>>>=20 >>>>>>>> Brian >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>> Stewart >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Sent from my iPad >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> On 31 Dec 2013, at 08:50, "Brian Trammell" = >>>>>>>>>> wrote: >>>>>>>>>>=20 >>>>>>>>>> hi Paul, all, >>>>>>>>>>=20 >>>>>>>>>> +n. >>>>>>>>>>=20 >>>>>>>>>> The separation between ADTs and ADT encoding between 7012 and = 7011 was explicit and purposeful. Specifically, we do _not_ want to = exclude other representations of the IPFIX Information Model from being = based upon other encodings of these ADTs, whether ISO 8601 (which either = has no epoch or epoch 0000-00-00 00:00 UTC, depending on how you count), = NTP (1904), Julian day based counting, etc, etc, etc=85 >>>>>>>>>>=20 >>>>>>>>>> If there is confusion on this point, I=92d suggest adding = more explanatory text on this point to Paragraph 2 of the front matter = to section 3.1. But as is, I emphatically recommend rejection of this = reported erratum. >>>>>>>>>>=20 >>>>>>>>>> Best regards, >>>>>>>>>>=20 >>>>>>>>>> Brian >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>> On 31 Dec 2013, at 03:58, Paul Aitken >>>>>>>>>>> wrote: >>>>>>>>>>>=20 >>>>>>>>>>> +1 >>>>>>>>>>>=20 >>>>>>>>>>> If anyone was going to raise an errata on this, it would = have been me ;-) >>>>>>>>>>>=20 >>>>>>>>>>> I've pointed this issue out before, probably more than once = - and have been encouraged to read RFC 3444. >>>>>>>>>>>=20 >>>>>>>>>>> P. >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>> On 30/12/2013 09:23, Andrew Feren wrote: >>>>>>>>>>>> The encoding for the time data types is specified RFC 7011 = Sections >>>>>>>>>>>> 6.1.7 through 6.1.10. >>>>>>>>>>>>=20 >>>>>>>>>>>> -Andrew >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>> On 12/30/2013 10:13 AM, RFC Errata System wrote: >>>>>>>>>>>>> The following errata report has been submitted for = RFC7012, >>>>>>>>>>>>> "Information Model for IP Flow Information Export = (IPFIX)". >>>>>>>>>>>>>=20 >>>>>>>>>>>>> -------------------------------------- >>>>>>>>>>>>> You may review the report below and at: >>>>>>>>>>>>>=20 >>>>>>>>>>>>> = http://www.rfc-editor.org/errata_search.php?rfc=3D7012&eid=3D3852 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> -------------------------------------- >>>>>>>>>>>>> Type: Technical >>>>>>>>>>>>> Reported by: Stewart Bryant=20 >>>>>>>>>>>>> >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Section: 3.1.15-17 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Original Text >>>>>>>>>>>>> ------------- >>>>>>>>>>>>> 3.1.15. dateTimeSeconds >>>>>>>>>>>>>=20 >>>>>>>>>>>>> The type "dateTimeSeconds" represents a time value = expressed with >>>>>>>>>>>>> second-level precision. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> 3.1.16. dateTimeMilliseconds >>>>>>>>>>>>>=20 >>>>>>>>>>>>> The type "dateTimeMilliseconds" represents a time value = expressed >>>>>>>>>>>>> with millisecond-level precision. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> 3.1.17. dateTimeMicroseconds >>>>>>>>>>>>>=20 >>>>>>>>>>>>> The type "dateTimeMicroseconds" represents a time value = expressed >>>>>>>>>>>>> with microsecond-level precision. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> 3.1.18. dateTimeNanoseconds >>>>>>>>>>>>>=20 >>>>>>>>>>>>> The type "dateTimeNanoseconds" represents a time value = expressed with >>>>>>>>>>>>> nanosecond-level precision. >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Corrected Text >>>>>>>>>>>>> -------------- >>>>>>>>>>>>> 3.1.15. dateTimeSeconds >>>>>>>>>>>>>=20 >>>>>>>>>>>>> The type "dateTimeSeconds" represents a time value in = units of >>>>>>>>>>>>> seconds based on coordinated universal time (UTC). The = choice of an >>>>>>>>>>>>> epoch, for example, 00:00 UTC, January 1, 1970, is left = to >>>>>>>>>>>>> corresponding encoding specifications for this type, for = example, the >>>>>>>>>>>>> IPFIX protocol specification. Leap seconds are excluded. = Note that >>>>>>>>>>>>> transformation of values might be required between = different >>>>>>>>>>>>> encodings if different epoch values are used. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> 3.1.16. dateTimeMilliseconds >>>>>>>>>>>>>=20 >>>>>>>>>>>>> The type "dateTimeMilliseconds" represents a time value = in units of >>>>>>>>>>>>> milliseconds based on coordinated universal time (UTC). = The choice >>>>>>>>>>>>> of an epoch, for example, 00:00 UTC, January 1, 1970, is = left to >>>>>>>>>>>>> corresponding encoding specifications for this type, for = example, the >>>>>>>>>>>>> IPFIX protocol specification. Leap seconds are excluded. = Note that >>>>>>>>>>>>> transformation of values might be required between = different >>>>>>>>>>>>> encodings if different epoch values are used. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> 3.1.17. dateTimeMicroseconds >>>>>>>>>>>>>=20 >>>>>>>>>>>>> The type "dateTimeMicroseconds" represents a time value = in units of >>>>>>>>>>>>> microseconds based on coordinated universal time (UTC). = The choice >>>>>>>>>>>>> of an epoch, for example, 00:00 UTC, January 1, 1970, is = left to >>>>>>>>>>>>> corresponding encoding specifications for this type, for = example, the >>>>>>>>>>>>> IPFIX protocol specification. Leap seconds are excluded. = Note that >>>>>>>>>>>>> transformation of values might be required between = different >>>>>>>>>>>>> encodings if different epoch values are used. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> 3.1.18. dateTimeNanoseconds >>>>>>>>>>>>>=20 >>>>>>>>>>>>> The type "dateTimeNanoseconds" represents a time value in = units of >>>>>>>>>>>>> nanoseconds based on coordinated universal time (UTC). = The choice of >>>>>>>>>>>>> an epoch, for example, 00:00 UTC, January 1, 1970, is = left to >>>>>>>>>>>>> corresponding encoding specifications for this type, for = example, the >>>>>>>>>>>>> IPFIX protocol specification. Leap seconds are excluded. = Note that >>>>>>>>>>>>> transformation of values might be required between = different >>>>>>>>>>>>> encodings if different epoch values are used. >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Notes >>>>>>>>>>>>> ----- >>>>>>>>>>>>> Although section 1.1 says : - "Definitions of timestamp = data types have been clarified." The edited text has removed the epoch = definition, and this does not seem to have been incorporated elsewhere = in the RFC. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Without a specified epoch, there is no unique definition = of the timestamps. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> My proposal above is to revert to the RFC5102 definitions. = RFC7102 is intended to be backwards compatible with RFC5102 and thus the = definitions need to be technically identical. Alternatively, if the text = is now included elsewhere in RFC7012 or in another RFC, it would be = helpful to the reader to provide a reference to the epoch definition in = an editorial update to dateTimeX definitions in RFC7102. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Instructions: >>>>>>>>>>>>> ------------- >>>>>>>>>>>>> This errata is currently posted as "Reported". If = necessary, please >>>>>>>>>>>>> use "Reply All" to discuss whether it should be verified = or >>>>>>>>>>>>> rejected. When a decision is reached, the verifying party = (IESG) >>>>>>>>>>>>> can log in to change the status and edit the report, if = necessary. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> -------------------------------------- >>>>>>>>>>>>> RFC7012 (draft-ietf-ipfix-information-model-rfc5102bis-10) >>>>>>>>>>>>> -------------------------------------- >>>>>>>>>>>>> Title : Information Model for IP Flow = Information Export (IPFIX) >>>>>>>>>>>>> Publication Date : September 2013 >>>>>>>>>>>>> Author(s) : B. Claise, Ed., B. Trammell, Ed. >>>>>>>>>>>>> Category : PROPOSED STANDARD >>>>>>>>>>>>> Source : IP Flow Information Export >>>>>>>>>>>>> Area : Operations and Management >>>>>>>>>>>>> Stream : IETF >>>>>>>>>>>>> Verifying Party : IESG >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> IPFIX mailing list >>>>>>>>>>>>>=20 >>>>>>>>>>>>> IPFIX@ietf.org >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/ipfix >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> IPFIX mailing list >>>>>>>>>>>>=20 >>>>>>>>>>>> IPFIX@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/ipfix >>>>>>>>>> _______________________________________________ >>>>>>>>>> IPFIX mailing list >>>>>>>>>>=20 >>>>>>>>>> IPFIX@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/ipfix >>>>>>>=20 >>>>>>>=20 >>>>>>> --=20 >>>>>>> For corporate legal information go to: >>>>>>>=20 >>>>>>>=20 >>>>>>> = http://www.cisco.com/web/about/doing_business/legal/cri/index.html >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>=20 >>>>>=20 >>>>> --=20 >>>>> For corporate legal information go to: >>>>>=20 >>>>>=20 >>>>> http://www.cisco.com/web/about/doing_business/legal/cri/index.html >>>>>=20 >>>>>=20 >>>>>=20 >>>>=20 >>>=20 >>>=20 >>> --=20 >>> For corporate legal information go to: >>>=20 >>>=20 >>> http://www.cisco.com/web/about/doing_business/legal/cri/index.html >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> IPFIX mailing list >>>=20 >>> IPFIX@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipfix >>=20 >=20 > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix --Apple-Mail=_87809E5E-C9E1-4F8B-8A04-383809B80D13 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 iQEcBAEBCgAGBQJS8fM/AAoJENt3nsOmbNJcrQEH/08/oWOCx/sVC4vWUtXAzcZQ VpQGLW0808hibmCkJTzubX98kUQDe2gGIkCwdwgZ3oCZcUGvkqTG/eF+0v9hAIE2 cJuaM9o0pnEpQvEzu3oRQgbB9aUhVUAYlpNXKd8VUc9ICyFwiYDgFfWIoAMHBF/y ab0SwmFK1NJgyEPh0GHuwjHugr9KKgK9iQ2WhHPH5JzPEOesLRZAd2al2NWUugAK 7CUj5LWCugDYZfWYMs+WJ82dJY1UuFNnNM5CJP8R1XeRr6omQ6RWERsOGh+kwPtm osUa4JbdQrSjiuYV6+6RN9VlptqmlkNwOJaDUteYraCSzEcYNo5k2Tqw8ykmCD4= =lYze -----END PGP SIGNATURE----- --Apple-Mail=_87809E5E-C9E1-4F8B-8A04-383809B80D13-- From n.brownlee@auckland.ac.nz Sun Feb 9 15:14:41 2014 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0AFD1A047A for ; Sun, 9 Feb 2014 15:14:41 -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 1oFMuZ5b_3h8 for ; Sun, 9 Feb 2014 15:14:38 -0800 (PST) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) by ietfa.amsl.com (Postfix) with ESMTP id F06351A03CA for ; Sun, 9 Feb 2014 15:14:35 -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=1391987679; x=1423523679; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=bmDu6Jx8USF3PSP2ZoqPXjo37TZJxLNFWuel+LHFWC0=; b=NibSY6ahFPK4XOxnXoVl2CwbOb1JxhbpwVc0MvHkhVWTGAANYaX+hMOj TTTiSVzQse1C7xM3vluOE8zXo6LNW3wgL3BhxmwIA8LRHZDmg1vIrlRej c4d1gdduXC1+E066EsBRHVbhoyir1HQnL8FqnDiG+dR1FAktgA7hzwTni c=; X-IronPort-AV: E=Sophos;i="4.95,814,1384254000"; d="scan'208";a="233516750" 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; 10 Feb 2014 12:14:19 +1300 Message-ID: <52F80BCA.2030408@auckland.ac.nz> Date: Mon, 10 Feb 2014 12:14:18 +1300 From: Nevil Brownlee 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: Paul Aitken , Andrew Feren , IPFIX Working Group References: <52EF4E92.3040906@auckland.ac.nz> <52EF71FA.3090005@cisco.com> In-Reply-To: <52EF71FA.3090005@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ipfix-ads@tools.ietf.org" , "ipfix-chairs@tools.ietf.org" Subject: Re: [IPFIX] IPFIX at IETF 89, London X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Feb 2014 23:14:42 -0000 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. 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, and there's been no discussion of them on the IPFIX list. 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 > > > 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 > > > 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. > > > On 03/02/2014 08:08, Nevil Brownlee wrote: >> >> Hi IPFIXers: >> >> Back when session scheduling for IETF 89 started, I requested a >> slot for IPFIX, "just in case." >> >> Since then the Link-Layer Attributes and Mediation Protocol drafts >> have been sent to the RFC Editor, and the text-adt draft is in WGLC. >> >> We expect a new revision of the MIB Variable export draft shortly, >> so that would be the only agenda item for London. I feel that >> version can be reviewed and discussed on the IPFIX list, so we >> don't now need to have a formal IPFIX meeting in London. >> >> If you believe that a meeting is needed, please email the list >> telling us what that is, and why we need meeting time for it. >> If I don't see such email(s) within the next week, we'll cancel >> the meeting. >> >> 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 paitken@cisco.com Mon Feb 10 02:33:01 2014 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B68A31A05DE for ; Mon, 10 Feb 2014 02:33:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.049 X-Spam-Level: X-Spam-Status: No, score=-10.049 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, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7fGufDBwBaB7 for ; Mon, 10 Feb 2014 02:32:59 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id 3101F1A00AE for ; Mon, 10 Feb 2014 02:32:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3682; q=dns/txt; s=iport; t=1392028379; x=1393237979; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=51tCDQfE15BKxCpioCBu1FcV3F4P1pdAAYXa6xwmyJY=; b=JrDkDWsvRwJnvP/neWuQnBjD3pZtIM4RxK2LnapawD+spsCPXAzu/CJe NOwfY9JEwOCbHTJlMzb0i8r3WqmcZT91/cWprV8skmfPtc75AACXf9mFm lmcBlFI8cTBzMOIvaPtZiEAnVrgvU7we3YuPpO8bH5f1fsn0mJd2jKGTh E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAL+p+FKQ/khM/2dsb2JhbABZDoJ+OMAigQ8WdIIlAQEBAwE4NgoBBQsLDgoJFg8JAwIBAgFFBgEMAQcBAYd5CA3IbBeOGw4DAVAHhDgBA5grgTKFFotZgm4/gWgEBRc X-IronPort-AV: E=Sophos;i="4.95,817,1384300800"; d="scan'208";a="4177829" Received: from ams-core-3.cisco.com ([144.254.72.76]) by aer-iport-2.cisco.com with ESMTP; 10 Feb 2014 10:32:57 +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 s1AAWuNE003371 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Feb 2014 10:32:57 GMT Received: from [10.61.101.54] (dhcp-10-61-101-54.cisco.com [10.61.101.54]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id s1AAWpHd015822; Mon, 10 Feb 2014 10:32:52 GMT Message-ID: <52F8AAB5.5050604@cisco.com> Date: Mon, 10 Feb 2014 10:32:21 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Nevil Brownlee , Andrew Feren , IPFIX Working Group References: <52EF4E92.3040906@auckland.ac.nz> <52EF71FA.3090005@cisco.com> <52F80BCA.2030408@auckland.ac.nz> In-Reply-To: <52F80BCA.2030408@auckland.ac.nz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ipfix-ads@tools.ietf.org" , "ipfix-chairs@tools.ietf.org" Subject: Re: [IPFIX] IPFIX at IETF 89, London X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 10:33:01 -0000 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 >> >> >> 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 >> >> >> 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. >> >> >> On 03/02/2014 08:08, Nevil Brownlee wrote: >>> >>> Hi IPFIXers: >>> >>> Back when session scheduling for IETF 89 started, I requested a >>> slot for IPFIX, "just in case." >>> >>> Since then the Link-Layer Attributes and Mediation Protocol drafts >>> have been sent to the RFC Editor, and the text-adt draft is in WGLC. >>> >>> We expect a new revision of the MIB Variable export draft shortly, >>> so that would be the only agenda item for London. I feel that >>> version can be reviewed and discussed on the IPFIX list, so we >>> don't now need to have a formal IPFIX meeting in London. >>> >>> If you believe that a meeting is needed, please email the list >>> telling us what that is, and why we need meeting time for it. >>> If I don't see such email(s) within the next week, we'll cancel >>> the meeting. >>> >>> Cheers, Nevil >>> >> >> > > From trammell@tik.ee.ethz.ch Mon Feb 10 07:31:15 2014 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21B031A0327 for ; Mon, 10 Feb 2014 07:31:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548] 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 5-l_qexKFDNK for ; Mon, 10 Feb 2014 07:31:12 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 823FD1A030B for ; Mon, 10 Feb 2014 07:31:12 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 06134D930B; Mon, 10 Feb 2014 16:31:12 +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 uNKVIbpgAvof; Mon, 10 Feb 2014 16:31:11 +0100 (MET) Received: from pb-10243.ethz.ch (pb-10243.ethz.ch [82.130.102.152]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 07266D9308; Mon, 10 Feb 2014 16:31:10 +0100 (MET) Content-Type: multipart/signed; boundary="Apple-Mail=_E6CE078F-1A43-43C4-84B5-9BAA9C754A60"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Brian Trammell In-Reply-To: <52F8AAB5.5050604@cisco.com> Date: Mon, 10 Feb 2014 16:31:09 +0100 Message-Id: <0705D07E-6FB1-4BB7-8AD7-8A38656CDB93@tik.ee.ethz.ch> References: <52EF4E92.3040906@auckland.ac.nz> <52EF71FA.3090005@cisco.com> <52F80BCA.2030408@auckland.ac.nz> <52F8AAB5.5050604@cisco.com> To: Paul Aitken X-Mailer: Apple Mail (2.1827) Cc: "ipfix-ads@tools.ietf.org" , Nevil Brownlee , IPFIX Working Group , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 15:31:15 -0000 --Apple-Mail=_E6CE078F-1A43-43C4-84B5-9BAA9C754A60 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 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? =46rom 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=92t think that=92s an = option for these two. OPSAWG would be an option, but only if we = definitively close IPFIX (otherwise the question is =93why not recharter = IPFIX=94). 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=92m co-chairing; we=92ve already tried to = de-conflict this with no luck. Cheers, Brian On 10 Feb 2014, at 11:32, Paul Aitken wrote: > Nevil, >=20 >> Hi Paul, Andrew and IPFIXers: >>=20 >> 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. >=20 > We're working on the next version. >=20 >=20 >> 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, >=20 > Oh come on Nevil! One's dated Dec 27th, the other Dec 31st. How fresh = do they need to be? >=20 > 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? >=20 >=20 >> and there's been no discussion of them on the IPFIX list. >=20 > 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. >=20 >=20 > P. >=20 >=20 >> The same goes for the Cisco IEs draft, current version -09, 15 Jan = 2014. >>=20 >> Therefore, IPFIX will not hold a formal meeting in London, I'll >> inform the secretariat that we're cancelling the IPFIX meeting. >>=20 >> Going forward from this ... >>=20 >> - of course we can have an informal get-together of IPFIX people >> in London - any volunteers to organise such a gathering? >>=20 >> - the IPFIX mailing list will remain open for quite some time, >> please use it to discuss anything relevant to IPFIX >>=20 >> Cheers, Nevil >>=20 >>=20 >> On 3/02/14 11:39 PM, Paul Aitken wrote: >>> Nevil, >>>=20 >>> 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: >>>=20 >>>=20 >>> aitken-ipfix-equivalent-ies >>> >>>=20 >>> 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. >>>=20 >>> aitken-ipfix-unobserved-fields >>> >>>=20 >>> 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. >>>=20 >>>=20 >>> P. >>>=20 >>>=20 >>> On 03/02/2014 08:08, Nevil Brownlee wrote: >>>>=20 >>>> Hi IPFIXers: >>>>=20 >>>> Back when session scheduling for IETF 89 started, I requested a >>>> slot for IPFIX, "just in case." >>>>=20 >>>> Since then the Link-Layer Attributes and Mediation Protocol drafts >>>> have been sent to the RFC Editor, and the text-adt draft is in = WGLC. >>>>=20 >>>> We expect a new revision of the MIB Variable export draft shortly, >>>> so that would be the only agenda item for London. I feel that >>>> version can be reviewed and discussed on the IPFIX list, so we >>>> don't now need to have a formal IPFIX meeting in London. >>>>=20 >>>> If you believe that a meeting is needed, please email the list >>>> telling us what that is, and why we need meeting time for it. >>>> If I don't see such email(s) within the next week, we'll cancel >>>> the meeting. >>>>=20 >>>> Cheers, Nevil >>>>=20 >>>=20 >>>=20 >>=20 >>=20 >=20 > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix --Apple-Mail=_E6CE078F-1A43-43C4-84B5-9BAA9C754A60 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 iQEcBAEBCgAGBQJS+PC+AAoJENt3nsOmbNJcCUQH/R5EZsWR7KJcJ2ItehnA7L1z JwB8b9g6PFuTRRMao39CwDHtsW6nv+We2f67mE02KCzbF1Cmbgklom2jAIqCRB2A OiyHQ3f/0iTOuNzGWKW6v6mym5CeoWkZbIHGMrVOsKsnOYalmuaLeD+pp4mMuka8 eSIwjEmCLaxR1WL0XnANQqXURrOCAF2IY5N/Q3lpjPK0Pr7teNGi/rOr166VBU4l Cdiwk2RMLMLPmxv8QBfWeN4lywfY5rL2GV7kOGiiuEcmwkAY709E/2biXE4m+vLh fls6Ctjh4wv2pBDMAajSKbez7uqxHuSDkGZ/ds0IxMuyly5oS17V6dBRrzALHpM= =PoZv -----END PGP SIGNATURE----- --Apple-Mail=_E6CE078F-1A43-43C4-84B5-9BAA9C754A60-- From joelja@bogus.com Mon Feb 10 07:47:46 2014 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF5011A0334 for ; Mon, 10 Feb 2014 07:47:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] 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 i31CREUTtP4M for ; Mon, 10 Feb 2014 07:47:43 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 7AFE41A032F for ; Mon, 10 Feb 2014 07:47:43 -0800 (PST) Received: from [192.168.43.134] (mdf0536d0.tmodns.net [208.54.5.223]) (authenticated bits=0) by nagasaki.bogus.com (8.14.7/8.14.7) with ESMTP id s1AFlYAA067695 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 10 Feb 2014 15:47:35 GMT (envelope-from joelja@bogus.com) Message-ID: <52F8F490.3040500@bogus.com> Date: Mon, 10 Feb 2014 07:47:28 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:27.0) Gecko/20100101 Thunderbird/27.0 MIME-Version: 1.0 To: Brian Trammell , Paul Aitken 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> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="KKXVlOgGcXT1QwQOdo8xlcWlDs4CE1X3E" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (nagasaki.bogus.com [147.28.0.81]); Mon, 10 Feb 2014 15:47:36 +0000 (UTC) Cc: "ipfix-ads@tools.ietf.org" , Nevil Brownlee , IPFIX Working Group , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 15:47:46 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --KKXVlOgGcXT1QwQOdo8xlcWlDs4CE1X3E Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 2/10/14, 7: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=92t think that=92s an= > option for these two.=20 Was not appreciated by some members of the IESG. under the circumstances and for the document in question I think the method applied was entirely apprpiate and that the results will speak for themselves. > OPSAWG would be an option, but only if we > definitively close IPFIX (otherwise the question is =93why not > recharter IPFIX=94). >=20 > 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=92m co-chairing; we=92ve already tried to > de-conflict this with no luck. >=20 > Cheers, >=20 > Brian >=20 > On 10 Feb 2014, at 11:32, Paul Aitken wrote: >=20 >> Nevil, >>=20 >>> Hi Paul, Andrew and IPFIXers: >>>=20 >>> Looking back at the IPFIX minutes for IETF-88 (Vancouver), we=20 >>> said that "the WG will close when the current charter items are=20 >>> complete." The only remaining charter item is the MIB Variable=20 >>> Export draft, current version is -03, 21 Oct 2013. It's=20 >>> 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. >>=20 >> We're working on the next version. >>=20 >>=20 >>> 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, >>=20 >> Oh come on Nevil! One's dated Dec 27th, the other Dec 31st. How >> fresh do they need to be? >>=20 >> 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? >>=20 >>=20 >>> and there's been no discussion of them on the IPFIX list. >>=20 >> 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. >>=20 >>=20 >> P. >>=20 >>=20 >>> The same goes for the Cisco IEs draft, current version -09, 15 >>> Jan 2014. >>>=20 >>> Therefore, IPFIX will not hold a formal meeting in London, I'll=20 >>> inform the secretariat that we're cancelling the IPFIX meeting. >>>=20 >>> Going forward from this ... >>>=20 >>> - of course we can have an informal get-together of IPFIX people=20 >>> in London - any volunteers to organise such a gathering? >>>=20 >>> - the IPFIX mailing list will remain open for quite some time,=20 >>> please use it to discuss anything relevant to IPFIX >>>=20 >>> Cheers, Nevil >>>=20 >>>=20 >>> On 3/02/14 11:39 PM, Paul Aitken wrote: >>>> Nevil, >>>>=20 >>>> 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: >>>>=20 >>>>=20 >>>> aitken-ipfix-equivalent-ies=20 >>>> >>>>=20 >>>> This document specifies a method for an Exporter to inform a=20 >>>> 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. >>>>=20 >>>> aitken-ipfix-unobserved-fields=20 >>>> >>>> >>>> >>>>=20 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. >>>>=20 >>>>=20 >>>> P. >>>>=20 >>>>=20 >>>> On 03/02/2014 08:08, Nevil Brownlee wrote: >>>>>=20 >>>>> Hi IPFIXers: >>>>>=20 >>>>> Back when session scheduling for IETF 89 started, I requested >>>>> a slot for IPFIX, "just in case." >>>>>=20 >>>>> Since then the Link-Layer Attributes and Mediation Protocol >>>>> drafts have been sent to the RFC Editor, and the text-adt >>>>> draft is in WGLC. >>>>>=20 >>>>> We expect a new revision of the MIB Variable export draft >>>>> shortly, so that would be the only agenda item for London. I >>>>> feel that version can be reviewed and discussed on the IPFIX >>>>> list, so we don't now need to have a formal IPFIX meeting in >>>>> London. >>>>>=20 >>>>> If you believe that a meeting is needed, please email the >>>>> list telling us what that is, and why we need meeting time >>>>> for it. If I don't see such email(s) within the next week, >>>>> we'll cancel the meeting. >>>>>=20 >>>>> Cheers, Nevil >>>>>=20 >>>>=20 >>>>=20 >>>=20 >>>=20 >>=20 >> _______________________________________________ IPFIX mailing list=20 >> IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix >=20 --KKXVlOgGcXT1QwQOdo8xlcWlDs4CE1X3E 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.22 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlL49JAACgkQ8AA1q7Z/VrLvaACffuBncCaePhsk7BHs+uN3b7It AocAoIvGS1UniEEEKj72GA2Mm2I8+P5K =8pML -----END PGP SIGNATURE----- --KKXVlOgGcXT1QwQOdo8xlcWlDs4CE1X3E-- From trammell@tik.ee.ethz.ch Mon Feb 10 08:41:39 2014 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A12531A06DC for ; Mon, 10 Feb 2014 08:41:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548] 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 l78_t_QjV7HE for ; Mon, 10 Feb 2014 08:41:36 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 568D71A017E for ; Mon, 10 Feb 2014 08:41:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id B1240D9308; Mon, 10 Feb 2014 17:41:35 +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 xjGlCEefp0Y2; Mon, 10 Feb 2014 17:41:35 +0100 (MET) Received: from pb-10243.ethz.ch (pb-10243.ethz.ch [82.130.102.152]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id AEF79D9310; Mon, 10 Feb 2014 17:41:34 +0100 (MET) Content-Type: multipart/signed; boundary="Apple-Mail=_F22E6468-DFF3-4538-8AEC-ABB1A3ABC94C"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Brian Trammell In-Reply-To: <52F8F490.3040500@bogus.com> Date: Mon, 10 Feb 2014 17:41:33 +0100 Message-Id: <191DD64B-4932-48DB-BE5C-AD240A43BD24@tik.ee.ethz.ch> 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> <52F8F490.3040500@bogus.com> To: joel jaeggli X-Mailer: Apple Mail (2.1827) Cc: IPFIX Working Group , "ipfix-ads@tools.ietf.org" , "ipfix-chairs@tools.ietf.org" , Nevil Brownlee 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 16:41:39 -0000 --Apple-Mail=_F22E6468-DFF3-4538-8AEC-ABB1A3ABC94C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 hi Joel, all, On 10 Feb 2014, at 16:47, joel jaeggli wrote: > On 2/10/14, 7: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? >=20 >> =46rom 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=92t think that=92s = an >> option for these two.=20 >=20 > Was not appreciated by some members of the IESG. under the = circumstances > and for the document in question I think the method applied was = entirely > apprpiate and that the results will speak for themselves. Would like to make clear I=92m not complaining in any way about the = outcome. :) But it is less clear to me that shuttering the WG and = AD-sponsoring the equivalent-ies and unobserved-fields work is an = acceptable way to move forward than it was in Vancouver. Cheers, Brian --Apple-Mail=_F22E6468-DFF3-4538-8AEC-ABB1A3ABC94C 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 iQEcBAEBCgAGBQJS+QE9AAoJENt3nsOmbNJcIBMH/ibhUEuwbIx2G9UQQqOsZt2a XGGhDL1t8CpVd81UCqO50cqI+jwWr8Migx6rj7FZk1PXhROqIpxhXwJOZEgIAX9X HPhpYwd/WSmXaTKw/RirQ/PNngQxZx+VTs1Ox8qyVi8aTd0TzHC2vDr11BTzoIb5 t4tAXwSd/6dXVsGptye6abelnyEQqim6ncz6ZuW8EBVFvPboReB/L9wyky1O7wc1 PbpfNmNq+k3VMoN0DKNOw94P8x39Xi9q5P80KPzHvrqKIHnynwigIDmhQdj10SKY tAdqsb+U+iTdnI87q39lwdv6uV7CJV3B4Co9kSDiPZEKRAgJ4hYrz5nw46jSkyI= =mTTJ -----END PGP SIGNATURE----- --Apple-Mail=_F22E6468-DFF3-4538-8AEC-ABB1A3ABC94C-- From n.brownlee@auckland.ac.nz Mon Feb 10 13:01:25 2014 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B7DC1A0509 for ; 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 ; 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 ; 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 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 , Paul Aitken 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 Working Group , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 >>>> >>>> >>>> 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 >>>> >>>> >>>> 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 From bclaise@cisco.com Mon Feb 10 13:22:27 2014 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E03A1A05D7 for ; Mon, 10 Feb 2014 13:22:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.049 X-Spam-Level: X-Spam-Status: No, score=-15.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YG5MVLFISArO for ; Mon, 10 Feb 2014 13:22:25 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 2384D1A0407 for ; Mon, 10 Feb 2014 13:22:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4242; q=dns/txt; s=iport; t=1392067345; x=1393276945; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=vDj7HW0OeNDkLCPaIZuxpQuNP6mzTRUVXmVPr/sik/M=; b=UfTFWmDqF0wk4ul7rzNfy2gRpy2yQTxV40G87PURYGCx2QQSrc4Cs5K/ 2CEtOAryVeKZlmWhzprdbcH9V5zsCPO9+ezlxfjd7mO+UVDMDffSo+PpS XA8JNPDiwqddljpAOFAbOkeKhN+OVlGLrve0xv94oZSjdicd98O3A5sAQ 8=; X-IronPort-AV: E=Sophos;i="4.95,820,1384300800"; d="scan'208";a="105352852" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 10 Feb 2014 21:22:24 +0000 Received: from [10.154.204.28] ([10.154.204.28]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s1ALMKJT012179; Mon, 10 Feb 2014 21:22:23 GMT Message-ID: <52F9430C.3040909@cisco.com> Date: Mon, 10 Feb 2014 13:22:20 -0800 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Paul Aitken , Nevil Brownlee , Andrew Feren , IPFIX Working Group References: <52EF4E92.3040906@auckland.ac.nz> <52EF71FA.3090005@cisco.com> <52F80BCA.2030408@auckland.ac.nz> <52F8AAB5.5050604@cisco.com> In-Reply-To: <52F8AAB5.5050604@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ipfix-ads@tools.ietf.org" , "ipfix-chairs@tools.ietf.org" Subject: Re: [IPFIX] IPFIX at IETF 89, London X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 21:22:27 -0000 On 10/02/2014 02:32, Paul Aitken 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. Consensus, sure? I checked the meeting minutes and I don't see that. What I recall is that two different proposals were discussed (draft-aitken-ipfix-equivalent-ies and draft-inacio-ipfix-penie-00), with no clear winner. Regards, Benoit > 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 >>> >>> >>> 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 >>> >>> >>> 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. >>> >>> >>> On 03/02/2014 08:08, Nevil Brownlee wrote: >>>> >>>> Hi IPFIXers: >>>> >>>> Back when session scheduling for IETF 89 started, I requested a >>>> slot for IPFIX, "just in case." >>>> >>>> Since then the Link-Layer Attributes and Mediation Protocol drafts >>>> have been sent to the RFC Editor, and the text-adt draft is in WGLC. >>>> >>>> We expect a new revision of the MIB Variable export draft shortly, >>>> so that would be the only agenda item for London. I feel that >>>> version can be reviewed and discussed on the IPFIX list, so we >>>> don't now need to have a formal IPFIX meeting in London. >>>> >>>> If you believe that a meeting is needed, please email the list >>>> telling us what that is, and why we need meeting time for it. >>>> If I don't see such email(s) within the next week, we'll cancel >>>> the meeting. >>>> >>>> Cheers, Nevil >>>> >>> >>> >> >> > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix > . > From paitken@cisco.com Mon Feb 10 14:49:51 2014 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCF231A08A8 for ; Mon, 10 Feb 2014 14:49:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.049 X-Spam-Level: X-Spam-Status: No, score=-10.049 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, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5GMipP5Y96Wb for ; Mon, 10 Feb 2014 14:49:46 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id 38B4F1A0488 for ; Mon, 10 Feb 2014 14:49:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=800; q=dns/txt; s=iport; t=1392072586; x=1393282186; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=YWjvMlPHBly2phxDp/T/TNwbOnlddpbhyxM+jbGDU3M=; b=D3i1uCdwJu9YnTsR1x72joSRw09IN3I2JHTrg/+BJa7Utgdu/EOzY0ew bvrAPVwomTcabJ3h2xvzqjij9bsZ6TquzUWf5JTnqNinmOgpImVDAJ+BQ vfVZ68EI5fRlfCSmKywc5nHOwsttkT9IBAiNyd1hZ/tLm4b/TB1Fb2//D I=; X-IronPort-AV: E=Sophos;i="4.95,820,1384300800"; d="scan'208";a="4859731" Received: from ams-core-3.cisco.com ([144.254.72.76]) by aer-iport-1.cisco.com with ESMTP; 10 Feb 2014 22:49:45 +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 s1AMniaU029320 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Feb 2014 22:49:45 GMT Received: from [10.61.101.158] (dhcp-10-61-101-158.cisco.com [10.61.101.158]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id s1AMndIZ024967; Mon, 10 Feb 2014 22:49:39 GMT Message-ID: <52F95765.50902@cisco.com> Date: Mon, 10 Feb 2014 22:49:09 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Benoit Claise , Nevil Brownlee , Andrew Feren , IPFIX Working Group References: <52EF4E92.3040906@auckland.ac.nz> <52EF71FA.3090005@cisco.com> <52F80BCA.2030408@auckland.ac.nz> <52F8AAB5.5050604@cisco.com> <52F9430C.3040909@cisco.com> In-Reply-To: <52F9430C.3040909@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ipfix-ads@tools.ietf.org" , "ipfix-chairs@tools.ietf.org" Subject: Re: [IPFIX] IPFIX at IETF 89, London X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 22:49:52 -0000 Benoit, >> I've presented these ideas in previous WG meetings, where the >> consensus was to wait for the next re-charter. > Consensus, sure? Yes: the work was interesting, but not relevant to the current charter. So, bring it up at the next recharter - which hasn't happened yet. > I checked the meeting minutes and I don't see that. > What I recall is that two different proposals were discussed > (draft-aitken-ipfix-equivalent-ies and draft-inacio-ipfix-penie-00), > with no clear winner. Sure; each of these drafts has different merits. It would be up to the WG to decide on the best solution. Look, here's a real problem in IPFIX which has resulted in not one but *two* different drafts trying to solve it in different ways. Do you propose to ignore it? P. From bclaise@cisco.com Mon Feb 10 16:50:31 2014 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E19711A061B for ; Mon, 10 Feb 2014 16:50:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.549 X-Spam-Level: X-Spam-Status: No, score=-14.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_ABOUTYOU=0.5, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qExK-Pkmb2Qb for ; Mon, 10 Feb 2014 16:50:29 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 29FA61A0714 for ; Mon, 10 Feb 2014 16:50:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1294; q=dns/txt; s=iport; t=1392079829; x=1393289429; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=JcM+8/CKOjz5DZIRZITpuve5MY1+IE6BFj/HBzFLmIs=; b=KaCIQJd5wGqP7d/VmSbGJXNfCXweg3HQ0yUxD6f3UbKbGd6QG8GQRVlo 2wovdSFnYc00hAcTtuMCkqvh8xoiF2x7u0b+g6QywJfMg6SW5jFYk6m1A hh+TZgImzQpXgdEA6ws7xHzqdjh7fHudKXKzeXVz4bI8gX5iPiQf65fFT 4=; X-IronPort-AV: E=Sophos;i="4.95,821,1384300800"; d="scan'208";a="105421062" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 11 Feb 2014 00:50:29 +0000 Received: from [10.154.208.79] ([10.154.208.79]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s1B0oLD1028891; Tue, 11 Feb 2014 00:50:22 GMT Message-ID: <52F973CD.80607@cisco.com> Date: Mon, 10 Feb 2014 16:50:21 -0800 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Paul Aitken , Nevil Brownlee , Andrew Feren , IPFIX Working Group References: <52EF4E92.3040906@auckland.ac.nz> <52EF71FA.3090005@cisco.com> <52F80BCA.2030408@auckland.ac.nz> <52F8AAB5.5050604@cisco.com> <52F9430C.3040909@cisco.com> <52F95765.50902@cisco.com> In-Reply-To: <52F95765.50902@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ipfix-ads@tools.ietf.org" , "ipfix-chairs@tools.ietf.org" Subject: Re: [IPFIX] IPFIX at IETF 89, London X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 00:50:31 -0000 Paul, At this point, I will be listening to the chairs to see ... if this is really "interesting", if there is enough support from the IPFIX community, if there is enough discussion on it, and if this work could be done in the decent time. (*) I guess that I'm so much involved in IPFIX that I have strong opinions about your drafts. That's the price you pay for an AD who knows IPFIX by heart. Regards, Benoit > Benoit, > >>> I've presented these ideas in previous WG meetings, where the >>> consensus was to wait for the next re-charter. >> Consensus, sure? > > Yes: the work was interesting, but not relevant to the current > charter. So, bring it up at the next recharter - which hasn't happened > yet. > > >> I checked the meeting minutes and I don't see that. >> What I recall is that two different proposals were discussed >> (draft-aitken-ipfix-equivalent-ies and draft-inacio-ipfix-penie-00), >> with no clear winner. > > Sure; each of these drafts has different merits. It would be up to the > WG to decide on the best solution. > > Look, here's a real problem in IPFIX which has resulted in not one but > *two* different drafts trying to solve it in different ways. Do you > propose to ignore it? > > P. > . > From Quittek@neclab.eu Tue Feb 11 01:02:22 2014 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62B751A0919 for ; Tue, 11 Feb 2014 01:02:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.15 X-Spam-Level: X-Spam-Status: No, score=-3.15 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548, 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 Nm0_jO-Q1wMy for ; Tue, 11 Feb 2014 01:02:18 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 918E11A0914 for ; Tue, 11 Feb 2014 01:02:18 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id C7BC8106C2D; Tue, 11 Feb 2014 10:02:17 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cdtinn2z-6Vh; Tue, 11 Feb 2014 10:02:17 +0100 (CET) X-ENC: Last-Hop-TLS-encrypted X-ENC: Last-Hop-TLS-encrypted Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailer1.neclab.eu (Postfix) with ESMTPS id AAA11106C25; Tue, 11 Feb 2014 10:01:42 +0100 (CET) Received: from HYDRA.office.hd ([169.254.4.189]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Tue, 11 Feb 2014 10:01:42 +0100 From: Juergen Quittek To: joel jaeggli , Brian Trammell , Paul Aitken Thread-Topic: [IPFIX] IPFIX at IETF 89, London Thread-Index: AQHPJneAZA4W28tlf0eM8CyINORWQpqvwSsg Date: Tue, 11 Feb 2014 09:01:42 +0000 Message-ID: <9AB93E4127C26F4BA7829DEFDCE5A6E877A36C4F@Hydra.office.hd> 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> <52F8F490.3040500@bogus.com> In-Reply-To: <52F8F490.3040500@bogus.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.2.165] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipfix-ads@tools.ietf.org" , Nevil Brownlee , IPFIX Working Group , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 09:02:22 -0000 Hi all, > -----Original Message----- > From: IPFIX [mailto:ipfix-bounces@ietf.org] On Behalf Of joel jaeggli > Sent: Montag, 10. Februar 2014 16:47 > To: Brian Trammell; Paul Aitken > Cc: ipfix-ads@tools.ietf.org; Nevil Brownlee; IPFIX Working Group; ipfix- > chairs@tools.ietf.org > Subject: Re: [IPFIX] IPFIX at IETF 89, London >=20 > On 2/10/14, 7: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? >=20 > > 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. >=20 > Was not appreciated by some members of the IESG. under the > circumstances and for the document in question I think the method applied > was entirely apprpiate and that the results will speak for themselves. As far as I understood this issue, it was not appreciated by all IESG membe= rs, because there still was an IPFIX WG in place. If IPFIX is closed, I do = not see how they could still have any problem. Juergen > > 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 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 > >>>> > >>>> > >>>> 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 > >>>> > >>>> > >>>> > >>>> > 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. > >>>> > >>>> > >>>> On 03/02/2014 08:08, Nevil Brownlee wrote: > >>>>> > >>>>> Hi IPFIXers: > >>>>> > >>>>> Back when session scheduling for IETF 89 started, I requested a > >>>>> slot for IPFIX, "just in case." > >>>>> > >>>>> Since then the Link-Layer Attributes and Mediation Protocol drafts > >>>>> have been sent to the RFC Editor, and the text-adt draft is in > >>>>> WGLC. > >>>>> > >>>>> We expect a new revision of the MIB Variable export draft shortly, > >>>>> so that would be the only agenda item for London. I feel that > >>>>> version can be reviewed and discussed on the IPFIX list, so we > >>>>> don't now need to have a formal IPFIX meeting in London. > >>>>> > >>>>> If you believe that a meeting is needed, please email the list > >>>>> telling us what that is, and why we need meeting time for it. If I > >>>>> don't see such email(s) within the next week, we'll cancel the > >>>>> meeting. > >>>>> > >>>>> Cheers, Nevil > >>>>> > >>>> > >>>> > >>> > >>> > >> > >> _______________________________________________ IPFIX > mailing list > >> IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix > > >=20 From internet-drafts@ietf.org Tue Feb 11 06:52:00 2014 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 575221A03EF; Tue, 11 Feb 2014 06:52:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DpwQlErjW3KO; Tue, 11 Feb 2014 06:51:58 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5854B1A0398; Tue, 11 Feb 2014 06:51:58 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140211145158.23396.64193.idtracker@ietfa.amsl.com> Date: Tue, 11 Feb 2014 06:51:58 -0800 Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action: draft-ietf-ipfix-text-adt-01.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 14:52:00 -0000 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 : Textual Representation of IPFIX Abstract Data Types Author : Brian Trammell Filename : draft-ietf-ipfix-text-adt-01.txt Pages : 13 Date : 2014-02-11 Abstract: This document defines UTF-8 representations for IPFIX abstract data types, to support interoperable usage of the IPFIX Information Elements with protocols based on textual encodings. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipfix-text-adt/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ipfix-text-adt-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-ipfix-text-adt-01 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 trammell@tik.ee.ethz.ch Tue Feb 11 06:55:01 2014 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BB041A0412 for ; Tue, 11 Feb 2014 06:55:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.747 X-Spam-Level: X-Spam-Status: No, score=-4.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548] 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 sbtJAoOu8PJY for ; Tue, 11 Feb 2014 06:54:57 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 826C11A0386 for ; Tue, 11 Feb 2014 06:54:57 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id C6437D930D for ; Tue, 11 Feb 2014 15:54:56 +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 yJZUKsCP6Glc for ; Tue, 11 Feb 2014 15:54:56 +0100 (MET) Received: from pb-10243.ethz.ch (pb-10243.ethz.ch [82.130.102.152]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 74DABD9304 for ; Tue, 11 Feb 2014 15:54:56 +0100 (MET) From: Brian Trammell Content-Type: multipart/signed; boundary="Apple-Mail=_AD95413E-7605-444E-B3E4-CA16E9147EA8"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Tue, 11 Feb 2014 15:54:55 +0100 References: <20140211145158.23396.13744.idtracker@ietfa.amsl.com> To: IPFIX Working Group Message-Id: Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) X-Mailer: Apple Mail (2.1827) Subject: [IPFIX] Fwd: New Version Notification for draft-ietf-ipfix-text-adt-01.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 14:55:01 -0000 --Apple-Mail=_AD95413E-7605-444E-B3E4-CA16E9147EA8 Content-Type: multipart/alternative; boundary="Apple-Mail=_E8E5567B-C16B-468A-AB16-5082836C3E94" --Apple-Mail=_E8E5567B-C16B-468A-AB16-5082836C3E94 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Greetings, all, This revision addresses WGLC comments to date; left open is the = representation of boolean-true and boolean-false, which I=92ve kept at = the literal integer values =931=94 and =930=94 respectively, because = it=92s not clear to me there=92s a better resolution that=92s consistent = with the rest of the document. WGLC continues up to the 14 Feb deadline. Best regards, Brian Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for draft-ietf-ipfix-text-adt-01.txt > Date: 11 Feb 2014 15:51:58 GMT+1 > To: "Brian Trammell" , Brian Trammell = >=20 >=20 > A new version of I-D, draft-ietf-ipfix-text-adt-01.txt > has been successfully submitted by Brian Trammell and posted to the > IETF repository. >=20 > Name: draft-ietf-ipfix-text-adt > Revision: 01 > Title: Textual Representation of IPFIX Abstract Data = Types > Document date: 2014-02-11 > Group: ipfix > Pages: 13 > URL: = http://www.ietf.org/internet-drafts/draft-ietf-ipfix-text-adt-01.txt > Status: = https://datatracker.ietf.org/doc/draft-ietf-ipfix-text-adt/ > Htmlized: = http://tools.ietf.org/html/draft-ietf-ipfix-text-adt-01 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipfix-text-adt-01 >=20 > Abstract: > This document defines UTF-8 representations for IPFIX abstract data > types, to support interoperable usage of the IPFIX Information > Elements with protocols based on textual encodings. >=20 >=20 >=20 >=20 > 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. >=20 > The IETF Secretariat --Apple-Mail=_E8E5567B-C16B-468A-AB16-5082836C3E94 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Greetings, all,

This revision = addresses WGLC comments to date; left open is the representation of = boolean-true and boolean-false, which I=92ve kept at the literal integer = values =931=94 and =930=94 respectively, because it=92s not clear to me = there=92s a better resolution that=92s consistent with the rest of the = document.

WGLC continues up to the 14 Feb = deadline.

Best = regards,

Brian

Begin forwarded = message:

From: = internet-drafts@ietf.org
<= /span>
Subject: = New Version = Notification for = draft-ietf-ipfix-text-adt-01.txt
Date: 11 Feb 2014 15:51:58 = GMT+1
To: = "Brian Trammell" = <trammell@tik.ee.ethz.ch>, = Brian Trammell <trammell@tik.ee.ethz.ch>


A new version of I-D, = draft-ietf-ipfix-text-adt-01.txt
has been successfully submitted by = Brian Trammell and posted to the
IETF repository.

Name: = draft-ietf-ipfix-text-adt
Revision: = 01
Title: Textual Representation of IPFIX = Abstract Data Types
Document date: 2014-02-11
Group: = ipfix
Pages: 13
URL: =            http://www.ietf.org/internet-drafts/draft-ietf-ipfix-text-adt-01.txt
Status:         https= ://datatracker.ietf.org/doc/draft-ietf-ipfix-text-adt/
Htmlized: =       http://to= ols.ietf.org/html/draft-ietf-ipfix-text-adt-01
Diff: =           h= ttp://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipfix-text-adt-01

= Abstract:
  This document defines UTF-8 representations = for IPFIX abstract data
  types, to support interoperable = usage of the IPFIX Information
  Elements with protocols = based on textual encodings.




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.

The IETF = Secretariat

= --Apple-Mail=_E8E5567B-C16B-468A-AB16-5082836C3E94-- --Apple-Mail=_AD95413E-7605-444E-B3E4-CA16E9147EA8 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 iQEcBAEBCgAGBQJS+jm/AAoJENt3nsOmbNJc2JsH/0kq/zb4TG/zl6qeIvp4bkCC b2uAprV0+cqeCwvsVwHqfphoXFq0Jzx8t+g1vjSSRDDKXxxDg9Q1z52v86lAXf1x c8a6wtEWi/5ZZ7wahqeZhXE2z6r+AUFE6OwW7uj0c/qCgEi1s0cEtzPahWL9CFNO was6dyQzDtIJvK3irtZkDUHq7y+oIbp9qtvDXUIcIKRqg4KZ9jNwqIXc/9mESbQH HT1efDng9DAroMXMP35ACPJON+8Y+EfAZs2DmdfsEvYCB/Be+x5gy3EnXwgT+f9q 1yTNWUEwEyySsf+s7mKVFH1Fn+pEZv6zRVuVcOas+WvupxupYJZ70prn/+Ankt8= =BrPH -----END PGP SIGNATURE----- --Apple-Mail=_AD95413E-7605-444E-B3E4-CA16E9147EA8-- From paitken@cisco.com Tue Feb 11 12:32:18 2014 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 477ED1A072F for ; Tue, 11 Feb 2014 12:32:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.503 X-Spam-Level: X-Spam-Status: No, score=-5.503 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_55=0.6, J_CHICKENPOX_57=0.6, RDNS_NONE=0.793, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P_P7QhHZBEni for ; Tue, 11 Feb 2014 12:32:15 -0800 (PST) Received: from aer-iport-4.cisco.com (unknown [173.38.203.54]) by ietfa.amsl.com (Postfix) with ESMTP id 587621A0709 for ; Tue, 11 Feb 2014 12:32:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10000; q=dns/txt; s=iport; t=1392150734; x=1393360334; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=hrwkEs+6HP0LJTDNT0vyQO9zp4kKyRiCBTE6L5mZa0w=; b=SjtaMFFmGZMjNP9jmtBxueLAMUvLFDt30iJ2DV2pNflKY2AeHLeqN7oV h0qxnaBtIKRIOUj3KlZU4FhKKGOesbxgi0HGqCoG5/di0mCf1pkoD35DM mIwO0BTp6k/IZ867xidOlL1McSLAwWesLjRT2bOz252l1NFF9fWwxw9c3 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmwFABKI+lKQ/khR/2dsb2JhbABagww4UYhktiiBFRZ0giUBAQEEAQEBawkBEQsRAwECAQkWBAQHCQMCAQIBFR8JCAYBDAYCAQEFh3wIBchOF45oFwEGhDIEmCqBMoUVi1mBb4E+ X-IronPort-AV: E=Sophos;i="4.95,827,1384300800"; d="scan'208,217";a="131895" Received: from ams-core-1.cisco.com ([144.254.72.81]) by aer-iport-4.cisco.com with ESMTP; 11 Feb 2014 20:32:12 +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 s1BKWCMW029861 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Feb 2014 20:32:12 GMT Received: from [10.61.97.208] (dhcp-10-61-97-208.cisco.com [10.61.97.208]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id s1BKWBVV021543; Tue, 11 Feb 2014 20:32:11 GMT Message-ID: <52FA88CB.4000009@cisco.com> Date: Tue, 11 Feb 2014 20:32:11 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Brian Trammell , IPFIX Working Group References: <20140211145158.23396.13744.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------060002000702010206020306" Subject: Re: [IPFIX] [Sender: "IPFIX" ] Fwd: New Version Notification for draft-ietf-ipfix-text-adt-01.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 20:32:18 -0000 This is a multi-part message in MIME format. --------------060002000702010206020306 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Brian, some suggestions: 1. true = 1, false = { anything else } - works with both the usual 0/1 convention and the IPFIX 1/2 convention 2. true = "true", false = "false" - quite unambiguous 3. true = "t", false = "f" - shorter P. On 11/02/2014 14:54, Brian Trammell wrote: > Greetings, all, > > This revision addresses WGLC comments to date; left open is the > representation of boolean-true and boolean-false, which I've kept at > the literal integer values "1" and "0" respectively, because it's not > clear to me there's a better resolution that's consistent with the > rest of the document. > > WGLC continues up to the 14 Feb deadline. > > Best regards, > > Brian > > Begin forwarded message: > >> *From: *internet-drafts@ietf.org >> *Subject: **New Version Notification for >> draft-ietf-ipfix-text-adt-01.txt* >> *Date: *11 Feb 2014 15:51:58 GMT+1 >> *To: *"Brian Trammell" > >, Brian Trammell >> > >> >> >> A new version of I-D, draft-ietf-ipfix-text-adt-01.txt >> has been successfully submitted by Brian Trammell and posted to the >> IETF repository. >> >> Name:draft-ietf-ipfix-text-adt >> Revision:01 >> Title:Textual Representation of IPFIX Abstract Data Types >> Document date:2014-02-11 >> Group:ipfix >> Pages:13 >> URL: http://www.ietf.org/internet-drafts/draft-ietf-ipfix-text-adt-01.txt >> Status: https://datatracker.ietf.org/doc/draft-ietf-ipfix-text-adt/ >> Htmlized: http://tools.ietf.org/html/draft-ietf-ipfix-text-adt-01 >> Diff: http://www.ietf.org/rfcdiff?url2=draft-ietf-ipfix-text-adt-01 >> >> Abstract: >> This document defines UTF-8 representations for IPFIX abstract data >> types, to support interoperable usage of the IPFIX Information >> Elements with protocols based on textual encodings. >> >> >> >> >> 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 >> . >> >> The IETF Secretariat > > > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix --------------060002000702010206020306 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Brian, some suggestions:


1. true = 1, false = { anything else }

    - works with both the usual 0/1 convention and the IPFIX 1/2 convention


2. true = "true", false = "false"

    - quite unambiguous


3. true = "t", false = "f"

    - shorter


P.


On 11/02/2014 14:54, Brian Trammell wrote:
Greetings, all,

This revision addresses WGLC comments to date; left open is the representation of boolean-true and boolean-false, which I’ve kept at the literal integer values “1” and “0” respectively, because it’s not clear to me there’s a better resolution that’s consistent with the rest of the document.

WGLC continues up to the 14 Feb deadline.

Best regards,

Brian

Begin forwarded message:

Subject: New Version Notification for draft-ietf-ipfix-text-adt-01.txt
Date: 11 Feb 2014 15:51:58 GMT+1
To: "Brian Trammell" <trammell@tik.ee.ethz.ch>, Brian Trammell <trammell@tik.ee.ethz.ch>


A new version of I-D, draft-ietf-ipfix-text-adt-01.txt
has been successfully submitted by Brian Trammell and posted to the
IETF repository.

Name: draft-ietf-ipfix-text-adt
Revision: 01
Title: Textual Representation of IPFIX Abstract Data Types
Document date: 2014-02-11
Group: ipfix
Pages: 13
URL:            http://www.ietf.org/internet-drafts/draft-ietf-ipfix-text-adt-01.txt
Status:         https://datatracker.ietf.org/doc/draft-ietf-ipfix-text-adt/
Htmlized:       http://tools.ietf.org/html/draft-ietf-ipfix-text-adt-01
Diff:           http://www.ietf.org/rfcdiff?url2=draft-ietf-ipfix-text-adt-01

Abstract:
  This document defines UTF-8 representations for IPFIX abstract data
  types, to support interoperable usage of the IPFIX Information
  Elements with protocols based on textual encodings.




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.

The IETF Secretariat



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

--------------060002000702010206020306-- From trammell@tik.ee.ethz.ch Tue Feb 11 13:11:39 2014 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B398E1A06DD for ; Tue, 11 Feb 2014 13:11:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.748 X-Spam-Level: X-Spam-Status: No, score=-6.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548] 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 blbMiV7iL2xA for ; Tue, 11 Feb 2014 13:11:36 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 4D3F41A0755 for ; Tue, 11 Feb 2014 13:11:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 68337D9303; Tue, 11 Feb 2014 22:11:35 +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 rKt2CGwf9ary; Tue, 11 Feb 2014 22:11:35 +0100 (MET) 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 CFF60D9302; Tue, 11 Feb 2014 22:11:34 +0100 (MET) Content-Type: multipart/signed; boundary="Apple-Mail=_485E39D3-A70F-4292-BD3F-51CF2F9AFE30"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Brian Trammell In-Reply-To: <52FA88CB.4000009@cisco.com> Date: Tue, 11 Feb 2014 22:11:33 +0100 Message-Id: References: <20140211145158.23396.13744.idtracker@ietfa.amsl.com> <52FA88CB.4000009@cisco.com> To: Paul Aitken X-Mailer: Apple Mail (2.1827) Cc: IPFIX Working Group Subject: Re: [IPFIX] [Sender: "IPFIX" ] Fwd: New Version Notification for draft-ietf-ipfix-text-adt-01.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 21:11:39 -0000 --Apple-Mail=_485E39D3-A70F-4292-BD3F-51CF2F9AFE30 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 11 Feb 2014, at 21:32, Paul Aitken wrote: > Brian, some suggestions: >=20 >=20 > 1. true =3D 1, false =3D { anything else } >=20 > - works with both the usual 0/1 convention and the IPFIX 1/2 = convention Much as I hate to propogate the idea the "2 is false" is anything other = than a terrible, terrible idea, I like the approach. The issue I have = with it is that the string "true" is false, which seems error-prone; the = bigger issue I have with it is that every other type has a set of = acceptable values and a set of unacceptable values. We don't for example = say that any unparseable string for an unsigned8 is 0. I'd be slightly more okay with this being encoded as an unsigned8, where = 0 is false and any nonzero value is true, but this means we have two = different encodings one of which has "2 is false" and the other has "2 = is true", and I don't like that either. We could say true =3D 1 and false =3D 0 | 2 but then we need to explain = that we're carrying forward something from 7011 encoding, which we do = for no other type. So to be unambiguous, I'm starting to lean in the direction of: > 2. true =3D "true", false =3D "false" >=20 > - quite unambiguous >=20 >=20 > 3. true =3D "t", false =3D "f" >=20 > - shorter Aside from the fact that these aren't case-insensitive (which at least = causes an error as opposed to a non-detected incorrect acceptance), I'd = say we could combine these: true =3D ('t' | 'T') 0*ALPHA false =3D ('f' | 'F') 0*ALPHA i.e., the decoder only looks at the first letter for [tT] or [fF], = probably with a note that "true" and "false" are the preferred = encodings. Thanks, cheers, Brian > P. >=20 >=20 > On 11/02/2014 14:54, Brian Trammell wrote: >> Greetings, all, >>=20 >> This revision addresses WGLC comments to date; left open is the = representation of boolean-true and boolean-false, which I=92ve kept at = the literal integer values =931=94 and =930=94 respectively, because = it=92s not clear to me there=92s a better resolution that=92s consistent = with the rest of the document. >>=20 >> WGLC continues up to the 14 Feb deadline. >>=20 >> Best regards, >>=20 >> Brian >>=20 >> Begin forwarded message: >>=20 >>> From: internet-drafts@ietf.org >>> Subject: New Version Notification for = draft-ietf-ipfix-text-adt-01.txt >>> Date: 11 Feb 2014 15:51:58 GMT+1 >>> To: "Brian Trammell" , Brian Trammell = >>>=20 >>>=20 >>> A new version of I-D, draft-ietf-ipfix-text-adt-01.txt >>> has been successfully submitted by Brian Trammell and posted to the >>> IETF repository. >>>=20 >>> Name: >>>=20 >>> =20 >>> draft-ietf-ipfix-text-adt >>> Revision: 01 >>> Title: >>>=20 >>> =20 >>> Textual Representation of IPFIX Abstract Data Types >>> Document date: 2014-02-11 >>> Group: >>>=20 >>> =20 >>> ipfix >>> Pages: >>>=20 >>> =20 >>> 13 >>> URL: = http://www.ietf.org/internet-drafts/draft-ietf-ipfix-text-adt-01.txt >>> Status: = https://datatracker.ietf.org/doc/draft-ietf-ipfix-text-adt/ >>> Htmlized: = http://tools.ietf.org/html/draft-ietf-ipfix-text-adt-01 >>> Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipfix-text-adt-01 >>>=20 >>> Abstract: >>> This document defines UTF-8 representations for IPFIX abstract = data >>> types, to support interoperable usage of the IPFIX Information >>> Elements with protocols based on textual encodings. >>>=20 >>>=20 >>>=20 >>>=20 >>> 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. >>>=20 >>> The IETF Secretariat >>=20 >>=20 >>=20 >> _______________________________________________ >> IPFIX mailing list >>=20 >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix >=20 --Apple-Mail=_485E39D3-A70F-4292-BD3F-51CF2F9AFE30 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 iQEcBAEBCgAGBQJS+pIFAAoJENt3nsOmbNJcoVYH/0A/T66gj5zfAftAmdfRqXWS P5sobWch/j3PQsgx8p4qXgphVu/EBS11q2fJRvSGmtspRCpbZLfrblHZ/GR27xNQ DqVNI2BMdgjpEFt8fJc2ygY1rrVm+OsdfZJbXggZzirtEQrFhOT/jUlnJq9bvRFm Z9kIAWZzbjXjHv0g0iKcjgxTqThMiJmldfM6OXAdhv09b9DgC4W2QWr5BbV49+bi Hp4torq3FCF6aQYZq7ObnxxtDUKKtxi8OzuGjMBD5NrVbgWxKyoeELR15guPUY+n FuJoW7kjoOS8ixId5/I44j98nS2xIEMH5/t+ixz1z5z5fmbjeG83vQSuLineyWU= =PUep -----END PGP SIGNATURE----- --Apple-Mail=_485E39D3-A70F-4292-BD3F-51CF2F9AFE30-- From paitken@cisco.com Tue Feb 11 13:32:30 2014 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 904861A075B for ; Tue, 11 Feb 2014 13:32:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.049 X-Spam-Level: X-Spam-Status: No, score=-12.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_LETTER=-2, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O2VlZubyv5wO for ; Tue, 11 Feb 2014 13:32:28 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id 852FB1A0775 for ; Tue, 11 Feb 2014 13:32:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=477; q=dns/txt; s=iport; t=1392154346; x=1393363946; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=wWXgYutcsyVWRg2mSX0cMXQ9CaPpbuuTOKMkfpeCU2s=; b=PWXLlRpDDkHEtuW4YNP/t++wXze0NHPxoFLGr4oYbGMTrGfEToI7ti6V MwDzmAVnbYKvGko98TXyfe385kIaZlQk/v79as10zPFM+o9tKMGGwREjE NO+xZYfoirhFNz3Dy4/4HmV+FmwAW51VAz5XUlbkDgflf5pYjnev7pse3 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhsFACaW+lKQ/khL/2dsb2JhbABagwzAGoEXFnSCJQEBAQMBOD8BAQULCyEWDwkDAgECAUUGDQEHAQGHeQjIZReOeQeEOAEDmCqGR4tZgy0 X-IronPort-AV: E=Sophos;i="4.95,827,1384300800"; d="scan'208";a="4888801" Received: from ams-core-2.cisco.com ([144.254.72.75]) by aer-iport-1.cisco.com with ESMTP; 11 Feb 2014 21:32:25 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s1BLWOKq028793 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Feb 2014 21:32:25 GMT Received: from [10.61.97.208] (dhcp-10-61-97-208.cisco.com [10.61.97.208]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id s1BLWNmj023649; Tue, 11 Feb 2014 21:32:24 GMT Message-ID: <52FA96E4.8010004@cisco.com> Date: Tue, 11 Feb 2014 21:32:20 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Brian Trammell References: <20140211145158.23396.13744.idtracker@ietfa.amsl.com> <52FA88CB.4000009@cisco.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: IPFIX Working Group Subject: Re: [IPFIX] Fwd: New Version Notification for draft-ietf-ipfix-text-adt-01.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 21:32:30 -0000 Brian, Aside from the fact that this is English-specific, it works for me. P. > Aside from the fact that these aren't case-insensitive (which at least causes an error as opposed to a non-detected incorrect acceptance), I'd say we could combine these: > > true = ('t' | 'T') 0*ALPHA > > false = ('f' | 'F') 0*ALPHA > > i.e., the decoder only looks at the first letter for [tT] or [fF], probably with a note that "true" and "false" are the preferred encodings. From andrewf@plixer.com Tue Feb 11 13:44:02 2014 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C91171A0776 for ; Tue, 11 Feb 2014 13:44:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.948 X-Spam-Level: X-Spam-Status: No, score=-1.948 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_ABOUTYOU=0.5, RP_MATCHES_RCVD=-0.548] 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 50PAdVTZLgfh for ; Tue, 11 Feb 2014 13:43:59 -0800 (PST) Received: from mx1.plixer.com (mx1.plixer.com [64.140.243.154]) by ietfa.amsl.com (Postfix) with ESMTP id 84E951A0771 for ; Tue, 11 Feb 2014 13:43:59 -0800 (PST) Received: from PLXRDC01.plxr.local ([::1]) by PLXRDC01.plxr.local ([::1]) with mapi id 14.03.0158.001; Tue, 11 Feb 2014 16:43:58 -0500 From: Andrew Feren To: Benoit Claise , Paul Aitken , Nevil Brownlee , IPFIX Working Group Thread-Topic: [IPFIX] IPFIX at IETF 89, London Thread-Index: AQHPILc0AfhsOV5eaE+OBCYr2tRDipqjqu8AgApAxACAAL1ygIAAtZoAgAAYQoCAACHdgIAA93xg Date: Tue, 11 Feb 2014 21:43:57 +0000 Message-ID: <8E7542283B89BB4DB672EB49CEE5AAB7054010B8@PLXRDC01.plxr.local> References: <52EF4E92.3040906@auckland.ac.nz> <52EF71FA.3090005@cisco.com> <52F80BCA.2030408@auckland.ac.nz> <52F8AAB5.5050604@cisco.com> <52F9430C.3040909@cisco.com> <52F95765.50902@cisco.com>,<52F973CD.80607@cisco.com> In-Reply-To: <52F973CD.80607@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [24.91.78.244] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipfix-ads@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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 21:44:03 -0000 Hi Benoit,=0A= =0A= I think both topics are interesting, but if I had to pick one to put some w= ork into it would be the unobserved fields draft. There is a need to commu= nicate this information (or lack of information ;-). I am already starting= to see exports where different vendors are choosing different ad hoc metho= ds to communicate N/A for the same IEs.=0A= =0A= As for draft-aitken-ipfix-equivalent-ies and draft-inacio-ipfix-penie, I'm = mostly interested in anything that encourages exporters to "publish" info a= bout the IEs they export. Given the lack of uptake for 5610 I'm not optimi= stic that an alternate/updated version of 5610 will get any more traction. = Most of the time I'd be happy to get a text file with 7013 style Informati= on Element Specifiers.=0A= =0A= Just my 2 cents,=0A= -Andrew=0A= ________________________________________=0A= From: Benoit Claise [bclaise@cisco.com]=0A= Sent: Monday, February 10, 2014 7:50 PM=0A= To: Paul Aitken; Nevil Brownlee; Andrew Feren; IPFIX Working Group=0A= Cc: ipfix-ads@tools.ietf.org; ipfix-chairs@tools.ietf.org=0A= Subject: Re: [IPFIX] IPFIX at IETF 89, London=0A= =0A= Paul,=0A= =0A= At this point, I will be listening to the chairs to see ...=0A= if this is really "interesting",=0A= if there is enough support from the IPFIX community,=0A= if there is enough discussion on it,=0A= and if this work could be done in the decent time.=0A= =0A= (*) I guess that I'm so much involved in IPFIX that I have strong=0A= opinions about your drafts. That's the price you pay for an AD who knows=0A= IPFIX by heart.=0A= =0A= Regards, Benoit=0A= > Benoit,=0A= >=0A= >>> I've presented these ideas in previous WG meetings, where the=0A= >>> consensus was to wait for the next re-charter.=0A= >> Consensus, sure?=0A= >=0A= > Yes: the work was interesting, but not relevant to the current=0A= > charter. So, bring it up at the next recharter - which hasn't happened=0A= > yet.=0A= >=0A= >=0A= >> I checked the meeting minutes and I don't see that.=0A= >> What I recall is that two different proposals were discussed=0A= >> (draft-aitken-ipfix-equivalent-ies and draft-inacio-ipfix-penie-00),=0A= >> with no clear winner.=0A= >=0A= > Sure; each of these drafts has different merits. It would be up to the=0A= > WG to decide on the best solution.=0A= >=0A= > Look, here's a real problem in IPFIX which has resulted in not one but=0A= > *two* different drafts trying to solve it in different ways. Do you=0A= > propose to ignore it?=0A= >=0A= > P.=0A= > .=0A= >=0A= =0A= From Quittek@neclab.eu Wed Feb 12 06:52:13 2014 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2C5B1A099A for ; Wed, 12 Feb 2014 06:52:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.15 X-Spam-Level: X-Spam-Status: No, score=-3.15 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548, 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 hnhjLbE9S57L for ; Wed, 12 Feb 2014 06:52:11 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 10E3A1A09B1 for ; Wed, 12 Feb 2014 06:52:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 02DD7106C6E; Wed, 12 Feb 2014 15:52:03 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zIaWYqzgFD6h; Wed, 12 Feb 2014 15:52:02 +0100 (CET) X-ENC: Last-Hop-TLS-encrypted X-ENC: Last-Hop-TLS-encrypted Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailer1.neclab.eu (Postfix) with ESMTPS id DA0B8106C6A; Wed, 12 Feb 2014 15:51:27 +0100 (CET) Received: from PALLENE.office.hd ([169.254.1.233]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Wed, 12 Feb 2014 15:51:06 +0100 From: Juergen Quittek To: Benoit Claise , Paul Aitken , Nevil Brownlee , Andrew Feren , IPFIX Working Group Thread-Topic: [IPFIX] IPFIX at IETF 89, London Thread-Index: AQHPJqYuRGHNYWHAu0y7FJaSANXb05qvBo6AgAAh3YCAAolscA== Date: Wed, 12 Feb 2014 14:51:05 +0000 Message-ID: <9AB93E4127C26F4BA7829DEFDCE5A6E877A49AB4@PALLENE.office.hd> References: <52EF4E92.3040906@auckland.ac.nz> <52EF71FA.3090005@cisco.com> <52F80BCA.2030408@auckland.ac.nz> <52F8AAB5.5050604@cisco.com> <52F9430C.3040909@cisco.com> <52F95765.50902@cisco.com> <52F973CD.80607@cisco.com> In-Reply-To: <52F973CD.80607@cisco.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.2.165] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipfix-ads@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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 14:52:13 -0000 Dear all, As technical contributor, I send my view on the two drafts from Paul: The equivalent-ies draft is targeted at several use cases and with some of = them I see need for discussion. I would have no problem with a standard tha= t restricted to be only applied if an exporter changes the IE identifier wi= thout any other technical change, for example, after registering an enterpr= ise-specific IE at IANA with a new number. But if this feature is used for = other use cases as listed in the draft, I see a lot of issues that should b= e investigated. Two example issues are (1) exporters declaring "similar" IE= s to be equivalent and (2) conflicting equivalence declarations from differ= ent exporters. There are more issues like these. Most of them can reduced t= o the core problem that the draft only defines a message format and not und= er which condition two IEs may or must not be declared equivalent. For the unobserved-fields draft I see similar issues. The semantics is not = fully clear and the same holds for implications on collectors. Does unobser= ved mean: I did not observe the IE, because there was no instance in any ob= served packet, because observation failed, because there is no instrumentat= ion to observe the IE, or for any other reason. These are all different use= case and there are more of them, maybe with more subtle differences, that = need discussion. My conclusion is, that I see both drafts addressing valid issues, but not a= s drafts to be finished soon. The both drafts look like good candidate an "= experimental" RFCs, because "equivalence" of measurements and "unobserved" = flow properties are concepts that may need time and operational experience = to define them well. Cheers, Juergen > -----Original Message----- > From: Benoit Claise [mailto:bclaise@cisco.com] > Sent: Dienstag, 11. Februar 2014 01:50 > To: Paul Aitken; Nevil Brownlee; Andrew Feren; IPFIX Working Group > Cc: ipfix-ads@tools.ietf.org; ipfix-chairs@tools.ietf.org > Subject: Re: [IPFIX] IPFIX at IETF 89, London >=20 > Paul, >=20 > At this point, I will be listening to the chairs to see ... > if this is really "interesting", > if there is enough support from the IPFIX community, > if there is enough discussion on it, > and if this work could be done in the decent time. >=20 > (*) I guess that I'm so much involved in IPFIX that I have strong opinion= s > about your drafts. That's the price you pay for an AD who knows IPFIX by > heart. >=20 > Regards, Benoit > > Benoit, > > > >>> I've presented these ideas in previous WG meetings, where the > >>> consensus was to wait for the next re-charter. > >> Consensus, sure? > > > > Yes: the work was interesting, but not relevant to the current > > charter. So, bring it up at the next recharter - which hasn't happened > > yet. > > > > > >> I checked the meeting minutes and I don't see that. > >> What I recall is that two different proposals were discussed > >> (draft-aitken-ipfix-equivalent-ies and draft-inacio-ipfix-penie-00), > >> with no clear winner. > > > > Sure; each of these drafts has different merits. It would be up to the > > WG to decide on the best solution. > > > > Look, here's a real problem in IPFIX which has resulted in not one but > > *two* different drafts trying to solve it in different ways. Do you > > propose to ignore it? > > > > P. > > . > > From wwwrun@rfc-editor.org Wed Feb 12 20:49:24 2014 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 054BD1A00EC; Wed, 12 Feb 2014 20:49:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, 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 bQ7l184yAZVd; Wed, 12 Feb 2014 20:49:22 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2607:f170:8000:1500::d3]) by ietfa.amsl.com (Postfix) with ESMTP id DD6671A00F2; Wed, 12 Feb 2014 20:49:21 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id D13BF7FC177; Wed, 12 Feb 2014 20:48:57 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20140213044857.D13BF7FC177@rfc-editor.org> Date: Wed, 12 Feb 2014 20:48:57 -0800 (PST) Cc: drafts-update-ref@iana.org, ipfix@ietf.org, rfc-editor@rfc-editor.org Subject: [IPFIX] RFC 7119 on Operation of the IP Flow Information Export (IPFIX) Protocol on IPFIX Mediators X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 04:49:24 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7119 Title: Operation of the IP Flow Information Export (IPFIX) Protocol on IPFIX Mediators Author: B. Claise, A. Kobayashi, B. Trammell Status: Standards Track Stream: IETF Date: February 2014 Mailbox: bclaise@cisco.com, akoba@nttv6.net, trammell@tik.ee.ethz.ch Pages: 32 Characters: 74807 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ipfix-mediation-protocol-10.txt URL: http://www.rfc-editor.org/rfc/rfc7119.txt 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. This document is a product of the IP Flow Information Export Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/search For downloading RFCs, see http://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From bclaise@cisco.com Wed Feb 12 21:57:49 2014 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E28011A0106 for ; Wed, 12 Feb 2014 21:57:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f6C6_yQneKaP for ; Wed, 12 Feb 2014 21:57:47 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 1CC8A1A0102 for ; Wed, 12 Feb 2014 21:57:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7302; q=dns/txt; s=iport; t=1392271066; x=1393480666; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=ifbLON2xYykKNX8vsd1vhaleLInEaDlBUaysqn2RmXM=; b=i5hkMFzXR7yRTc36CVmzKTmfJx/iifuRKWOSBAveVGCkMiIHcm8QZ9BV 5JIg/LjrFdsJEQPyX53rc3IYKjNVf2C5llxLS8a4m4/+6/H63zMJ2corK 8V4EfStBax4TUhf3nMacWp536RMrsSvl/4WxA8PVtRJsCHWzVwd9i4wg6 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FAI9d/FKrRDoH/2dsb2JhbAA/GoMKOMARgRgWdIIlAQEBBAEBAUsqDQQcAwECCgMTBAsJAwIBAgEVChUHAggGDQYCAQEFCwcCBIdjDjbHeReCXItKQhgGgimCCQSJSI5jgTKFFYQXgXmFSoFvgV8bgTU X-IronPort-AV: E=Sophos;i="4.95,836,1384300800"; d="scan'208,217";a="102339674" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 13 Feb 2014 05:57:45 +0000 Received: from [10.21.93.209] (sjc-vpn5-1489.cisco.com [10.21.93.209]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s1D5vj7P023524 for ; Thu, 13 Feb 2014 05:57:45 GMT Message-ID: <52FC5ED9.5030306@cisco.com> Date: Wed, 12 Feb 2014 21:57:45 -0800 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "ipfix@ietf.org" References: <20140211215718.CBBC47FC3A7@rfc-editor.org> In-Reply-To: <20140211215718.CBBC47FC3A7@rfc-editor.org> X-Forwarded-Message-Id: <20140211215718.CBBC47FC3A7@rfc-editor.org> Content-Type: multipart/alternative; boundary="------------040509060703000600050601" Subject: [IPFIX] Fwd: RFC 7125 on Revision of the tcpControlBits IP Flow Information Export (IPFIX) Information Element X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 05:57:50 -0000 This is a multi-part message in MIME format. --------------040509060703000600050601 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Congratulations to the authors and the IPFIX community for this achievement. Regards, Benoit -------- Original Message -------- Subject: RFC 7125 on Revision of the tcpControlBits IP Flow Information Export (IPFIX) Information Element Date: Tue, 11 Feb 2014 13:57:13 -0800 From: Reply-To: To: , CC: , A new Request for Comments is now available in online RFC libraries. RFC 7125 Title: Revision of the tcpControlBits IP Flow Information Export (IPFIX) Information Element Author: B. Trammell, P. Aitken Status: Informational Stream: IETF Date: February 2014 Mailbox: trammell@tik.ee.ethz.ch, paitken@cisco.com Pages: 6 Characters: 11679 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-trammell-ipfix-tcpcontrolbits-revision-05.txt URL: http://www.rfc-editor.org/rfc/rfc7125.txt This document revises the tcpControlBits IP Flow Information Export (IPFIX) Information Element as originally defined in RFC 5102 to reflect changes to the TCP Flags header field since RFC 793. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/search/rfc_search.php For downloading RFCs, see http://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC . --------------040509060703000600050601 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Congratulations to the authors and the IPFIX community for this achievement.

Regards, Benoit


-------- Original Message --------
Subject: RFC 7125 on Revision of the tcpControlBits IP Flow Information Export (IPFIX) Information Element
Date: Tue, 11 Feb 2014 13:57:13 -0800
From: <rfc-editor@rfc-editor.org>
Reply-To: <ietf@ietf.org>
To: <ietf-announce@ietf.org>, <rfc-dist@rfc-editor.org>
CC: <drafts-update-ref@iana.org>, <rfc-editor@rfc-editor.org> 


A new Request for Comments is now available in online RFC libraries.

        
        RFC 7125

        Title:      Revision of the tcpControlBits IP 
                    Flow Information Export (IPFIX)
                    Information Element 
        Author:     B. Trammell, P. Aitken
        Status:     Informational
        Stream:     IETF
        Date:       February 2014
        Mailbox:    trammell@tik.ee.ethz.ch, 
                    paitken@cisco.com
        Pages:      6
        Characters: 11679
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-trammell-ipfix-tcpcontrolbits-revision-05.txt

        URL:        http://www.rfc-editor.org/rfc/rfc7125.txt

This document revises the tcpControlBits IP Flow Information Export
(IPFIX) Information Element as originally defined in RFC 5102 to
reflect changes to the TCP Flags header field since RFC 793.


INFORMATIONAL: This memo provides information for the Internet community.
It does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/search/rfc_search.php
For downloading RFCs, see http://www.rfc-editor.org/rfc.html

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC


.


--------------040509060703000600050601-- From bclaise@cisco.com Wed Feb 12 22:34:32 2014 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A39F1A0121 for ; Wed, 12 Feb 2014 22:34:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7BH0gIBCb1eR for ; Wed, 12 Feb 2014 22:34:30 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 1C3531A011B for ; Wed, 12 Feb 2014 22:34:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8118; q=dns/txt; s=iport; t=1392273266; x=1393482866; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=NZZYyjnaH2Xr8W8269BCJqNs8FQaZens3Yunb3Je6gk=; b=BM1JL18SXun595J/TiZOSCY1J+HL1VaTUtblymzoiCNb+NuFy3tYUa3L EtLKsqM44snU/jCD60cRG1rkFkOt+SYjg/y9LhmSt6O2y0HUd2MVW0JSn 86vPt6NJ7rJ6WWOm6zk0OwR8CazwEmhuUM6ykKxPEJqZg1bTE6zUB/kvR 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgwFAOtm/FKrRDoI/2dsb2JhbABZgwo4wBKBFhZ0giUBAQEEAQEBSyoNBBwDAQIKAxMPCQMCAQIBFQoVBwIIBg0GAgEBBQsHAgSHYw7IQReOJkIYBoQyBIlIjmOBMoUVhBeCA4VAgW+BXxuBNQ X-IronPort-AV: E=Sophos;i="4.95,837,1384300800"; d="scan'208,217";a="105621737" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 13 Feb 2014 06:34:25 +0000 Received: from [10.21.93.209] (sjc-vpn5-1489.cisco.com [10.21.93.209]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s1D6YJLa015171 for ; Thu, 13 Feb 2014 06:34:19 GMT Message-ID: <52FC676B.3090406@cisco.com> Date: Wed, 12 Feb 2014 22:34:19 -0800 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "ipfix@ietf.org" References: <20140213044857.D13BF7FC177@rfc-editor.org> In-Reply-To: <20140213044857.D13BF7FC177@rfc-editor.org> X-Forwarded-Message-Id: <20140213044857.D13BF7FC177@rfc-editor.org> Content-Type: multipart/alternative; boundary="------------070107070504070702080002" Subject: [IPFIX] Fwd: RFC 7119 on Operation of the IP Flow Information Export (IPFIX) Protocol on IPFIX Mediators X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 06:34:32 -0000 This is a multi-part message in MIME format. --------------070107070504070702080002 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Great job from the IPFIX community. Regards, Benoit -------- Original Message -------- Subject: RFC 7119 on Operation of the IP Flow Information Export (IPFIX) Protocol on IPFIX Mediators Date: Wed, 12 Feb 2014 20:48:57 -0800 From: Reply-To: To: , CC: , , A new Request for Comments is now available in online RFC libraries. RFC 7119 Title: Operation of the IP Flow Information Export (IPFIX) Protocol on IPFIX Mediators Author: B. Claise, A. Kobayashi, B. Trammell Status: Standards Track Stream: IETF Date: February 2014 Mailbox: bclaise@cisco.com, akoba@nttv6.net, trammell@tik.ee.ethz.ch Pages: 32 Characters: 74807 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ipfix-mediation-protocol-10.txt URL: http://www.rfc-editor.org/rfc/rfc7119.txt 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. This document is a product of the IP Flow Information Export Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/search For downloading RFCs, see http://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC . --------------070107070504070702080002 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Great job from the IPFIX community.

Regards, Benoit


-------- Original Message --------
Subject: RFC 7119 on Operation of the IP Flow Information Export (IPFIX) Protocol on IPFIX Mediators
Date: Wed, 12 Feb 2014 20:48:57 -0800
From: <rfc-editor@rfc-editor.org>
Reply-To: <ietf@ietf.org>
To: <ietf-announce@ietf.org>, <rfc-dist@rfc-editor.org>
CC: <drafts-update-ref@iana.org>, <ipfix@ietf.org>, <rfc-editor@rfc-editor.org> 


A new Request for Comments is now available in online RFC libraries.

        
        RFC 7119

        Title:      Operation of the IP Flow Information
                    Export (IPFIX) Protocol on IPFIX Mediators 
        Author:     B. Claise, A. Kobayashi,
                    B. Trammell
        Status:     Standards Track
        Stream:     IETF
        Date:       February 2014
        Mailbox:    bclaise@cisco.com, 
                    akoba@nttv6.net, 
                    trammell@tik.ee.ethz.ch
        Pages:      32
        Characters: 74807
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-ipfix-mediation-protocol-10.txt

        URL:        http://www.rfc-editor.org/rfc/rfc7119.txt

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.

This document is a product of the IP Flow Information Export Working Group of the IETF.

This is now a Proposed Standard.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Internet
Official Protocol Standards (STD 1) for the standardization state and
status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/search
For downloading RFCs, see http://www.rfc-editor.org/rfc.html

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC


.


--------------070107070504070702080002-- From nobody Fri Feb 14 10:44:32 2014 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18C2B1A0352 for ; Fri, 14 Feb 2014 10:44:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.448 X-Spam-Level: X-Spam-Status: No, score=-4.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RP_MATCHES_RCVD=-0.548] 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 ua-GcBrD2vA8 for ; Fri, 14 Feb 2014 10:44:24 -0800 (PST) Received: from mx1.plixer.com (mx1.plixer.com [64.140.243.154]) by ietfa.amsl.com (Postfix) with ESMTP id 89EEB1A025F for ; Fri, 14 Feb 2014 10:44:24 -0800 (PST) Received: from PLXRDC01.plxr.local ([::1]) by PLXRDC01.plxr.local ([::1]) with mapi id 14.03.0158.001; Fri, 14 Feb 2014 13:44:22 -0500 From: Andrew Feren To: Paul Aitken , Brian Trammell Thread-Topic: [IPFIX] Fwd: New Version Notification for draft-ietf-ipfix-text-adt-01.txt Thread-Index: AQHPJ3DH0Wx7/md74Uihy1aMXLTMepq1F9gA Date: Fri, 14 Feb 2014 18:44:21 +0000 Message-ID: <8E7542283B89BB4DB672EB49CEE5AAB705404BA4@PLXRDC01.plxr.local> References: <20140211145158.23396.13744.idtracker@ietfa.amsl.com> <52FA88CB.4000009@cisco.com> , <52FA96E4.8010004@cisco.com> In-Reply-To: <52FA96E4.8010004@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [24.91.78.244] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/1Eb03BZIfep1kSE8G8LfxaYPQ40 Cc: IPFIX Working Group Subject: Re: [IPFIX] Fwd: New Version Notification for draft-ietf-ipfix-text-adt-01.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 18:44:28 -0000 Hi Paul and Brian,=0A= =0A= This works for me too.=0A= =0A= FWIW I think worrying about this one tiny instance being English specific i= s way too little too late. When we start translating the IE names, IE desc= riptions, data type names, data semantic names, etc. then we can worry abou= t if boolean values need some internationalization.=0A= =0A= -Andrew=0A= ________________________________________=0A= From: IPFIX [ipfix-bounces@ietf.org] on behalf of Paul Aitken [paitken@cisc= o.com]=0A= Sent: Tuesday, February 11, 2014 4:32 PM=0A= To: Brian Trammell=0A= Cc: IPFIX Working Group=0A= Subject: Re: [IPFIX] Fwd: New Version Notification for draft-ietf-ipfix-te= xt-adt-01.txt=0A= =0A= Brian,=0A= =0A= Aside from the fact that this is English-specific, it works for me.=0A= =0A= P.=0A= =0A= =0A= > Aside from the fact that these aren't case-insensitive (which at least ca= uses an error as opposed to a non-detected incorrect acceptance), I'd say w= e could combine these:=0A= >=0A= > true =3D ('t' | 'T') 0*ALPHA=0A= >=0A= > false =3D ('f' | 'F') 0*ALPHA=0A= >=0A= > i.e., the decoder only looks at the first letter for [tT] or [fF], probab= ly with a note that "true" and "false" are the preferred encodings.=0A= =0A= =0A= _______________________________________________=0A= IPFIX mailing list=0A= IPFIX@ietf.org=0A= https://www.ietf.org/mailman/listinfo/ipfix=0A= From nobody Fri Feb 14 12:18:49 2014 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 961471A0309 for ; Fri, 14 Feb 2014 12:18:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.147 X-Spam-Level: X-Spam-Status: No, score=-2.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.548] 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 y_LAVtXjWkVd for ; Fri, 14 Feb 2014 12:18:46 -0800 (PST) Received: from mx1.plixer.com (mx1.plixer.com [64.140.243.154]) by ietfa.amsl.com (Postfix) with ESMTP id EEF2E1A0337 for ; Fri, 14 Feb 2014 12:18:45 -0800 (PST) Received: from PLXRDC01.plxr.local ([::1]) by PLXRDC01.plxr.local ([::1]) with mapi id 14.03.0158.001; Fri, 14 Feb 2014 15:18:43 -0500 From: Andrew Feren To: =?windows-1256?Q?IPFIX_Working_Group_=FD=5Bipfix=40ietf=2Eorg=5D=FD?= Thread-Topic: RFC 6759 clarification question Thread-Index: Ac8puQiY56b/KEajQS2cCOOB6xg5wA== Date: Fri, 14 Feb 2014 20:18:43 +0000 Message-ID: <8E7542283B89BB4DB672EB49CEE5AAB705404D9C@PLXRDC01.plxr.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [24.91.78.244] Content-Type: multipart/alternative; boundary="_000_8E7542283B89BB4DB672EB49CEE5AAB705404D9CPLXRDC01plxrloc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/MMKWO4DFPqn5hbckb56PEKDQG3E Subject: [IPFIX] RFC 6759 clarification question X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 20:18:48 -0000 --_000_8E7542283B89BB4DB672EB49CEE5AAB705404D9CPLXRDC01plxrloc_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable Hi IPFIX experts, The discussion about how to encode boolean in draft-trammell-ipfix-text-adt= got me thinking about some IEs from RFC 6759. p2pTechnology(288), tunnelTechnology(289), and encryptedTechnology(290) all specify possible values as '{ "yes", "y", 1 }, { "no", "n", 2 } and { "= unassigned", "u", 0 }'. It was not initially clear to me if the 0,1,and 2 = were integer values or character values. It was explained to me that that = they are intended to be the integer values. As I thought about this I wondered if "string" is really the right type for= this? True, all of the possible values can be represented as UTF-8, but t= his feels like an abuse of string type. At least until now I had assumed t= hat a string value was intended to be displayable, but this breaks that ass= umption. Is my understanding of what string means flawed? -Andrew --_000_8E7542283B89BB4DB672EB49CEE5AAB705404D9CPLXRDC01plxrloc_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
Hi IPFIX experts,

The discussion about how to encode boolean in draft-trammell-ipfix-text-adt= got me thinking about some IEs from RFC 6759.

p2pTechnology(288), tunnelTechnology(289), and encryptedTechnology(290)

all specify possible values as '{ "yes", "y", 1 }, { &q= uot;no", "n", 2 } and { "unassigned", "u"= ;, 0 }'.  It was not initially clear to me if the 0,1,and 2 were integ= er values or character values.  It was explained to me that that they = are intended to be the integer values.

As I thought about this I wondered if "string" is really the righ= t type for this?  True, all of the possible values can be represented = as UTF-8, but this feels like an abuse of string type.  At least until= now I had assumed that a string value was intended to be displayable, but this breaks that assumption.

Is my understanding of what string means flawed?

-Andrew
--_000_8E7542283B89BB4DB672EB49CEE5AAB705404D9CPLXRDC01plxrloc_-- From nobody Fri Feb 14 12:44:55 2014 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04FE51A0350 for ; Fri, 14 Feb 2014 12:44:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548] 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 fkM4Ev1G67ph for ; Fri, 14 Feb 2014 12:44:50 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 23E9B1A030A for ; Fri, 14 Feb 2014 12:44:50 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 1AB20D930E; Fri, 14 Feb 2014 21:44:48 +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 RxLdg3psPUoA; Fri, 14 Feb 2014 21:44:47 +0100 (MET) 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 83EABD9304; Fri, 14 Feb 2014 21:44:47 +0100 (MET) Content-Type: multipart/signed; boundary="Apple-Mail=_F7204154-0C3F-4795-B680-59085B030AB8"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Brian Trammell In-Reply-To: <8E7542283B89BB4DB672EB49CEE5AAB705404D9C@PLXRDC01.plxr.local> Date: Fri, 14 Feb 2014 21:44:46 +0100 Message-Id: References: <8E7542283B89BB4DB672EB49CEE5AAB705404D9C@PLXRDC01.plxr.local> To: Andrew Feren X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/Pnwgk4kXBVYL5UO92l697u9SO98 Cc: =?utf-8?Q?=22IPFIX_Working_Group_=E2=80=8E=5Bipfix=40ietf=2Eorg?= =?utf-8?Q?=5D=E2=80=8E=22?= Subject: Re: [IPFIX] RFC 6759 clarification question X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 20:44:53 -0000 --Apple-Mail=_F7204154-0C3F-4795-B680-59085B030AB8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1256 Hi, Andrew, I'd answer this question with RFC 7013 section 4.2 para 6 and section = 4.9 para 4. Cheers, Brian On 14 Feb 2014, at 21:18, Andrew Feren wrote: > Hi IPFIX experts, >=20 > The discussion about how to encode boolean in = draft-trammell-ipfix-text-adt got me thinking about some IEs from RFC = 6759. >=20 > p2pTechnology(288), tunnelTechnology(289), and = encryptedTechnology(290) >=20 > all specify possible values as '{ "yes", "y", 1 }, { "no", "n", 2 } = and { "unassigned", "u", 0 }'. It was not initially clear to me if the = 0,1,and 2 were integer values or character values. It was explained to = me that that they are intended to be the integer values. >=20 > As I thought about this I wondered if "string" is really the right = type for this? True, all of the possible values can be represented as = UTF-8, but this feels like an abuse of string type. At least until now = I had assumed that a string value was intended to be displayable, but = this breaks that assumption. >=20 > Is my understanding of what string means flawed? >=20 > -Andrew > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix --Apple-Mail=_F7204154-0C3F-4795-B680-59085B030AB8 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 iQEcBAEBCgAGBQJS/oA+AAoJENt3nsOmbNJct6AH/0WoOCk++bU8npT3QPbLSUpz HFJdh+x4ljlUB+dlaBGhTnfID35w8xUqoeBkDLbWKu50QttUpoifvgYtHEKDFpMu PZzGO+eK4R82SKADRmiKkW21Z9cSuVJOwayK1qjuh58y28ixO0C/NjKMOTSYmxmQ pmuL/LuiaI1/BlD/FihHGTqgIIl88KK4cOqW4ch3MAMtSM/G8wuuKvJnMAmVgjik Q34MwsFYivPHS7QXBciQ+TZAjxTA71jYkgQKm4F0iWaKx8ak0K7X/dmlP8Pe1q4U 6S7etd2/RLOKtLsBCjyCzg/JTt42m4dwTYjVrBaUV8P4F0NbQUfZFODKQl4yT8I= =boAt -----END PGP SIGNATURE----- --Apple-Mail=_F7204154-0C3F-4795-B680-59085B030AB8-- From nobody Fri Feb 14 13:49:07 2014 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C95321A0445 for ; Fri, 14 Feb 2014 13:49:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.549 X-Spam-Level: X-Spam-Status: No, score=-14.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_ABOUTYOU=0.5, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vo8tFbz5Fz7W for ; Fri, 14 Feb 2014 13:48:59 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 7C1671A0411 for ; Fri, 14 Feb 2014 13:48:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3103; q=dns/txt; s=iport; t=1392414529; x=1393624129; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=5aWlz6VOYP13TDbFdqi9UvsTHDgnXGwijN5C/NpKq6k=; b=FI/e1m0/IuvAGrAAUlWvuMJG6TYhK7f9m2ai/iFRg3SIzd/AATJ67U/c D37pEEaP4xCbiAxnd31lW9H2YzJFIXoZsruU0eP6yf1iMmi+oxLYITAX3 rKPYWDLKNmEfuEDnyJ8po41vzC60GzDlp2NsIXWYlBSgokpu0uYReH0mn Q=; X-IronPort-AV: E=Sophos;i="4.95,847,1384300800"; d="scan'208";a="304228984" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-8.cisco.com with ESMTP; 14 Feb 2014 21:48:49 +0000 Received: from [10.82.245.17] (rtp-vpn2-1296.cisco.com [10.82.245.17]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s1ELmlau018538; Fri, 14 Feb 2014 21:48:47 GMT Message-ID: <52FE7355.2000809@cisco.com> Date: Fri, 14 Feb 2014 14:49:41 -0500 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Andrew Feren , Paul Aitken , Nevil Brownlee , IPFIX Working Group References: <52EF4E92.3040906@auckland.ac.nz> <52EF71FA.3090005@cisco.com> <52F80BCA.2030408@auckland.ac.nz> <52F8AAB5.5050604@cisco.com> <52F9430C.3040909@cisco.com> <52F95765.50902@cisco.com>, <52F973CD.80607@cisco.com> <8E7542283B89BB4DB672EB49CEE5AAB7054010B8@PLXRDC01.plxr.local> In-Reply-To: <8E7542283B89BB4DB672EB49CEE5AAB7054010B8@PLXRDC01.plxr.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/cpjhYyrFyKjILnsgRrvyzoKEdlI Cc: "ipfix-ads@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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 21:49:02 -0000 Hi Andrew, > Hi Benoit, > > I think both topics are interesting, but if I had to pick one to put some work into it would be the unobserved fields draft. There is a need to communicate this information (or lack of information ;-). I am already starting to see exports where different vendors are choosing different ad hoc methods to communicate N/A for the same IEs. > > As for draft-aitken-ipfix-equivalent-ies and draft-inacio-ipfix-penie, I'm mostly interested in anything that encourages exporters to "publish" info about the IEs they export. Given the lack of uptake for 5610 I'm not optimistic that an alternate/updated version of 5610 will get any more traction. You nailed it. This is my argument against draft-aitken-ipfix-equivalent-ies. RFC 5610 is a nice mechanism for all the Exporters to send some IPFIX information (the type of enterprise(specific IEs) to the Collector, to basically plan nice. In practice, do you see any implementation of it in your Collector? I'm afraid that draft-aitken-ipfix-equivalent-ies would fall in the same category. > Most of the time I'd be happy to get a text file with 7013 style Information Element Specifiers. Yes, received a single time from the different vendors (as opposed from all the Exporters) and hard-coded in collectors. Note that some automation is possible if the format is agreed upon. Regards, Benoit (as a contributor) > > Just my 2 cents, > -Andrew > ________________________________________ > From: Benoit Claise [bclaise@cisco.com] > Sent: Monday, February 10, 2014 7:50 PM > To: Paul Aitken; Nevil Brownlee; Andrew Feren; IPFIX Working Group > Cc: ipfix-ads@tools.ietf.org; ipfix-chairs@tools.ietf.org > Subject: Re: [IPFIX] IPFIX at IETF 89, London > > Paul, > > At this point, I will be listening to the chairs to see ... > if this is really "interesting", > if there is enough support from the IPFIX community, > if there is enough discussion on it, > and if this work could be done in the decent time. > > (*) I guess that I'm so much involved in IPFIX that I have strong > opinions about your drafts. That's the price you pay for an AD who knows > IPFIX by heart. > > Regards, Benoit >> Benoit, >> >>>> I've presented these ideas in previous WG meetings, where the >>>> consensus was to wait for the next re-charter. >>> Consensus, sure? >> Yes: the work was interesting, but not relevant to the current >> charter. So, bring it up at the next recharter - which hasn't happened >> yet. >> >> >>> I checked the meeting minutes and I don't see that. >>> What I recall is that two different proposals were discussed >>> (draft-aitken-ipfix-equivalent-ies and draft-inacio-ipfix-penie-00), >>> with no clear winner. >> Sure; each of these drafts has different merits. It would be up to the >> WG to decide on the best solution. >> >> Look, here's a real problem in IPFIX which has resulted in not one but >> *two* different drafts trying to solve it in different ways. Do you >> propose to ignore it? >> >> P. >> . >> > . > From nobody Fri Feb 14 15:13:20 2014 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 236BB1A044F; Fri, 14 Feb 2014 15:13:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h52js0DHNL1Z; Fri, 14 Feb 2014 15:13:14 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D5CF01A0343; Fri, 14 Feb 2014 15:13:14 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140214231314.23049.36315.idtracker@ietfa.amsl.com> Date: Fri, 14 Feb 2014 15:13:14 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/FX4w_Q443cda7TEm1bAvEfOtJr0 Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action: draft-ietf-ipfix-mib-variable-export-04.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 23:13:17 -0000 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 Authors : Paul Aitken Benoit Claise Colin McDowall Juergen Schoenwaelder Filename : draft-ietf-ipfix-mib-variable-export-04.txt Pages : 64 Date : 2014-02-14 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-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-ipfix-mib-variable-export-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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Feb 14 15:34:11 2014 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42F4D1A04FB for ; Fri, 14 Feb 2014 15:34:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.049 X-Spam-Level: X-Spam-Status: No, score=-10.049 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, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HBNqoByHAqzs for ; Fri, 14 Feb 2014 15:34:05 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id 3FEA81A04FA for ; Fri, 14 Feb 2014 15:34:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2956; q=dns/txt; s=iport; t=1392420845; x=1393630445; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=XsM02TWYzHJkkShXzn623VSYdEyb2iO/m2l79Xdnep4=; b=J20JNS2aBjhWksqRJku5+uQ5/Ec70KV7X1VhH4fWoy4sJRrpDYCDbSsh nNbueiY2ahiJ+6APF3pWtghfCkzxJH31ctql3A444LGlSwIrc6GWZnQtg qQp71Hz2aYn78hpABm5/fW+virqMAGM8EOIXTTFIepi57IljG2td9x6BW g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiIFAKin/lKQ/khR/2dsb2JhbABZgwY4Ub84gRcWdIIlAQEBBAEBATU2ChELGAkWDwkDAgECARUwEwYCAQEFh3wIBchjF48AFoQiBJgsgTKFFYtcgy08 X-IronPort-AV: E=Sophos;i="4.95,848,1384300800"; d="scan'208";a="5122561" Received: from ams-core-1.cisco.com ([144.254.72.81]) by aer-iport-1.cisco.com with ESMTP; 14 Feb 2014 23:34:03 +0000 Received: from [10.61.78.105] (ams3-vpn-dhcp3689.cisco.com [10.61.78.105]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s1ENY11S027564 for ; Fri, 14 Feb 2014 23:34:01 GMT Message-ID: <52FEA7E7.9080101@cisco.com> Date: Fri, 14 Feb 2014 23:33:59 +0000 From: Colin McDowall User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: ipfix@ietf.org References: <20140214231314.23049.36315.idtracker@ietfa.amsl.com> In-Reply-To: <20140214231314.23049.36315.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/8iHQvZ6gONwUvGOIR39tnT47Jbg Subject: Re: [IPFIX] I-D Action: draft-ietf-ipfix-mib-variable-export-04.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 23:34:08 -0000 Hi All, This is the latest version of the IPFIX MIB Export Draft based on the excellent feedback from the previous version. Thanks to all the reviewers. Several of the clear mistakes found in the reviews are resolved. The major change in this version is that the mibObjectValue IE has been expanded to multiple IEs based on the SYNTAX as documented in the SMIv2 RFC. Also since the way the previous document described indexing was confusing and didn't match the MIB RFCs that has been rewritten to refer to exporting Sequences. Individual MIB Objects that are part of a sequence are now refered to as columnar objects. There might still be some scope for simplifying sequence export down further. There is also a new template defined to refer to exporting complete SEQUENCES as an option export. This should make exporting a simple IPFIX export of a complete MIB Sequence/Conceptual table much simpler. I'll be starting discussions on the mailer next week for some of the remaining points. Thanks, colin On 14/02/2014 23: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 : Exporting MIB Variables using the IPFIX Protocol > Authors : Paul Aitken > Benoit Claise > Colin McDowall > Juergen Schoenwaelder > Filename : draft-ietf-ipfix-mib-variable-export-04.txt > Pages : 64 > Date : 2014-02-14 > > 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-04 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-ipfix-mib-variable-export-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. > > 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 nobody Sun Feb 23 15:38:41 2014 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FA381A0764 for ; Sun, 23 Feb 2014 15:38:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.152 X-Spam-Level: X-Spam-Status: No, score=0.152 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, 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 lSCq3dAmYzjs for ; Sun, 23 Feb 2014 15:38:38 -0800 (PST) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) by ietfa.amsl.com (Postfix) with ESMTP id 112DE1A075A for ; Sun, 23 Feb 2014 15:38:37 -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=1393198718; x=1424734718; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=YkaZYLGoQSyI4G1BIiMPgECPIbibH3HF7TivN3b11Sc=; b=CtcOH4wxHBoZIh6cxG4+QS/X5JVlKuY/p8rTd9pzdVj6GyjKZ1rzBw75 REORO8G810aEqh4tJYQt4RAiPZiFcr1b+n0nJZ0poLuWwIqirjJr7KtyP bgouyLUWxtQvby3qFE9wHZZd1eOMlDuoYp/jY3GEtSnuD8A0X7q4Tht0z o=; X-IronPort-AV: E=Sophos;i="4.97,530,1389697200"; d="scan'208";a="235516169" 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; 24 Feb 2014 12:38:37 +1300 Message-ID: <530A867C.8040408@auckland.ac.nz> Date: Mon, 24 Feb 2014 12:38:36 +1300 From: Nevil Brownlee 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: Colin McDowall , ipfix@ietf.org References: <20140214231314.23049.36315.idtracker@ietfa.amsl.com> <52FEA7E7.9080101@cisco.com> In-Reply-To: <52FEA7E7.9080101@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/Lif_vP_iapjhSvsbNP9S5Qc6Oo8 Subject: Re: [IPFIX] I-D Action: draft-ietf-ipfix-mib-variable-export-04.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Feb 2014 23:38:40 -0000 Hi all: Colin published this version back on 15 February; seems to me it answers many of the issues raised by the MIB Variables draft back at the Vancouver meeting. However, Colin points out in its Introduction (and below) that it still has many points that need discussion. Please - especially if you're closely familiar with SNMP - take a little time to read this version, and send your comments/suggestions for improvements to the list. Cheers, Nevil On 15/02/14 12:33 PM, Colin McDowall wrote: > Hi All, > > This is the latest version of the IPFIX MIB Export Draft based on the > excellent > feedback from the previous version. Thanks to all the reviewers. > > Several of the clear mistakes found in the reviews are resolved. > > The major change in this version is that the mibObjectValue IE has been > expanded > to multiple IEs based on the SYNTAX as documented in the SMIv2 RFC. > > Also since the way the previous document described indexing was > confusing and didn't > match the MIB RFCs that has been rewritten to refer to exporting > Sequences. > > Individual MIB Objects that are part of a sequence are now refered to as > columnar objects. > > There might still be some scope for simplifying sequence export down > further. > > There is also a new template defined to refer to exporting complete > SEQUENCES > as an option export. This should make exporting a simple IPFIX export of > a complete > MIB Sequence/Conceptual table much simpler. > > I'll be starting discussions on the mailer next week for some of the > remaining > points. > > Thanks, > colin > > On 14/02/2014 23: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 : Exporting MIB Variables using the IPFIX >> Protocol >> Authors : Paul Aitken >> Benoit Claise >> Colin McDowall >> Juergen Schoenwaelder >> Filename : draft-ietf-ipfix-mib-variable-export-04.txt >> Pages : 64 >> Date : 2014-02-14 >> >> 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-04 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-ipfix-mib-variable-export-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. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix >> > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix -- --------------------------------------------------------------------- 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 stephan.neuhaus@tik.ee.ethz.ch Mon Feb 24 11:38:40 2014 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B66F1A024F for ; Mon, 24 Feb 2014 11:38:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.019 X-Spam-Level: *** X-Spam-Status: No, score=3.019 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FF_IHOPE_YOU_SINK=2.166, J_CHICKENPOX_51=0.6, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RHNjPp-LBGmD for ; Mon, 24 Feb 2014 11:38:37 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 4D11E1A02A0 for ; Mon, 24 Feb 2014 11:38:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 59693D9304 for ; Mon, 24 Feb 2014 20:38:35 +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 eEuBlw-Fjy8b for ; Mon, 24 Feb 2014 20:38:35 +0100 (MET) Received: from mairac.local (77-56-63-150.dclient.hispeed.ch [77.56.63.150]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: neuhaust) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id E72C8D9300 for ; Mon, 24 Feb 2014 20:38:34 +0100 (MET) Message-ID: <530B9FBA.6020905@tik.ee.ethz.ch> Date: Mon, 24 Feb 2014 20:38:34 +0100 From: Stephan Neuhaus User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: ipfix@ietf.org References: <20140120125443.14390.21012.idtracker@ietfa.amsl.com> In-Reply-To: <20140120125443.14390.21012.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/BcUUb-wKloL47mElDv02ChJZx1o X-Mailman-Approved-At: Mon, 24 Feb 2014 11:52:04 -0800 Subject: Re: [IPFIX] I-D Action: draft-ietf-ipfix-text-adt-00.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2014 19:40:45 -0000 Dear all, I'm terribly sorry to come in so late, and I am aware that my input might not be considered at this stage, but I'd like to make a few remarks about floating-point I/O, a subject that I pursue as a kind of weird hobby. This is in Section 4.4 of the draft. [In case you're wondering, I'm referring to ...-01.txt, despite my Subject line.] All of the problems outlined below could be fixed if we could assume that each side uses IEEE float32 and float64 types. Then we could forgo the expensive binary-to-decimal and decimal-to-binary conversions, transmit a hex string, and be done with it. Or perhaps even something like printf(3)'s "%a" specifier. I would like to begin with three very trivial and trivially fixed points: First, the syntax description contains both " and ' as delimiters for single-character constants. Just for consistency's sake, I'd suggest using just one delimiter. (The rest of the draft seems to favour ") Second, the format should support both 'e' and 'E' as exponent delimiters, i.e., 6.023E23 should be a valid number. This will eliminate a host of interoperability problems when people use "%G" (instead of "%g") in printf(3). Third, I'm not sure if this has been given consideration, but in some locales, and in some applications, it is customary to leave the leading zero out when writing numbers between zero and one. For example, there are ".45" caliber handguns, but not "0.45" ones. I'm not sure, however, that supporting this would justify the resulting increased complexity of the ABNF. The next point isn't so trivial any more. I'm not sure about the correct extreme values for IEEE floating-point values. You write that they were taken directly from the standard (which I don't have), but my C implementation has FLT_MIN 1.17549435E-38F FLT_MAX 3.40282347E+38F DBL_MAX 1.7976931348623157E+308 DBL_MIN 2.2250738585072014E-308 As you can see, the maximum values given here and in ...-01.txt agree to within some rounding error, but it is also clear that the values given in the standard are, strictly speaking, larger than the largest representable floating-point value. (3.403e38 > 3.4028...e38). If someone were to adhere slavishly to the text of the standard (and I know that I would), that could lead to code like #define IPFIX_FLT_MAX 3.403e38F In this case, you would rely on the compiler to convert this to FLT_MAX and not, say, INF, which would be unwise. This would cause interoperability problems which would be very hard to debug because they are so rare. The minimum values also do not agree, and I think in this case it has to do with normalisation. I'm not sure that IEEE 754-2008 requires that denormals must be supported because they can cause all kinds of performance degradation. (Typically, FPUs optimise for normalised arithmetic, using slower paths or even software for denormals. Knuth in Vol II of TAOCP doesn't even support gradual underflow and rounds everything that can't be nomalised to zero.) In any case, I believe the wording of this part of Section 4.4 should be changed to say that (1) the normative reference for the extreme values is IEEE 754-2008 and that they have the *approximate* values given here (which ought to be a strong hint to use FLT_MAX etc in an implementation that has IEEE support); (2) that all implementations MUST support at least the ranges given by IEEE 754-2008 for 32 and 64-bit floats; and (3) that values whose absolute value is in excess of the maximum should (MUST?) be rounded-to-zero to the maximum and that values whose absolute value is less than the minimum should (MUST?) be rounded to zero. (GNU libc strtod(3) does this already.) But more importantly, I am concerned about two things. First is the representation of corner cases and extreme values. We might not like it, but measurements will occasionally turn up as NaN, Inf or -Inf. Someone divides zero by zero and gets NaN, or someone divides one by zero and gets Inf. It happens, and in some cases, Inf (unlike NaN) is actually the right answer, so one can't argue that Infs happen only in broken implementations. So I'd move that the three special values "NaN" (or "nan" or "NAN"), "['+']Inf" (or "['+']inf" or "['+']INF") and "-Inf" (or "-inf" or "-INF") be supported. In the IEEE standard, NaNs can be signaling or quiet, but apart from the people who wrote that standard, no one understands what that's supposed to mean, so I'd also move that the recipient of the "NaN" token SHOULD convert this into a quiet NaN, which will probably happen anyway. Usually the C expression "0.0F/0.0F" or "0.0/0.0" does the trick. Second is the absence of precision requirements. Ideally, if both sides use IEEE 754 (and who doesn't, these days?) the transmitted strings should enable the receiver to reconstruct the exact bit pattern that was present on the sender side, modulo endianness. After all, we insist that a string that the sending side knows as "hello" appears on the receiving side as "hello", too; we wouldn't consider "hell" an acceptable alternative! This is easiest if you simply transmit a hex string in network byte order or use printf(3)'s "%a" format, which seems to me to be OK since the ADT format isn't meant for human consumption, but I can see that a decimal representation might be more palatable. Brian has pointed out to me that if you have such stringent precision requirements, you ought to use IPFIX binary transfer, and he is of course right. On the other hand, not many people understand the concept of "significant digits", so if one uses the printf(3) "%f" format instead of "%g", one could easily turn the easily represented 1e-10F to 0.0000000 by a careless "%.8f" (arguing that floats have only at most eight digits in them anyway). Luckily, correct text-to-float and float-to-text conversion has been solved as a technical problem for two decades and a half, almost; GNU libc has had the relevant conversion algorithms in strto{f,d,l}(3) and scanf(3) for ages now (even though it is a good idea to read the man page thoroughly to make sure that one gets the corner and error cases right); these allow printing of floating-point numbers with the smallest number of digits so that reading them back will produce the same bit pattern. In the absence of such algorithms, I think senders SHOULD use nine significant(!) digits for non-zero and finite float32 and seventeen for float64. That will still not *guarantee* the same bit pattern on the sender and on the receiver, but it will *enable* them to recover it. If anyone is interested, the canonical papers on the topic are Guy L. Steele, Jon L. White, "How to Print Floating-Point Numbers Accurately", SIGPLAN '90; and William D. Clinger, "How to Read Floating-Point Numbers Accurately", SIGPLAN '90. Best regards, and apologies again for my late comments, Stephan From nobody Tue Feb 25 00:57:25 2014 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD6621A0198 for ; Mon, 24 Feb 2014 11:51:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.747 X-Spam-Level: X-Spam-Status: No, score=-4.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547] 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 3CM134x8keu4 for ; Mon, 24 Feb 2014 11:51:51 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 91CE61A0184 for ; Mon, 24 Feb 2014 11:51:51 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 3D378D9304 for ; Mon, 24 Feb 2014 20:51:50 +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 sakpRWFRRORm for ; Mon, 24 Feb 2014 20:51:50 +0100 (MET) Received: from mairac.local (77-56-63-150.dclient.hispeed.ch [77.56.63.150]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: neuhaust) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 0C458D9300 for ; Mon, 24 Feb 2014 20:51:50 +0100 (MET) Message-ID: <530BA2D5.6080308@tik.ee.ethz.ch> Date: Mon, 24 Feb 2014 20:51:49 +0100 From: Stephan Neuhaus User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: ipfix@ietf.org References: <20140120125443.14390.21012.idtracker@ietfa.amsl.com> <530B9FBA.6020905@tik.ee.ethz.ch> In-Reply-To: <530B9FBA.6020905@tik.ee.ethz.ch> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/ih8k2T-tQlCxYg8gmrnmGLIUiAQ X-Mailman-Approved-At: Tue, 25 Feb 2014 00:57:24 -0800 Subject: Re: [IPFIX] I-D Action: draft-ietf-ipfix-text-adt-00.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2014 19:51:53 -0000 On 2014-02-24, 20:38, Stephan Neuhaus wrote: > Best regards, and apologies again for my late comments, I should have added that I'd be willing to propose the text for a new and improved Section 4.4. Best regards, Stephan From nobody Wed Feb 26 02:19:07 2014 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8E0B1A01F5 for ; Wed, 26 Feb 2014 02:19:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_50=0.8, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.547, 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 azTMW7l8bo8O for ; Wed, 26 Feb 2014 02:18:59 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 837541A0078 for ; Wed, 26 Feb 2014 02:18:59 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 03767106E6A; Wed, 26 Feb 2014 11:18:58 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0+34OgIZvcc4; Wed, 26 Feb 2014 11:18:57 +0100 (CET) X-ENC: Last-Hop-TLS-encrypted X-ENC: Last-Hop-TLS-encrypted Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailer1.neclab.eu (Postfix) with ESMTPS id D9574106E67; Wed, 26 Feb 2014 11:18:42 +0100 (CET) Received: from PALLENE.office.hd ([169.254.1.233]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Wed, 26 Feb 2014 11:18:42 +0100 From: Juergen Quittek To: Paul Aitken , Brian Trammell Thread-Topic: Encoding of Boolean values in draft-ietf-ipfix-text-adt Thread-Index: Ac8y3B45n91/HcdQS/mF+FP3WFGALg== Date: Wed, 26 Feb 2014 10:18:42 +0000 Message-ID: <9AB93E4127C26F4BA7829DEFDCE5A6E877A6B701@PALLENE.office.hd> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.2.165] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/JVmsY7C1kn3NM9HRR1-hz-3LIRs Cc: IPFIX Working Group Subject: [IPFIX] Encoding of Boolean values in draft-ietf-ipfix-text-adt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2014 10:19:03 -0000 Dear all, The open question is: What is the best textual encoding for Boolean values = in flow records? Here are the alternatives discussed so far: 1. true: "1", false: "0" Pro: very common, used by several programming languages, international (not= language-specific) Con: 0 may be misinterpreted as "don't know" 2. true: "true", false: "false" Pro: very common, unambiguous, used by several programming languages,=20 Con: not international: English language-specific 3. true:"1", false: "2" Pro: in line with SMI encoding for Booleans Con: unknown outside of SNMP community. Not intuitively clear which is true= and which is false 4. true: "t"*, false: "f"* Con: may be confusing or misleading. Writing now as technical contributor, I would eliminate option #4 because I= do not see any advantage of this alternative. #3 has only a weak "pro" bei= ng used by SMI. Thus, we should either choose #1 or #2. Here, I would go f= or #1 because it is not language-specific. Cheers, Juergen > -----Original Message----- > From: IPFIX [mailto:ipfix-bounces@ietf.org] On Behalf Of Paul Aitken > Sent: Dienstag, 11. Februar 2014 22:32 > To: Brian Trammell > Cc: IPFIX Working Group > Subject: Re: [IPFIX] Fwd: New Version Notification for draft-ietf-ipfix-t= ext- > adt-01.txt >=20 > Brian, >=20 > Aside from the fact that this is English-specific, it works for me. >=20 > P. >=20 >=20 > > Aside from the fact that these aren't case-insensitive (which at least = causes > an error as opposed to a non-detected incorrect acceptance), I'd say we > could combine these: > > > > true =3D ('t' | 'T') 0*ALPHA > > > > false =3D ('f' | 'F') 0*ALPHA > > > > i.e., the decoder only looks at the first letter for [tT] or [fF], prob= ably with a > note that "true" and "false" are the preferred encodings. >=20 >=20 > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From nobody Wed Feb 26 02:48:45 2014 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DB021A0233 for ; Wed, 26 Feb 2014 02:48:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.047 X-Spam-Level: X-Spam-Status: No, score=-12.047 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id trLTmn4ssC77 for ; Wed, 26 Feb 2014 02:48:34 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id 5711C1A0241 for ; Wed, 26 Feb 2014 02:48:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7065; q=dns/txt; s=iport; t=1393411711; x=1394621311; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=m0VGjE4n6P/CHpvbiaxRK+mlQj1eqyVtM7PMvmm/DEU=; b=Ra2vJHdgk0VYD0rKukJztI1IALoOnXlnt+ZLQ1F2eZk4IChnhBdPMIlm MrluMrlI+dLzktk1wlZ5wpFwP64+VmZYz1jf1sqM5TGTaPjFYHK6OY7ON hyGKMrFftuQezOBy4kIs/inrOeK1NNpZm8qLM9kXoKmvArRA87FhQyRkf c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFABrGDVOQ/khL/2dsb2JhbABZgwY7wUqBHRZ0giUBAQEEAQEBawsMBAsRBAEBAQkeBw8CFh8JCAYBDAEFAgEBEIdxDchzEwSOUAcGhDIEmDaGSYtfgy0 X-IronPort-AV: E=Sophos;i="4.97,547,1389744000"; d="scan'208,217";a="5516601" Received: from ams-core-2.cisco.com ([144.254.72.75]) by aer-iport-2.cisco.com with ESMTP; 26 Feb 2014 10:48:30 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s1QAmTYJ005865 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 26 Feb 2014 10:48:30 GMT Received: from [10.147.1.32] (dhcp-10-147-1-32.cisco.com [10.147.1.32]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id s1QAmSYh006280; Wed, 26 Feb 2014 10:48:28 GMT Message-ID: <530DC67C.70104@cisco.com> Date: Wed, 26 Feb 2014 10:48:28 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Juergen Quittek , Brian Trammell References: <9AB93E4127C26F4BA7829DEFDCE5A6E877A6B701@PALLENE.office.hd> In-Reply-To: <9AB93E4127C26F4BA7829DEFDCE5A6E877A6B701@PALLENE.office.hd> Content-Type: multipart/alternative; boundary="------------080701030307000802080800" Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/RTgWtbWAGfVWSt4fcmHMu47QSQE Cc: IPFIX Working Group Subject: Re: [IPFIX] Encoding of Boolean values in draft-ietf-ipfix-text-adt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2014 10:48:39 -0000 This is a multi-part message in MIME format. --------------080701030307000802080800 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Juergen, The values in option 1 conflict with the RFC 7011 (IPFIX Protocol) boolean encoding definition, which says: 6.1.5. boolean The boolean data type is specified according to the TruthValue in [RFC2579]. It is encoded as a single-octet integer per Section 6.1.1,with the value 1 for true and value 2 for false. Every other value is undefined. Option 3 provides the benefits of consistency with RFC 7011, and no conversion required between the RFC 7011 and text-adt formats. Expressed another way: the IPFIX WG group already decided the boolean encoding. Although we might not like that definition now, we should consistently use the same encoding across all the IPFIX RFCs. P. On 26/02/2014 10:18, Juergen Quittek wrote: > Dear all, > > The open question is: What is the best textual encoding for Boolean values in flow records? > > Here are the alternatives discussed so far: > > 1. true: "1", false: "0" > Pro: very common, used by several programming languages, international (not language-specific) > Con: 0 may be misinterpreted as "don't know" > > 2. true: "true", false: "false" > Pro: very common, unambiguous, used by several programming languages, > Con: not international: English language-specific > > 3. true:"1", false: "2" > Pro: in line with SMI encoding for Booleans > Con: unknown outside of SNMP community. Not intuitively clear which is true and which is false > > 4. true: "t"*, false: "f"* > Con: may be confusing or misleading. > > Writing now as technical contributor, I would eliminate option #4 because I do not see any advantage of this alternative. #3 has only a weak "pro" being used by SMI. Thus, we should either choose #1 or #2. Here, I would go for #1 because it is not language-specific. > > Cheers, > Juergen > > > > >> -----Original Message----- >> From: IPFIX [mailto:ipfix-bounces@ietf.org] On Behalf Of Paul Aitken >> Sent: Dienstag, 11. Februar 2014 22:32 >> To: Brian Trammell >> Cc: IPFIX Working Group >> Subject: Re: [IPFIX] Fwd: New Version Notification for draft-ietf-ipfix-text- >> adt-01.txt >> >> Brian, >> >> Aside from the fact that this is English-specific, it works for me. >> >> P. >> >> >>> Aside from the fact that these aren't case-insensitive (which at least causes >> an error as opposed to a non-detected incorrect acceptance), I'd say we >> could combine these: >>> true = ('t' | 'T') 0*ALPHA >>> >>> false = ('f' | 'F') 0*ALPHA >>> >>> i.e., the decoder only looks at the first letter for [tT] or [fF], probably with a >> note that "true" and "false" are the preferred encodings. >> >> >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix --------------080701030307000802080800 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Juergen,

The values in option 1 conflict with the RFC 7011 (IPFIX Protocol) boolean encoding definition, which says:

6.1.5.  boolean

   The boolean data type is specified according to the TruthValue in
   [RFC2579].  It is encoded as a single-octet integer per
   Section 6.1.1, with the value 1 for true and value 2 for false.
   Every other value is undefined.

Option 3 provides the benefits of consistency with RFC 7011, and no conversion required between the RFC 7011 and text-adt formats.

Expressed another way: the IPFIX WG group already decided the boolean encoding. Although we might not like that definition now, we should consistently use the same encoding across all the IPFIX RFCs.

P.


On 26/02/2014 10:18, Juergen Quittek wrote:
Dear all,

The open question is: What is the best textual encoding for Boolean values in flow records?

Here are the alternatives discussed so far:

1. true: "1", false: "0"
Pro: very common, used by several programming languages, international (not language-specific)
Con:  0 may be misinterpreted as "don't know"

2. true: "true", false: "false"
Pro: very common, unambiguous, used by several programming languages, 
Con:  not international: English language-specific

3. true:"1", false: "2"
Pro: in line with SMI encoding for Booleans
Con: unknown outside of SNMP community. Not intuitively clear which is true and which is false

4. true: "t"*, false: "f"*
Con: may be confusing or misleading.

Writing now as technical contributor, I would eliminate option #4 because I do not see any advantage of this alternative. #3 has only a weak "pro" being used by SMI.  Thus, we should either choose #1 or #2. Here, I would go for #1 because it is not language-specific.

Cheers,
    Juergen





-----Original Message-----
From: IPFIX [mailto:ipfix-bounces@ietf.org] On Behalf Of Paul Aitken
Sent: Dienstag, 11. Februar 2014 22:32
To: Brian Trammell
Cc: IPFIX Working Group
Subject: Re: [IPFIX] Fwd: New Version Notification for draft-ietf-ipfix-text-
adt-01.txt

Brian,

Aside from the fact that this is English-specific, it works for me.

P.



Aside from the fact that these aren't case-insensitive (which at least causes

an error as opposed to a non-detected incorrect acceptance), I'd say we
could combine these:

true = ('t' | 'T') 0*ALPHA

false = ('f' | 'F') 0*ALPHA

i.e., the decoder only looks at the first letter for [tT] or [fF], probably with a

note that "true" and "false" are the preferred encodings.


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

--------------080701030307000802080800-- From nobody Wed Feb 26 04:02:11 2014 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 507381A02A4 for ; Wed, 26 Feb 2014 04:02:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.902 X-Spam-Level: X-Spam-Status: No, score=-3.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, 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 32CPoOUZBvXq for ; Wed, 26 Feb 2014 04:02:04 -0800 (PST) Received: from trammell.ch (trammell1.nine.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 88FFF1A0060 for ; Wed, 26 Feb 2014 04:02:04 -0800 (PST) Received: from pb-10243.ethz.ch (pb-10243.ethz.ch [82.130.102.152]) by trammell.ch (Postfix) with ESMTPSA id 7B0331A0034 for ; Wed, 26 Feb 2014 13:01:32 +0100 (CET) From: Brian Trammell Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Wed, 26 Feb 2014 13:01:31 +0100 References: <2C6BBBA7-0F82-419B-B6C0-2587AA1CDB09@tik.ee.ethz.ch> To: IPFIX Working Group Message-Id: Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/G3hEjsbAB1kCNmjb6RCnUSFOak8 Subject: [IPFIX] Encoding of Boolean values in draft-ietf-ipfix-text-adt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2014 12:02:07 -0000 hi Paul, Juergen, On 26 Feb 2014, at 11:48, Paul Aitken wrote: > Juergen, >=20 > The values in option 1 conflict with the RFC 7011 (IPFIX Protocol) = boolean encoding definition, which says: >=20 > 6.1.5. boolean >=20 > The boolean data type is specified according to the TruthValue in > [RFC2579]. It is encoded as a single-octet integer per > Section 6.1.1,=20 > with the value 1 for true and value 2 for false > . > Every other value is undefined. >=20 >=20 > Option 3 provides the benefits of consistency with RFC 7011, and no = conversion required between the RFC 7011 and text-adt formats. This is, pedantically speaking, not correct: the representation in IPFIX = are 0x01 and 0x02, while the representation with text-adt for option 3 = would be 0x31 (UTF-8 '1') and 0x32 (UTF-8 '2'). Conversion is necessary = in any case, but you are correct that option 3 provides less opportunity = for confusion when building transcoders than option 1. > Expressed another way: the IPFIX WG group already decided the boolean = encoding. Although we might not like that definition now, we should = consistently use the same encoding across all the IPFIX RFCs. I have to disagree here. As above, it's _not_ the same encoding. It's = simply a _related_ encoding. The IPFIX boolean encoding is _just barely_ explainable by reference to = the SMI definition (which explicitly uses 0 for undefined, missing from = the IPFIX definition); otherwise it is a clear error by violation of the = principle of least surprise. It is _barely acceptable_ in that it is = defined as a binary representation such that the expectation is that = only developers debugging protocol implementations will be looking at = the bits on the wire. (Indeed, as an aside, given the violation of the = principle of least surprise, I would be interested to know how many = implementations of IPFIX incorrectly export 0 for false and 1 for true.) Carrying this encoding forward into a _human readable_ representation of = the ADT would compound the error we made in 5101; here, as the intention = is that the text-adt representations _are_ indeed understandable by = people who are not IPFIX developers, the violation of the principle of = least surprise would not, I think, be a defensible decision. Option 2, "true" and "false" is a compromise position, recognizing that = by using strings which do not collide with the binary encoding, we = reduce the possibility of confusion that option 1 presents. Regards, Brian > P. >=20 >=20 > On 26/02/2014 10:18, Juergen Quittek wrote: >> Dear all, >>=20 >> The open question is: What is the best textual encoding for Boolean = values in flow records? >>=20 >> Here are the alternatives discussed so far: >>=20 >> 1. true: "1", false: "0" >> Pro: very common, used by several programming languages, = international (not language-specific) >> Con: 0 may be misinterpreted as "don't know" >>=20 >> 2. true: "true", false: "false" >> Pro: very common, unambiguous, used by several programming languages,=20= >> Con: not international: English language-specific >>=20 >> 3. true:"1", false: "2" >> Pro: in line with SMI encoding for Booleans >> Con: unknown outside of SNMP community. Not intuitively clear which = is true and which is false >>=20 >> 4. true: "t"*, false: "f"* >> Con: may be confusing or misleading. >>=20 >> Writing now as technical contributor, I would eliminate option #4 = because I do not see any advantage of this alternative. #3 has only a = weak "pro" being used by SMI. Thus, we should either choose #1 or #2. = Here, I would go for #1 because it is not language-specific. >>=20 >> Cheers, >> Juergen >>=20 >>=20 >>=20 >>=20 >>=20 >>> -----Original Message----- >>> From: IPFIX [ >>> mailto:ipfix-bounces@ietf.org >>> ] On Behalf Of Paul Aitken >>> Sent: Dienstag, 11. Februar 2014 22:32 >>> To: Brian Trammell >>> Cc: IPFIX Working Group >>> Subject: Re: [IPFIX] Fwd: New Version Notification for = draft-ietf-ipfix-text- >>> adt-01.txt >>>=20 >>> Brian, >>>=20 >>> Aside from the fact that this is English-specific, it works for me. >>>=20 >>> P. >>>=20 >>>=20 >>>=20 >>>> Aside from the fact that these aren't case-insensitive (which at = least causes >>>>=20 >>> an error as opposed to a non-detected incorrect acceptance), I'd say = we >>> could combine these: >>>=20 >>>> true =3D ('t' | 'T') 0*ALPHA >>>>=20 >>>> false =3D ('f' | 'F') 0*ALPHA >>>>=20 >>>> i.e., the decoder only looks at the first letter for [tT] or [fF], = probably with a >>>>=20 >>> note that "true" and "false" are the preferred encodings. >>>=20 >>>=20 >>> _______________________________________________ >>> IPFIX mailing list >>>=20 >>> IPFIX@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipfix >=20 > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From nobody Wed Feb 26 08:22:29 2014 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D02AB1A02A3 for ; Wed, 26 Feb 2014 03:50:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.747 X-Spam-Level: X-Spam-Status: No, score=-6.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547] 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 ScYeHMbIBt0D for ; Wed, 26 Feb 2014 03:50:30 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id B8C791A028E for ; Wed, 26 Feb 2014 03:50:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 21DF8D9309; Wed, 26 Feb 2014 12:50:27 +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 S2cBBLpP3Phe; Wed, 26 Feb 2014 12:50:22 +0100 (MET) Received: from pb-10243.ethz.ch (pb-10243.ethz.ch [82.130.102.152]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id F1533D9305; Wed, 26 Feb 2014 12:50:21 +0100 (MET) Content-Type: multipart/signed; boundary="Apple-Mail=_C9D19FA2-2841-4EC3-842C-17D8BF209258"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Brian Trammell In-Reply-To: <530DC67C.70104@cisco.com> Date: Wed, 26 Feb 2014 12:50:21 +0100 Message-Id: <2C6BBBA7-0F82-419B-B6C0-2587AA1CDB09@tik.ee.ethz.ch> References: <9AB93E4127C26F4BA7829DEFDCE5A6E877A6B701@PALLENE.office.hd> <530DC67C.70104@cisco.com> To: Paul Aitken X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/tgT_oEO94rb05z-T0tFv-K-BDxc X-Mailman-Approved-At: Wed, 26 Feb 2014 08:22:21 -0800 Cc: IPFIX Working Group Subject: Re: [IPFIX] Encoding of Boolean values in draft-ietf-ipfix-text-adt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2014 11:50:39 -0000 --Apple-Mail=_C9D19FA2-2841-4EC3-842C-17D8BF209258 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 hi Paul, Juergen, On 26 Feb 2014, at 11:48, Paul Aitken wrote: > Juergen, >=20 > The values in option 1 conflict with the RFC 7011 (IPFIX Protocol) = boolean encoding definition, which says: >=20 > 6.1.5. boolean >=20 > The boolean data type is specified according to the TruthValue in > [RFC2579]. It is encoded as a single-octet integer per > Section 6.1.1,=20 > with the value 1 for true and value 2 for false > . > Every other value is undefined. >=20 >=20 > Option 3 provides the benefits of consistency with RFC 7011, and no = conversion required between the RFC 7011 and text-adt formats. This is, pedantically speaking, not correct: the representation in IPFIX = are 0x01 and 0x02, while the representation with text-adt for option 3 = would be 0x31 (UTF-8 '1') and 0x32 (UTF-8 '2'). Conversion is necessary = in any case, but you are correct that option 3 provides less opportunity = for confusion when building transcoders than option 1. > Expressed another way: the IPFIX WG group already decided the boolean = encoding. Although we might not like that definition now, we should = consistently use the same encoding across all the IPFIX RFCs. I have to disagree here. As above, it's _not_ the same encoding. It's = simply a _related_ encoding. The IPFIX boolean encoding is _just barely_ explainable by reference to = the SMI definition (which explicitly uses 0 for undefined, missing from = the IPFIX definition); otherwise it is a clear error by violation of the = principle of least surprise. It is _barely acceptable_ in that it is = defined as a binary representation such that the expectation is that = only developers debugging protocol implementations will be looking at = the bits on the wire. (Indeed, as an aside, given the violation of the = principle of least surprise, I would be interested to know how many = implementations of IPFIX incorrectly export 0 for false and 1 for true.) Carrying this encoding forward into a _human readable_ representation of = the ADT would compound the error we made in 5101; here, as the intention = is that the text-adt representations _are_ indeed understandable by = people who are not IPFIX developers, the violation of the principle of = least surprise would not, I think, be a defensible decision. Option 2, "true" and "false" is a compromise position, recognizing that = by using strings which do not collide with the binary encoding, we = reduce the possibility of confusion that option 1 presents. Regards, Brian > P. >=20 >=20 > On 26/02/2014 10:18, Juergen Quittek wrote: >> Dear all, >>=20 >> The open question is: What is the best textual encoding for Boolean = values in flow records? >>=20 >> Here are the alternatives discussed so far: >>=20 >> 1. true: "1", false: "0" >> Pro: very common, used by several programming languages, = international (not language-specific) >> Con: 0 may be misinterpreted as "don't know" >>=20 >> 2. true: "true", false: "false" >> Pro: very common, unambiguous, used by several programming languages,=20= >> Con: not international: English language-specific >>=20 >> 3. true:"1", false: "2" >> Pro: in line with SMI encoding for Booleans >> Con: unknown outside of SNMP community. Not intuitively clear which = is true and which is false >>=20 >> 4. true: "t"*, false: "f"* >> Con: may be confusing or misleading. >>=20 >> Writing now as technical contributor, I would eliminate option #4 = because I do not see any advantage of this alternative. #3 has only a = weak "pro" being used by SMI. Thus, we should either choose #1 or #2. = Here, I would go for #1 because it is not language-specific. >>=20 >> Cheers, >> Juergen >>=20 >>=20 >>=20 >>=20 >>=20 >>> -----Original Message----- >>> From: IPFIX [ >>> mailto:ipfix-bounces@ietf.org >>> ] On Behalf Of Paul Aitken >>> Sent: Dienstag, 11. Februar 2014 22:32 >>> To: Brian Trammell >>> Cc: IPFIX Working Group >>> Subject: Re: [IPFIX] Fwd: New Version Notification for = draft-ietf-ipfix-text- >>> adt-01.txt >>>=20 >>> Brian, >>>=20 >>> Aside from the fact that this is English-specific, it works for me. >>>=20 >>> P. >>>=20 >>>=20 >>>=20 >>>> Aside from the fact that these aren't case-insensitive (which at = least causes >>>>=20 >>> an error as opposed to a non-detected incorrect acceptance), I'd say = we >>> could combine these: >>>=20 >>>> true =3D ('t' | 'T') 0*ALPHA >>>>=20 >>>> false =3D ('f' | 'F') 0*ALPHA >>>>=20 >>>> i.e., the decoder only looks at the first letter for [tT] or [fF], = probably with a >>>>=20 >>> note that "true" and "false" are the preferred encodings. >>>=20 >>>=20 >>> _______________________________________________ >>> IPFIX mailing list >>>=20 >>> IPFIX@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipfix >=20 > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix --Apple-Mail=_C9D19FA2-2841-4EC3-842C-17D8BF209258 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 iQEcBAEBCgAGBQJTDdT9AAoJENt3nsOmbNJc8O4H/jNJRySch9/5lMubSt6Wm+mm CPfJT48Kz8P3Pn+YMSCycybuQnTbyFKlt/lfz68v2xFIMM9TyPO4fwAbJ075JR14 y+sRWsS5+0wTd8sY/tGU+HaDlT17UYZUPzEFCPDR8RPDsPgJ6zsYzFHcStgxLEwI wA05edDgUeEp2GoZtXwRp3l1T3HT+nz2xGEM4aaCxHI3VFRv2UZFMSXuqP7mpmRT VPINGSUVOJItTh58LGNEqpsBsnq6NNAaWUyHcucFgNwzncKC7c0yQzDPVgyV8of8 gk+BUPjnFXUhJbmYXcjJCDbVej7w/fX904yqlJ+miC7FFy61UssgG96riPvlkeg= =yKJF -----END PGP SIGNATURE----- --Apple-Mail=_C9D19FA2-2841-4EC3-842C-17D8BF209258-- From nobody Thu Feb 27 00:43:24 2014 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 589281A00CF for ; Thu, 27 Feb 2014 00:43:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.149 X-Spam-Level: X-Spam-Status: No, score=-5.149 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.547, 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 DcCCVlNP3_Tw for ; Thu, 27 Feb 2014 00:43:20 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id B0F941A0086 for ; Thu, 27 Feb 2014 00:43:19 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 0565A106E76; Thu, 27 Feb 2014 09:43:18 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LF2wqQrNNZWh; Thu, 27 Feb 2014 09:43:17 +0100 (CET) X-ENC: Last-Hop-TLS-encrypted X-ENC: Last-Hop-TLS-encrypted Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailer1.neclab.eu (Postfix) with ESMTPS id D8D45106E6F; Thu, 27 Feb 2014 09:43:02 +0100 (CET) Received: from PALLENE.office.hd ([169.254.1.233]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Thu, 27 Feb 2014 09:42:41 +0100 From: Juergen Quittek To: Paul Aitken , Juergen Quittek , Brian Trammell Thread-Topic: Encoding of Boolean values in draft-ietf-ipfix-text-adt Thread-Index: Ac8y3B45n91/HcdQS/mF+FP3WFGALv//95AA//+KlTA= Date: Thu, 27 Feb 2014 08:42:41 +0000 Message-ID: <9AB93E4127C26F4BA7829DEFDCE5A6E877A6CD74@PALLENE.office.hd> References: <9AB93E4127C26F4BA7829DEFDCE5A6E877A6B701@PALLENE.office.hd> <530DC67C.70104@cisco.com> In-Reply-To: <530DC67C.70104@cisco.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.99.69] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/qELuOda-F17loxDlUWQI-Ib5RdQ Cc: IPFIX Working Group Subject: Re: [IPFIX] Encoding of Boolean values in draft-ietf-ipfix-text-adt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2014 08:43:22 -0000 Hi Paul, You are right. It is another pro for the true=3D"1" and false=3D"2" encodin= g that it is in line with RFC 7011. Thank you for pointing out this issue a= nd sorry for not having this in my previous email. For developers it would= be a step of convenience to have encodings in line and use the one from SM= I and RFC7011.=20 However, the textual representation addresses a larger community than just = implementers. The textual representation is something that will be particul= arly interesting to people not very familiar with IPFIX encoding details. H= ere I think that the 1-2 encoding should not be used, because of its high p= otential to be not understood or misunderstood. Cheers, Juergen > -----Original Message----- > From: Paul Aitken [mailto:paitken@cisco.com] > Sent: Mittwoch, 26. Februar 2014 11:48 > To: Juergen Quittek; Brian Trammell > Cc: IPFIX Working Group > Subject: Re: Encoding of Boolean values in draft-ietf-ipfix-text-adt >=20 > Juergen, >=20 > The values in option 1 conflict with the RFC 7011 (IPFIX Protocol) boolea= n > encoding definition, which says: >=20 >=20 > 6.1.5. boolean >=20 > The boolean data type is specified according to the TruthValue in > [RFC2579]. It is encoded as a single-octet integer per > Section 6.1.1, with the value 1 for true and value 2 for false. > Every other value is undefined. >=20 > Option 3 provides the benefits of consistency with RFC 7011, and no > conversion required between the RFC 7011 and text-adt formats. >=20 > Expressed another way: the IPFIX WG group already decided the boolean > encoding. Although we might not like that definition now, we should > consistently use the same encoding across all the IPFIX RFCs. >=20 > P. >=20 >=20 > On 26/02/2014 10:18, Juergen Quittek wrote: >=20 >=20 > Dear all, >=20 > The open question is: What is the best textual encoding for Boolean > values in flow records? >=20 > Here are the alternatives discussed so far: >=20 > 1. true: "1", false: "0" > Pro: very common, used by several programming languages, > international (not language-specific) > Con: 0 may be misinterpreted as "don't know" >=20 > 2. true: "true", false: "false" > Pro: very common, unambiguous, used by several programming > languages, > Con: not international: English language-specific >=20 > 3. true:"1", false: "2" > Pro: in line with SMI encoding for Booleans > Con: unknown outside of SNMP community. Not intuitively clear > which is true and which is false >=20 > 4. true: "t"*, false: "f"* > Con: may be confusing or misleading. >=20 > Writing now as technical contributor, I would eliminate option #4 > because I do not see any advantage of this alternative. #3 has only a wea= k > "pro" being used by SMI. Thus, we should either choose #1 or #2. Here, I > would go for #1 because it is not language-specific. >=20 > Cheers, > Juergen >=20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: IPFIX [mailto:ipfix-bounces@ietf.org] On Behalf Of > Paul Aitken > Sent: Dienstag, 11. Februar 2014 22:32 > To: Brian Trammell > Cc: IPFIX Working Group > Subject: Re: [IPFIX] Fwd: New Version Notification for draft- > ietf-ipfix-text- > adt-01.txt >=20 > Brian, >=20 > Aside from the fact that this is English-specific, it works for > me. >=20 > P. >=20 >=20 >=20 > Aside from the fact that these aren't case-insensitive > (which at least causes >=20 > an error as opposed to a non-detected incorrect acceptance), > I'd say we > could combine these: >=20 >=20 > true =3D ('t' | 'T') 0*ALPHA >=20 > false =3D ('f' | 'F') 0*ALPHA >=20 > i.e., the decoder only looks at the first letter for [tT] > or [fF], probably with a >=20 > note that "true" and "false" are the preferred encodings. >=20 >=20 >=20 > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix >=20 From nobody Thu Feb 27 00:48:40 2014 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C137F1A071B for ; Thu, 27 Feb 2014 00:48:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.048 X-Spam-Level: X-Spam-Status: No, score=-12.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_LETTER=-2, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bd6CADo1Cq4i for ; Thu, 27 Feb 2014 00:48:27 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id 1371C1A07D3 for ; Thu, 27 Feb 2014 00:48:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4271; q=dns/txt; s=iport; t=1393490906; x=1394700506; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=N0RihQsSYgv3UJlY7QDj+GsaGbWkGG+80zRqC6in9y0=; b=JW8Jqeg6FKsPEkLDvlA31C5Kkl7Zxzjv5LQqubVDi/uIETAumNyrcxlG 6a0CHCIKSjYNftCdpnbMZI5cBZFz7fE5tuwvEiWbjckNj30i6PDx+cVY+ MjVo8KJkuOK261T3zZPdLhP03gSI4yC/9xvJLtHudDZFAA14f8wzVAouC E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAJL7DlOQ/khL/2dsb2JhbABagwY7wV+BFhZ0giUBAQEEAQEBNTYLDAQLEQQBAQEJHgcPAhYfCQgGAQwBBQIBARCHZQ3KMxMEjXIRAVAHBoQxAQOYOIZKi1+DLYFx X-IronPort-AV: E=Sophos;i="4.97,553,1389744000"; d="scan'208";a="5625177" Received: from ams-core-2.cisco.com ([144.254.72.75]) by aer-iport-2.cisco.com with ESMTP; 27 Feb 2014 08:48:24 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s1R8mOG9025385 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 Feb 2014 08:48:24 GMT Received: from [10.61.106.109] (dhcp-10-61-106-109.cisco.com [10.61.106.109]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id s1R8mMxA002476; Thu, 27 Feb 2014 08:48:23 GMT Message-ID: <530EFBEF.309@cisco.com> Date: Thu, 27 Feb 2014 08:48:47 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Juergen Quittek , Brian Trammell References: <9AB93E4127C26F4BA7829DEFDCE5A6E877A6B701@PALLENE.office.hd> <530DC67C.70104@cisco.com> <9AB93E4127C26F4BA7829DEFDCE5A6E877A6CD74@PALLENE.office.hd> In-Reply-To: <9AB93E4127C26F4BA7829DEFDCE5A6E877A6CD74@PALLENE.office.hd> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/12bS-rICu88SmK3VRAtzu8oaZwg Cc: IPFIX Working Group Subject: Re: [IPFIX] Encoding of Boolean values in draft-ietf-ipfix-text-adt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2014 08:48:37 -0000 Juergen, Since there's potential for the 1/2 and "1"/"0" encodings to be confused, and since this is by definition a textual encoding, I'd prefer option 2 ("true", "false"). P. On 27/02/2014 08:42, Juergen Quittek wrote: > Hi Paul, > > You are right. It is another pro for the true="1" and false="2" encoding that it is in line with RFC 7011. Thank you for pointing out this issue and sorry for not having this in my previous email. For developers it would be a step of convenience to have encodings in line and use the one from SMI and RFC7011. > > However, the textual representation addresses a larger community than just implementers. The textual representation is something that will be particularly interesting to people not very familiar with IPFIX encoding details. Here I think that the 1-2 encoding should not be used, because of its high potential to be not understood or misunderstood. > > Cheers, > Juergen > >> -----Original Message----- >> From: Paul Aitken [mailto:paitken@cisco.com] >> Sent: Mittwoch, 26. Februar 2014 11:48 >> To: Juergen Quittek; Brian Trammell >> Cc: IPFIX Working Group >> Subject: Re: Encoding of Boolean values in draft-ietf-ipfix-text-adt >> >> Juergen, >> >> The values in option 1 conflict with the RFC 7011 (IPFIX Protocol) boolean >> encoding definition, which says: >> >> >> 6.1.5. boolean >> >> The boolean data type is specified according to the TruthValue in >> [RFC2579]. It is encoded as a single-octet integer per >> Section 6.1.1, with the value 1 for true and value 2 for false. >> Every other value is undefined. >> >> Option 3 provides the benefits of consistency with RFC 7011, and no >> conversion required between the RFC 7011 and text-adt formats. >> >> Expressed another way: the IPFIX WG group already decided the boolean >> encoding. Although we might not like that definition now, we should >> consistently use the same encoding across all the IPFIX RFCs. >> >> P. >> >> >> On 26/02/2014 10:18, Juergen Quittek wrote: >> >> >> Dear all, >> >> The open question is: What is the best textual encoding for Boolean >> values in flow records? >> >> Here are the alternatives discussed so far: >> >> 1. true: "1", false: "0" >> Pro: very common, used by several programming languages, >> international (not language-specific) >> Con: 0 may be misinterpreted as "don't know" >> >> 2. true: "true", false: "false" >> Pro: very common, unambiguous, used by several programming >> languages, >> Con: not international: English language-specific >> >> 3. true:"1", false: "2" >> Pro: in line with SMI encoding for Booleans >> Con: unknown outside of SNMP community. Not intuitively clear >> which is true and which is false >> >> 4. true: "t"*, false: "f"* >> Con: may be confusing or misleading. >> >> Writing now as technical contributor, I would eliminate option #4 >> because I do not see any advantage of this alternative. #3 has only a weak >> "pro" being used by SMI. Thus, we should either choose #1 or #2. Here, I >> would go for #1 because it is not language-specific. >> >> Cheers, >> Juergen >> >> >> >> >> >> -----Original Message----- >> From: IPFIX [mailto:ipfix-bounces@ietf.org] On Behalf Of >> Paul Aitken >> Sent: Dienstag, 11. Februar 2014 22:32 >> To: Brian Trammell >> Cc: IPFIX Working Group >> Subject: Re: [IPFIX] Fwd: New Version Notification for draft- >> ietf-ipfix-text- >> adt-01.txt >> >> Brian, >> >> Aside from the fact that this is English-specific, it works for >> me. >> >> P. >> >> >> >> Aside from the fact that these aren't case-insensitive >> (which at least causes >> >> an error as opposed to a non-detected incorrect acceptance), >> I'd say we >> could combine these: >> >> >> true = ('t' | 'T') 0*ALPHA >> >> false = ('f' | 'F') 0*ALPHA >> >> i.e., the decoder only looks at the first letter for [tT] >> or [fF], probably with a >> >> note that "true" and "false" are the preferred encodings. >> >> >> >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix >> From nobody Thu Feb 27 01:11:45 2014 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF11C1A066A for ; Thu, 27 Feb 2014 01:03:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.747 X-Spam-Level: X-Spam-Status: No, score=-6.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547] 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 daYP23DSPjZ1 for ; Thu, 27 Feb 2014 01:03:29 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 9F44C1A0061 for ; Thu, 27 Feb 2014 01:03:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 3ED0ED9307; Thu, 27 Feb 2014 10:03:26 +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 yiqNKt-2WVWj; Thu, 27 Feb 2014 10:03:26 +0100 (MET) 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 81233D9305; Thu, 27 Feb 2014 10:03:25 +0100 (MET) Content-Type: multipart/signed; boundary="Apple-Mail=_874EAC9E-244F-48BA-B30E-316CAAC9C275"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Brian Trammell In-Reply-To: <530EFBEF.309@cisco.com> Date: Thu, 27 Feb 2014 10:03:24 +0100 Message-Id: <21E20909-3A1B-4420-9130-005E38D7D551@tik.ee.ethz.ch> References: <9AB93E4127C26F4BA7829DEFDCE5A6E877A6B701@PALLENE.office.hd> <530DC67C.70104@cisco.com> <9AB93E4127C26F4BA7829DEFDCE5A6E877A6CD74@PALLENE.office.hd> <530EFBEF.309@cisco.com> To: Paul Aitken X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/K73MtaHtKr8GvH1wgLMcEzwYvec X-Mailman-Approved-At: Thu, 27 Feb 2014 01:11:41 -0800 Cc: IPFIX Working Group Subject: Re: [IPFIX] Encoding of Boolean values in draft-ietf-ipfix-text-adt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2014 09:03:32 -0000 --Apple-Mail=_874EAC9E-244F-48BA-B30E-316CAAC9C275 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Paul, Juergen, I'm okay with this. We can simply leave it unstated and up to reader = implementers as to how much they want to follow the principle of liberal = acceptance. Cheers, Brian On 27 Feb 2014, at 09:48, Paul Aitken wrote: > Juergen, >=20 > Since there's potential for the 1/2 and "1"/"0" encodings to be = confused, and since this is by definition a textual encoding, I'd prefer = option 2 ("true", "false"). >=20 > P. >=20 >=20 > On 27/02/2014 08:42, Juergen Quittek wrote: >> Hi Paul, >>=20 >> You are right. It is another pro for the true=3D"1" and false=3D"2" = encoding that it is in line with RFC 7011. Thank you for pointing out = this issue and sorry for not having this in my previous email. For = developers it would be a step of convenience to have encodings in line = and use the one from SMI and RFC7011. >>=20 >> However, the textual representation addresses a larger community than = just implementers. The textual representation is something that will be = particularly interesting to people not very familiar with IPFIX encoding = details. Here I think that the 1-2 encoding should not be used, because = of its high potential to be not understood or misunderstood. >>=20 >> Cheers, >> Juergen >>=20 >>> -----Original Message----- >>> From: Paul Aitken [mailto:paitken@cisco.com] >>> Sent: Mittwoch, 26. Februar 2014 11:48 >>> To: Juergen Quittek; Brian Trammell >>> Cc: IPFIX Working Group >>> Subject: Re: Encoding of Boolean values in draft-ietf-ipfix-text-adt >>>=20 >>> Juergen, >>>=20 >>> The values in option 1 conflict with the RFC 7011 (IPFIX Protocol) = boolean >>> encoding definition, which says: >>>=20 >>>=20 >>> 6.1.5. boolean >>>=20 >>> The boolean data type is specified according to the TruthValue in >>> [RFC2579]. It is encoded as a single-octet integer per >>> Section 6.1.1, with the value 1 for true and value 2 for false. >>> Every other value is undefined. >>>=20 >>> Option 3 provides the benefits of consistency with RFC 7011, and no >>> conversion required between the RFC 7011 and text-adt formats. >>>=20 >>> Expressed another way: the IPFIX WG group already decided the = boolean >>> encoding. Although we might not like that definition now, we should >>> consistently use the same encoding across all the IPFIX RFCs. >>>=20 >>> P. >>>=20 >>>=20 >>> On 26/02/2014 10:18, Juergen Quittek wrote: >>>=20 >>>=20 >>> Dear all, >>>=20 >>> The open question is: What is the best textual encoding for = Boolean >>> values in flow records? >>>=20 >>> Here are the alternatives discussed so far: >>>=20 >>> 1. true: "1", false: "0" >>> Pro: very common, used by several programming languages, >>> international (not language-specific) >>> Con: 0 may be misinterpreted as "don't know" >>>=20 >>> 2. true: "true", false: "false" >>> Pro: very common, unambiguous, used by several programming >>> languages, >>> Con: not international: English language-specific >>>=20 >>> 3. true:"1", false: "2" >>> Pro: in line with SMI encoding for Booleans >>> Con: unknown outside of SNMP community. Not intuitively clear >>> which is true and which is false >>>=20 >>> 4. true: "t"*, false: "f"* >>> Con: may be confusing or misleading. >>>=20 >>> Writing now as technical contributor, I would eliminate option = #4 >>> because I do not see any advantage of this alternative. #3 has only = a weak >>> "pro" being used by SMI. Thus, we should either choose #1 or #2. = Here, I >>> would go for #1 because it is not language-specific. >>>=20 >>> Cheers, >>> Juergen >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> -----Original Message----- >>> From: IPFIX [mailto:ipfix-bounces@ietf.org] On Behalf Of >>> Paul Aitken >>> Sent: Dienstag, 11. Februar 2014 22:32 >>> To: Brian Trammell >>> Cc: IPFIX Working Group >>> Subject: Re: [IPFIX] Fwd: New Version Notification for = draft- >>> ietf-ipfix-text- >>> adt-01.txt >>>=20 >>> Brian, >>>=20 >>> Aside from the fact that this is English-specific, it = works for >>> me. >>>=20 >>> P. >>>=20 >>>=20 >>>=20 >>> Aside from the fact that these aren't = case-insensitive >>> (which at least causes >>>=20 >>> an error as opposed to a non-detected incorrect = acceptance), >>> I'd say we >>> could combine these: >>>=20 >>>=20 >>> true =3D ('t' | 'T') 0*ALPHA >>>=20 >>> false =3D ('f' | 'F') 0*ALPHA >>>=20 >>> i.e., the decoder only looks at the first letter = for [tT] >>> or [fF], probably with a >>>=20 >>> note that "true" and "false" are the preferred = encodings. >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> IPFIX mailing list >>> IPFIX@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipfix >>>=20 >=20 > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix --Apple-Mail=_874EAC9E-244F-48BA-B30E-316CAAC9C275 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 iQEcBAEBCgAGBQJTDv9cAAoJENt3nsOmbNJcxm4IAJ37ZB7Ir3XneThrr3VpbEj/ LdXPdTjAkrTFUey0AcpnxV9FXwl7a4x9Z8v9bxh/hEiYks/odKOg96ZdDUNmwpp6 i11fYep56lzPiCRu01c3eTpcFYT/UTJkX3v1orCs4FsxrinzFBEe7P94W8PswkAT 9q4Qq2SIWX/X6OCAQi9uZN4Chtmfb7T0m1J6oFDqjWYSYeMW3OqkPx33W28+6CA1 SMbBgYnUY8B5lWLx7C+5R1yReSxgw3qSYwkKKjnkDJis10fnGlD7ddZ059dTu1Av VVyVhGNNbS6xLHWI/GyKszNsmzEfyl79TaLKcovVVEUJ7USxWAK7RFTTFKxIyNY= =uQAD -----END PGP SIGNATURE----- --Apple-Mail=_874EAC9E-244F-48BA-B30E-316CAAC9C275--