From nobody Sun Aug 3 22:07: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 A9FCD1B2861; Sun, 3 Aug 2014 22:07:38 -0700 (PDT) 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 BcbJ4YhV3fR4; Sun, 3 Aug 2014 22:07:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 104DB1B2858; Sun, 3 Aug 2014 22:07:37 -0700 (PDT) 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.6.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140804050737.28858.12663.idtracker@ietfa.amsl.com> Date: Sun, 03 Aug 2014 22:07:37 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/UnBmdChTARSnJrz2eUga9CZT7Ns Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action: draft-ietf-ipfix-text-adt-08.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, 04 Aug 2014 05:07:39 -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-08.txt Pages : 13 Date : 2014-08-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-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-ipfix-text-adt-08 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 Aug 4 00:32:17 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 108181B2898 for ; Mon, 4 Aug 2014 00:32:16 -0700 (PDT) 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 RtpzDB5PJ-lU for ; Mon, 4 Aug 2014 00:32:13 -0700 (PDT) Received: from trammell.ch (trammell1.nine.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id B7CCA1B2856 for ; Mon, 4 Aug 2014 00:32:13 -0700 (PDT) Received: from [IPv6:2001:67c:10ec:2a49:8000::1008] (unknown [IPv6:2001:67c:10ec:2a49:8000::1008]) by trammell.ch (Postfix) with ESMTPSA id B51731A1910 for ; Mon, 4 Aug 2014 09:32:11 +0200 (CEST) From: Brian Trammell Content-Type: multipart/signed; boundary="Apple-Mail=_1B7B8BF4-08D5-406A-A88F-D00B369C17DD"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Mon, 4 Aug 2014 09:32:12 +0200 References: <20140804050737.28858.12663.idtracker@ietfa.amsl.com> To: "ipfix@ietf.org Group" Message-Id: <0CBA48F7-719E-482C-968C-10C00CF57882@trammell.ch> Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/Mpmj5mnxFpgcMk4ExAmnqcqkqwI Subject: [IPFIX] Fwd: I-D Action: draft-ietf-ipfix-text-adt-08.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, 04 Aug 2014 07:32:16 -0000 --Apple-Mail=_1B7B8BF4-08D5-406A-A88F-D00B369C17DD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Greetings, all, This revision addresses final IETF LC comments on extensibility and = copy/paste errors in the examples (thanks, Paul)! Best regards, Brian Begin forwarded message: > From: internet-drafts@ietf.org > Subject: [IPFIX] I-D Action: draft-ietf-ipfix-text-adt-08.txt > Date: 4 Aug 2014 07:07:37 GMT+2 > 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-08.txt > Pages : 13 > Date : 2014-08-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-08 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipfix-text-adt-08 >=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 --Apple-Mail=_1B7B8BF4-08D5-406A-A88F-D00B369C17DD 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 iQEcBAEBCgAGBQJT3zb8AAoJENt3nsOmbNJclEQH/0zgiIMOIrpFASSSoFYfms3Y k4pd7FMQotKZxfgkCO6Zr0tSEqLqjnEN75u70kbK0NzC8dHyhjbsxUKmBUZVy9en CfjZLu8vS6+XEkvCa+W2VYL6BxVFhY16Rcsq+Uq3TYirtzeVHG3t6j4/kScp601D rH2IDR7R5CkNzx2R36OO8uZryDAKeC2EekQv2E464pND99nGHdgEVHtDXOwVZ/HE tckFl6g9noYW4Ol0jsLv9JOUiAXlipFCqUQNXuUVhuFhDQDwV3mi683XyaMIjueL y97Ddt8Kr29iY9BteJ/xORXdMSXw0JH7+RbdjlWwmwLEsNQvgD4TgHRdN26H244= =XgVU -----END PGP SIGNATURE----- --Apple-Mail=_1B7B8BF4-08D5-406A-A88F-D00B369C17DD-- From nobody Mon Aug 4 01:04:37 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 7A8DE1B28B4 for ; Mon, 4 Aug 2014 01:04:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 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.001, 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 HvQpsFbzB0fC for ; Mon, 4 Aug 2014 01:04:34 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B3881B28B0 for ; Mon, 4 Aug 2014 01:04:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3081; q=dns/txt; s=iport; t=1407139473; x=1408349073; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=c7HZdlK4ZVsxVeqMDTl6Bl8uEC5YtjEi9TIYWhp0Or8=; b=P6FmxkRgW2oYldj0vVsqHVpzsR7i3lJ2C7dGKIm3OX6n/rhufkE5hYQx EFZhfJGs6BW9Ga+Jb4tCeTeJYJIyA4BBi1zLcNx8VeAIdt6ziYHbX0fxJ FxHsn5mze9sdKkVV0iLWkrMgwrLTYJtK3g4FRN3DnEsrn4MyYzCqoFQ/U 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAEANw931OtJssW/2dsb2JhbABb2CYBgS13hAQBAQMBeAYLCwQKExYPCQMCAQIBRQYBDAgBAYg2CMQ2F49ThEsBBJwGhyONPINOPA X-IronPort-AV: E=Sophos;i="5.01,796,1400025600"; d="scan'208,217";a="132498853" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 04 Aug 2014 08:04:31 +0000 Received: from [10.61.109.110] (dhcp-10-61-109-110.cisco.com [10.61.109.110]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s7484UaQ002134; Mon, 4 Aug 2014 08:04:31 GMT Message-ID: <53DF3E8E.5050905@cisco.com> Date: Mon, 04 Aug 2014 09:04:30 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Brian Trammell , "ipfix@ietf.org Group" References: <20140804050737.28858.12663.idtracker@ietfa.amsl.com> <0CBA48F7-719E-482C-968C-10C00CF57882@trammell.ch> In-Reply-To: <0CBA48F7-719E-482C-968C-10C00CF57882@trammell.ch> Content-Type: multipart/alternative; boundary="------------050800010208060007090609" Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/vDViNPKOVaafvaNVmi3bLgSs1Jg Subject: Re: [IPFIX] Fwd: I-D Action: draft-ietf-ipfix-text-adt-08.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, 04 Aug 2014 08:04:35 -0000 This is a multi-part message in MIME format. --------------050800010208060007090609 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Brian, > This revision addresses final IETF LC comments on extensibility and copy/paste errors in the examples (thanks, Paul)! You missed tcpControlBits: since it's defined as unsigned16 in [IANA], you should either use unsigned16 or explain why unsigned8 is being used (eg, say that reduced-size encoding is being used). Recall: >> And tcpControlBits: >> >> tcpControlBits(6)[1] >> >> - has been revised to unsigned16 [RFC7125]. Changing this would also make Figure 2 align more neatly. > > It'll probably still be exported as 1 byte everywhere, but the type is indeed unsigned16 > It would be useful to discuss reduced size encoding and show a specific example. eg, if I'm collecting ingressInterface which is nominally a u32, but I'm a small device so I only export a u8, should I export: ingressInterface(10)[1] or ingressInterface(10)[1] P. --------------050800010208060007090609 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Brian,

This revision addresses final IETF LC comments on extensibility and copy/paste errors in the examples (thanks, Paul)!

You missed tcpControlBits: since it's defined as unsigned16 in [IANA], you should either use unsigned16 or explain why unsigned8 is being used (eg, say that reduced-size encoding is being used).

Recall:

And tcpControlBits:

         tcpControlBits(6)<unsigned8>[1]

- has been revised to unsigned16 [RFC7125]. Changing this would also make Figure 2 align more neatly.


It'll probably still be exported as 1 byte everywhere, but the type is indeed unsigned16

It would be useful to discuss reduced size encoding and show a specific example. eg, if I'm collecting ingressInterface which is nominally a u32, but I'm a small device so I only export a u8, should I export:

ingressInterface(10)<unsigned32>[1]

or

ingressInterface(10)<unsigned8>[1]

P.
--------------050800010208060007090609-- From nobody Mon Aug 4 01:10: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 183CC1B28B2 for ; Mon, 4 Aug 2014 01:10:57 -0700 (PDT) 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 ZtYtppg7o7rE for ; Mon, 4 Aug 2014 01:10:51 -0700 (PDT) Received: from trammell.ch (trammell1.nine.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 0BCB61B288E for ; Mon, 4 Aug 2014 01:10:51 -0700 (PDT) Received: from pb-10243.ethz.ch (pb-10243.ethz.ch [82.130.102.152]) by trammell.ch (Postfix) with ESMTPSA id 289321A03F8; Mon, 4 Aug 2014 10:10:19 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_D501237D-3AEF-4692-9B45-16DB5D3B43AD"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Brian Trammell In-Reply-To: <53DF3E8E.5050905@cisco.com> Date: Mon, 4 Aug 2014 10:10:19 +0200 Message-Id: References: <20140804050737.28858.12663.idtracker@ietfa.amsl.com> <0CBA48F7-719E-482C-968C-10C00CF57882@trammell.ch> <53DF3E8E.5050905@cisco.com> To: Paul Aitken X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/7CUsFpNmzrHBeLCK-daRB7YXN6g Cc: "ipfix@ietf.org Group" Subject: Re: [IPFIX] I-D Action: draft-ietf-ipfix-text-adt-08.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, 04 Aug 2014 08:10:57 -0000 --Apple-Mail=_D501237D-3AEF-4692-9B45-16DB5D3B43AD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 04 Aug 2014, at 10:04, Paul Aitken wrote: > Brian, >=20 >> This revision addresses final IETF LC comments on extensibility and = copy/paste errors in the examples (thanks, Paul)! >=20 > You missed tcpControlBits: since it's defined as unsigned16 in [IANA], = you should either use unsigned16 or explain why unsigned8 is being used = (eg, say that reduced-size encoding is being used). >=20 > Recall: >=20 >>> And tcpControlBits: >>>=20 >>> tcpControlBits(6)[1] >>>=20 >>> - has been revised to unsigned16 [RFC7125]. Changing this would also = make Figure 2 align more neatly. Note that in a textual encoding, alignment is irrelevant. >> It'll probably still be exported as 1 byte everywhere, but the type = is indeed unsigned16 Ah, indeed. Rev -09 then. >=20 > It would be useful to discuss reduced size encoding and show a = specific example. eg, if I'm collecting ingressInterface which is = nominally a u32, but I'm a small device so I only export a u8, should I = export: >=20 > ingressInterface(10)[1] >=20 > or >=20 > ingressInterface(10)[1] This is an interesting question but it would not appear to be in scope = at all for this document.=20 Thanks, cheers, Brian --Apple-Mail=_D501237D-3AEF-4692-9B45-16DB5D3B43AD 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 iQEcBAEBCgAGBQJT3z/rAAoJENt3nsOmbNJccxEIAK1ozxPfJyT/mnj+wSo3g8rE ZIjZNjZiWcCkocz+U+u+8CtiArUNWwqe42vsony3NC68V44TWzPtdX5CfQW+BTbP nkdkYbhiHlIddbaEyoKonbD6U4OCdEkiHk0AExIn4oDtvojq4I8h38G9hrki0fo3 CHEHyZiFCncKqUgtwVTsV67Yq0WXWFoj/PDJZ2kmIgUpfLfWFN4JpmUBMAN+evw5 dLZ1hQV4ns3KIiskG/TIAP9vvwcZokVr1xXAVDSGqQkGFVmprQnCwu2AqcQGCHbN ayD5oFVPc1nSsgqiJtcxfUrBasq7PQU3sHvBwI5eCax4k1WJtMBz6SEh02ttDTk= =k9ma -----END PGP SIGNATURE----- --Apple-Mail=_D501237D-3AEF-4692-9B45-16DB5D3B43AD-- From nobody Mon Aug 4 01:14:17 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 EDC6D1B28C1; Mon, 4 Aug 2014 01:14:12 -0700 (PDT) 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 Z8uDqPU3vKFO; Mon, 4 Aug 2014 01:14:11 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 71EB41B28AE; Mon, 4 Aug 2014 01:14:11 -0700 (PDT) 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.6.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140804081411.27946.50342.idtracker@ietfa.amsl.com> Date: Mon, 04 Aug 2014 01:14:11 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/GT-4uYQ1B0Yl3jPoe3y6Qm4tmXQ Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action: draft-ietf-ipfix-text-adt-09.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, 04 Aug 2014 08:14:13 -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-09.txt Pages : 13 Date : 2014-08-04 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-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-ipfix-text-adt-09 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 Aug 4 01:22: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 373161B28B2 for ; Mon, 4 Aug 2014 01:22:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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.001, 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 fY0ZE4_5FLF7 for ; Mon, 4 Aug 2014 01:21:58 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F6671B28AE for ; Mon, 4 Aug 2014 01:21:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1395; q=dns/txt; s=iport; t=1407140518; x=1408350118; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=q/fgG+hCcM3zFGRUMF58sycE15YfeQ5CF+TcI8oWZoU=; b=IMOcNwLHRGSd+d0NmXRdIGcBnbs47MgJ+o2Be9syyuZqdE8gkujDXtjq XU3XCa9lMHATHPMGA7XPhQkQTDwUWzIkjqj2taCdkJZYH8SiB3+v7dV59 OEje6+BsweQbXIUtzTYeiODaNKUPFSjkriUrWHbC6Iddrnn6zWXdgsDa/ E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqoEAJZB31OtJssW/2dsb2JhbABbhDbTcAGBLXeEAwEBAQMBOEABBQsLDgoJFg8JAwIBAgFFBg0BBQIBAYg2CMRCF45qEQFQB4RLAQScBocjjTyDTjwvgQ0 X-IronPort-AV: E=Sophos;i="5.01,796,1400025600"; d="scan'208";a="131859186" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 04 Aug 2014 08:21:56 +0000 Received: from [10.61.109.110] (dhcp-10-61-109-110.cisco.com [10.61.109.110]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s748Lup8008217; Mon, 4 Aug 2014 08:21:56 GMT Message-ID: <53DF42A4.1090506@cisco.com> Date: Mon, 04 Aug 2014 09:21:56 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Brian Trammell References: <20140804050737.28858.12663.idtracker@ietfa.amsl.com> <0CBA48F7-719E-482C-968C-10C00CF57882@trammell.ch> <53DF3E8E.5050905@cisco.com> 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/9x87R0NXwyHgEGYts48J5DXfruA Cc: "ipfix@ietf.org Group" Subject: Re: [IPFIX] I-D Action: draft-ietf-ipfix-text-adt-08.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, 04 Aug 2014 08:22:01 -0000 Brian, > On 04 Aug 2014, at 10:04, Paul Aitken wrote: > >> Brian, >> >>> This revision addresses final IETF LC comments on extensibility and copy/paste errors in the examples (thanks, Paul)! >> You missed tcpControlBits: since it's defined as unsigned16 in [IANA], you should either use unsigned16 or explain why unsigned8 is being used (eg, say that reduced-size encoding is being used). >> >> Recall: >> >>>> And tcpControlBits: >>>> >>>> tcpControlBits(6)[1] >>>> >>>> - has been revised to unsigned16 [RFC7125]. Changing this would also make Figure 2 align more neatly. > Note that in a textual encoding, alignment is irrelevant. That was cut-n-paste from an earlier email. I can't immediately see what it was referring to. >>> It'll probably still be exported as 1 byte everywhere, but the type is indeed unsigned16 > Ah, indeed. Rev -09 then. > >> It would be useful to discuss reduced size encoding and show a specific example. eg, if I'm collecting ingressInterface which is nominally a u32, but I'm a small device so I only export a u8, should I export: >> >> ingressInterface(10)[1] >> >> or >> >> ingressInterface(10)[1] > This is an interesting question but it would not appear to be in scope at all for this document. Where would such a clarification be given if not here? P. From nobody Mon Aug 4 01:27:34 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 F15F01B28B6 for ; Mon, 4 Aug 2014 01:27:32 -0700 (PDT) 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 nN87phrqpfYb for ; Mon, 4 Aug 2014 01:27:31 -0700 (PDT) Received: from trammell.ch (trammell1.nine.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 707D31B28BB for ; Mon, 4 Aug 2014 01:27:30 -0700 (PDT) Received: from pb-10243.ethz.ch (pb-10243.ethz.ch [82.130.102.152]) by trammell.ch (Postfix) with ESMTPSA id C06EB1A04A2; Mon, 4 Aug 2014 10:26:59 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_F0940FEE-148E-42BB-BAF2-99DD8987C42B"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Brian Trammell In-Reply-To: <53DF42A4.1090506@cisco.com> Date: Mon, 4 Aug 2014 10:27:00 +0200 Message-Id: <8E297726-A5BE-411A-8506-B952CE07A8FE@trammell.ch> References: <20140804050737.28858.12663.idtracker@ietfa.amsl.com> <0CBA48F7-719E-482C-968C-10C00CF57882@trammell.ch> <53DF3E8E.5050905@cisco.com> <53DF42A4.1090506@cisco.com> To: Paul Aitken X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/KrDswWNQpSL3HqJ8ZbXYNrp4ODE Cc: "ipfix@ietf.org Group" Subject: Re: [IPFIX] I-D Action: draft-ietf-ipfix-text-adt-08.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, 04 Aug 2014 08:27:33 -0000 --Apple-Mail=_F0940FEE-148E-42BB-BAF2-99DD8987C42B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 04 Aug 2014, at 10:21, Paul Aitken wrote: > Brian, >=20 >> On 04 Aug 2014, at 10:04, Paul Aitken wrote: >>=20 >>> Brian, >>>=20 >>>> This revision addresses final IETF LC comments on extensibility and = copy/paste errors in the examples (thanks, Paul)! >>> You missed tcpControlBits: since it's defined as unsigned16 in = [IANA], you should either use unsigned16 or explain why unsigned8 is = being used (eg, say that reduced-size encoding is being used). >>>=20 >>> Recall: >>>=20 >>>>> And tcpControlBits: >>>>>=20 >>>>> tcpControlBits(6)[1] >>>>>=20 >>>>> - has been revised to unsigned16 [RFC7125]. Changing this would = also make Figure 2 align more neatly. >> Note that in a textual encoding, alignment is irrelevant. >=20 > That was cut-n-paste from an earlier email. I can't immediately see = what it was referring to. Ah.. then disregard. >>>> It'll probably still be exported as 1 byte everywhere, but the type = is indeed unsigned16 >> Ah, indeed. Rev -09 then. >>=20 >>> It would be useful to discuss reduced size encoding and show a = specific example. eg, if I'm collecting ingressInterface which is = nominally a u32, but I'm a small device so I only export a u8, should I = export: >>>=20 >>> ingressInterface(10)[1] >>>=20 >>> or >>>=20 >>> ingressInterface(10)[1] >> This is an interesting question but it would not appear to be in = scope at all for this document. >=20 > Where would such a clarification be given if not here? So you're talking about distinguishing among typed export types (i.e., = how to handle internal storage at an EP or CP), and this document is = about textual representation of these data types (where the internal = storage is (1) not in scope and (2) as per section 4.2 is only a matter = of implicit ranges when no explicit range for an IE is given. I'm really not seeing how these relate. Cheers, Brian --Apple-Mail=_F0940FEE-148E-42BB-BAF2-99DD8987C42B 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 iQEcBAEBCgAGBQJT30PUAAoJENt3nsOmbNJcz8sH/RCyhIMWW3S7na4Ny6RKDEmA kIQkHBFea7oPg/i9Bz9CUjVzHNKSbUyn23vUyMgd32NqZcCN8EwtOmoifS9SmRtQ HE3kvHJnCcJJLFEsrXoSR4/u4a30uyRFG8I8gqw+wmfLHBMsNOoIzRx69XFa0t8E 10pP/XnrmzAvWD+54douL87E//8sqcLXff2kL7aYvqcEgtpqU4nU6LZH76fwIAnq 2PQonIGDRO88m3WkjrjguNN4m20rsoOQJS9r1cE9MyI6wrvzcAesqbLvqwlWrKr7 giIL2bl+k/5g5Z2cuFww+NRX7FRmV5u1v5XlLNhxfCsMPRnObq05isVM/DAUvTY= =vAB+ -----END PGP SIGNATURE----- --Apple-Mail=_F0940FEE-148E-42BB-BAF2-99DD8987C42B-- From nobody Mon Aug 4 01:39:53 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 CE3131B28B9 for ; Mon, 4 Aug 2014 01:39:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 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.001, 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 FZs0bJostaaU for ; Mon, 4 Aug 2014 01:39:49 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F08AF1A0252 for ; Mon, 4 Aug 2014 01:39:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3084; q=dns/txt; s=iport; t=1407141589; x=1408351189; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=EJISY5v2/teSr9XG9cMi/W+ee1oPKZsQ1i09ltNdvJM=; b=HR/e6FAliVcbihdOEpEOfkGfdSsy3mjbtOrDL3Pta9JXqpK+Q+ZS/ZMO pi26zvlmoKuoA11Ps5YQ7xiqEo1Y/D/SXEcGlMOK7RIhrDyfg991aXnKY tA0q0XspFTvIeYJQjr9oni9rM/rLmKTCEUdkVZmV415MNNVHU2tOww8iF 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAEAExG31OtJssW/2dsb2JhbABb2CYBgS13hAQBAQMBeAEFCwsEChMWDwkDAgECAUUGDQEHAQGINgjENBePA0kHhEsBBJwGhyONPINOPIE0 X-IronPort-AV: E=Sophos;i="5.01,796,1400025600"; d="scan'208,217";a="132527970" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 04 Aug 2014 08:39:47 +0000 Received: from [10.61.109.110] (dhcp-10-61-109-110.cisco.com [10.61.109.110]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s748dkXU009809; Mon, 4 Aug 2014 08:39:47 GMT Message-ID: <53DF46D2.6080100@cisco.com> Date: Mon, 04 Aug 2014 09:39:46 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Brian Trammell References: <20140804050737.28858.12663.idtracker@ietfa.amsl.com> <0CBA48F7-719E-482C-968C-10C00CF57882@trammell.ch> <53DF3E8E.5050905@cisco.com> <53DF42A4.1090506@cisco.com> <8E297726-A5BE-411A-8506-B952CE07A8FE@trammell.ch> In-Reply-To: <8E297726-A5BE-411A-8506-B952CE07A8FE@trammell.ch> Content-Type: multipart/alternative; boundary="------------020108060707090401010401" Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/we4T2KY7pRW9TFTMtjwzLUJOYJw Cc: "ipfix@ietf.org Group" Subject: Re: [IPFIX] I-D Action: draft-ietf-ipfix-text-adt-08.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, 04 Aug 2014 08:39:51 -0000 This is a multi-part message in MIME format. --------------020108060707090401010401 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Brian, > So you're talking about distinguishing among typed export types (i.e., how to handle internal storage at an EP or CP), and this document is about textual representation of these data types (where the internal storage is (1) not in scope and (2) as per section 4.2 is only a matter of implicit ranges when no explicit range for an IE is given. > > I'm really not seeing how these relate. Nope; I'm saying that in one line you should explain how reduced size encoding works wrt text encoding, using the example you've created using tcpControlBits: tcpControlBits(6)[1] Here the size of [1] doesn't immediately seem to agree with the type. So under Figure 1 you could say, "Note that IPFIX Reduced-Size Encoding [RFC7011] is being used for tcpControlBits." (The same was done under Figure 19 in RFC6313.) This both shows readers how to use RSE with textual encodings, and prevents future errata from "correcting" this apparent "mistake". P. --------------020108060707090401010401 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Brian,

So you're talking about distinguishing among typed export types (i.e., how to handle internal storage at an EP or CP), and this document is about textual representation of these data types (where the internal storage is (1) not in scope and (2) as per section 4.2 is only a matter of implicit ranges when no explicit range for an IE is given.

I'm really not seeing how these relate.

Nope; I'm saying that in one line you should explain how reduced size encoding works wrt text encoding, using the example you've created using tcpControlBits:

         tcpControlBits(6)<unsigned16>[1]

Here the size of [1] doesn't immediately seem to agree with the <unsigned16> type.

So under Figure 1 you could say, "Note that IPFIX Reduced-Size Encoding [RFC7011] is being used for tcpControlBits."

(The same was done under Figure 19 in RFC6313.)

This both shows readers how to use RSE with textual encodings, and prevents future errata from "correcting" this apparent "mistake".

P.
--------------020108060707090401010401-- From nobody Fri Aug 8 01:08:23 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 6C7121A0AC6; Fri, 8 Aug 2014 01:08:21 -0700 (PDT) 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 4b1rArv6KiRo; Fri, 8 Aug 2014 01:08:20 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 81A2F1A0ADB; Fri, 8 Aug 2014 01:08:02 -0700 (PDT) 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.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140808080802.13402.61212.idtracker@ietfa.amsl.com> Date: Fri, 08 Aug 2014 01:08:02 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/tANKl0CXv_GBK6FgFYfGatdsC2A Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action: draft-ietf-ipfix-text-adt-10.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, 08 Aug 2014 08:08:22 -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-10.txt Pages : 13 Date : 2014-08-08 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-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-ipfix-text-adt-10 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 Aug 15 03:01:12 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 15DAD1A09A6 for ; Fri, 15 Aug 2014 03:01:12 -0700 (PDT) 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 w4W_vC8_7Yy0 for ; Fri, 15 Aug 2014 03:01:09 -0700 (PDT) Received: from trammell.ch (trammell1.nine.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 5B2C81A099B for ; Fri, 15 Aug 2014 03:01:09 -0700 (PDT) Received: from [IPv6:2001:67c:10ec:2a49:8000::1008] (unknown [IPv6:2001:67c:10ec:2a49:8000::1008]) by trammell.ch (Postfix) with ESMTPSA id 412541A0560 for ; Fri, 15 Aug 2014 12:00:38 +0200 (CEST) From: Brian Trammell Content-Type: multipart/signed; boundary="Apple-Mail=_0FC4BCDA-27BB-4D55-8FAC-0C7265E699FE"; protocol="application/pgp-signature"; micalg=pgp-sha512 Message-Id: <9192668E-3CB8-4874-8FB0-520EE585048F@trammell.ch> Date: Fri, 15 Aug 2014 12:00:40 +0200 To: "ipfix@ietf.org Group" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/CesaTD1czlmAgBL_hqFeJHAieko Subject: [IPFIX] Partial review of draft-ietf-ipfix-mib-variable-export-06 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, 15 Aug 2014 10:01:12 -0000 --Apple-Mail=_0FC4BCDA-27BB-4D55-8FAC-0C7265E699FE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Greetings, all, I've taken a look at the MIB variable export draft; apologies for the = lateness of this review. I am by no means an SNMP expert, and do not intend to become enough of = one to be able to adequately review this document, so this review should = be read with the caveat that I expect the document will receive adequate = review from SNMP/SMI experts to catch any problems on that side of the = fence. I've also therefore presumed that all unfamiliar terminology = (e.g. "Conceptual Rows") is defined in the SNMP world. The general approach -- using options data records to enhance template = records on a per-information-element basis -- seems sound. Indexed MIB = variables make this a bit more complicated than it otherwise would be = but as far as I can tell the method for addressing this seems sound as = well. I'm a little concerned by the complexity of the proposed solution. = However, I can't really separate accidental from essential complexity = because I don't have a feel for how much of it is necessary in order to = bolt the SNMP data model onto the side of the IPFIX protocol. So I = presume the authors have made some effort to define the least = complicated way to do so. Given the large scope, I'm also concerned about scope creep. It's = implicit but not explicitly clear in section 2 that the primary goal of = this document is (1) to allow the correlation of SNMP- and IPFIX-MP- = sourced data by exporting them together and (2) to allow SNMP push data = from SNMP-only devices to be more easily integrated into IPFIX-based = collection infrastructures. What the mechanism in the document should _not_ be used for is to expand = the IPFIX information model to also include the contents of all the = various MIBs, such that SMI IEs could be used alongside IPFIX IEs to = export information from non-SNMP sources of data. Otherwise we've = created Yet Another Representation for lots of common IEs already in the = IPFIX IE registry, which would significantly complicate the comparison = and combination of data at collectors. The document needs to make this = explicit, either in section 1 or 2. The template management characteristics of the proposed mechanism still = need some work as well. Section 5.7 should consider SCTP features for template management = explicitly: that MIB Field Options Data Records MUST be exported = reliably. MIB Field Options Data Records MUST also be exported on the = same stream as the templates with which they are associated. Even though = reliability is implied by the requirement to place a MIB Field ODR in = the same Message with its associated Template. This may cause problems with environments with restricted Message sizes = (i.e., UDP transport over IPv4 with unknown path MTU (576), even UDP = transport over non-Jumbo Ethernet (1460), as the MIB Field ODRs for a = given template may be quite large. The document should provide guidance = as to what to do in this case. Note also that over UDP this implies the MIB Field ODPs will need to be = resent with every template. Given the side of MIB Field ODPs this may = imply significantly increased overhead compared with RFC 7011 IPFIX. The document ignores template withdrawal and ID reuse. Personally, I'm = okay with this feature being mutually exclusive with template withdrawal = and ID reuse, because withdrawal and reuse are impossible to implement = in a way that guarantees interoperability and unambiguous interpretation = of data values when not used with a reliable or selectively-reliable = transport, and significantly complicate template management in any case. = But the document either needs to state that this feature may not be used = with withdrawal and ID reuse, or needs to explain what happens to MIB = Field ODP state when a template is withdrawn. Best regards, Brian --Apple-Mail=_0FC4BCDA-27BB-4D55-8FAC-0C7265E699FE 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 iQEcBAEBCgAGBQJT7dpIAAoJENt3nsOmbNJcGJgH/0Hipw1Ogwrg1vaLvhX+TOkp dFjS3oyvcCnphc/ViK328V/+qEij4aOTqHwff+Bdv9nPtEnv3aG4u5520xahzALK V9s7fzS69GI4SZXni9zEO+Lmic3YNs4AaLrOJanRC/DSStCVHXE1BW5YTTGiI4UU 9rXK0T4csBsW+cV9cA0D3Psr7w2zZjrxVc4Y1q5DovUNby9jMbWYzyEbqW++yGY7 2d3Df7n+b9vPVlxUQOZ+Wh0SGa96G4j242XS5MflPh+3gBSOwZOrUTeMVAMk1wto rvDXmimTIi1mlggLeKoTsFiI/krw2U0OzfCSEKgP2P36MAe8pdFz7Umk0mdbdL4= =DGA5 -----END PGP SIGNATURE----- --Apple-Mail=_0FC4BCDA-27BB-4D55-8FAC-0C7265E699FE-- From nobody Mon Aug 18 17:52: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 726921A8746; Mon, 18 Aug 2014 17:52:23 -0700 (PDT) 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 aHxWoQR_Zaqw; Mon, 18 Aug 2014 17:52:21 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4561D1A8752; Mon, 18 Aug 2014 17:52:19 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140819005219.24441.21794.idtracker@ietfa.amsl.com> Date: Mon, 18 Aug 2014 17:52:19 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/bNlROThkVGOqvaIgbB30dKDGwhA Cc: ipfix chair , ipfix mailing list , RFC Editor Subject: [IPFIX] Protocol Action: 'Textual Representation of IPFIX Abstract Data Types' to Proposed Standard (draft-ietf-ipfix-text-adt-10.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, 19 Aug 2014 00:52:24 -0000 The IESG has approved the following document: - 'Textual Representation of IPFIX Abstract Data Types' (draft-ietf-ipfix-text-adt-10.txt) as Proposed Standard This document is the product of the IP Flow Information Export Working Group. The IESG contact persons are Benoit Claise and Joel Jaeggli. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-ipfix-text-adt/ Technical Summary 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. Working Group Summary The WG has consensus that this document is useful and has discussed and reviewed it. There is strong consensus on the document. Document Quality It is a short document with clear structure and clear definitions. The WG has reviewed it at WGLC and received comments have been addressed. Personnel Juergen Quittek is the document shepherd. Benoit Claise is the responsible Area Director. From nobody Thu Aug 28 15:18: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 8917E1A0035 for ; Thu, 28 Aug 2014 15:18:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.669 X-Spam-Level: X-Spam-Status: No, score=-5.669 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, 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 fIumckZdeifR for ; Thu, 28 Aug 2014 15:18:53 -0700 (PDT) Received: from e7.ny.us.ibm.com (e7.ny.us.ibm.com [32.97.182.137]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8578E1A00D8 for ; Thu, 28 Aug 2014 15:18:53 -0700 (PDT) Received: from /spool/local by e7.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 28 Aug 2014 18:18:52 -0400 Received: from d01dlp02.pok.ibm.com (9.56.250.167) by e7.ny.us.ibm.com (192.168.1.107) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Thu, 28 Aug 2014 18:18:50 -0400 Received: from b01cxnp22036.gho.pok.ibm.com (b01cxnp22036.gho.pok.ibm.com [9.57.198.26]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id 1B81B6E8040 for ; Thu, 28 Aug 2014 18:18:38 -0400 (EDT) Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by b01cxnp22036.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id s7SMInID2621874 for ; Thu, 28 Aug 2014 22:18:49 GMT Received: from d01av02.pok.ibm.com (localhost [127.0.0.1]) by d01av02.pok.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id s7SMInmD008319 for ; Thu, 28 Aug 2014 18:18:49 -0400 Received: from d01ml263.pok.ibm.com (d01ml263.pok.ibm.com [9.63.8.130]) by d01av02.pok.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id s7SMInVZ008316 for ; Thu, 28 Aug 2014 18:18:49 -0400 X-KeepSent: 352B6DAA:7EF39A08-85257D42:00799799; type=4; name=$KeepSent To: ipfix@ietf.org X-Mailer: IBM Notes Release 9.0.1 October 14, 2013 Message-ID: From: Wayne Tackabury Date: Thu, 28 Aug 2014 18:18:49 -0400 X-MIMETrack: Serialize by Router on D01ML263/01/M/IBM(Release 9.0.1FP1|April 03, 2014) at 08/28/2014 18:18:49 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=0ABBF7D1DFEA11098f9e8a93df938690918c0ABBF7D1DFEA1109" Content-Disposition: inline X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 14082822-5806-0000-0000-000000547DAF Archived-At: http://mailarchive.ietf.org/arch/msg/ipfix/rWpoJWbUHngu2m39NoncX_JD0Y0 Subject: [IPFIX] WG Status, basically 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, 28 Aug 2014 22:18:55 -0000 --0__=0ABBF7D1DFEA11098f9e8a93df938690918c0ABBF7D1DFEA1109 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable Hi all....somewhat recent WG document rat, first time poster to the lis= t. My sense, based on readings from a Vancouver "is it time to wrap up" ag= enda item, and mailling list archives and particularly an exchange right aro= und the time of London, is that the WG is in that oft-gray state between "winding down all current work items" and "closed out, somebody give us= a ring if there's a compelling reason for recharter" (at least, I've seen= that oft-gray-ness before). The Ops area report still lists us as active, and I can see there's sti= ll maybe 3-4 I'D's under discussion. Then again, looks like the London WG= meetings were cancelled and nothing was scheduled for Toronto. Of cou= rse, that can mean that the work is being entirely satisfied on the list. I= s there a concise statement of status anyone can offer up? How about this for a quick way to ask a (maybe different) question -- d= o folks anticipate active meetings in Honolulu in November? Thanks! Regards, Wayne Tackabury IBM Security Software Group= --0__=0ABBF7D1DFEA11098f9e8a93df938690918c0ABBF7D1DFEA1109 Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

Hi all....somewhat recent WG do= cument rat, first time poster to the list.

My sense, based on readings from a= Vancouver "is it time to wrap up" agenda item, and mailling = list archives and particularly an exchange right around the time of Lon= don, is that the WG is in that oft-gray state between "winding dow= n all current work items" and "closed out, somebody give us a= ring if there's a compelling reason for recharter" (at least, I'v= e seen that oft-gray-ness before).

The Ops area report still lists us= as active, and I can see there's still maybe 3-4 I'D's under discussio= n.  Then again, looks like the London WG meetings were cancelled a= nd nothing was scheduled for Toronto.   Of course, that can mean t= hat the work is being entirely satisfied on the list.  Is there a = concise statement of status anyone can offer up?

How about this for a quick way to = ask a (maybe different) question -- do folks anticipate active meetings= in Honolulu in November?

Thanks!

Regards,
Wayne Tackabury
IBM Security Software Group=
= --0__=0ABBF7D1DFEA11098f9e8a93df938690918c0ABBF7D1DFEA1109--