Re: [IPFIX] Fwd: Last Call: <draft-ietf-ipfix-text-adt-07.txt> (Textual Representation of IPFIX Abstract Data Types) to Proposed Standard
Paul Aitken <paitken@cisco.com> Thu, 17 July 2014 14:05 UTC
Return-Path: <paitken@cisco.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F5B21A0AF2; Thu, 17 Jul 2014 07:05:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -13.901
X-Spam-Level:
X-Spam-Status: No, score=-13.901 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, J_CHICKENPOX_37=0.6, 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 6Fd638ormapQ; Thu, 17 Jul 2014 07:05:17 -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 D48CC1A0AE0; Thu, 17 Jul 2014 07:05:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13569; q=dns/txt; s=iport; t=1405605918; x=1406815518; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=px3Xc7HEVF9fLaMLPf/WBR3Od4Wi8ayNJ6K6QPKdarg=; b=l82aLn4nsNYJYEMkjg7BkZlxKX1NAQHslJuUHsj9LSJz49fJqYHnwohI 0SEuAfEr70ik8T8EMhQjIvch15ZQiJLdTzeyMwYS92u/IrNQZH6rBqMb4 Z6ThqIqSdgC4EJiW56rDnOpt+CfrJkdN6SfYGqJYmu5OROMBjxQ/7aobY 4=;
X-IronPort-AV: E=Sophos;i="5.01,678,1400025600"; d="scan'208,217";a="115493832"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 17 Jul 2014 14:05:16 +0000
Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s6HE5ELk018122 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Jul 2014 14:05:15 GMT
Received: from [10.61.107.35] (dhcp-10-61-107-35.cisco.com [10.61.107.35]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id s6HE5Dr3026248; Thu, 17 Jul 2014 15:05:13 +0100 (BST)
Message-ID: <53C7D814.3030906@cisco.com>
Date: Thu, 17 Jul 2014 15:05:08 +0100
From: Paul Aitken <paitken@cisco.com>
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: Benoit Claise <bclaise@cisco.com>
Subject: Re: [IPFIX] Fwd: Last Call: <draft-ietf-ipfix-text-adt-07.txt> (Textual Representation of IPFIX Abstract Data Types) to Proposed Standard
References: <20140716222427.14473.7386.idtracker@ietfa.amsl.com> <53C6FDCB.5030804@cisco.com>
In-Reply-To: <53C6FDCB.5030804@cisco.com>
Content-Type: multipart/alternative; boundary="------------080702020301070805080506"
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/5BGni0qdipYgXzhCWsA0SXHqAmo
X-Mailman-Approved-At: Fri, 18 Jul 2014 08:56:43 -0700
Cc: "ietf@ietf.org" <ietf@ietf.org>, "ipfix@ietf.org" <ipfix@ietf.org>, Brian Trammell <trammell@tik.ee.ethz.ch>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Jul 2014 14:05:24 -0000
Benoit, Brian, All, 4. Data Type Encodings Each subsection of this section defines a textual encoding for the abstract data types defined in [RFC7012]. Is 7012 the correct reference? Isn't IANA's IPFIX registry now understood to be the master reference? (ie, http://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-information-element-data-types) With a view to extensibility, this document doesn't say what to do if/when new data types are added to IANA (eg, see ietf-ipfix-mib-variable-export). eg even one line to say that they can be represented in a default or limited way, or that they cannot be represented at all - in which case, how should the representation be extended in future, if needs be? Appendix A / Figure 1: While Figure 1 in this draft initially seems identical to Figure 1 in section10.2 of 7013, there are some important differences between them: 7013: sourceIPv4Address(8)<ipv4Address>[4]{key} destinationIPv4Address(12)<ipv4Address>[4]{key} Figure 1: sourceIPv6Address(27)<ipv4Address>[4]{key} destinationIPv6Address(28)<ipv4Address>[4]{key} ... tcpControlBits(6)<unsigned8>[1] flowEndReason(136)<unsigned8>[1] This has been wrong since -00 : sourceIPv6Address(27)<ipv4Address>[4]{key} destinationIPv6Address(28)<ipv4Address>[4]{key} (Figure 2 shows a length of 16 for these, so presumably s/v4/v6/ and s/[4]/[16]/ in the above definitions.) And tcpControlBits: tcpControlBits(6)<unsigned8>[1] - has been revised to unsigned16 [RFC7125]. Changing this would also make Figure 2 align more neatly. Figure 3: it's not clear how the strings for the timestamp, IPv6 address, and protocol identifier fields get mapped to the corresponding dateTimeMilliseconds, ipv6address, and unsigned8 types shown in Figures 1 and 2. eg, conversion is required between "tcp" and 6, so the draft should mention that. P. On 16/07/2014 23:33, Benoit Claise wrote: > Dear IPFIX WG, > > In the text below, I explain the reason behind the second IETF LC: > > During the IESG telechat, the IESG concluded that this document should be > Proposed Standard, and not Informational as initially proposed in v6. > This IETF LC should focus on the Proposed Standard changes in the > latest version. > > > Regards, Benoit > > -------- Original Message -------- > Subject: [IPFIX] Last Call: <draft-ietf-ipfix-text-adt-07.txt> > (Textual Representation of IPFIX Abstract Data Types) to Proposed > Standard > Date: Wed, 16 Jul 2014 15:24:27 -0700 > From: The IESG <iesg-secretary@ietf.org> > Reply-To: <ietf@ietf.org> > To: IETF-Announce <ietf-announce@ietf.org> > CC: <ipfix@ietf.org> > > > > The IESG has received a request from the IP Flow Information Export WG > (ipfix) to consider the following document: > - 'Textual Representation of IPFIX Abstract Data Types' > <draft-ietf-ipfix-text-adt-07.txt> > > During the IESG telechat, the IESG concluded that this document should be > Proposed Standard, and not Informational as initially proposed in v6. > This IETF LC should focus on the Proposed Standard changes in the > latest version. > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2014-07-30. Exceptionally, comments may be > sent toiesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > 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 file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-ipfix-text-adt/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-ipfix-text-adt/ballot/ > > > No IPR declarations have been submitted directly on this I-D. > > > _______________________________________________ > 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
- Re: [IPFIX] Fwd: Last Call: <draft-ietf-ipfix-tex… Brian Trammell
- Re: [IPFIX] Fwd: Last Call: <draft-ietf-ipfix-tex… Brian Trammell
- Re: [IPFIX] Fwd: Last Call: <draft-ietf-ipfix-tex… Paul Aitken
- Re: [IPFIX] Fwd: Last Call: <draft-ietf-ipfix-tex… Paul Aitken