IETF Logo Mail Archive

Re: [pntaw] New version of draft-hutton-rtcweb-nat-firewall-considerations

Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> Mon, 23 September 2013 08:59 UTC

Return-Path: <sergio.garcia.murillo@gmail.com>
X-Original-To: pntaw@ietfa.amsl.com
Delivered-To: pntaw@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A43BD11E80DE for <pntaw@ietfa.amsl.com>; Mon, 23 Sep 2013 01:59:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.442
X-Spam-Level:
X-Spam-Status: No, score=-2.442 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, SUBJECT_FUZZY_TION=0.156]
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 v81Ahg6TpsKU for <pntaw@ietfa.amsl.com>; Mon, 23 Sep 2013 01:59:23 -0700 (PDT)
Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) by ietfa.amsl.com (Postfix) with ESMTP id E365A21F8201 for <pntaw@ietf.org>; Mon, 23 Sep 2013 01:59:22 -0700 (PDT)
Received: by mail-wi0-f173.google.com with SMTP id hq15so1942468wib.0 for <pntaw@ietf.org>; Mon, 23 Sep 2013 01:59:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=QCkIdDWZGQeelFbzfrKonfH/3UhiqM+YW0DAtcjnj4k=; b=FDe9C6VeLWVEpavSv3/d/t4fkB4yfjv98zIjg2keUIJi3uU/oOYMPmtQHfoi6oWuww CyAWSZg2NmSeUa9JDxltSTj8DCugWSl6m9A0HLpYNhwGhcSlf2Z8VIjFkZhN2Iy7InI/ xib0UV7/YqepPJk8ibt5MsPf6i9AHsgBHFWAwqcPyRr39vveoD4E5RKd/+mEs0HIaJDM IB1/kfKEga12Bhc74q4Syrpb1QPUNKLuYoD+mCQZQ9WqJtD2JhGbvIsa7WxBATUNQcIH yUTDxlFk040opTGMUXBOapl8oV08aFqLSCMc/mMgSMespnZUpvLGLk+4PWc2nwtstw25 guuA==
X-Received: by 10.194.9.70 with SMTP id x6mr16125449wja.22.1379926762081; Mon, 23 Sep 2013 01:59:22 -0700 (PDT)
Received: from [192.168.1.45] (54.Red-83-61-124.dynamicIP.rima-tde.net. [83.61.124.54]) by mx.google.com with ESMTPSA id e1sm23625304wij.6.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 23 Sep 2013 01:59:21 -0700 (PDT)
Message-ID: <524002E8.8080506@gmail.com>
Date: Mon, 23 Sep 2013 10:59:20 +0200
From: Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: "Hutton, Andrew" <andrew.hutton@siemens-enterprise.com>
References: <9F33F40F6F2CD847824537F3C4E37DDF17BCF3A5@MCHP04MSX.global-ad.net>, <523CCD06.3030902@gmail.com> <9F33F40F6F2CD847824537F3C4E37DDF17BD0178@MCHP04MSX.global-ad.net>
In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF17BD0178@MCHP04MSX.global-ad.net>
Content-Type: multipart/alternative; boundary="------------050603050506070700040300"
Cc: "pntaw@ietf.org" <pntaw@ietf.org>
Subject: Re: [pntaw] New version of draft-hutton-rtcweb-nat-firewall-considerations
X-BeenThere: pntaw@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discussion list for practices related to proxies, NATs, TURN, and WebRTC" <pntaw.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pntaw>, <mailto:pntaw-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pntaw>
List-Post: <mailto:pntaw@ietf.org>
List-Help: <mailto:pntaw-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pntaw>, <mailto:pntaw-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 23 Sep 2013 08:59:23 -0000

El 22/09/2013 0:40, Hutton, Andrew escribió:
>
> We don't believe that discussing issues around DPI inspection is 
> within scope or desirable and we are not trying to work around it.

Why?

>  However all scenarios that involve accessing WebRTC services from 
> behind a firewall are within scope whether it is a service deployed by 
> an enterprise or not.
>
> Regarding requirement F37 I already raised an issue with this some 
> time ago and a change will be made in the next update to the use case 
> draft. The issue is that this should not refer to a firewall "that 
> only allows HTTP(S) traffic" but should include the case of HTTP Proxy 
> being deployed and the fw allowing traffic from the proxy even if it 
> is not HTTP(S). Once this change gets in to the use case draft I think 
> we are aligned with it.

Why are you changing the requirement and cutting the scope so it matches 
your proposed solution? Shouldn't it be the other way round?

Best regards
Sergio

v2.23.0 | Report a Bug | By Email