From nobody Sat Mar 1 06:52:57 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 B933E1A0E7F for ; Sat, 1 Mar 2014 06:52:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.749 X-Spam-Level: X-Spam-Status: No, score=-3.749 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 9q2OOD-rWplA for ; Sat, 1 Mar 2014 06:52:52 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 024021A0E88 for ; Sat, 1 Mar 2014 06:52:52 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 8A47A106EF4; Sat, 1 Mar 2014 15:52:49 +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 vGRTI85dqrAj; Sat, 1 Mar 2014 15:52:49 +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 6B350106EF2; Sat, 1 Mar 2014 15:52:34 +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; Sat, 1 Mar 2014 15:52:34 +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//+KlTCAAeZPgP/8ZkDg Date: Sat, 1 Mar 2014 14:52:34 +0000 Message-ID: <9AB93E4127C26F4BA7829DEFDCE5A6E877A6FAA6@PALLENE.office.hd> References: <9AB93E4127C26F4BA7829DEFDCE5A6E877A6B701@PALLENE.office.hd> <530DC67C.70104@cisco.com> <9AB93E4127C26F4BA7829DEFDCE5A6E877A6CD74@PALLENE.office.hd> <530EFBEF.309@cisco.com> In-Reply-To: <530EFBEF.309@cisco.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.0.208] 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/Bp46bPkHMzyKCO5p-KJvpk4AQPc 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: Sat, 01 Mar 2014 14:52:55 -0000 Hi Paul, > -----Original Message----- > From: Paul Aitken [mailto:paitken@cisco.com] > Sent: Donnerstag, 27. Februar 2014 09:49 > To: Juergen Quittek; Brian Trammell > Cc: IPFIX Working Group > Subject: Re: Encoding of Boolean values in draft-ietf-ipfix-text-adt >=20 > Juergen, >=20 > Since there's potential for the 1/2 and "1"/"0" encodings to be confused,= and How could they get confused?=20 A "1" means true in both encodings. Cheers, Juergen > since this is by definition a textual encoding, I'd prefer option 2 ("tru= e", > "false"). >=20 > P. >=20 >=20 > On 27/02/2014 08:42, Juergen Quittek wrote: > > Hi Paul, > > > > You are right. It is another pro for the true=3D"1" and false=3D"2" enc= oding that > it is in line with RFC 7011. Thank you for pointing out this issue and so= rry 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 hig= h > 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 =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. > >> > >> > >> > >> _______________________________________________ > >> IPFIX mailing list > >> IPFIX@ietf.org > >> https://www.ietf.org/mailman/listinfo/ipfix > >> From nobody Sat Mar 1 06:53: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 44F831A0E81 for ; Sat, 1 Mar 2014 06:52:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.749 X-Spam-Level: X-Spam-Status: No, score=-3.749 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 sepnr-ehlySF for ; Sat, 1 Mar 2014 06:52:52 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 63C741A0E7E for ; Sat, 1 Mar 2014 06:52:52 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id E8662106EF2; Sat, 1 Mar 2014 15:52:49 +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 gmwtbu+6v0un; Sat, 1 Mar 2014 15:52:49 +0100 (CET) X-ENC: Last-Hop-TLS-encrypted X-ENC: Last-Hop-TLS-encrypted Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailer1.neclab.eu (Postfix) with ESMTPS id C9899106EF3; Sat, 1 Mar 2014 15:52:34 +0100 (CET) Received: from PALLENE.office.hd ([169.254.1.233]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Sat, 1 Mar 2014 15:52:34 +0100 From: Juergen Quittek To: Brian Trammell , Paul Aitken Thread-Topic: [IPFIX] Encoding of Boolean values in draft-ietf-ipfix-text-adt Thread-Index: Ac8y3B45n91/HcdQS/mF+FP3WFGALv//95AA//+KlTCAAfs3ff/8ep0g Date: Sat, 1 Mar 2014 14:52:34 +0000 Message-ID: <9AB93E4127C26F4BA7829DEFDCE5A6E877A6FAAB@PALLENE.office.hd> References: <9AB93E4127C26F4BA7829DEFDCE5A6E877A6B701@PALLENE.office.hd> <530DC67C.70104@cisco.com> <9AB93E4127C26F4BA7829DEFDCE5A6E877A6CD74@PALLENE.office.hd> <530EFBEF.309@cisco.com> <21E20909-3A1B-4420-9130-005E38D7D551@tik.ee.ethz.ch> In-Reply-To: <21E20909-3A1B-4420-9130-005E38D7D551@tik.ee.ethz.ch> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.0.208] 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/YWQ6SFx2NO2s_-KoH9DRiX0YKZk 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: Sat, 01 Mar 2014 14:52:56 -0000 Hi Brian, What do you mean with "leaving it unstated"? Not fixing the textual encoding? Cheers, Juergen > -----Original Message----- > From: Brian Trammell [mailto:trammell@tik.ee.ethz.ch] > Sent: Donnerstag, 27. Februar 2014 10:03 > To: Paul Aitken > Cc: Juergen Quittek; IPFIX Working Group > Subject: Re: [IPFIX] Encoding of Boolean values in draft-ietf-ipfix-text-= adt >=20 > Paul, Juergen, >=20 > 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. >=20 > Cheers, >=20 > Brian >=20 > On 27 Feb 2014, at 09:48, Paul Aitken wrote: >=20 > > Juergen, > > > > Since there's potential for the 1/2 and "1"/"0" encodings to be confuse= d, > 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=3D"1" and false=3D"2" en= coding > 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 s= tep 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 hig= h > 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 =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. > >>> > >>> > >>> > >>> _______________________________________________ > >>> IPFIX mailing list > >>> IPFIX@ietf.org > >>> https://www.ietf.org/mailman/listinfo/ipfix > >>> > > > > _______________________________________________ > > IPFIX mailing list > > IPFIX@ietf.org > > https://www.ietf.org/mailman/listinfo/ipfix From nobody Sat Mar 1 07:11:42 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 622331A906E for ; Sat, 1 Mar 2014 07:11:41 -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 4cthkZ5czhmW for ; Sat, 1 Mar 2014 07:11:38 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id EFE311A906D for ; Sat, 1 Mar 2014 07:11:37 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id BCC7ED9302; Sat, 1 Mar 2014 16:11:34 +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 s2JE4DPKFpXM; Sat, 1 Mar 2014 16:11:34 +0100 (MET) Received: from [10.100.50.232] (unknown [158.230.100.10]) (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 0B829D9300; Sat, 1 Mar 2014 16:11:33 +0100 (MET) Content-Type: multipart/signed; boundary="Apple-Mail=_04FF6B0C-7AED-477D-8215-85B79D3FA059"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Brian Trammell In-Reply-To: <9AB93E4127C26F4BA7829DEFDCE5A6E877A6FAAB@PALLENE.office.hd> Date: Sat, 1 Mar 2014 15:11:32 +0000 Message-Id: References: <9AB93E4127C26F4BA7829DEFDCE5A6E877A6B701@PALLENE.office.hd> <530DC67C.70104@cisco.com> <9AB93E4127C26F4BA7829DEFDCE5A6E877A6CD74@PALLENE.office.hd> <530EFBEF.309@cisco.com> <21E20909-3A1B-4420-9130-005E38D7D551@tik.ee.ethz.ch> <9AB93E4127C26F4BA7829DEFDCE5A6E877A6FAAB@PALLENE.office.hd> To: Juergen Quittek X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/m1AvYnYUUxBH7P9u7jXbNs8zzP0 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: Sat, 01 Mar 2014 15:11:41 -0000 --Apple-Mail=_04FF6B0C-7AED-477D-8215-85B79D3FA059 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii hi Juergen, no, I mean, if a collector wants to try and interpret "t" as "true", = then we leave that up to the certificate, and don't specify anything = helpful in the document. Cheers, Brian On 1 Mar 2014, at 14:52, Juergen Quittek wrote: > Hi Brian, > What do you mean with "leaving it unstated"? > Not fixing the textual encoding? > Cheers, > Juergen >=20 >> -----Original Message----- >> From: Brian Trammell [mailto:trammell@tik.ee.ethz.ch] >> Sent: Donnerstag, 27. Februar 2014 10:03 >> To: Paul Aitken >> Cc: Juergen Quittek; IPFIX Working Group >> Subject: Re: [IPFIX] Encoding of Boolean values in = draft-ietf-ipfix-text-adt >>=20 >> Paul, Juergen, >>=20 >> 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. >>=20 >> Cheers, >>=20 >> Brian >>=20 >> On 27 Feb 2014, at 09:48, Paul Aitken wrote: >>=20 >>> 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=_04FF6B0C-7AED-477D-8215-85B79D3FA059 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 iQEcBAEBCgAGBQJTEfikAAoJENt3nsOmbNJcjDkH/23997pF3wgUsFrN1RKHiDdf KY7HGFpsul4m5FqitPEexTr9YgvCjiRIJt+yOcK2foYE6xqLYi+qQj0YeEHKSD6N 43g3UUuBMxGSLIBHNpW9LMXpqnWB0H/3gBO7eE5pwqaa+P2wrl0bPyqLWAEEcrfB 8nG8eLDYL6WJ/ns1bvuJdBV2H/hZqXIwNYUFjD0fzzP3wxgqlSVzZ/lfq4ic/m5j ZrxWz+ltMdW7q46GaNH34/BvK42XJTIodpfinIjH95LAedhPVGuT1qjphJEid/g4 0bXNcEA7Z3aZ3ttl+waXPy5kPzP0htPymUQZF5W3WmfRpzqIKAsdbk1Ic7M2MT4= =+/q3 -----END PGP SIGNATURE----- --Apple-Mail=_04FF6B0C-7AED-477D-8215-85B79D3FA059-- From nobody Sat Mar 1 09:12: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 2FF181A024F for ; Sat, 1 Mar 2014 09:12:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 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.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 J1ctCQeVaa9N for ; Sat, 1 Mar 2014 09:12:51 -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 490011A0131 for ; Sat, 1 Mar 2014 09:12:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=436; q=dns/txt; s=iport; t=1393693969; x=1394903569; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=6ES5PZIo1yW0bUy9Q4cyvn9arifP/oBm8E8YrhLyFKs=; b=ADcMkm++MSneQ/YTqrFtXxn9WmN/Nl6M46EhKMSx8zWCMXWpOAsYUZbZ fnDls2QO7Xh1gpYN6fvtoxnkrZaJE8o2ndWeHGGCyVAPuADFfgbfNhTKG TYy5Wb6sC92DK8YXfdiqA1NgDAkQdxojPFhEGLzYgYu7iQU/ZKhWM+nFn s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFAJsUElOQ/khR/2dsb2JhbABagwbCMYETFnSCJQEBAQMBOEABEAshFg8JAwIBAgFFBgEMAQcBAYdtCMwRF45ZB4Q4AQOYPIZKi2GDLQ X-IronPort-AV: E=Sophos;i="4.97,568,1389744000"; d="scan'208";a="5977038" Received: from ams-core-1.cisco.com ([144.254.72.81]) by aer-iport-2.cisco.com with ESMTP; 01 Mar 2014 17:12:47 +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 s21HClK1012976 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 1 Mar 2014 17:12:47 GMT Received: from [10.61.105.140] (dhcp-10-61-105-140.cisco.com [10.61.105.140]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id s21HCjsQ013927; Sat, 1 Mar 2014 17:12:46 GMT Message-ID: <53121590.2050101@cisco.com> Date: Sat, 01 Mar 2014 17:14:56 +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> <530EFBEF.309@cisco.com> <9AB93E4127C26F4BA7829DEFDCE5A6E877A6FAA6@PALLENE.office.hd> In-Reply-To: <9AB93E4127C26F4BA7829DEFDCE5A6E877A6FAA6@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/m_34OC_fA8jh-rHIWbNqq7fjibo 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: Sat, 01 Mar 2014 17:12:53 -0000 Juergen, >> Since there's potential for the 1/2 and "1"/"0" encodings to be confused, and > How could they get confused? > A "1" means true in both encodings. No: as Brian pointed out, in one case it's the value 0x01 while in the other it's the value 0x31 (the ASCII code for a textual "1"). Given that so few of us noticed this suggests that it's a bad idea. Also, what value means false? It's just too unclear. P. From nobody Sun Mar 2 05:00:36 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 4EAC31A0D1A; Sun, 2 Mar 2014 05:00:34 -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_00=-1.9, 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 Mvikh6p5bo0M; Sun, 2 Mar 2014 05:00:32 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2607:f170:8000:1500::d3]) by ietfa.amsl.com (Postfix) with ESMTP id 377DC1A0D14; Sun, 2 Mar 2014 05:00:32 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id B76E37FC393; Sun, 2 Mar 2014 05:00:24 -0800 (PST) To: stbryant@cisco.com, bclaise@cisco.com, trammell@tik.ee.ethz.ch From: RFC Errata System Message-Id: <20140302130026.B76E37FC393@rfc-editor.org> Date: Sun, 2 Mar 2014 05:00:24 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/D-Xx8-faED4LNtqC6yNZ80CHtTY Cc: iesg@ietf.org, ipfix@ietf.org, rfc-editor@rfc-editor.org Subject: [IPFIX] [Errata Rejected] 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: Sun, 02 Mar 2014 13:00:34 -0000 The following errata report has been rejected 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=3852 -------------------------------------- Status: Rejected Type: Technical Reported by: Stewart Bryant Date Reported: 2013-12-30 Rejected by: Benoit Claise (IESG) Section: 3.1.15-17 Original Text ------------- 3.1.15. dateTimeSeconds The type "dateTimeSeconds" represents a time value expressed with second-level precision. 3.1.16. dateTimeMilliseconds The type "dateTimeMilliseconds" represents a time value expressed with millisecond-level precision. 3.1.17. dateTimeMicroseconds The type "dateTimeMicroseconds" represents a time value expressed with microsecond-level precision. 3.1.18. dateTimeNanoseconds The type "dateTimeNanoseconds" represents a time value expressed with nanosecond-level precision. Corrected Text -------------- 3.1.15. dateTimeSeconds 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. 3.1.16. dateTimeMilliseconds 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. 3.1.17. dateTimeMicroseconds 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. 3.1.18. dateTimeNanoseconds 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. 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. Without a specified epoch, there is no unique definition of the timestamps. 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. --VERIFIER NOTES-- Reject reason: issue addressed in errata 3881 -------------------------------------- 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 nobody Sun Mar 2 05:10: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 E664D1A0CC8; Sun, 2 Mar 2014 05:10:53 -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_00=-1.9, 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 k3WuG2E2TfoV; Sun, 2 Mar 2014 05:10:42 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2607:f170:8000:1500::d3]) by ietfa.amsl.com (Postfix) with ESMTP id 5E65E1A0CE2; Sun, 2 Mar 2014 05:10:42 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id DE1F57FC39E; Sun, 2 Mar 2014 05:10:39 -0800 (PST) To: trammell@tik.ee.ethz.ch, bclaise@cisco.com, trammell@tik.ee.ethz.ch From: RFC Errata System Message-Id: <20140302131039.DE1F57FC39E@rfc-editor.org> Date: Sun, 2 Mar 2014 05:10:39 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/TzHKzcZiZf8kygPBv6jsKnoNdFM Cc: iesg@ietf.org, ipfix@ietf.org, rfc-editor@rfc-editor.org Subject: [IPFIX] [Errata Verified] 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: Sun, 02 Mar 2014 13:10:54 -0000 The following errata report has been verified 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 -------------------------------------- Status: Verified Type: Technical Reported by: Brian Trammell Date Reported: 2014-02-05 Verified by: Benoit Claise (IESG) 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. -------------------------------------- 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 nobody Mon Mar 3 03:31:47 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 829681A0007; Mon, 3 Mar 2014 03:31:44 -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 XQK-LOFOob-v; Mon, 3 Mar 2014 03:31:43 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D6461A0005; Mon, 3 Mar 2014 03:31:43 -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.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140303113143.22375.5426.idtracker@ietfa.amsl.com> Date: Mon, 03 Mar 2014 03:31:43 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/_R9c1ZsXyl3byEN7CM-OxpsXH_M Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action: draft-ietf-ipfix-text-adt-02.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: Mon, 03 Mar 2014 11:31:44 -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-02.txt Pages : 13 Date : 2014-03-03 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-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-ipfix-text-adt-02 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 Mon Mar 3 03:34: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 3904F1A0040 for ; Mon, 3 Mar 2014 03:34:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vkc5IIj7TGMl for ; Mon, 3 Mar 2014 03:34:34 -0800 (PST) Received: from trammell.ch (trammell1.nine.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 8F0201A003D for ; Mon, 3 Mar 2014 03:34:33 -0800 (PST) Received: from dhcp-9fd0.meeting.ietf.org (dhcp-9fd0.meeting.ietf.org [31.133.159.208]) by trammell.ch (Postfix) with ESMTPSA id 5F0541A096D for ; Mon, 3 Mar 2014 12:34:30 +0100 (CET) From: Brian Trammell Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 3 Mar 2014 11:34:29 +0000 References: <20140303113143.22375.5426.idtracker@ietfa.amsl.com> To: "ipfix@ietf.org 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/gfDYyzg_gOSS5MwSgh7N30Fimmc Subject: [IPFIX] Fwd: I-D Action: draft-ietf-ipfix-text-adt-02.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, 03 Mar 2014 11:34:36 -0000 Greetings, all, This revision includes the "true"/"false solution for booleans, and = draft fixes to the floating-point concerns raised in WGLC. Cheers, Brian Begin forwarded message: > From: internet-drafts@ietf.org > Subject: [IPFIX] I-D Action: draft-ietf-ipfix-text-adt-02.txt > Date: 3 March 2014 11:31:43 GMT > To: i-d-announce@ietf.org > Cc: ipfix@ietf.org >=20 >=20 > 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. >=20 > Title : Textual Representation of IPFIX Abstract Data = Types > Author : Brian Trammell > Filename : draft-ietf-ipfix-text-adt-02.txt > Pages : 13 > Date : 2014-03-03 >=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 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ipfix-text-adt/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-ipfix-text-adt-02 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipfix-text-adt-02 >=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 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From nobody Mon Mar 3 03:59:06 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 39DF31A0053 for ; Mon, 3 Mar 2014 03:42:27 -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 Fe4CNbLzKMzj for ; Mon, 3 Mar 2014 03:42:25 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 53F401A000E for ; Mon, 3 Mar 2014 03:42:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 83902D930A; Mon, 3 Mar 2014 12:42:21 +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 wZKF6EBohgvJ; Mon, 3 Mar 2014 12:42:21 +0100 (MET) Received: from [82.130.103.8] (nb-10245.ethz.ch [82.130.103.8]) (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 482A8D9309; Mon, 3 Mar 2014 12:42:21 +0100 (MET) Message-ID: <53146A9D.8060007@tik.ee.ethz.ch> Date: Mon, 03 Mar 2014 12:42:21 +0100 From: Stephan Neuhaus User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Brian Trammell References: <20140120125443.14390.21012.idtracker@ietfa.amsl.com> <530B9FBA.6020905@tik.ee.ethz.ch> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/I3Wzg5wYbuhqPJIIa0DsDoVT-2E X-Mailman-Approved-At: Mon, 03 Mar 2014 03:59:05 -0800 Cc: "ipfix@ietf.org Group" 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, 03 Mar 2014 11:42:27 -0000 On 03/03/2014 09:47 AM, Brian Trammell wrote: > hi Stephan, > > Thanks for your comments; comments^2 inline... Hi Brian, thanks for your comments^2. I can live with all of your proposed changes. Many of the issues with reconstructability of bit patterns (a.k.a. "keeping precision") could be solved with a "guide to implementers". Do such things exist for RFCs? Best regards, Stephan From nobody Mon Mar 3 10:14: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 810AD1A003B for ; Mon, 3 Mar 2014 10:14:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.149 X-Spam-Level: X-Spam-Status: No, score=-3.149 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 P7lEh5QKmQsK for ; Mon, 3 Mar 2014 10:14:01 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id E2BB41A0233 for ; Mon, 3 Mar 2014 10:13:26 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id B4F34106F4C; Mon, 3 Mar 2014 19:13:23 +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 ELRLyQR5bjLO; Mon, 3 Mar 2014 19:13:23 +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 94FDF106F4B; Mon, 3 Mar 2014 19:13:13 +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; Mon, 3 Mar 2014 19:12:52 +0100 From: Juergen Quittek To: Brian Trammell , "ipfix@ietf.org Group" Thread-Topic: [IPFIX] Fwd: I-D Action: draft-ietf-ipfix-text-adt-02.txt Thread-Index: AQHPNtSkUaPB371310uwamJbXZ6D9prPqmYw Date: Mon, 3 Mar 2014 18:12:52 +0000 Message-ID: <9AB93E4127C26F4BA7829DEFDCE5A6E877A71B68@PALLENE.office.hd> References: <20140303113143.22375.5426.idtracker@ietfa.amsl.com> In-Reply-To: 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/wI2_U7oFLfx3Lg0z9-YhAGTehao Subject: Re: [IPFIX] Fwd: I-D Action: draft-ietf-ipfix-text-adt-02.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, 03 Mar 2014 18:14:04 -0000 Hi Brian, Does the new version address all issues raised at WGLC? Thanks, Juergen > -----Original Message----- > From: IPFIX [mailto:ipfix-bounces@ietf.org] On Behalf Of Brian Trammell > Sent: Montag, 3. M=E4rz 2014 12:34 > To: ipfix@ietf.org Group > Subject: [IPFIX] Fwd: I-D Action: draft-ietf-ipfix-text-adt-02.txt >=20 > Greetings, all, >=20 > This revision includes the "true"/"false solution for booleans, and draft= fixes > to the floating-point concerns raised in WGLC. >=20 > Cheers, >=20 > Brian >=20 > Begin forwarded message: >=20 > > From: internet-drafts@ietf.org > > Subject: [IPFIX] I-D Action: draft-ietf-ipfix-text-adt-02.txt > > Date: 3 March 2014 11:31:43 GMT > > To: i-d-announce@ietf.org > > Cc: ipfix@ietf.org > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the IP Flow Information Export Working Gro= up > of the IETF. > > > > Title : Textual Representation of IPFIX Abstract Data = Types > > Author : Brian Trammell > > Filename : draft-ietf-ipfix-text-adt-02.txt > > Pages : 13 > > Date : 2014-03-03 > > > > 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-02 > > > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipfix-text-adt-02 > > > > > > 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.i= etf.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 >=20 > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From nobody Mon Mar 3 10:21:36 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 0ED5E1A01FC for ; Mon, 3 Mar 2014 10:21:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oODfizmic0we for ; Mon, 3 Mar 2014 10:21:32 -0800 (PST) Received: from trammell.ch (trammell1.nine.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 694E91A0166 for ; Mon, 3 Mar 2014 10:21:32 -0800 (PST) Received: from dhcp-9fd0.meeting.ietf.org (dhcp-9fd0.meeting.ietf.org [31.133.159.208]) by trammell.ch (Postfix) with ESMTPSA id A2B541A0C0C; Mon, 3 Mar 2014 19:20:57 +0100 (CET) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Brian Trammell In-Reply-To: <9AB93E4127C26F4BA7829DEFDCE5A6E877A71B68@PALLENE.office.hd> Date: Mon, 3 Mar 2014 18:20:56 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140303113143.22375.5426.idtracker@ietfa.amsl.com> <9AB93E4127C26F4BA7829DEFDCE5A6E877A71B68@PALLENE.office.hd> To: Juergen Quittek X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/DZ5GyhSePfG3giTkGYDsk2EQo9s Cc: "ipfix@ietf.org Group" Subject: Re: [IPFIX] I-D Action: draft-ietf-ipfix-text-adt-02.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, 03 Mar 2014 18:21:35 -0000 hi Juergen, all, Yes, sorry; this version addresses all WGLC issues, and is in my opinion = ready for submission to the IESG. Cheers, Brian On 3 Mar 2014, at 18:12, Juergen Quittek wrote: > Hi Brian, > Does the new version address all issues raised at WGLC? > Thanks, > Juergen >=20 >> -----Original Message----- >> From: IPFIX [mailto:ipfix-bounces@ietf.org] On Behalf Of Brian = Trammell >> Sent: Montag, 3. M=E4rz 2014 12:34 >> To: ipfix@ietf.org Group >> Subject: [IPFIX] Fwd: I-D Action: draft-ietf-ipfix-text-adt-02.txt >>=20 >> Greetings, all, >>=20 >> This revision includes the "true"/"false solution for booleans, and = draft fixes >> to the floating-point concerns raised in WGLC. >>=20 >> Cheers, >>=20 >> Brian >>=20 >> Begin forwarded message: >>=20 >>> From: internet-drafts@ietf.org >>> Subject: [IPFIX] I-D Action: draft-ietf-ipfix-text-adt-02.txt >>> Date: 3 March 2014 11:31:43 GMT >>> To: i-d-announce@ietf.org >>> Cc: ipfix@ietf.org >>>=20 >>>=20 >>> 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. >>>=20 >>> Title : Textual Representation of IPFIX Abstract = Data Types >>> Author : Brian Trammell >>> Filename : draft-ietf-ipfix-text-adt-02.txt >>> Pages : 13 >>> Date : 2014-03-03 >>>=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 >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-ipfix-text-adt/ >>>=20 >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-ietf-ipfix-text-adt-02 >>>=20 >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipfix-text-adt-02 >>>=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 >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>>=20 >>> _______________________________________________ >>> IPFIX mailing list >>> 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 Tue Mar 4 06:43: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 996C31A0284; Tue, 4 Mar 2014 06:43:52 -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 uUfZ3p41ACu5; Tue, 4 Mar 2014 06:43:51 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 382D41A0152; Tue, 4 Mar 2014 06:43:51 -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.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140304144351.29299.78668.idtracker@ietfa.amsl.com> Date: Tue, 04 Mar 2014 06:43:51 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/dPOJME5T5aTlGYQLrTUhZgAV7O8 Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action: draft-ietf-ipfix-mib-variable-export-05.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, 04 Mar 2014 14:43:53 -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-05.txt Pages : 80 Date : 2014-03-04 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-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-ipfix-mib-variable-export-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Mar 4 08:40: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 ADDD71A01CD for ; Tue, 4 Mar 2014 08:40:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 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.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 ntSRbLR59O1l for ; Tue, 4 Mar 2014 08:40:23 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by ietfa.amsl.com (Postfix) with ESMTP id 70AE91A00F5 for ; Tue, 4 Mar 2014 08:40:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2918; q=dns/txt; s=iport; t=1393951220; x=1395160820; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=dyc2b8RGS7Ia/iirraxVuLE8s5lTRV0hh8kpNNTgb44=; b=KyKjtarw2FdN/LBeMGdTCfEWCFFc3w2mrYGZtbGoP1k/vvVrbzykt6Gx dpav56T4AvNwZUqusU1YBuuv0Jg2xIEMpDAC0K2U4EOfAoEPRcOhXJvTA g+K9sbSB14pp1SIWtwFMktVPChppubpa4WKdxzGT+5idQ+tI21BoZPumN k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApcFACcBFlOtJXG8/2dsb2JhbABagwY7UcBzgR0WdIIlAQEBBAEBATU2ChELEgYJFg8JAwIBAgEVIg4TBgIBAQWHcAgFzHMXjlgWhCIEmDyBMoUYi2GDLQ X-IronPort-AV: E=Sophos;i="4.97,585,1389744000"; d="scan'208";a="24837778" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by alln-iport-8.cisco.com with ESMTP; 04 Mar 2014 16:40:20 +0000 Received: from [144.254.153.26] (dhcp-144-254-153-26.cisco.com [144.254.153.26]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id s24GeIsL004525 for ; Tue, 4 Mar 2014 16:40:18 GMT Message-ID: <531601F1.7000909@cisco.com> Date: Tue, 04 Mar 2014 16:40:17 +0000 From: Colin McDowall 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: <20140304144351.29299.78668.idtracker@ietfa.amsl.com> In-Reply-To: <20140304144351.29299.78668.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/Ffg-2MhxSM-38aMZXVTa2ZrkKcU Subject: Re: [IPFIX] I-D Action: draft-ietf-ipfix-mib-variable-export-05.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, 04 Mar 2014 16:40:25 -0000 Hi All, This is the latest version of the IPFIX MIB Export Draft that should resolve all the open Todo items and review comments. The structure or the document is now much improved and the architecture clarified. The exporting of Sequence MIB Objects is now clear and unambiguous. While it is still possible to specify the index for an individual field, exporting using the mibObjectValueSequence structured data field is much simpler and efficient for sending a complete or partial table. The following are new examples added to the draft: 5.3. Exporting A Sequence Table: The OSPF Neighbor Sequence 5.4. Exporting Augmented Sequence Table: The IF-MIB id to name mapping 5.8. Exporting With Multiple Contexts: The OSPF Neighbor Sequence Revisited This draft also calls out that the exporting process might not have an underlying SNMP implementation or worry about indexing, and that the MIB Objects can be used purely as extra types for IPFIX. Thanks, colin On 04/03/2014 14:43, 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-05.txt > Pages : 80 > Date : 2014-03-04 > > 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-05 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-ipfix-mib-variable-export-05 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix >