Re: [IPFIX] WG Last Call for draft-ietf-ipfix-information-model-rfc5102bis-05.txt

Benoit Claise <bclaise@cisco.com> Thu, 08 November 2012 15:49 UTC

Return-Path: <bclaise@cisco.com>
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E5DB21F8839 for <ipfix@ietfa.amsl.com>; Thu, 8 Nov 2012 07:49:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.525
X-Spam-Level:
X-Spam-Status: No, score=-10.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AG03xPKlLx1F for <ipfix@ietfa.amsl.com>; Thu, 8 Nov 2012 07:49:23 -0800 (PST)
Received: from av-tac-rtp.cisco.com (av-tac-rtp.cisco.com [64.102.19.209]) by ietfa.amsl.com (Postfix) with ESMTP id A2F3521F880A for <ipfix@ietf.org>; Thu, 8 Nov 2012 07:49:23 -0800 (PST)
X-TACSUNS: Virus Scanned
Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qA8FnHkB017863; Thu, 8 Nov 2012 10:49:17 -0500 (EST)
Received: from [10.82.236.201] (rtp-vpn5-1221.cisco.com [10.82.236.201]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qA8FnF5m005293; Thu, 8 Nov 2012 10:49:15 -0500 (EST)
Message-ID: <509BD47B.5060401@cisco.com>
Date: Thu, 08 Nov 2012 10:49:15 -0500
From: Benoit Claise <bclaise@cisco.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2
MIME-Version: 1.0
To: Paul Aitken <paitken@cisco.com>
References: <506CBFE3.10607@auckland.ac.nz> <5090547C.5020803@cisco.com> <F37F4EC6-E7AB-4975-93A7-82B7CDCD13EF@tik.ee.ethz.ch> <5091271E.3050206@cisco.com>
In-Reply-To: <5091271E.3050206@cisco.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: Nevil Brownlee <n.brownlee@auckland.ac.nz>, IPFIX Working Group <ipfix@ietf.org>
Subject: Re: [IPFIX] WG Last Call for draft-ietf-ipfix-information-model-rfc5102bis-05.txt
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
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: Thu, 08 Nov 2012 15:49:24 -0000

Paul, Brian
>
>>>
>>>> 1.1. Changes since RFC 5102
>>>>
>>>>     This document obsoletes the Proposed Standard revision of the 
>>>> IPFIX
>>>>     Protocol Specification [RFC5102].  The following changes have been
>>>>     made to this document with respect to the previous document:
>>>>
>>>>        - All outstanding technical and editorial errata filed on the
>>>>     [RFC5102] as of publication time have been corrected
>>>>        - All references into [RFC5101] have been updated to 
>>>> [RFC5101bis],
>>>>     reflecting changes in that document as necessary
>>>>        - Information element definitions have been removed, as the
>>>>     reference for these is now [IPFIX-IANA]; categorizations of
>>>>     information elements as defines in [RFC5102] have been retained in
>>>>     section 5.
>>>>        - The process for modifying [IPFIX-IANA] has been improved, 
>>>> and is
>>>>     now described in [IPFIX-IE-DOCTORS]; Section 6 has been updated
>>>>     accordingly, and a new section 7.3 gives IANA considerations 
>>>> for this
>>>>     process.
>>>>        - Definitions of timestamp data types have been clarified
>>>>        - Appendices A and B have been removed
>>> BTW, the indentation of that section makes it difficult to read. Can 
>>> you get all the text - including the wrapped lines - to the right of 
>>> the bullets?
>> I'm not an nroff hacker. Any pointers?
>
> Personally, I had to hack rfc2xml to make it do what I wanted.
>
>
>> It's also not clear that this section should survive IESG processing 
>> / RFC editor processing.
>
> Since this doc obsoletes 5102, I find it useful to get a high level 
> overview of what was changed, and for that overview to be given early 
> in the document.

We should keep this section. This is much appreciated during the IESG 
review, and for historical reasons.

Regards, Benoit