Re: [IPFIX] Gen-ART Telechat Review of draft-ietf-ipfix-data-link-layer-monitoring-07

Ben Campbell <ben@nostrum.com> Thu, 21 November 2013 16:18 UTC

Return-Path: <ben@nostrum.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 0C1081ADF88; Thu, 21 Nov 2013 08:18:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.036
X-Spam-Level:
X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no
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 4duv1Szuz8EO; Thu, 21 Nov 2013 08:18:15 -0800 (PST)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 738BA1ADF65; Thu, 21 Nov 2013 08:18:15 -0800 (PST)
Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id rALGI2ds067290 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 21 Nov 2013 10:18:03 -0600 (CST) (envelope-from ben@nostrum.com)
Content-Type: text/plain; charset="iso-8859-1"
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
From: Ben Campbell <ben@nostrum.com>
In-Reply-To: <528DF263.3010908@cisco.com>
Date: Thu, 21 Nov 2013 10:18:02 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <D7E0F5D3-7B95-4293-926D-544C17B80442@nostrum.com>
References: <9F0317F4-CAC5-49C7-89C8-199FA2B78DF0@nostrum.com> <528DF263.3010908@cisco.com>
To: Benoit Claise <bclaise@cisco.com>
X-Mailer: Apple Mail (2.1822)
Received-SPF: pass (shaman.nostrum.com: 173.172.146.58 is authenticated by a trusted mechanism)
X-Mailman-Approved-At: Thu, 21 Nov 2013 12:13:05 -0800
Cc: "gen-art@ietf.org Team (gen-art@ietf.org)" <gen-art@ietf.org>, draft-ietf-ipfix-data-link-layer-monitoring.all@tools.ietf.org, ipfix@ietf.org
Subject: Re: [IPFIX] Gen-ART Telechat Review of draft-ietf-ipfix-data-link-layer-monitoring-07
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: Thu, 21 Nov 2013 16:18:17 -0000

On Nov 21, 2013, at 5:45 AM, Benoit Claise <bclaise@cisco.com> wrote:

> Hi Ben,
> 
> Thanks for your review.
> See in-line.
>> I am the assigned Gen-ART reviewer for this draft. For background on
>> Gen-ART, please see the FAQ at
>> < http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>> 
>> Please wait for direction from your document shepherd
>> or AD before posting a new version of the draft.
>> 
>> Document: draft-ietf-ipfix-data-link-layer-monitoring-07
>> Reviewer: Ben Campbell
>> Review Date: 2013-11-19
>> IESG Telechat date: 2013-11-21
>> 
>> Summary: This draft is essentially ready for publication as a standards track RFC. However, there is one issue that I unfortunately missed in my last call review of version 06 that should be considered prior to publication.
>> 
>> Major issues:
>> 
>> None
>> 
>> Minor issues:
>> 
>> There's a normative downref to RFC 2804, which is informational. That seems a really odd draft for a normative reference. There may be precedent, as I note that RFC 5477, referenced here for security considerations, does the same thing.
> Actually RFC 5477 uses an informative reference to RFC 2804.

Oops sorry, missed that. But it does cite 2804 in the same context (i.e. capture payload octets, subject to [RFC 2804]

>> I apologize for bringing this up this late in the process--I missed it in my earlier review at last call.
>> 
>> As I understand it the context is that certain data elements can include payload octets. This is subject to the security considerations in 5477, which basically say don't include too much, because of guidance from 2804. But my reading of 2804 does not give specific guidance things like how much payload one can capture before it becomes too much.
>> 
>> I think the simplest solution would be to keep the reference to the 5477 security considerations, and reiterate that this model is not intended for gross capture of payloads, perhaps with an _informative_ reference to 2804.
> The informative reference would be in line with RFC 5477. So yes.
> Not sure if we need the reiteration.

I think a sentence or two would save the reader from having to flip back and forth between docs. But it's not a big deal one way or ahother.

Thanks!

Ben.