Re: [IPFIX] I-D Action: draft-ietf-ipfix-text-adt-08.txt

Paul Aitken <paitken@cisco.com> Mon, 04 August 2014 08:39 UTC

Return-Path: <paitken@cisco.com>
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 <ipfix@ietfa.amsl.com>; 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 <ipfix@ietfa.amsl.com>; 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 <ipfix@ietf.org>; 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 <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: Brian Trammell <ietf@trammell.ch>
References: <20140804050737.28858.12663.idtracker@ietfa.amsl.com> <0CBA48F7-719E-482C-968C-10C00CF57882@trammell.ch> <53DF3E8E.5050905@cisco.com> <A9D47C27-897B-4090-A6DA-AF330A05DE67@trammell.ch> <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" <ipfix@ietf.org>
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 <ipfix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipfix>, <mailto:ipfix-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipfix/>
List-Post: <mailto:ipfix@ietf.org>
List-Help: <mailto:ipfix-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipfix>, <mailto:ipfix-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 04 Aug 2014 08:39:51 -0000

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.