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

Ben Campbell <ben@nostrum.com> Tue, 19 November 2013 21:17 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 894EF1ADF4B; Tue, 19 Nov 2013 13:17:14 -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 RPGW8GAx5XwT; Tue, 19 Nov 2013 13:17:13 -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 564D21AE150; Tue, 19 Nov 2013 13:17:13 -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 rAJLH4SI052101 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 19 Nov 2013 15:17:06 -0600 (CST) (envelope-from ben@nostrum.com)
From: Ben Campbell <ben@nostrum.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 19 Nov 2013 15:17:03 -0600
Message-Id: <9F0317F4-CAC5-49C7-89C8-199FA2B78DF0@nostrum.com>
To: draft-ietf-ipfix-data-link-layer-monitoring.all@tools.ietf.org, ipfix@ietf.org
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
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: Tue, 19 Nov 2013 13:18:54 -0800
Cc: "gen-art@ietf.org Team (gen-art@ietf.org)" <gen-art@ietf.org>
Subject: [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: Tue, 19 Nov 2013 21:17:14 -0000

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.  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.

Nits/editorial comments:

None