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

Paul Aitken <paitken@cisco.com> Tue, 24 December 2013 23:21 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 1F9901AE12D; Tue, 24 Dec 2013 15:21:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.038
X-Spam-Level:
X-Spam-Status: No, score=-10.038 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, RP_MATCHES_RCVD=-0.538, 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 o7-0Hyjvq87t; Tue, 24 Dec 2013 15:21:36 -0800 (PST)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id 1BA291AE12A; Tue, 24 Dec 2013 15:21:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3357; q=dns/txt; s=iport; t=1387927292; x=1389136892; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=jzl7lbtRmb6UU2MuyKAXY5twsMs7udeA0lr5MeZObEA=; b=FuAsxDU6Wa+4UmOiSCif7Q8kZfqfFA7ICjoM0vL+A/U44CB64SkVdrKV bmRpNy7fIBxo7cz2XPmeqAjYBXEMMQmsbaPfSsSiL0IF7vR/yCoghTq2o hmmnM2LlWkMpursDm3jUjcKQj5ncknCsxmZ6zZP1YdZouU4GQ5MmWMoH4 U=;
X-IronPort-AV: E=Sophos;i="4.95,545,1384300800"; d="scan'208,217";a="2063492"
Received: from ams-core-2.cisco.com ([144.254.72.75]) by aer-iport-2.cisco.com with ESMTP; 24 Dec 2013 23:21:31 +0000
Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id rBONLVdn007937 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Dec 2013 23:21:31 GMT
Received: from [10.21.69.138] (sjc-vpn3-1418.cisco.com [10.21.69.138]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id rBONLSsP012699; Tue, 24 Dec 2013 23:21:29 GMT
Message-ID: <52BA16F3.4000507@cisco.com>
Date: Tue, 24 Dec 2013 16:21:23 -0700
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.2.0
MIME-Version: 1.0
To: Ben Campbell <ben@nostrum.com>, Benoit Claise <bclaise@cisco.com>
References: <9F0317F4-CAC5-49C7-89C8-199FA2B78DF0@nostrum.com> <528DF263.3010908@cisco.com> <D7E0F5D3-7B95-4293-926D-544C17B80442@nostrum.com>
In-Reply-To: <D7E0F5D3-7B95-4293-926D-544C17B80442@nostrum.com>
Content-Type: multipart/alternative; boundary="------------000000050301030005010201"
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: Tue, 24 Dec 2013 23:21:38 -0000

Benoit, Ben,

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

I've moved RFC2804 to an Informative reference, and changed the text to say:

    With sufficient length, this element also reports octets from the IP
    payload. However full packet capture of arbitrary packet streams is
    explicitly out of scope per the Security Considerations section of
    RFC5477 and RFC2804.

P.