Re: [Int-area] FW: New Version Notification for draft-eckert-intarea-flow-metadata-framework-01.txt

Toerless Eckert <eckert@cisco.com> Fri, 19 July 2013 03:40 UTC

Return-Path: <eckert@cisco.com>
X-Original-To: int-area@ietfa.amsl.com
Delivered-To: int-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D481011E8279 for <int-area@ietfa.amsl.com>; Thu, 18 Jul 2013 20:40:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.512
X-Spam-Level:
X-Spam-Status: No, score=-10.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tcd+ZX5FWaeh for <int-area@ietfa.amsl.com>; Thu, 18 Jul 2013 20:40:07 -0700 (PDT)
Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 95F4711E8276 for <int-area@ietf.org>; Thu, 18 Jul 2013 20:40:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1196; q=dns/txt; s=iport; t=1374205207; x=1375414807; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=rj/L2ll7w4Ab6qhK/UxOmhRvkoCAf2vnbnjNLuIww9g=; b=FmF61BWpWiSOiO1GK+l+hzTvXKTGc4Kq1CjHvbYa9ftKLmdVu5Ng+I77 e2QJJYDAMCW1T6IkpP7iHP/8R/UUQIrKZs0sVCk3aveHG3cUQUq4OemKj kXwixweA7PV0Z1+aMGB4k8/7eMhnP6urmwjt50fI6J2Jz38hokIRyBT+q w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgEFAKS06FGrRDoJ/2dsb2JhbABagwbBSYEVFnSCJAEBAQMBOj0CBQsLIQwZDwU6O4dxBbZLkA8HCgyDZgOJKI40AZFNgVmBWRyBLCQ
X-IronPort-AV: E=Sophos;i="4.89,698,1367971200"; d="scan'208";a="83413536"
Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 19 Jul 2013 03:40:04 +0000
Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r6J3e4C0026292 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Jul 2013 03:40:04 GMT
Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id r6J3e4Mf005918; Thu, 18 Jul 2013 20:40:04 -0700
Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id r6J3e4gm005917; Thu, 18 Jul 2013 20:40:04 -0700
Date: Thu, 18 Jul 2013 20:40:04 -0700
From: Toerless Eckert <eckert@cisco.com>
To: mohamed.boucadair@orange.com
Message-ID: <20130719034004.GP23170@cisco.com>
References: <94C682931C08B048B7A8645303FDC9F36EE2DDB4FE@PUEXCB1B.nanterre.francetelecom.fr> <45A697A8FFD7CF48BCF2BE7E106F0604090C8510@xmb-rcd-x04.cisco.com> <94C682931C08B048B7A8645303FDC9F36EE2DDB59F@PUEXCB1B.nanterre.francetelecom.fr> <20130719031237.GM23170@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20130719031237.GM23170@cisco.com>
User-Agent: Mutt/1.4.2.2i
Cc: "int-area@ietf.org" <int-area@ietf.org>
Subject: Re: [Int-area] FW: New Version Notification for draft-eckert-intarea-flow-metadata-framework-01.txt
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/int-area>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Jul 2013 03:40:13 -0000

Btw: I wrote something about proxies i would like to amend:

> See section 3.1.4.1 which talks about proxies. The problem really is where
> the proxied information comes from. If the proxy is doing DPI inspection to
> deduce it or some configured mappings, then it's likely going to be unreliable
> (encryption) or suffer from problems in getting it provisioned.

In a prior life, we IETF standardized IP Multicast SSM which does require
application upgrade (signal S,G), and then we and other vendors implemented
what we call "SSM mapping" to work around that (not requiring application
update). Call it an SSM proxy. No vendor brought this into the IETF
because we always wanted to see this positioned as a temporary transition
technology and not make it too attractive to run forever. 

Now, you don't want to know what really is deployed in networks and what
strategies customer apply. Lets just say that SSM mapping is very successfull.

So, to a degree you can account my above paragraph either as 
"famous last words" or "don't give up the good fight". So i am all for
standardizing any proxy methods the IETF thinks makes sense to standardize.

Cheers
    Toerless