Re: [Int-area] L. Eggert's comment (draft-boucadair-intarea-host-identifier-scenarios)

Joe Touch <touch@isi.edu> Wed, 23 July 2014 17:10 UTC

Return-Path: <touch@isi.edu>
X-Original-To: int-area@ietfa.amsl.com
Delivered-To: int-area@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1960D1B290B for <int-area@ietfa.amsl.com>; Wed, 23 Jul 2014 10:10:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] 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 7GsiazMD-dRi for <int-area@ietfa.amsl.com>; Wed, 23 Jul 2014 10:09:59 -0700 (PDT)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E80F1A0AD7 for <int-area@ietf.org>; Wed, 23 Jul 2014 10:09:59 -0700 (PDT)
Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s6NH4Kur016541 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 23 Jul 2014 10:04:20 -0700 (PDT)
Message-ID: <53CFEB14.3020301@isi.edu>
Date: Wed, 23 Jul 2014 10:04:20 -0700
From: Joe Touch <touch@isi.edu>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: mohamed.boucadair@orange.com, "Internet Area (int-area@ietf.org)" <int-area@ietf.org>
References: <787AE7BB302AE849A7480A190F8B933003973B@OPEXCLILM23.corporate.adroot.infra.ftgroup>
In-Reply-To: <787AE7BB302AE849A7480A190F8B933003973B@OPEXCLILM23.corporate.adroot.infra.ftgroup>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: http://mailarchive.ietf.org/arch/msg/int-area/sBLDKMRvNi09pz-7h9HnKl7sP7s
Cc: "draft-boucadair-intarea-host-identifier-scenarios@tools.ietf.org" <draft-boucadair-intarea-host-identifier-scenarios@tools.ietf.org>
Subject: Re: [Int-area] L. Eggert's comment (draft-boucadair-intarea-host-identifier-scenarios)
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.15
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: Wed, 23 Jul 2014 17:10:02 -0000

I'd like to add some context from my viewpoint:

On 7/23/2014 5:32 AM, mohamed.boucadair@orange.com wrote:
> Hi all,
>
> Lars raised a point about
> draft-boucadair-intarea-host-identifier-scenarios that is basically to
> question whether it is worth continuing this effort if no viable
> solutions can be designed to solve this problem.
>
> I do agree this is a fair point. I have several comments to make here:
>
> ·The lack of a recommendation in RFC6967 should not be interpreted as
> there is no working solution.

Agreed. The WG decided not to make a recommendation - but that also 
means that the analysis in that doc should not be taken as a 
recommendation either. This doc claims that RFC6967 says that a TCP 
solution may be possible, but that was based on only one candidate TCP 
approach *and* the TCP approach was considered roughly equivalent to 5 
of the other 7 approaches.

> ·The analysis in RFC6967 is specific to particular cases that span many
> administrative domains (read CGN). So, the drawbacks of several
> solutions discussed in RFC6967 are irrelevant for scenarios that are
> restricted to a single administrative domain (or where an administrative
> relationship is setup between involved parties).

Or behind home NATs.

Joe