Re: [hiaps] Draft Charter Revised

joel jaeggli <joelja@bogus.com> Wed, 15 January 2014 18:35 UTC

Return-Path: <joelja@bogus.com>
X-Original-To: hiaps@ietfa.amsl.com
Delivered-To: hiaps@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E12C1AE128 for <hiaps@ietfa.amsl.com>; Wed, 15 Jan 2014 10:35:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.438
X-Spam-Level:
X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] 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 Rc6xn_3COKIf for <hiaps@ietfa.amsl.com>; Wed, 15 Jan 2014 10:35:00 -0800 (PST)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id EA96C1AE125 for <hiaps@ietf.org>; Wed, 15 Jan 2014 10:34:59 -0800 (PST)
Received: from mb-aye.local (c-50-174-18-221.hsd1.ca.comcast.net [50.174.18.221]) (authenticated bits=0) by nagasaki.bogus.com (8.14.7/8.14.7) with ESMTP id s0FIYjIS026665 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 15 Jan 2014 18:34:45 GMT (envelope-from joelja@bogus.com)
Message-ID: <52D6D4BF.7070603@bogus.com>
Date: Wed, 15 Jan 2014 10:34:39 -0800
From: joel jaeggli <joelja@bogus.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:27.0) Gecko/20100101 Thunderbird/27.0
MIME-Version: 1.0
To: mohamed.boucadair@orange.com, "sarikaya@ieee.org" <sarikaya@ieee.org>, "hiaps@ietf.org" <hiaps@ietf.org>
References: <CAC8QAcdTNOPdhPfZrgg2SLerDs8b=DSHyVmXi7baLTdO6ZjwHw@mail.gmail.com> <94C682931C08B048B7A8645303FDC9F36F45EC4344@PUEXCB1B.nanterre.francetelecom.fr>
In-Reply-To: <94C682931C08B048B7A8645303FDC9F36F45EC4344@PUEXCB1B.nanterre.francetelecom.fr>
X-Enigmail-Version: 1.6
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="8opSl5qC1xFFSRrQwceu9cwSxbKHLFeFT"
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (nagasaki.bogus.com [147.28.0.81]); Wed, 15 Jan 2014 18:34:46 +0000 (UTC)
Cc: "Dirk.von-Hugo@telekom.de" <Dirk.von-Hugo@telekom.de>
Subject: Re: [hiaps] Draft Charter Revised
X-BeenThere: hiaps@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Host Identification, Address and Prefix Sharing in Wi-Fi Access \(hiaps\)" <hiaps.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/hiaps>, <mailto:hiaps-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hiaps/>
List-Post: <mailto:hiaps@ietf.org>
List-Help: <mailto:hiaps-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hiaps>, <mailto:hiaps-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Jan 2014 18:35:01 -0000

On 1/15/14, 6:52 AM, mohamed.boucadair@orange.com wrote:
> Hi Behcet, all,
> 
> I just read the proposed charter text. I don't understand why the scope is limited to the emergency case. IMHO, the emergency case is only a use case among others. I don't understand either why "Wi-Fi" access is mentioned in the title of the proposed bof.

my 12/12/13 observation was as follows

> Description: Host identification is required in IPv4 when the hosts are
behind a NAT box or
> when the communication is tunneled such as using IPSec. Host
identification is also
> required in IPv6 when the hosts are assigned addresses from a shared
prefix. In most of
> these scenarios, the hosts access the network using Wireless Local Area
Networks, aka
> Wi-Fi access. In case the hosts are behind a NAT box, there is a strong
need for the host
> identification when the host is accessing a fixed network and trying to
place an emergency >call.

It is likely given current events, that persistent identifiers visible
to on-path observers are going to be viewed by the IETF community in
general in an extraordinarily negative light. in particular in the IPv6
context I would think it antithetical to the goals of regular rotation
of temporary/privacy or cryptographically generated addresses to retain
host identity bindings that are visible outside a limited scope e.g. an
l2 domain and which persist across host address changes.

In terms of employing them for roaming, the question of how would they
be generated and where who they be stored becomes germain. What
semantics are they actually carrying and the question of persistence
further raises the  stakes with respect to revalation to remote observers.



> Cheers,
> Med
> 
> De : Behcet Sarikaya [mailto:sarikaya2012@gmail.com]
> Envoyé : mercredi 8 janvier 2014 21:14
> À : hiaps@ietf.org
> Cc : Dirk.von-Hugo@telekom.de
> Objet : Draft Charter Revised
> 
> Hi all,
> Based on the comments received so far and based on our contacts with ETSI, we have revised the charter. Please check the current version at:
> 
> http://trac.tools.ietf.org/bof/trac/
> Please direct all comments and support to the list.
> Kind regards,
> Behcet
> 
> 
> 
> _______________________________________________
> hiaps mailing list
> hiaps@ietf.org
> https://www.ietf.org/mailman/listinfo/hiaps
>