From Dirk.von-Hugo@telekom.de Mon Dec 2 00:50:59 2013 Return-Path: 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 6EA131AE27B for ; Mon, 2 Dec 2013 00:50:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.251 X-Spam-Level: X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, 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 aU3Yga13NVJM for ; Mon, 2 Dec 2013 00:50:57 -0800 (PST) Received: from tcmail13.telekom.de (tcmail13.telekom.de [80.149.113.165]) by ietfa.amsl.com (Postfix) with ESMTP id B49321AE27D for ; Mon, 2 Dec 2013 00:50:55 -0800 (PST) Received: from he113472.emea1.cds.t-internal.com ([10.134.93.130]) by tcmail11.telekom.de with ESMTP/TLS/AES128-SHA; 02 Dec 2013 09:50:52 +0100 Received: from HE113484.emea1.cds.t-internal.com ([10.134.93.124]) by HE113472.emea1.cds.t-internal.com ([::1]) with mapi; Mon, 2 Dec 2013 09:50:51 +0100 From: To: , Date: Mon, 2 Dec 2013 09:50:49 +0100 Thread-Topic: [hiaps] Host identifiers Thread-Index: Ac7r0DIeFoZMySK6SjmRDsKliOzhoQDatfqA Message-ID: <05C81A773E48DD49B181B04BA21A342A2C7602F526@HE113484.emea1.cds.t-internal.com> References: <68AE2650-6670-4FDC-83DC-112D662DABEC@cisco.com> In-Reply-To: <68AE2650-6670-4FDC-83DC-112D662DABEC@cisco.com> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: hiaps@ietf.org Subject: Re: [hiaps] Host identifiers 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 08:50:59 -0000 Dear all, I tend to agree with Dan that in our case the Host_id needs not to be the f= ull IP address but 'must [only] be unique to each host under the same share= d IP address' (RFC 6967) - so given that this shared address is available, = only e.g. those 8 bits are required for complete identification. However assuming a 'mobile scenario' the point of attachment (providing tha= t shared IP address) may change and at each such a handover the Host_id mi= ght have to change too. To prevent frequent change and follow-up signaling = we could try to re-use considerations in HIP (RFC 4423) (public key) or in = RFC 3986 (URI) .... and we would presumably end up in a more-byte consuming= definition (such as full IP address). What do you think? Best regards Dirk -----Original Message----- From: hiaps [mailto:hiaps-bounces@ietf.org] On Behalf Of Dan Wing Sent: Donnerstag, 28. November 2013 01:24 To: sarikaya@ieee.org Cc: hiaps@ietf.org Subject: Re: [hiaps] Host identifiers On Nov 27, 2013, at 12:07 PM, Behcet Sarikaya wrot= e: > Hi all, >=20 > I would like to ask a simple question and hopefully open up a discussion:= what is host identifier or HOST_ID?=20 >=20 > In RFC 6967, it is defined as: >=20 > due to address sharing, servers need > extra information beyond the source IP address to=20 > differentiate the > sending host. We call this information the HOST_ID. > The answer seems to be different for each use case. For prefix sharing, i= t is the sending host's IPv6 address. For hosts behind NAT, it is the sendi= ng host's IPv4 address. It doesn't need to be the sending host's IP address. For example, if all t= he hosts behind a NAT are in the 192.168.1/24 subnet, an 8-bit HOST_ID woul= d be enough to uniquely identify each host behind the NAT, and no purpose i= n using 32 bits. That is, the most significant bits of the IPv4 address ar= e not necessary. As another example, with an IPv6 client communicating to = a NAT64, the most significant bits of the IPv6 address are not necessary (b= ecause all of the subscribers using an ISP's NAT64 belong to that ISP, and = have been assigned IPv6 addresses from the ISP's own IPv6 prefix), and the = least significant 64 bits of the IPv6 address are also not necessary (becau= se IPv6 privacy addresses makes them pretty useless to identify a particula= r 'host'). So with NAT64 there are really about the same number of bits us= ed to identify a 'subscriber' as with IPv4 -- which is not much of a surpri= se. > What about other cases? For CGNs? CGN is just a big NAT, so same use-case applies. But need to think about i= mpact of VRFs or VLANs or similar technology behind the CGN, which could me= an there are multiple "customers" (users) with 192.168.1/24 subnets, but ea= ch connecting to that CGN using different VLAN (or VRF). If those all shar= e the same public IPv4 address, then HOST_ID would need to include the VRF/= VLAN number (if all that is necessary is identifying the 'subscriber') and = possibly also the subscriber host's IPv4 address (if the need extends to de= scribing the host, too). -d _______________________________________________ hiaps mailing list hiaps@ietf.org https://www.ietf.org/mailman/listinfo/hiaps From mohamed.boucadair@orange.com Mon Dec 2 01:00:33 2013 Return-Path: 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 31A871AE387 for ; Mon, 2 Dec 2013 01:00:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.549 X-Spam-Level: X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no 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 Jz1ul8r0LRAr for ; Mon, 2 Dec 2013 01:00:32 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id D13661AE370 for ; Mon, 2 Dec 2013 01:00:31 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id D7703324286; Mon, 2 Dec 2013 10:00:28 +0100 (CET) Received: from puexch91.nanterre.francetelecom.fr (unknown [10.101.44.48]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id BAD1E4C015; Mon, 2 Dec 2013 10:00:28 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by puexch91.nanterre.francetelecom.fr ([10.101.44.48]) with mapi; Mon, 2 Dec 2013 10:00:28 +0100 From: To: "Dirk.von-Hugo@telekom.de" , "dwing@cisco.com" , "sarikaya@ieee.org" Date: Mon, 2 Dec 2013 10:00:26 +0100 Thread-Topic: [hiaps] Host identifiers Thread-Index: Ac7r0DIeFoZMySK6SjmRDsKliOzhoQDatfqAAABG3vA= Message-ID: <94C682931C08B048B7A8645303FDC9F36F3566B0DD@PUEXCB1B.nanterre.francetelecom.fr> References: <68AE2650-6670-4FDC-83DC-112D662DABEC@cisco.com> <05C81A773E48DD49B181B04BA21A342A2C7602F526@HE113484.emea1.cds.t-internal.com> In-Reply-To: <05C81A773E48DD49B181B04BA21A342A2C7602F526@HE113484.emea1.cds.t-internal.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.12.2.11814 Cc: "hiaps@ietf.org" Subject: Re: [hiaps] Host identifiers 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 09:00:33 -0000 Hi Dirk, HIP can be used indeed, but this assumes every server is speaking HIP. This= by far a non-viable assumption. As for the discussion on the frequent change of the HOST_ID, the suggestion= to use a permanent identifier will raise a lot of privacy discussion and o= bjections. IMHO before having solution-oriented discussion, let's see first if people = understand well the problem space and the set of use cases identified so fa= r.=20 Cheers, Med=20 >-----Message d'origine----- >De=A0: hiaps [mailto:hiaps-bounces@ietf.org] De la part de Dirk.von- >Hugo@telekom.de >Envoy=E9=A0: lundi 2 d=E9cembre 2013 09:51 >=C0=A0: dwing@cisco.com; sarikaya@ieee.org >Cc=A0: hiaps@ietf.org >Objet=A0: Re: [hiaps] Host identifiers > >Dear all, > >I tend to agree with Dan that in our case the Host_id needs not to be the >full IP address but 'must [only] be unique to each host under the same >shared IP address' (RFC 6967) - so given that this shared address is >available, only e.g. those 8 bits are required for complete identification= . > >However assuming a 'mobile scenario' the point of attachment (providing >that shared IP address) may change and at each such a handover the Host_i= d >might have to change too. To prevent frequent change and follow-up >signaling we could try to re-use considerations in HIP (RFC 4423) (public >key) or in RFC 3986 (URI) .... and we would presumably end up in a more- >byte consuming definition (such as full IP address). > >What do you think? > >Best regards >Dirk >-----Original Message----- >From: hiaps [mailto:hiaps-bounces@ietf.org] On Behalf Of Dan Wing >Sent: Donnerstag, 28. November 2013 01:24 >To: sarikaya@ieee.org >Cc: hiaps@ietf.org >Subject: Re: [hiaps] Host identifiers > > >On Nov 27, 2013, at 12:07 PM, Behcet Sarikaya >wrote: > >> Hi all, >> >> I would like to ask a simple question and hopefully open up a discussion= : >what is host identifier or HOST_ID? >> >> In RFC 6967, it is defined as: >> >> due to address sharing, servers need >> extra information beyond the source IP address to >> differentiate the >> sending host. We call this information the HOST_ID. >> The answer seems to be different for each use case. For prefix sharing, >it is the sending host's IPv6 address. For hosts behind NAT, it is the >sending host's IPv4 address. > >It doesn't need to be the sending host's IP address. For example, if all >the hosts behind a NAT are in the 192.168.1/24 subnet, an 8-bit HOST_ID >would be enough to uniquely identify each host behind the NAT, and no >purpose in using 32 bits. That is, the most significant bits of the IPv4 >address are not necessary. As another example, with an IPv6 client >communicating to a NAT64, the most significant bits of the IPv6 address ar= e >not necessary (because all of the subscribers using an ISP's NAT64 belong >to that ISP, and have been assigned IPv6 addresses from the ISP's own IPv6 >prefix), and the least significant 64 bits of the IPv6 address are also no= t >necessary (because IPv6 privacy addresses makes them pretty useless to >identify a particular 'host'). So with NAT64 there are really about the >same number of bits used to identify a 'subscriber' as with IPv4 -- which >is not much of a surprise. > >> What about other cases? For CGNs? > >CGN is just a big NAT, so same use-case applies. But need to think about >impact of VRFs or VLANs or similar technology behind the CGN, which could >mean there are multiple "customers" (users) with 192.168.1/24 subnets, but >each connecting to that CGN using different VLAN (or VRF). If those all >share the same public IPv4 address, then HOST_ID would need to include the >VRF/VLAN number (if all that is necessary is identifying the 'subscriber') >and possibly also the subscriber host's IPv4 address (if the need extends >to describing the host, too). > >-d > >_______________________________________________ >hiaps mailing list >hiaps@ietf.org >https://www.ietf.org/mailman/listinfo/hiaps >_______________________________________________ >hiaps mailing list >hiaps@ietf.org >https://www.ietf.org/mailman/listinfo/hiaps From sarikaya2012@gmail.com Mon Dec 2 08:32:37 2013 Return-Path: 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 820531AC82B for ; Mon, 2 Dec 2013 08:32:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 jOhyPKm0N6Ag for ; Mon, 2 Dec 2013 08:32:36 -0800 (PST) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 0BF701AC499 for ; Mon, 2 Dec 2013 08:32:35 -0800 (PST) Received: by mail-la0-f49.google.com with SMTP id er20so8254262lab.36 for ; Mon, 02 Dec 2013 08:32:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:date:message-id:subject:from:to:cc :content-type; bh=MRvqPAdyT7IhhUcF4ovUT5OBYnDVwL12HwLKWrL3pDE=; b=rqSDyjjQlNQ3EgEVtIpYxHSs0i9C/fKurqSR02fDYW+t+6u7HJwgjzsf5LRPFMRKzC wDZxS4U7MlXFoc27hSeiS63bgmfXEfRZRYZy4ZbOjznprn6de3WfvD9QW0uixY7iuNEQ H4PpNTeSEwkS6VTxI6er+AClb/9MjFVqhtbrgw00QPXE1vXZ0C/jETdiX6aGvx3v5Iv1 ybXSpH2uxcfCOw8h58UCdK1MwGj3QjGwpxsUA5ceHf7+Xa9LwZ0h5Uo2NThKe82RNZez PdC8oIUZfBnpp5ljkbKeqvsoI+g0s+O86L7nudq2FtaHOGtL3T0LAK1SsE8Dig8rqwmV 856Q== MIME-Version: 1.0 X-Received: by 10.152.22.131 with SMTP id d3mr169041laf.52.1386001952684; Mon, 02 Dec 2013 08:32:32 -0800 (PST) Received: by 10.114.217.129 with HTTP; Mon, 2 Dec 2013 08:32:32 -0800 (PST) Date: Mon, 2 Dec 2013 10:32:32 -0600 Message-ID: From: Behcet Sarikaya To: hiaps@ietf.org Content-Type: multipart/alternative; boundary=089e0158b8660c3cbd04ec8fba1e Cc: Xueli , Mohamed Boucadair , "Dirk.von-Hugo@telekom.de" Subject: [hiaps] Hiaps use cases X-BeenThere: hiaps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: sarikaya@ieee.org List-Id: "Host Identification, Address and Prefix Sharing in Wi-Fi Access \(hiaps\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 16:32:37 -0000 --089e0158b8660c3cbd04ec8fba1e Content-Type: text/plain; charset=ISO-8859-1 I started a new tread on the use case issue that Med brought up. Based on what Med said in his previous mail: >IMHO before having solution-oriented discussion, let's see first if people >understand well the problem space and the set of use cases identified >so far. for this we currently have: http://tools.ietf.org/id/draft-boucadair-intarea-host-identifier-scenarios-03.txt and http://tools.ietf.org/id/draft-sarikaya-aps-prefix-sharing-usecase-00.txt We are expecting a new draft on this and I know we already have some people working on it. Regards, Behcet --089e0158b8660c3cbd04ec8fba1e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I started a new tread on the use case issue that Med = brought up.
Based on what Med said in his previous mail:
<= div>
>IMHO before having solution-oriented discussion, let's see = first if=20 people
>understand well the problem space and the set of use cases= =20 identified
>so far.

We are expecting a ne= w draft on this and I know we already have some people working on it.

Regards,

Behcet
--089e0158b8660c3cbd04ec8fba1e-- From dwing@cisco.com Mon Dec 2 11:29:23 2013 Return-Path: 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 106061A1F5F for ; Mon, 2 Dec 2013 11:29:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 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, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 Mvl8x1fidpjp for ; Mon, 2 Dec 2013 11:29:20 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 954451AD687 for ; Mon, 2 Dec 2013 11:29:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4529; q=dns/txt; s=iport; t=1386012557; x=1387222157; h=mime-version:subject:from:in-reply-to:date:cc:message-id: references:to; bh=oTkVf8GUiKhpeRFi8GytfL7ck6JbIthim+JqaZSzz5s=; b=AZNr65BPmqwcSFf70KlAxXDbhE1GPnDmbuWckEv7rDcu/hIKE9eDq/Hk lZWNjzNaJ/y8CgB5aql9M3VT+3Nua/lolm4BVH+6e57u1qUmNpR551JW4 4xRyHEDm6NnID1RT3TSNI2GzYbja2sm1L5DSvoI4BJ8Oft0IKBWqgyT6v 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuoGAD7enFKrRDoJ/2dsb2JhbABZgwc4sGqIUIElFnSCJQEBAQMBAQEBZAcLBQsLBEIhBjAGExuHVAMJBQ65Bw2GYheMd4FAAQFPBxaDCoETA4FTh2+MZ4FrgTCLKoU5g0obgTU X-IronPort-AV: E=Sophos;i="4.93,812,1378857600"; d="scan'208,217";a="96759115" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 02 Dec 2013 19:29:14 +0000 Received: from sjc-vpn7-1075.cisco.com (sjc-vpn7-1075.cisco.com [10.21.148.51]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id rB2JSouk014459; Mon, 2 Dec 2013 19:29:02 GMT Content-Type: multipart/alternative; boundary="Apple-Mail=_7E06083C-A8DC-42F4-80FB-C4D6E3FBC384" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Dan Wing In-Reply-To: Date: Mon, 2 Dec 2013 11:28:50 -0800 Message-Id: <726C15B0-DC5F-4438-8EEE-EEA650CE562E@cisco.com> References: To: X-Mailer: Apple Mail (2.1510) Cc: hiaps@ietf.org, "Dirk.von-Hugo@telekom.de" , Mohamed Boucadair , Xueli Subject: Re: [hiaps] Hiaps use cases 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 19:29:23 -0000 --Apple-Mail=_7E06083C-A8DC-42F4-80FB-C4D6E3FBC384 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Dec 2, 2013, at 8:32 AM, Behcet Sarikaya = wrote: > I started a new tread on the use case issue that Med brought up. > Based on what Med said in his previous mail: >=20 > >IMHO before having solution-oriented discussion, let's see first if = people=20 > >understand well the problem space and the set of use cases identified > >so far. >=20 > for this we currently have:=20 > = http://tools.ietf.org/id/draft-boucadair-intarea-host-identifier-scenarios= -03.txt It lists: (1) Section 3.1: Carrier Grade NAT (CGN) (2) Section 3.2: A+P (e.g., MAP ) (3) Section 3.3: Application Proxies (4) Section 3.4: Provider Wi-Fi (5) Section 3.5: Policy and Charging Architectures (6) Section 3.6: Cellular Networks (7) Section 3.7: Femtocells (8) Section 3.8: Overlay Networks (e.g., CDNs) (9) Section 3.9: Emergency Calls but none of those are the 'roaming' situation which I believe Dirk von = Hugo was concerned with, where he wanted an identifier to persist across = network attach points. (Veering into solutions, I wonder if an = MPTCP-like connection identifier would solve the problem, even if MPTCP = itself isn't used). -d >=20 > and > = http://tools.ietf.org/id/draft-sarikaya-aps-prefix-sharing-usecase-00.txt >=20 > We are expecting a new draft on this and I know we already have some = people working on it. >=20 > Regards, >=20 > Behcet > _______________________________________________ > hiaps mailing list > hiaps@ietf.org > https://www.ietf.org/mailman/listinfo/hiaps --Apple-Mail=_7E06083C-A8DC-42F4-80FB-C4D6E3FBC384 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1
On Dec 2, 2013, at 8:32 AM, Behcet Sarikaya <sarikaya2012@gmail.com> wrote:

I started a new tread on the use case issue that Med brought up.
Based on what Med said in his previous mail:

>IMHO before having solution-oriented discussion, let's see first if people
>understand well the problem space and the set of use cases identified
>so far.


It lists:
   (1)  Section 3.1: Carrier Grade NAT (CGN)
   (2)  Section 3.2: A+P (e.g., MAP )
   (3)  Section 3.3: Application Proxies
   (4)  Section 3.4: Provider Wi-Fi
   (5)  Section 3.5: Policy and Charging Architectures
   (6)  Section 3.6: Cellular Networks
   (7)  Section 3.7: Femtocells
   (8)  Section 3.8: Overlay Networks (e.g., CDNs)
   (9)  Section 3.9: Emergency Calls

but none of those are the 'roaming' situation which I believe Dirk von Hugo was concerned with, where he wanted an identifier to persist across network attach points.  (Veering into solutions, I wonder if an MPTCP-like connection identifier would solve the problem, even if MPTCP itself isn't used).

-d




We are expecting a new draft on this and I know we already have some people working on it.

Regards,

Behcet
_______________________________________________
hiaps mailing list
hiaps@ietf.org
https://www.ietf.org/mailman/listinfo/hiaps

--Apple-Mail=_7E06083C-A8DC-42F4-80FB-C4D6E3FBC384-- From mohamed.boucadair@orange.com Tue Dec 3 00:12:37 2013 Return-Path: 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 6C9351AE09B for ; Tue, 3 Dec 2013 00:12:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.548 X-Spam-Level: X-Spam-Status: No, score=-1.548 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no 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 W7LW9a7FBnpu for ; Tue, 3 Dec 2013 00:12:35 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 333F41AE074 for ; Tue, 3 Dec 2013 00:12:35 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id C66452DC1A8; Tue, 3 Dec 2013 09:12:31 +0100 (CET) Received: from puexch31.nanterre.francetelecom.fr (unknown [10.101.44.29]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id A502B238070; Tue, 3 Dec 2013 09:12:31 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by puexch31.nanterre.francetelecom.fr ([10.101.44.29]) with mapi; Tue, 3 Dec 2013 09:12:31 +0100 From: To: Dan Wing , "sarikaya@ieee.org" , "Dirk.von-Hugo@telekom.de" Date: Tue, 3 Dec 2013 09:12:30 +0100 Thread-Topic: [hiaps] Hiaps use cases Thread-Index: Ac7vlMyC4UTNDGDgTHWQ/WT0mMV6vAAY8+Og Message-ID: <94C682931C08B048B7A8645303FDC9F36F38DAB8D0@PUEXCB1B.nanterre.francetelecom.fr> References: <726C15B0-DC5F-4438-8EEE-EEA650CE562E@cisco.com> In-Reply-To: <726C15B0-DC5F-4438-8EEE-EEA650CE562E@cisco.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F36F38DAB8D0PUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.12.2.210914 Cc: "hiaps@ietf.org" , Xueli Subject: Re: [hiaps] Hiaps use cases 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 08:12:37 -0000 --_000_94C682931C08B048B7A8645303FDC9F36F38DAB8D0PUEXCB1Bnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, Dirk, would it be possible to have more details on the use case that requir= es a persistent identifier? Thanks. Cheers, Med De : Dan Wing [mailto:dwing@cisco.com] Envoy=E9 : lundi 2 d=E9cembre 2013 20:29 =C0 : sarikaya@ieee.org Cc : hiaps@ietf.org; Xueli; BOUCADAIR Mohamed IMT/OLN; Dirk.von-Hugo@teleko= m.de Objet : Re: [hiaps] Hiaps use cases On Dec 2, 2013, at 8:32 AM, Behcet Sarikaya > wrote: I started a new tread on the use case issue that Med brought up. Based on what Med said in his previous mail: >IMHO before having solution-oriented discussion, let's see first if people >understand well the problem space and the set of use cases identified >so far. for this we currently have: http://tools.ietf.org/id/draft-boucadair-intarea-host-identifier-scenarios-= 03.txt It lists: (1) Section 3.1: Carrier Grade NAT (CGN) (2) Section 3.2: A+P (e.g., MAP ) (3) Section 3.3: Application Proxies (4) Section 3.4: Provider Wi-Fi (5) Section 3.5: Policy and Charging Architectures (6) Section 3.6: Cellular Networks (7) Section 3.7: Femtocells (8) Section 3.8: Overlay Networks (e.g., CDNs) (9) Section 3.9: Emergency Calls but none of those are the 'roaming' situation which I believe Dirk von Hugo= was concerned with, where he wanted an identifier to persist across networ= k attach points. (Veering into solutions, I wonder if an MPTCP-like connec= tion identifier would solve the problem, even if MPTCP itself isn't used). -d and http://tools.ietf.org/id/draft-sarikaya-aps-prefix-sharing-usecase-00.txt We are expecting a new draft on this and I know we already have some people= working on it. Regards, Behcet _______________________________________________ hiaps mailing list hiaps@ietf.org https://www.ietf.org/mailman/listinfo/hiaps --_000_94C682931C08B048B7A8645303FDC9F36F38DAB8D0PUEXCB1Bnante_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi all,=

 

 

Cheers,

Med

&n= bsp;

De :<= /b> Dan = Wing [mailto:dwing@cisco.com]
Envoy=E9 : lundi 2 d=E9cembre= 2013 20:29
=C0 : sarikaya@ieee.org
Cc : hiap= s@ietf.org; Xueli; BOUCADAIR Mohamed IMT/OLN; Dirk.von-Hugo@telekom.de
<= b>Objet : Re: [hiaps] Hiaps use cases

<= /div>

 

&n= bsp;

On Dec 2, 2013, at 8:32 AM, Be= hcet Sarikaya <sarikaya2012@gm= ail.com> wrote:



I started a new tread on the use= case issue that Med brought up.

B= ased on what Med said in his previous mail:


>IMHO before having sol= ution-oriented discussion, let's see first if people
>understand wel= l the problem space and the set of use cases identified
>so far.=

for this we currently have:
<= a href=3D"http://tools.ietf.org/id/draft-boucadair-intarea-host-identifier-= scenarios-03.txt">http://tools.ietf.org/id/draft-boucadair-intarea-host-ide= ntifier-scenarios-03.txt

 

It lists:= 

 
=A0=A0 (1)=A0 Section 3.1: Carrier Gra=
de NAT (CGN)
=A0=A0 (2)=A0 Section 3.2: A+P (e.g., MAP=
 )
=A0=A0 (3)=A0 Section 3.3: Application Proxies=

=A0=A0 (4) =A0Section 3.4: Provider Wi-Fi
= 
=A0=A0 (5)=A0 Section 3.5: Policy and Charging Architectures
=A0=A0 (6)=A0 Section 3.6: Cellular Networks
=A0=A0 (7)=A0 Section 3.7: Femtocells
=A0=A0 (8)=A0=
 Section 3.8: Overlay Networks (e.g., CDNs)
=A0=A0 (9)=
=A0 Section 3.9: Emergency Calls

=  

but none of those are = the 'roaming' situation which I believe Dirk von Hugo was concerned with, w= here he wanted an identifier to persist across network attach points.  = ;(Veering into solutions, I wonder if an MPTCP-like connection identifier w= ould solve the problem, even if MPTCP itself isn't used).

 

-d

 

 



 

We are expecting a new draft on this and I kno= w we already have some people working on it.

Regards,

Behcet

_______________________________________________
hiaps maili= ng list
hiaps@ietf.org
https://www.ietf.org/mailm= an/listinfo/hiaps

 <= /o:p>

= --_000_94C682931C08B048B7A8645303FDC9F36F38DAB8D0PUEXCB1Bnante_-- From Dirk.von-Hugo@telekom.de Tue Dec 3 01:51:41 2013 Return-Path: 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 D45531AE0DF for ; Tue, 3 Dec 2013 01:51:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.25 X-Spam-Level: X-Spam-Status: No, score=-2.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 ysJXU8s16-OY for ; Tue, 3 Dec 2013 01:51:38 -0800 (PST) Received: from tcmail93.telekom.de (tcmail93.telekom.de [80.149.113.205]) by ietfa.amsl.com (Postfix) with ESMTP id 7BAA81A1F71 for ; Tue, 3 Dec 2013 01:51:37 -0800 (PST) Received: from he111628.emea1.cds.t-internal.com ([10.134.93.20]) by tcmail91.telekom.de with ESMTP/TLS/AES128-SHA; 03 Dec 2013 10:51:14 +0100 Received: from HE113484.emea1.cds.t-internal.com ([10.134.93.124]) by HE111628.emea1.cds.t-internal.com ([::1]) with mapi; Tue, 3 Dec 2013 10:51:13 +0100 From: To: , , Date: Tue, 3 Dec 2013 10:51:12 +0100 Thread-Topic: [hiaps] Hiaps use cases Thread-Index: Ac7vlMyC4UTNDGDgTHWQ/WT0mMV6vAAY8+OgAARcOgA= Message-ID: <05C81A773E48DD49B181B04BA21A342A2C760B5986@HE113484.emea1.cds.t-internal.com> References: <726C15B0-DC5F-4438-8EEE-EEA650CE562E@cisco.com> <94C682931C08B048B7A8645303FDC9F36F38DAB8D0@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36F38DAB8D0@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: multipart/alternative; boundary="_000_05C81A773E48DD49B181B04BA21A342A2C760B5986HE113484emea1_" MIME-Version: 1.0 Cc: hiaps@ietf.org, xueli@huawei.com Subject: Re: [hiaps] Hiaps use cases 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 09:51:42 -0000 --_000_05C81A773E48DD49B181B04BA21A342A2C760B5986HE113484emea1_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Med and all, Frankly spoken I had no dedicated use case in mind but just thought of the = several cases where a mobile terminal is involved at which an ongoing sessi= on may be active while moving between e.g. for Use Case 4: Open Wi-Fi or Pr= ovider Wi-Fi with visiting nodes, or UC5/6/7 which mention mobile operators= networks or services. Of course for sessions which start and complete while being served by an at= tach point under the same edge router no handover will occur. What I had in mind are applications requiring session continuity such as VL= AN connectivity for moving devices. With a new session set up and new credentials to be exchanged and agreed on= at each visit of a WiFi spot and corresponding service disruption the cust= omer may be not amused ... the newly assigned Host_id might be the minor pr= oblem. But maybe I misunderstood something here. Should we discuss on this? Best regards Dirk From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] Sent: Dienstag, 3. Dezember 2013 09:13 To: Dan Wing; sarikaya@ieee.org; von Hugo, Dirk Cc: hiaps@ietf.org; Xueli Subject: RE: [hiaps] Hiaps use cases Hi all, Dirk, would it be possible to have more details on the use case that requir= es a persistent identifier? Thanks. Cheers, Med De : Dan Wing [mailto:dwing@cisco.com] Envoy=E9 : lundi 2 d=E9cembre 2013 20:29 =C0 : sarikaya@ieee.org Cc : hiaps@ietf.org; Xueli; BOUCADAIR Mohamed IMT/OLN; Dirk.von-Hugo@teleko= m.de Objet : Re: [hiaps] Hiaps use cases On Dec 2, 2013, at 8:32 AM, Behcet Sarikaya > wrote: I started a new tread on the use case issue that Med brought up. Based on what Med said in his previous mail: >IMHO before having solution-oriented discussion, let's see first if people >understand well the problem space and the set of use cases identified >so far. for this we currently have: http://tools.ietf.org/id/draft-boucadair-intarea-host-identifier-scenarios-= 03.txt It lists: (1) Section 3.1: Carrier Grade NAT (CGN) (2) Section 3.2: A+P (e.g., MAP ) (3) Section 3.3: Application Proxies (4) Section 3.4: Provider Wi-Fi (5) Section 3.5: Policy and Charging Architectures (6) Section 3.6: Cellular Networks (7) Section 3.7: Femtocells (8) Section 3.8: Overlay Networks (e.g., CDNs) (9) Section 3.9: Emergency Calls but none of those are the 'roaming' situation which I believe Dirk von Hugo= was concerned with, where he wanted an identifier to persist across networ= k attach points. (Veering into solutions, I wonder if an MPTCP-like connec= tion identifier would solve the problem, even if MPTCP itself isn't used). -d and http://tools.ietf.org/id/draft-sarikaya-aps-prefix-sharing-usecase-00.txt We are expecting a new draft on this and I know we already have some people= working on it. Regards, Behcet _______________________________________________ hiaps mailing list hiaps@ietf.org https://www.ietf.org/mailman/listinfo/hiaps --_000_05C81A773E48DD49B181B04BA21A342A2C760B5986HE113484emea1_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Med an= d all,

Frankly spoken I ha= d no dedicated use case in mind but just thought of the several cases where= a mobile terminal is involved at which an ongoing session may be active wh= ile moving between e.g. for Use Case 4: Open Wi-Fi or Provider Wi-Fi with v= isiting nodes, or UC5/6/7 which mention mobile operators networks or servic= es.

Of course for sessions= which start and complete while being served by an attach point under the s= ame edge router no handover will occur.

What I had in mind are applications requiring session contin= uity such as VLAN connectivity for moving devices.

With a new session set up and new credentials to b= e exchanged and agreed on at each visit of a WiFi spot and corresponding se= rvice disruption the customer may be not amused … the newly assigned = Host_id might be the minor problem.

But maybe I misunderstood something here.

Should we discuss on this?

<= p class=3DMsoNormal> 

Best regards

Dirk=

From: mohamed.boucad= air@orange.com [mailto:mohamed.boucadair@orange.com]
Sent: Diens= tag, 3. Dezember 2013 09:13
To: Dan Wing; sarikaya@ieee.org; von = Hugo, Dirk
Cc: hiaps@ietf.org; Xueli
Subject: RE: [hiap= s] Hiaps use cases

 

Hi all,

 

Dirk, would it be= possible to have more details on the use case that requires a persistent i= dentifier? Thanks.

 

Cheers,

Med

 =

De : Dan Wing [mailto:dwin= g@cisco.com]
Envoy=E9 : lundi 2 d=E9cembre 2013 20:29
=C0 : sarikaya@ieee.org
Cc : hiaps@ietf.org; Xueli= ; BOUCADAIR Mohamed IMT/OLN; Dirk.von-Hugo@telekom.de
Objet : Re: [hiaps] Hiaps use cases

 

 

On Dec 2, 2013, at 8:32 AM, Behcet Sarikaya <= ;sarikaya2012@gmail.com> w= rote:

 

I started a new trea= d on the use case issue that Med brought up.

Based on what Med said in his previous mail:


>IMHO bef= ore having solution-oriented discussion, let's see first if people
>= understand well the problem space and the set of use cases identified
&g= t;so far.

=

 

It lists:

 
   (1)  Se=
ction 3.1: Carrier Grade NAT (CGN)
   (2)&nb=
sp; Section 3.2: A+P (e.g., MAP )
   (3)&nbs=
p; Section 3.3: Application Proxies
   (4) &=
nbsp;Section 3.4: Provider Wi-Fi
   (5) =
; Section 3.5: Policy and Charging Architectures
 =
;  (6)  Section 3.6: Cellular Networks
 =
;  (7)  Section 3.7: Femtocells
  =
 (8)  Section 3.8: Overlay Networks (e.g., CDNs)
=
   (9)  Section 3.9: Emergency Calls
 

but= none of those are the 'roaming' situation which I believe Dirk von Hugo wa= s concerned with, where he wanted an identifier to persist across network a= ttach points.  (Veering into solutions, I wonder if an MPTCP-like conn= ection identifier would solve the problem, even if MPTCP itself isn't used)= .

 

=

-d

=  

 

<= /div>

 <= /o:p>

We are expecting a new draft on this and I know we already have some peop= le working on it.

Regards,

= Behcet

_______________= ________________________________
hiaps mailing list
hiaps@ietf.org
https://www.ietf.org/mailman/listinfo/hiaps

 

<= /html>= --_000_05C81A773E48DD49B181B04BA21A342A2C760B5986HE113484emea1_-- From sarikaya2012@gmail.com Tue Dec 3 09:08:30 2013 Return-Path: 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 580411A82E2 for ; Tue, 3 Dec 2013 09:08:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 4Q3AWxBBZFup for ; Tue, 3 Dec 2013 09:08:29 -0800 (PST) Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 922451A1F66 for ; Tue, 3 Dec 2013 09:08:28 -0800 (PST) Received: by mail-la0-f48.google.com with SMTP id n7so9159725lam.21 for ; Tue, 03 Dec 2013 09:08:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=ydw3+9GspxWQ51smklUCP2ej3YwTX3Sz65RYO9INtEQ=; b=udEhjwri1g3I7Vc4rZC4O+63RRxfFmrtb4VlCjxiusrwLzGzeuP290katpxV6qH48E ARuYJM3Pm0TPC3xsItbOeMps0jUvE3qhCA9++YYOGwn2mTQfxXqwgxaYy7bxsj7sD0jG M+ab+0iXQYqCM1WtyZp0iFOMootVhWhTVJ4m8DkCW/5AHz+XE2W0oyrV0VtsAXOKEroL /BPBILjmRuoEheifBiCERL+uENQapcUAkzBdGqeVTPnZyBgswJdBCDadYFOVy/ndKYca Z38L2tkb7haKjMbqkIGRL7MMLERHWXzhIwmI9F1guKWu4rGC6eqP0isVGnxhm9kagLxd LElQ== MIME-Version: 1.0 X-Received: by 10.112.37.134 with SMTP id y6mr1096309lbj.29.1386090505194; Tue, 03 Dec 2013 09:08:25 -0800 (PST) Received: by 10.114.217.129 with HTTP; Tue, 3 Dec 2013 09:08:25 -0800 (PST) In-Reply-To: <726C15B0-DC5F-4438-8EEE-EEA650CE562E@cisco.com> References: <726C15B0-DC5F-4438-8EEE-EEA650CE562E@cisco.com> Date: Tue, 3 Dec 2013 11:08:25 -0600 Message-ID: From: Behcet Sarikaya To: Dan Wing Content-Type: multipart/alternative; boundary=001a1134d7d2304fbc04eca458ff Cc: hiaps@ietf.org, "Dirk.von-Hugo@telekom.de" , Mohamed Boucadair , Xueli Subject: Re: [hiaps] Hiaps use cases X-BeenThere: hiaps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: sarikaya@ieee.org List-Id: "Host Identification, Address and Prefix Sharing in Wi-Fi Access \(hiaps\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 17:08:30 -0000 --001a1134d7d2304fbc04eca458ff Content-Type: text/plain; charset=ISO-8859-1 On Mon, Dec 2, 2013 at 1:28 PM, Dan Wing wrote: > > On Dec 2, 2013, at 8:32 AM, Behcet Sarikaya > wrote: > > I started a new tread on the use case issue that Med brought up. > Based on what Med said in his previous mail: > > >IMHO before having solution-oriented discussion, let's see first if > people > >understand well the problem space and the set of use cases identified > >so far. > > for this we currently have: > > http://tools.ietf.org/id/draft-boucadair-intarea-host-identifier-scenarios-03.txt > > > It lists: > > (1) Section 3.1: Carrier Grade NAT (CGN) > (2) Section 3.2: A+P (e.g., MAP ) > (3) Section 3.3: Application Proxies > (4) Section 3.4: Provider Wi-Fi > (5) Section 3.5: Policy and Charging Architectures > (6) Section 3.6: Cellular Networks > (7) Section 3.7: Femtocells > (8) Section 3.8: Overlay Networks (e.g., CDNs) > (9) Section 3.9: Emergency Calls > > > Are these use case well understood? Any issues with them? There is also interest in combining Med's use cases draft with the prefix sharing use case draft and also in the process concentrating on some of them like emergency calls, CGNs and prefix sharing. What do you think? Behcet > but none of those are the 'roaming' situation which I believe Dirk von > Hugo was concerned with, where he wanted an identifier to persist across > network attach points. (Veering into solutions, I wonder if an MPTCP-like > connection identifier would solve the problem, even if MPTCP itself isn't > used). > > -d > > > > > > and > http://tools.ietf.org/id/draft-sarikaya-aps-prefix-sharing-usecase-00.txt > > We are expecting a new draft on this and I know we already have some > people working on it. > > Regards, > > Behcet > _______________________________________________ > hiaps mailing list > hiaps@ietf.org > https://www.ietf.org/mailman/listinfo/hiaps > > > --001a1134d7d2304fbc04eca458ff Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Mon, Dec 2, 2013 at 1:28 PM, Dan Wing <dwing@cisco.com> wrote:

On Dec 2, 2013, at 8:32 AM, Behcet Sarikaya <sarikaya2012@gmail= .com> wrote:

I started a new tread o= n the use case issue that Med brought up.
Based on what Med said i= n his previous mail:

>IMHO before having solution-orien= ted discussion, let's see first if=20 people
>understand well the problem space and the set of use cases= =20 identified
>so far.


It lists:
   (1)  Section =
3.1: Carrier Grade NAT (CGN)
   (2)  Section 3.2: A+P (e.g., MAP )
   (3)  Section 3.3: Application Proxies
   (4)  Section 3.4: Provider Wi-Fi
   (5)  Section 3.5: Policy and Charging Architectures
   (6)  Section 3.6: Cellular Networks
   (7)  Section 3.7: Femtocells
   (8)  Section 3.8: Overlay Networks (e.g., CDNs)
   (9)  Section 3.9: Emergency Calls

=

Are these use case well understood? Any is= sues with them?

There is also interest in combining Med&#= 39;s use cases draft with the prefix sharing use case draft and also in the= process concentrating on some of them like emergency calls, CGNs and prefi= x sharing.

What do you think?

Behcet
= =A0
but none of those are the 'roaming' situation = which I believe Dirk von Hugo was concerned with, where he wanted an identi= fier to persist across network attach points. =A0(Veering into solutions, I= wonder if an MPTCP-like connection identifier would solve the problem, eve= n if MPTCP itself isn't used).

-d



=A0

=

We = are expecting a new draft on this and I know we already have some people wo= rking on it.

Regards,

Behcet
_______________________________________________
hiaps mailing list
hiaps@ietf.org
http= s://www.ietf.org/mailman/listinfo/hiaps


--001a1134d7d2304fbc04eca458ff-- From dwing@cisco.com Tue Dec 3 15:49:28 2013 Return-Path: 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 192D11AE1E6 for ; Tue, 3 Dec 2013 15:49:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 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, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 wU71fWpVGa17 for ; Tue, 3 Dec 2013 15:49:20 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 6D9C71AE1D5 for ; Tue, 3 Dec 2013 15:49:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8275; q=dns/txt; s=iport; t=1386114558; x=1387324158; h=mime-version:subject:from:in-reply-to:date:cc:message-id: references:to; bh=c/1jI7/o2XROBxiwD3eR+TwG7l1Vl6ArjcYkFAnhrLk=; b=eTkMmt8QLvVYT7pVeySOQHcd7RksMkOIyujN0KytjGp5MaWbD/1yzGNF qC2D3ta3lucSwXMl9bfFPP/q9F/eZkzvY+Vqk8HADDN6B10ZNq3nNfGtf W1kWrwvANxBQ84CfwC7QUIoQS3ZubFlesVc7kyVdABLRQ7aGPWiZl1Xz7 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlIGAEdtnlKrRDoJ/2dsb2JhbABagwc4sGqIUYEbFnSCJQEBAQMBAQEBZAcLEAsYLiEGMAYTG4dUAwkFDrlxDYcxF4xtgUABAUsEB4MggRMDgVOHb4xngWuBMIUVhhWFOYNKG4E1 X-IronPort-AV: E=Sophos;i="4.93,820,1378857600"; d="scan'208,217";a="99439487" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 03 Dec 2013 23:49:15 +0000 Received: from [10.155.144.85] ([10.155.144.85]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id rB3NnCsn017641; Tue, 3 Dec 2013 23:49:12 GMT Content-Type: multipart/alternative; boundary="Apple-Mail=_45B5FBA2-70B1-4749-AFBC-0152D89BE88A" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Dan Wing In-Reply-To: Date: Tue, 3 Dec 2013 15:49:12 -0800 Message-Id: <2DD9F847-2802-49D5-8118-0CBCEE22F855@cisco.com> References: <726C15B0-DC5F-4438-8EEE-EEA650CE562E@cisco.com> To: X-Mailer: Apple Mail (2.1510) Cc: hiaps@ietf.org, "Dirk.von-Hugo@telekom.de" , Mohamed Boucadair , Xueli Subject: Re: [hiaps] Hiaps use cases 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 23:49:28 -0000 --Apple-Mail=_45B5FBA2-70B1-4749-AFBC-0152D89BE88A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Dec 3, 2013, at 9:08 AM, Behcet Sarikaya = wrote: >=20 >=20 >=20 > On Mon, Dec 2, 2013 at 1:28 PM, Dan Wing wrote: >=20 > On Dec 2, 2013, at 8:32 AM, Behcet Sarikaya = wrote: >=20 >> I started a new tread on the use case issue that Med brought up. >> Based on what Med said in his previous mail: >>=20 >> >IMHO before having solution-oriented discussion, let's see first if = people=20 >> >understand well the problem space and the set of use cases = identified >> >so far. >>=20 >> for this we currently have:=20 >> = http://tools.ietf.org/id/draft-boucadair-intarea-host-identifier-scenarios= -03.txt >=20 > It lists: > (1) Section 3.1: Carrier Grade NAT (CGN) > (2) Section 3.2: A+P (e.g., MAP ) > (3) Section 3.3: Application Proxies > (4) Section 3.4: Provider Wi-Fi > (5) Section 3.5: Policy and Charging Architectures > (6) Section 3.6: Cellular Networks > (7) Section 3.7: Femtocells > (8) Section 3.8: Overlay Networks (e.g., CDNs) > (9) Section 3.9: Emergency Calls >=20 >=20 > Are these use case well understood? Any issues with them? I understand the first 4. I understand the rest less. Specifically, = overlay networks (8) I understand because I have chatted several times = with Brandon, but the I-D doesn't adequately motivate the use-case. = Emergency calls (9) is all over the map -- discusses solutions (which I = believe is out of scope for the document, or should be?), some of which = cannot work (specifically the location when using VPN cannot work). Not = sure of use-case #5, 6, or 7. -d >=20 > There is also interest in combining Med's use cases draft with the = prefix sharing use case draft and also in the process concentrating on = some of them like emergency calls, CGNs and prefix sharing. >=20 > What do you think? >=20 > Behcet > =20 > but none of those are the 'roaming' situation which I believe Dirk von = Hugo was concerned with, where he wanted an identifier to persist across = network attach points. (Veering into solutions, I wonder if an = MPTCP-like connection identifier would solve the problem, even if MPTCP = itself isn't used). >=20 > -d >=20 >=20 >=20 > =20 >=20 >>=20 >> and >> = http://tools.ietf.org/id/draft-sarikaya-aps-prefix-sharing-usecase-00.txt >>=20 >> We are expecting a new draft on this and I know we already have some = people working on it. >>=20 >> Regards, >>=20 >> Behcet >> _______________________________________________ >> hiaps mailing list >> hiaps@ietf.org >> https://www.ietf.org/mailman/listinfo/hiaps >=20 >=20 --Apple-Mail=_45B5FBA2-70B1-4749-AFBC-0152D89BE88A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 sarikaya2012@gmail.com> = wrote:



On Mon, Dec 2, = 2013 at 1:28 PM, Dan Wing <dwing@cisco.com> wrote:

On Dec 2, 2013, at 8:32 AM, Behcet Sarikaya <sarikaya2012@gmail.com> wrote:

I started a new = tread on the use case issue that Med brought up.
Based on what = Med said in his previous mail:

>IMHO before having = solution-oriented discussion, let's see first if=20 people
>understand well the problem space and the set of use = cases=20 identified
>so far.


It = lists:
=
   (1)  Section 3.1: Carrier Grade NAT (CGN)
   (2)  Section 3.2: A+P (e.g., MAP )
   (3)  Section 3.3: Application Proxies
   (4)  Section 3.4: Provider Wi-Fi
   (5)  Section 3.5: Policy and Charging Architectures
   (6)  Section 3.6: Cellular Networks
   (7)  Section 3.7: Femtocells
   (8)  Section 3.8: Overlay Networks (e.g., CDNs)
   (9)  Section 3.9: Emergency =
Calls


Are these use case well understood? Any issues with = them?

I = understand the first 4.  I understand the rest less. =  Specifically, overlay networks (8) I understand because I have = chatted several times with Brandon, but the I-D doesn't adequately = motivate the use-case.  Emergency calls (9) is all over the map -- = discusses solutions (which I believe is out of scope for the document, = or should be?), some of which cannot work (specifically the location = when using VPN cannot work).  Not sure of use-case #5, 6, or = 7.

-d



There is also interest in = combining Med's use cases draft with the prefix sharing use case draft = and also in the process concentrating on some of them like emergency = calls, CGNs and prefix sharing.

What do you = think?

Behcet
 
but none of those are the 'roaming' situation which = I believe Dirk von Hugo was concerned with, where he wanted an = identifier to persist across network attach points.  (Veering into = solutions, I wonder if an MPTCP-like connection identifier would solve = the problem, even if MPTCP itself isn't used).
=

-d



 


We are expecting a new draft on = this and I know we already have some people working on it.

Regards,

Behcet
_______________________________________________
hiaps mailing = list
hiaps@ietf.org
https://www.ietf.org/mailman/listinfo/hiaps



= --Apple-Mail=_45B5FBA2-70B1-4749-AFBC-0152D89BE88A-- From Roland.Schott@telekom.de Wed Dec 4 02:35:46 2013 Return-Path: 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 81A1A1AE252 for ; Wed, 4 Dec 2013 02:35:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] autolearn=no 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 txIshwPMNsd6 for ; Wed, 4 Dec 2013 02:35:39 -0800 (PST) Received: from tcmail33.telekom.de (tcmail33.telekom.de [80.149.113.247]) by ietfa.amsl.com (Postfix) with ESMTP id D2B1C1AE0E6 for ; Wed, 4 Dec 2013 02:35:37 -0800 (PST) Received: from he111631.emea1.cds.t-internal.com ([10.134.93.23]) by tcmail31.telekom.de with ESMTP/TLS/AES128-SHA; 04 Dec 2013 11:35:33 +0100 Received: from HE111648.emea1.cds.t-internal.com ([10.134.93.17]) by HE111631.emea1.cds.t-internal.com ([::1]) with mapi; Wed, 4 Dec 2013 11:35:33 +0100 From: To: , Date: Wed, 4 Dec 2013 11:35:31 +0100 Thread-Topic: [hiaps] Hiaps use cases Thread-Index: Ac7wglGajninLQZAQAK81fNj2YUgkwAV2QUQ Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D18DE8F3762@HE111648.emea1.cds.t-internal.com> References: <726C15B0-DC5F-4438-8EEE-EEA650CE562E@cisco.com> <2DD9F847-2802-49D5-8118-0CBCEE22F855@cisco.com> In-Reply-To: <2DD9F847-2802-49D5-8118-0CBCEE22F855@cisco.com> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: multipart/related; boundary="_004_580BEA5E3B99744AB1F5BFF5E9A3C67D18DE8F3762HE111648emea1_"; type="multipart/alternative" MIME-Version: 1.0 Cc: hiaps@ietf.org, xueli@huawei.com, mohamed.boucadair@orange.com, Dirk.von-Hugo@telekom.de Subject: Re: [hiaps] Hiaps use cases 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 10:35:46 -0000 --_004_580BEA5E3B99744AB1F5BFF5E9A3C67D18DE8F3762HE111648emea1_ Content-Type: multipart/alternative; boundary="_000_580BEA5E3B99744AB1F5BFF5E9A3C67D18DE8F3762HE111648emea1_" --_000_580BEA5E3B99744AB1F5BFF5E9A3C67D18DE8F3762HE111648emea1_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, regarding (5) Section 3.5: Policy and Charging Architectures RS: I do not understand why double NAT is not described or allowed (6) Section 3.6: Cellular Networks RS: do we have here also the use case for using private Ipv4 addresses? (7) Section 3.7: Femtocells RS: this use case seems similar to the WiFi use case and belongs IMHO to the "use case" heterogeneous networks in general (9) Section 3.9: Emergency Calls RS: This is a general use case and must be discussed for all use cases What about the use case where mobile and/or fixed access are backup links f= or each other, e.g. BBF use case? Is it included in Overlay Networks? [cid:image003.png@01CEF0E4.F017BBA0] Regards Roland Von: hiaps [mailto:hiaps-bounces@ietf.org] Im Auftrag von Dan Wing Gesendet: Mittwoch, 4. Dezember 2013 00:49 An: sarikaya@ieee.org Cc: hiaps@ietf.org; von Hugo, Dirk; Mohamed Boucadair; Xueli Betreff: Re: [hiaps] Hiaps use cases On Dec 3, 2013, at 9:08 AM, Behcet Sarikaya > wrote: On Mon, Dec 2, 2013 at 1:28 PM, Dan Wing > wrote: On Dec 2, 2013, at 8:32 AM, Behcet Sarikaya > wrote: I started a new tread on the use case issue that Med brought up. Based on what Med said in his previous mail: >IMHO before having solution-oriented discussion, let's see first if people >understand well the problem space and the set of use cases identified >so far. for this we currently have: http://tools.ietf.org/id/draft-boucadair-intarea-host-identifier-scenarios-= 03.txt It lists: (1) Section 3.1: Carrier Grade NAT (CGN) (2) Section 3.2: A+P (e.g., MAP ) (3) Section 3.3: Application Proxies (4) Section 3.4: Provider Wi-Fi (5) Section 3.5: Policy and Charging Architectures (6) Section 3.6: Cellular Networks (7) Section 3.7: Femtocells (8) Section 3.8: Overlay Networks (e.g., CDNs) (9) Section 3.9: Emergency Calls Are these use case well understood? Any issues with them? I understand the first 4. I understand the rest less. Specifically, overl= ay networks (8) I understand because I have chatted several times with Bran= don, but the I-D doesn't adequately motivate the use-case. Emergency calls= (9) is all over the map -- discusses solutions (which I believe is out of = scope for the document, or should be?), some of which cannot work (specific= ally the location when using VPN cannot work). Not sure of use-case #5, 6,= or 7. -d There is also interest in combining Med's use cases draft with the prefix s= haring use case draft and also in the process concentrating on some of them= like emergency calls, CGNs and prefix sharing. What do you think? Behcet but none of those are the 'roaming' situation which I believe Dirk von Hugo= was concerned with, where he wanted an identifier to persist across networ= k attach points. (Veering into solutions, I wonder if an MPTCP-like connec= tion identifier would solve the problem, even if MPTCP itself isn't used). -d and http://tools.ietf.org/id/draft-sarikaya-aps-prefix-sharing-usecase-00.txt We are expecting a new draft on this and I know we already have some people= working on it. Regards, Behcet _______________________________________________ hiaps mailing list hiaps@ietf.org https://www.ietf.org/mailman/listinfo/hiaps --_000_580BEA5E3B99744AB1F5BFF5E9A3C67D18DE8F3762HE111648emea1_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

= reg= arding

 

 
   (5)  Section 3.5: Policy and C=
harging Architectures
&=
nbsp;
RS: I do not understand why=
 double NAT is not described or allowed
 
&nbs=
p;
   (6)  Section=
 3.6: Cellular Networks
 
RS: do we have here also =
the use case for using private
Ipv4 addresses?
&nbs=
p;
 
=

   (7)  Section 3.7: Femtocells=

 
RS: this use case seems similar to the WiFi use case =
and
belongs IMHO to the R=
20;use case” heterogeneous networks in general
 
&n=
bsp;  (9)  Section 3.9: Emergency Calls
 
RS: This is a=
 general use case and must be discussed for all use cases=

 
 
What about th=
e use case where mobile and/or fixed access are backup links for each other=
,
e.g. BBF use case? Is it included =
in Overlay Networks?
 
 
 
 
 
Regards
 
Roland
 
 <=
/p>
 
=
 
@ieee.org
Cc:=
 hiaps@ietf.org; von Hugo, Dirk; Mohamed Boucadair; Xueli
Betreff=
: Re: [hiaps] Hiaps use cases
 
 
On Dec 3, 2013, at 9:08 AM, Behcet Sarikaya=
 <sarikaya2012@gmail.com&g=
t; wrote:


<=
div>
 
 
=
On Mon, Dec 2, 2013 at 1:28 PM, Dan Wing <dwing@cisco.com> wrote:

 
On Dec 2, 2013, at 8:32 AM, Behcet Sarikaya <sarikaya2012@gmail.com> wr=
ote:


<=
div>
I started a new tread on the use case issue that M=
ed brought up.
Based on what Med s=
aid in his previous mail:

>IMHO before having solution-oriented dis=
cussion, let's see first if people 
>understand well the problem spac=
e and the set of use cases identified
>so far.
for this we currently have: 
http://tools.ietf.org/id/draft-boucadair-intarea-host-ide=
ntifier-scenarios-03.txt
 
It =
lists:
   (1)  Section 3.1: Carrier Grade NAT (CGN)
   (2)  Section 3.2: A+P (e.g., MAP )
   (3)  Section 3.3: Application Proxies<=
o:p>
   (4)  Section 3.4: Provider Wi-Fi
   (5)  Section 3.5: Policy and Charging A=
rchitectures
   (6)  Section 3.6: Cellu=
lar Networks
   (7)  Section 3.7: Femto=
cells
   (8)  Section 3.8: Overlay Netw=
orks (e.g., CDNs)
   (9)  Section 3.9: =
Emergency Calls
 =

 
=

Are these use case well understood? Any iss=
ues with them?

 

I understand the f= irst 4.  I understand the rest less.  Specifically, overlay netwo= rks (8) I understand because I have chatted several times with Brandon, but= the I-D doesn't adequately motivate the use-case.  Emergency calls (9= ) is all over the map -- discusses solutions (which I believe is out of sco= pe for the document, or should be?), some of which cannot work (specificall= y the location when using VPN cannot work).  Not sure of use-case #5, = 6, or 7.

 

-d

 



<= /p>

 

There is also interest= in combining Med's use cases draft with the prefix sharing use case draft = and also in the process concentrating on some of them like emergency calls,= CGNs and prefix sharing.

What do you think?

Behcet

&nbs= p;

=

but none of those are the 'roaming' sit= uation which I believe Dirk von Hugo was concerned with, where he wanted an= identifier to persist across network attach points.  (Veering into so= lutions, I wonder if an MPTCP-like connection identifier would solve the pr= oblem, even if MPTCP itself isn't used).

 

-d

 

 

=


 



We are expecting a new draft on this and I know we alrea= dy have some people working on it.

Regards,

Behcet

_______________________________________________
hiaps mailing list
= hiaps@ietf.org
<= a href=3D"https://www.ietf.org/mailman/listinfo/hiaps" target=3D"_blank">ht= tps://www.ietf.org/mailman/listinfo/hiaps

 

 

 = ;

= --_000_580BEA5E3B99744AB1F5BFF5E9A3C67D18DE8F3762HE111648emea1_-- --_004_580BEA5E3B99744AB1F5BFF5E9A3C67D18DE8F3762HE111648emea1_ Content-Type: image/png; name="image003.png" Content-Description: image003.png Content-Disposition: inline; filename="image003.png"; size=27667; creation-date="Wed, 04 Dec 2013 10:35:31 GMT"; modification-date="Wed, 04 Dec 2013 10:35:31 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAZQAAADbCAYAAABKvGetAAAAAXNSR0IArs4c6QAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAGuTSURBVHhe 7d0FmG1V2QDgNVy6QdCfkhYEVEAURLq7BAGlJEQBQUAU6RAMkFaQblApQUJAQlKlJQQlLqkgISF9 z7/edd3XwzBz5/ScfWZ9z3OemTmz99prfWvtr6OvEiFkyBhoIwYcsTfeeCM9YcyYMeGVV14Jb7/9 dujr62vjU/PQIwUDztTkk08epplmmrTkiSaaKEw66aQjZfldtc6+zFC6aj9KP5l//etf4dVXXw1v vvlmePrpp8NDDz0UXnzxxfDRj340TDjhhImJTDXVVOn3LMuUfru7YgHOkXP12muvJUFlkkkmCc8/ /3w6Z/PMM0+YaaaZwpRTTpn+/r//+7+umHOvTiIzlF7d2Q6tC+O45557whNPPBHefffd8NhjjyVG 8clPfjLMMMMMSWokMfrppS8Yiu8yQ+nQJvX4Y5wpZ+/1119PGrAPoeb9998P//nPf5Jg8+ijj6bf MZiJJ544MZbFFlssTDvttD2Onc4uLzOUzuK7J5723nvvhccffzzcdNNN6WXFOCaYYIKw4IILps8U U0yRmIjvMmQMDDcGMBhn9q233kqM5e67707MheY8/fTTh6WWWirMO++8SYvJ0BwGMkNpDn8j7u7b brst3HzzzeGFF14IiyyySGIg888/f5L6MmQMlAUDmMzf/va38OCDD4Zbb701MZMlllgirLjiiskc m6ExDGSG0hjeRtxdo0ePDhdddFF46qmnwvLLLx+WWWaZcU7QEYeMvOCewgBTGa3ld7/7XdKqN9xw w/DpT3+6p9bYqcVkhtIpTJf4OV60K664Imkka6yxRnKwZ8gY6DUMMINdc8014frrr0/+lU033TSM GjWq15bZ1vVkhtJW9JZ7cE7zX/3qV+GOO+4IW2+9dXK0Z8gY6HUM8AuedtppyWG/7bbbhskmm6zX l9yy9WWvactQ2XsDnX/++eGBBx4Ie+yxx4eYiaiuf/zjHx9aNEfn3//+9wGRwTFqPOGd1SAa5/bb bw8vvfRSYFrzQg8FDz/88AfGkdvCHs423k4wvjV4XobexMCss84adt111/DOO++EU045Jf3MUBsG MkOpDU8j7qo777wz3HfffeFb3/rWgCauyy67LHzpS18K//znP8fhBqPYaKONwjnnnDMgvtiqf/jD H36I4dCEOPm9uGeccUYw9lBwyCGHhN13330cA7n33nvDj370oxQ+OhD89re/TXbyZsH4nvOXv/yl 2aHy/V2MAU56Z5/gcOWVV3bxTLtraqViKFEADddeG8Lll4do02/+c911lRAF3Qz9MIDw85msvvrq YcYZZxwQP6K6JC3+4Q9/SCGZtIxbbrklMaHBomSKvBMhxdXg+rXXXjvlBgjtrCU/Re4BU5znVcNg 2ffXxoNz//33N73XRUJmLXNs+mF5gGHFgDO+ySabJO1ZmHyGoTEw6oAIQ182vFc880yIqmcl/PnP IZpZQpSK+9LPZj8sK5EmRRNGCHPNFWL+RC4FYqfvuuuulCS25pprDsocvGSf+MQnkqS++OKLJ+fl 0UcfHZZeeulkcxbbj4AfccQR6RrhxRjJ73//+/T/q6++OmU0zzzzzIkZXXLJJSknwLWkQ05R4ZzH HHNMSpp0fzWj8nzfmesqq6ySos9oKeutt14ynR155JHhhhtuSIlssvcPO+ywNMepp546mdVmn332 dD2tRQ4CcxmGKASaye7www+P5+3PYb755kt5NRis7xEW4abWPMsss4Rf/vKXaR0f+chHhvclyU9v CwacSVo4QWeuSCRyuaDxo7nrGcq//x3CSSeF+PL2hS237IvEoy+GrIYWffrCwgv3RQIRwh//WImh gn2ROLTlXJZqUCo+IomoDwYIOn8C4i/qS4QMYqu8BclOZvzPf/7zsNJKK6U6XpdHtfKLX/xiOOus sxLBR5BvvPHGxFxoJvvvv39iEM8++2wizhiagACRNr4TaSZUuXihL7300jSejGimNnOgsXz+859P TOxzn/tcmHPOOcPJJ58c93jhxDAEFbjfc31nTpiWezAMz8Hg3L/ssssmBnjBBRek/++7776BGZAm pTLAQgstFM/MH8MzUdpZcskls+O2VCe8vskW1SBEOeYclfHjrutNXjfeWIn1eSrhK18JMeqivoNQ y9UEy6226gtPPtkX/vrXXCcTzhBpxfbGB2omIeLrr79+YhIIN+Yx99xzp3pKL7/88jgth7aiJAvC z4S2ww47JE1inXXWSRoIOzUGVJiT/MSEaAgIPsL93HPPfUA65MvAzJjlMDcZ0P7G5BD84j5mOZqE vAIS5sYbb5zGOf7445Pzn8Zi7rSpXXbZJc1RHah11103aT5PPvlk+HeUatSD8v/PfOYzycS32267 Jds65+10001Xy1HL15QUAwQkplXnOkPJGcoLL/RFRqIGVPu2kkl/4on7olO4jQ9p3/RbOjKCzMQz VI0j1zFVMQlgAP7+2Mc+lohtUU+piLhCwF0raYzmweQERIlhMDQB1/JLFD8xDNoOExSmscEGG3xg ncZjhlh00UUTU7j44ovT/91vPsxYn/3sZ8N2222XtAcMqXDY00IwCXMX0YOhKR+DcBTrMpZ5F/Px e8FkaWMYDvMexuTvDL2LAecyM5Pa9rfrNZTxMRIb3d85WhAxBAfRICkX0vJgKImXJmgn06ptO7rj qoKwDzUbmsxss82WiDKijvgjzgg3gu7DVHT22WeHVVddNTEILyZ/iSgtJqq99torfe8eRNuzMQrm KWYr1/BdDPRCF3tN4/F8kWIYIbMUZkVTYV4DSmoI9xXWvNVWWyW7+GqrrRY233zz5H+hMWF4tBlM ar/99kva0worrJDGND/MsgDrMY7v+Y6K8vxD4Sz/v5wYyHXpatu3rvehRJoQCUwIX/jChxd0wgkn JALB8QrY8EmMn/rUp8JPfvKTcOKJJyZHq5BRREOtnoGcalIXRI8tsECIBLI2xPXqVQg6XwEzToHX gdaK8PJ5uM7vcE7ip6VgBpze/s8h7m+mJpoIrQFxFyJMymdKAhz8zGXMUn7OMccc6Scm4X4EvPql 9r/CYU6zYFbj18Dg+Efcx4yGuRTMjubFTOd79xcFAa3TWObnGmYt8zaHr371q+k7/hj30HbcZ31+ Z1f3fOvoH73Wq2dkpK2LdsusqkoE32KGwTHQ9ZnyMWE1Sr0h2qo/vIiddtop2ca//vWvp3+K2jn4 4INTRM/3v//9FPLn/yRLRIGpYyCGQvCMl0cHcIjS6cg+LqT+X/ziF4mwI+IZMgZGOgZEEh511FHh uOOOS8JJhsEx0PUmr/FtHiZRLTEICy1KUDNTkB4RRtIvKXqwkD+mrrfffic6ZmV456zY/MJkDGQM ZAw0goFSM5SBkst8xwTBpi2jmenroIMOCuedd96gCXPqv/3736+GnXb6WvjmN7dLuRLV9vJGEJvv yRjIGMgYGGkYKDVDYZ6p1jrY2IuoHL+z6YsikucwVGgn+/drr70aTjjhzBTOylwmT4HjOUPGQMZA xkDGwNAYKDVDEWFTXbuJdsLZKyJo0kknjdrGN8PXvva15GMR0TOYyYtTfppppo6azE+TloIZXXjh hYmxqFclz0LEWIaMgYyBjIGMgR71oWy55ZYpYY6JSnip7OnNNtssaSWifHwvIcn/lMsYrP4ShoLZ rLPOSuHYY0+NEV/XpuQ74/h9iy22SAzp2GOPTfkMGTIGMgYyBjIGPoyBrtdQotIxKMgXkEegLtSp p54aQ4u/MC5MVFkOtZx8rwS10h3jK+jnOdHtkkBZkJ/97GfpfnkSwkWFDe68884pe/rHP/5xeOSR R/J5yhjIGMgYyBiowkDXhw0rCvnqq30Dhg3XspOYSC0F3WIljZiNHWI+w4dHld8iGe/0008fV932 4x//eKoz9ZVYE6aX2oXmsOFaTlW+phoDhel5oHI9KiMwPw9UA0uNrKIyQ/V4klElJqvpphSOxNfh TCzMYcO1n/eu11BiPlmsrVSJJTtqX1T1lbUwk5jDFg9wJfpRBlaHJLWp2UQTkiyp5IYaTzQVmdTf +MY3wm233dbYBPNdGQMlx4CqBEzNTMzVwCqwzTbbpOTjgUDxT4nI/UFdNTll6rOptJCrEJTngHQ9 Q1lqqb4QlYFogqrEUhohVQZu5eeOOyoxYWlMLPMRYumQ8dfykgWuNpToL90MZWErNSIRcOWVV05Z 1arWKh2SIWNgpGBAhKQ+7JqjFWffT++F9gCD9WUX6DIQs1FVWqFRJZOUyGl3F86Rsk+dWGfXm7wg IWrG4ZprQvjTnyoxqqsvqr+tQQ1n/MQTV5KZKyoasXRGfcUhFQVU2oWf5qqrrkrMhWrPz8K3g8mU rU9GNnm15myNpFEEvMj5kkVe+DWZh2kZTFZaLqn3RhCj2avAIOG4KJ2kPQDwvgCBNkxeTGI//elP UxsEZW5oNML41V1TQqdTkE1etWO6FAylWI7Wzgo5tqqII0e8pMaYB9kUIMJMXpotSaBUBwqQtOSz qJRLuykDZIZShl3qrjk+HNueYg6qU6hUIUJSmRIMgQbCXOz9KJqn+U4rAIEurlPTzXdq7amXJSCG cMaMduihh6YPZkKA46ehtTClMUV3AjJDqR3LLZL1a39gM1ci/FFQiU6+1nyM1SwzsR4OQ1FlqtMK M1ZHTAFB7XG9XCQvkpYXL0PGQC9iAAOQs8Wfor8M4q8gKLMVbUPEJDOWqEnfCXTx3igg+u1vfzvs s88+ScvX/ExJJWYyATWukVvGP0PYwbSuieYKaQEZug8DpWIo3Ye+D89IpVoSlQrHzAAiwEhm3/nO d8Jaa60Vvve9732oD3oZ1pXnmDEwPgxgGsxQgmCYtZh+5XH5Hvi+iNTys2iRwEyGedA8fIcR+X8R TFMwFT8xK4yEr5LJLEP3YSAzlDbtiYKUmAcnPRVem1h9PdQWkyRJc7npppvGvXBtmkYeNmOg7RjA NPg2MJGNNtoonXPaiXBiPhRAE9FF88wzz0xl/lX+pnnQSvggVQiX/6W1AWc9pz6NRNgx5qLQqzYG fDH+zg2v2r6tDT2g6/uhNLSqLrqJBKZRFHMAbYUExlmpvS27MDOYOH0vSjf006i1H0oXoThPZZgx QKPQ8XKB2FDIT34UScY0D+dfrxwmYc57ocByt3wHhN1jOu5R+cI7oLgrDUTPGTX4aP0c91pB62tE IPP/TuWm5H4otR+wUjnla19W917p5Skiw0S9YDBeIpFh6o55wYYqZNnO1WWnfDuxm8cuIwayU772 Xcsmr9px1ZIrZf2SsGgn/CwKWJLiMJcNN9wwRbycdNJJ2enYEmznQTIGMgY6iYHMUDqJ7X7PWn75 5VOMvQgWTnstZ/lVVEemsRx++OEpGiZDxkDGQMZAGTCQGUoX7BIbMafkddddlyLD2KLviWUB9thj jxRqqfyESLEMGQPdjgEhwWpx9VKDuoHqkHX7PgzX/LJTfrgwP8Bz+U6Wimn766+/fmpbLERSXSP5 LBdddFEKxywahtVSo6yRpWWnfCNYy/eotyWxV607eSKy3Z3hgQpGNoMtPr7Ro0cnx307g1i8e4cc ckiqUi444MEHH0z5ZAJoMgyOgcxQuvB08LMstthiKTJMNIwQShrLn/70p3DuueemsEzJXw56qyNd xsdQhGoK4zQfL3Orn92FWzFuSkNVrR7s/0XLhP4CAFwKtyX9DjV2N+OlmJuEXiHyP/jBD5K5lulW iwfZ760UfjAUmvs888yTOrG2C0Rh7rjjjkmYU/likkkmSQ332snE2rWWTo6bGUonsV3ns9QvEmpM YxGGKa6f5Iex/PrXv04/SWpi+lslOQ3GUJjcdtppp5TJLHeA5rTQQgu1XAKtE0Udu1y5DwmriFh1 HSkRQEceeWT47Gc/OyAufvOb36SoPjWuqgGhonHav6OOOiqFlvu9jCCUV2HIrbfeOuWKEHb0EBJo opYdLcXZdYZEOQotLgAO4Me5cy1NpzCbuQYDUXjy+eefD7PNNls6//obEaaKthHCiWkQ9gXhdy2h 55lnnkml7wcrTjk+XM8000xpzgVj1K5Cfb4M48dAZiglOCGkIuYDRfGUzveCeLHks2AspClJYnJZ xPM3A4MxFHWXvLQHHXRQCm2mnTDDzTLLLKUrgNkIfhA6yagS+NSbInXD1e67756CKrbffvtUwLA/ YL5yLxRErAaMCZF64oknUsQf6bdVQkEj62vmHoSbdrLVVluNW8M000yTeghhLHfeeWc6N0Lk1fTC YKzd+VW1W+DJAw88ENtHTJPqf8GlrHj170RCYkRyWDAJSY/q5anjpVaeM4hx0YbkdPFHnnPOOckn iUH7uxEfiHskWjKveT7NnNUAI8swOAZK5ZR/770QHnooxENZiVm3oSWfO++sRImmHEfEC7Lsssum sOIrr7wyqf6kNs58kWFKu5CWMZtWAwaCCBQJZ3w9JFMvHPDTi80cV4CXkCkEISkAU0J8EIwyAWKG kWLu1gloH6RqhAdDB0yT7O4c0wCTIJEjSohmAcbzQbiK2lX+J5scg6rGWRnwRJPob9oq/saE4UmN O0xZJeK//vWviaFgFHwTkgcxjyILnrlXcAothAnNOT/rrLOSJiebHlMHmLECrLQ8pfKdQ3jla5RA 2QyTJpwJklHlAtNU5LId71YZ9rfWOZZGQ9Fx98wzK9HME6JE0xclOz+b+6C7Dz7Yl8ria/8777x9 LatkXOsGNHKdl45m4EX0YiFY1HwvKGLmxUTQfF9vlePBNBQvFMnv6aefTmYAjEKZDaHPXmQvOyJB UizMDBgfk5CXcL755ku/k1oxlYeiZGBu1eaPRnDRqXs4aTFLDAXBYoKEZ34QjB7RIYmTnpkD4WHh hRdOGgjmbz9oeYob0iSVIIEPPjLmL9F8cIqZkLTdB2fNEMRO4cZzrFdk1/zzz58eCxf2mGbmJ2EE zgSecN7TuOHusssuS9c707Q0P42laR2mqqkdZnzHHXckPH/5y19OTIRg5fxceOGFidHT+DB4+wB3 QvBl5zcLtCZzveCCCxKzYvqUR1ZW82Sz+Bjq/lIwlEjDYgXTSrTZhyiN9MUNVRq++U88k/HQhSjN 9EU7bYj23b54eFpXHn8o5Lfi/wjycsstF1ZfffXkqET4SMJ8HQgeYl5EhtXiRB+MoTDbMK2Rxklu JFIJmUwPHMzTTz998qkgpl48DM8LrqYTM4GXX6lyBJLpDuFl72ZGKAOopsuWj+hhnBg4Zy1ihlGQ mnUftA8k2dNOOy0RUdI5RsRZTbpW5t2ekciZ0QqGghAy0yCUvuMnQIDrFQiGA5c0LHtJ4HAOaK6Y Bu0CXpwb+027xTSdGwm88EJDgzOMFl6cK0KRJF/nyH20FeXtjWM8WiBCT4Oh0WFMTGHOPW3GdZg+ k1grgInZWWaOIzx5RwhStbxPrXh+mcYohcnrkksqUeUNkRD1xQM7luC36hPfgyhJhljBtC+aYipR kizT9v1vrl7Wb33rW0miU2zPi+XFRsRpMkxi/tdofgBpEYHYdttt02e33XZL/hs2cS8WokoSFyiA wLBdi5IhgZK4EQ7SveswOlKfCKAyAdyZN+ZCYsYQtCngvC2q4mKYpGxr9Z174A2hpZn4G3NGgIsI L9e5ntkMDhFdjMX1ZQF7ycREe8BYBCEwRQEEn9DjbCDKziktlonWdSIXSf78LYQfWjfGQkNjIhOG 7H5M11li6sWojbvnnnsmxuO5ShcRXhSSbKWggpmpJcZkZ28lHDPbZfgwBkqhoUS/W5TaQnyZ6+uo WM+GR5oQo5f6ouQR4mGv587uupZj2AslMozKjxF4CUltGADpbnyRYYNpKMbgYMa4SNdMM8wX1H8+ BZoQE5jvSXS0Jc8iZXvZMZhnn302SZXuAcwUomnKALQRxH7NNddMzEF/D02eMBCOYcSRqQbBROiY s0jIcIXBF85pa6WhYUj2RhVe+MP0aT7Gp8lgUu7BnMsAhAp7bv5wYb+LEFt4o5Wovk3DLb7HUGlj Wmn73tmlqYiYc4YQb74TWgnGTZPB0J07Z9wz4Qez8VwaIXCNubQKmHudZb1cMBd7RzAyh1xG/4NY LgVDufbavmha6YuHqv4j4uUm7RR9qQeLiY8acyQSIdqyQzTp1P+cbrsD0/BiMReQdr2gHKBeDOYI oZZwQQquTj4bjKG4ny2cScsYXmp2buYvTILUft999yXNiDkIUfDCs3GrV8Yc5gVkMigYE2ZDUi8D OEe0C5Ivc57QVoQQMK9gAgIVbr755mRuhHdSuzBZkrZIJveQzhFNAQsYKoLEZCh6D374mPgfEFj7 10jIa7fhkyZnrZhCGUEAiX1lhqMl0bT4AZ1lzK4sfsBO4L4U1YajphlfuBBV4Q+ixIssM9eLXbQD 5eBk6iGxCFV0mBFXLy0Jh+Q+EEQhJOy3X4i5BiHarTuB+s4/A6HCTIRqwhFAIJkqODsRSvCLX/wi OTX7h7p2fsb5iRkDw4+BotqwvkZMdd4jvkGmS74gGiitNUPsXltmJJAYmViKHu7WQgonfbPJMiFI RiIhS8obn81ef/koUEcVuswYGf/caQ0afHkhtCRmF6a+84fQLJSagD8MuJHY/d7FXF5ZrRjgU6t+ H2u9r7iOSYkGwBzIrFiEX9c7Die9cHpCZ6ugqHrgPfrxj3+cmAtnvYALJsoM0bcdkRRJaXfDYBoK 7YOzWaVe5gJw9tlnJ7PMFltskWLTaTC1gBbVG230WIwe+VGUNv4TTWSjarmtdNcwoTAzMUeJikEA ihwKi2G3F1nkJRHJ0q2A6IiEcgbaaRYqTKVMVRhwJ4EJEeM3h+GMKEIimPycB+/VYCGzTJlMdvwe u+yyS0NJts7jEUcckbRk6+djkcNSC/BXIfBaBJszwZIpsdnQ68H6oXDOf/e7303nD60RhDLiAUPp dthzz0rl8ss/PMtoh65Ec00lbvi4f8Z8iEp0/lWik7gSnb+VuNGVqJJW4gGtxAM26FJfeqlSmW++ WzDX/Ik4iC9HJUp5XXs0YpRNR/cpCiodx0Ukjh1d41BnP5p3Kt65wSBqv5Wo7VYi06lETaMhfEVn d3qno4ZS9/3Rx1fZYIMNKtE6Ufe947shavSVaOn40PsQhZlKjHhMexSZXiUm7Lb0uWUcrCc0FGGE ksiAkEWJUBzGtBdONBEmfCicwCJCBoJoIQvbbfdCdGBfHp2m70apsPdljeoABb+TtJjAhERyogpf 5UsBVHqOSZFipD9OaL4XpjHmCer/QAEPruWY5vgn5bqfpFv4axrFsqgyCZbV2lWjYw11H7zwNZF+ RfzQ8ERzcciypVeDwAW1qYSwNqs5SSIVIdUNYB8FF4gcHMgcSpvgm+OLoxnQqLbbbrsUyCEiiulJ eC/NRWSfiDjBCyK+5KN4V0Vp0Tz1CJKTI+Sc39P7y08hGMTZ4bdw1oSfM3nTYpR9kfsjs522YG9E 3zF5O5/yf9QN23TTTVP0HXMaZzs/CP+H/aJ52Ttn1L4KjPDd+Do2GsN7IEdJxB4fpZ8jFsrABQfT UCKhqkQneyVGW4xbBsk1HtpKjMKoxANd8/KeeqpS+frXK5UodIx4iEUQK/GlrkQf1ThcxBemEmss VSIRqERCnnAcX+BKjF5KGmFkOAPiLRKSJLVGApL+H1/giOPyITlmX1difkQlRq1VImOtwEf0N31o zdHsU4kRXpXI6EbUOYrEPb4/8QWKAAfFuxeFkkqMVquwHMTw6Mo+++yTzkJkHJUorFSi2bISGUcl 9vxJZ4M2EItMViLxr0TmlN7j6K+oHHzwwQnvxx57bLo3VoWoRCaRziLNKAbgpLMZw68rNBXPoFGh EXvvvXe6z/+d4ciY0t/RF5L20djGMi5NJDKpSnTAV6IJLa1nMA2l2ODITNMaaSoxGKgS/T4jau+r F1tqpzypVzSXOH6SkFwLjnhx/kDeg+9IQ76XRT4YSJTkV4v5UiMahPwKaxUKXC1h+14QBOlOeCyJ kN9K+CSNsHDEusZeFFFk7vP/ouaXMOXCpm0/isJ7kE7qJwn73t51E9CE+AZIx6R0mm51rgMNmKRt bfBnHcD3tCnamfUVIIzYmewFoAHQBmgiAjz4Lf1OowDC1jfbbLOUsCjXRJkeGoa/VSiWt8JPwv9Z +Gf8n2ZCG+IbEV4N74JrOMX9TXtWF47fRdi6MGuJjSI+nV3305ScQcmlzi5/lGuNby/to2RKmqf7 jC2R0hmv1XdDQ+LrEkqPFu2///5pv0cilIKheDcR/P7gsBQls6m61GKx4g6Jw6Cc9dFHH53UZxFM 1NIMg2OA+o9BeyH6R9d4gZm1EAsvMROj5DWO2KLwIdMWRzmnKrwzFWDozCFF5I7uk54jUVIhS/ui ZImXHhFi+ojSY3pB3d8twMwlcvCYY45JdbhOPvnkNF8gosgarPvSSy8dVxUAE+Jcts4DDzwwREk4 ETQEi1nG5+KLL06BBWUGpjl76h0Uwo+pMIkK4cdACBPqa1knYq7EPUYhotDHuRHd5XsCCbxhyMXP QtjwU8ANYYOpSwCAGmgAgyjGdx88Y+bAWP7np/Fdy4RbCEzMcb4zJ6ZNpi5rMedaAVPcL+YdGIPJ zhkeiVAahjLY5jgI0RGXXk4hsSQMgJmwmyo94nuEoEhEG2iseA6S36T7Y97ad0wRBtKgl7u/P8SL JvzaNWzfGIeXE+5JoPxTXlq+EeUyEAcvFps3e7bseGN6Sb3w7N1s6fYIM+ErIOmSatmk7SNi3C1A eDFv6y+qLEtUlKAo2sd5wxwRFIQMLjAS2gpmQmJFPJUMseZCy7NGGnRZwboQd5FV/B32mybBV4JQ 08RobQQRpUuE7ivJApc+mHM0gyW/A2HQmXI9fPuJCThjIhKdK2VaMCDaiIRCfj2ainPjHGEwaoEB WfTF/QQf2g0/EO3b+IUviLCA8dk3PhRjOn80jnrA+8F3Cyf2nI9nxEEZjH3RnF857rgxbZ1qNMlW dthhTLR/tvc5bV1Ek4PHFyr5Bdic+0esiJwpfAZ8K7GGUiU6YStRO6lE81clSoSVaNKpRKdkJRZH TPbr6OhMM2KXjuadivFdy8YdQ72TXR1Eya4SKxNXorSeng2iCaUSX84mV9S629nk+QissRqiplWJ BSIr0eSXvhalZN78Aezp0Wmbvme3jwStEplQJSaMVmKZmnjedkhjFrb61s22cyM5C/ZzIB9aZL6V yDAqO++8cwWeIrEeN7GopaX1wyucFcC/FjWa5IPys8B3ZCjJ12LMAqKZqhKd6ykiLAaTpD0wD+fU fe4v/ID8IFFoqUQNKd3uPBd7E02s4/aA/8PcnNUChvKhVGNbdFvM6Ur+lMi8kq9nJEEpNJRo6owR GSFGUFSirTNEG3tIPUxa8TFWDGyK9abGxEqyIUol7asX1u3SCulZ90e5KP0jlJiuSOCkcxoMqY7f pJDISY1MW0w+W265ZYrYoe0wcQD3kNxI7n6SCPlKSJU0E9IoibUwtZEWW5mU1grcW29hchExREOh ZakowIdAe6F5WSuNhUbsez4UHQ1dT0sTVST6iDQrT6KVLXJbsc56xnBOlKwfKPKLtgoP9pxGIeKy ANczOynHwsRUQNF8S/SXM1T422gVzErV0YHOKu3YWaJRMHMbl2/Lfe4vzrEilLRkVYoLC0ZRyZmm U7QTppXQchotT29vmWvNtyhk6YyPFChF2LDN4KONZaGi2aAS1djW9S1h5pp66sp/S+KPXGbi0Eta Q/wQCIX8qvtJYDYcjkKJo8SVXhj+K2YF4aJeZqXcCyep2l1+FzrqJeUPEVLKDCZ0E+Hgh/DSeQ4z iJBlTv4o0aawTn9LWu0GwOii9pSYnzVzsCvoyDyH+XEoM7tw7MKPTo5AGClmzPSFCTF3wQWcGUuF AuOUpQhkvXvh3Pj0r5zMVIjB+r7bGer4woYHw4fK3syAhBDVuZVtaZRJ1Yvz4by+NAylQFI8hy3P EYnCTNzs4dyG4X82wu4FKHpKYCjVEmUxQxoHgimCplqLQVSLQo+0FQ589nDaiO/93wtVTTxoJAgL hlO01O1m4mLdtKYie54UXU0kMIii0CapHPMlOSugiTkqlMlZS4ouxqkuzDn8pyDPYCAMNMJQjIOJ CFDwHnDyy5frdSgdQ+n1DRnO9TFR0VQ4WYVZFhE0wzmnsj4bsxRVSEvDgGggGDbNrZuZZlnx3c55 N8pQCFM0bAFDBCzmUFWoexkyQ+nl3a1xbSRvoZgkZ3ZlrXvlXBR9S2ocJl82AAaEFPMVsOnTVDKU DwMYipBw5lqaeT1g/wkSzMVC7/UGKiJR6xmnLNeWwilfFmSWdZ7MWNRxxQ/l8iCAhTO9rGvqlnlz AnP6ZmbSLTtS/zxolHxgjWiW9l9YueRH/knv2fgSrOufXXfdkRlKd+3HsMyG7R8DEaXEJyA6ptFW wcOygPzQjIE2YkAAhiixRqsWC3KRkyQikBlUhWLvXC9CZii9uKt1rkkopogrSV3rxNhpoZyywoW/ ZsgYGMkY4P8SUCEUuWhd3Ag+JPeqlEBgU3yVX6UXITOUXtzVOtekYqqoI1nMbMTyUGQSi1LKkDEw kjFAyBL6K0y+WVDRWNQX0G9ISHmvQWYovbajda4HIyE5kaC0TOY/4ZyPmdxJMuumelp1Lq1jl4vm ESrtM1KLAnYM2R18kKhHUXoSKlvRN56QFitMpEgvZjS/F/XgOristj4qM5S2orf7B8dAOAllwFPv i9wSCWdqKKkMe+utt3b/QoZxhpytktdUYFYkMUP5MaCgJb+HIpet7NTJSS8nRaVude0kwBaVucuP tZK0AO4FRHfzGkhiivgV7X+r5xp7zaQscCUuFP9rxo7czThoZm7Kp8v2F36tsGB1hYFmxs33Dg8G VDYQ3quApxL37QDN4TTx8u4p7a+CQi9US8gaSjtOS4nG5HyX1a2eUlHbqHr6JClVWtXpkuXtZ4YP YoBWpxqAn812acy4HT4MKI0j14SZS0+ldjETK1TD7Yc//GE6NwQ2ocUEkrLDqAMilH0Ref6NY0Cv GKXGqd20kIE0EKVRlGHhb9GWVRl20Srqd7ELj3TQnEnxR/4T9c36160a6fjp9vVrjKbkveRDpfAV N61untau+atGoaKCvjF8KcL19RgqM2RqUObda8Hc5ZvI5i0q/g42JEc9x73ELAyGSUCPGX3WlWvp BemqBejMQ5QEA7RyBUhp3cJ4BVSo/qxwqTIpnQDCmJwURVMJa4qPMpmWGXLplTLvXgvmXrTslcmt Um6tUDQj0u5XUqQXQvIXPwzHo8xiL+ZI0GD4mfhNSJs6U8JDhu7BQFHx2Dnls1AVmjZJMJKDxVfi vA4XCOrAyJwdQQCENZpSGSEzlDLuWovmrHy4F8xLVfSJaGRoJh9aikz72FAoZdnr7c3JWFQZFnap dAWTGl8NX0MvaDXWg6Eov2/dRa0m0XMZOoMB5wozly/iJyGmyK3SK8W+8I8QehBsdeowECambhF4 /vjHPyYnvegyPyUal7FcT2YonTnzXfkU7WeZsPTk0NK3GaZSLNDLi4nIsvdSs08zJ3A+Fm1XCwLQ lUipY1IYIi0sdqMMXJGkXj8lwSnL30jtpzoeny/9Lwbsg7NVtEDwNfxrDcAXUjAQAs5AjcC6BZF6 5PDByVHZa6+9UkO7skFmKGXbsRbO97jjjguHHnpoivA677zzGq5VVO+U2K9J8L1AcAUnkC7XWGON xEiV/pe3kDWUek9F49djKDTFXgi7xUT23XffFPQi4gyDKRNkhlKm3WrxXL2INAjSHd9HhsYwEHuO pzBQ5hbROosttlhjA+W7RjwGmOW23377cOaZZ6a2xAS95ZZbrjR4yVFepdmq1k6UGYpkTRLKzKQ5 3FaXW8lVmpvD5Ui/W0Vjdb6E6TMZizzjoysLZIZSlp1q8TyZZkg+6gopAZEhYyBjoDswwOejGrFI L6bTMpW6zwylO85Qx2dBknZgVRfO5VQ6jv78wIyB8WJANBonvTyvMpXyyT6UEXywhfqSfoQNZ6bS +EGQP0Db40ORmKYNQIaMgZGIgayhjMBd5/hTAI8fRSx+ZiYj8BDkJWcMtAEDmaG0AandPqQCj8sv v3xYYYUVUnZuhoyBjIGMgVZgIDOUVmCxZGNI+uI/kS0syitDxkDGQMZAKzCQGUorsFiyMWgm8iUu ueSS8MlPfrJks8/TzRjIGOhWDGSG0q0706Z5yZlQfl6XRuGJah1lyBjIGMgYaAUGMkNpBRZLNMbD Dz+cOi/qu3DppZeWaOZ5qhkDGQPdjoHMULp9h1o8P3W0VPtV1kGDrAwZAxkDGQOtwkBmKK3CZEnG kTB13XXXpS5xyjtkyBjIGMgYaBUGMkNpFSZLMA7/iWKQjz76aCq7nvNPSrBpeYoZAyXCQGYoJdqs ZqcqM36rrbZK5dXPOuusZofL92cMZAxkDHwAA5mhjKADQUOhmcw444xhpplmGkErz0vNGOhuDPBt Pvvss6XvYpoZSnefs5bObtZZZ025J7LjV1tttZaOnQfLGMgYaBwDeupodjdUYzZN3DpRfXjMmDGp NJOf9UBmKPVgq+TX8p3IQZF7oiVvhoyBjIHuwABGgoBrejc+0HbinHPOafukX3nllXDkkUfWzbwy Q2n71nTHA0g1+sfrJvjjH/94yIPbHbPOs8gY6E4MYACiJX/3u9+Nl+hqYnfKKaeEp59+OhVkfeaZ ZwZckK6pyiCNGjUq8HWyIvzrX/8Kp556aqpgDWgnv/zlL8PJJ58czj777HHPfemll1JOmWcVDOmu u+4Kjz/+eHrmDTfcEGhAkpmvvfba5D/tr+U8+OCD4cILLwxPPfVUepZ7POOHP/xhUPuvVsgMpVZM lfw6qqu8k+mmmy4wffVCP/eSb0mefkkxgGgj1Aj/v//973DbbbcNaKq6/vrrA8I+zTTTJEJ9wAEH hAceeGC8q55wwgmD5OP9998/WRMmn3zyoPYe5sAHOuWUU6bPFFNMkVp3v/nmm+n5/ueae++9N41P izn66KODvkfGPOyww8JFF12U7sG4HnnkkUALAU8++WRiGpiZkky+Z8UonlNPNGhmKCU91PVO2+E4 8cQT04EW6ZUhYyBjoDEM3HHHHeGvf/1r2GSTTcKXv/zlQEO4//77PzCY9wwz2XTTTcOGG24YFlxw waC9L4I+FLgGI5l33nnTM/g7f/WrX6WQ/2WXXTYsvfTSYf3110/jXXXVVUkr8fdaa62VGAPNxv2K v37hC18ISy21VLpGMI46fhtvvHFqL0wDofVcdtll6br11lsvzDnnnOGWW24JiyyySFh44YXDjjvu WFe9v6FXN9Tq8/9LgQEqLbWXdJL9J6XYsjzJLsUADeKII44Iu+++e9htt93Cueeem7SVasBwaBiI OtAZFUGnSQwFrplhhhnC9NNPP+5SGo4oMBqHfkYF3Hjjjcks9b3vfS99rr766qS10Db0OgLMW5hP 8bfvaD18qsZjAtt3333T/db1l7/8JWlcGsbRwOqBzFDqwVZJryWd/PSnP01SyK677poOXIaMgYyB xjDAbKweHk3fZ4cddgjzzz//BwbTHoKEXwBN4NVXX63Z1OydrY6wYnZiukLoqx33mMQGG2yQ5rHt ttuGrbfeOpm2XVdt1vZ7NTOjBRnP96pnbLbZZmGLLbZIa7E2zzbnettbZIbS2Jkq1V0Oh/pdXgSS T64wXKrty5PtMgwwIa200kppVvwjiL38rptuuimZlcFCCy2UNIwrrrgiaQLMVUxjrAOXX355Ct+v BgyA1gCKiK/q/8tT8VEhnDmLc997vdFGGyWTlO+YtTEAzMK1hSaDAWFmtJECaB8vv/xyogUYifsw IkyGNsNHw/z1xBNPpOizWiEzlFoxVeLrqL8HH3xwuOeee8J3v/vdEq8kTz1jYPgxgInQPm699dZk YuIfwTxo/gVTwDhWXHHFRMg5yBHzT3/604mAM0H1j7JSrHWJJZZIiyP8sSZUaxif/exnkzDIh4JZ /fa3v00aBAYz++yzJ4c7Pw5tA0NQTXyeeeZJ42ESX/ziF9P9BdBsjOkZrjVv83TvfPPNl67FaESY YYa1Ql/kXuMPfK51pHxd12LgscceSxINtZwdN0NrMSDEc7nllks2Zy9gQRha+5Q8WrdhwH4jnwP5 JDnG+VAwCn4ITnAawdprr500iUbAszCAwhyF+BdMBzMrzGKNjm0Mmk410HIIpLVGemUNpRHsl+we ksfKK6+c7KtU4QwZAxkDzWNgfAEumAZH/DXXXBPOO++8pE2suuqqDTMTsy2YB5MWTadag/E3TaRR MFZ/ZmIsTKtWZuL6zFAa3YES3Ud9pUb7mSO8SrRxeaqlxQBCzBTG2f39738/rLPOOh+I2irtwoaY eDZ59erOVq2LikwFJ9lU21FHwNI7ssRs8uoImvNDSoCBzFBKsEnNTPGf//xnSrCSJFU46ZoZL9/7 YQxkhjIyT4WoLaVXZM1zwK+yyirJPCQnhamLViL6qxXAiS8ybPnllx+wUrg8s9NOOy09iq9l7rnn Tia2ueaaK30n18Q8WSg48jnvaVDMckCNMIIn03g18AnyrfT/frA1jTiT14svvpgcpwjtSAAHZY01 1kix6uoJZcgYyBhoHgOSG6+88spkSvZ+CblFVxB+jEbNrSLiq/mnhRQCLFuec38gUH5FORU5JD4L LLBAikAT+SV4QBSY3Bj/E0Em+uzMM88cV1tMgiSmUx1a7DnGRUNqhRHBUDii1bj52c9+lhL8hNwd e+yxqdYNrg25vQokECGONJSBnG69uu68royBdmGAxH733Xen/A+lTOSkiOyTPyIXhbNeaHH/MiuE 2eqkYhpB/8x5f1cnNLpebS1Oc1n3Iq4GAs/ynpsPbUl4sVBhWfyKQmJ4NBb/p534XXgw+ud5ggjk nRA6qzPx+YLqoRs9zVDU0zn//PPDIYcckiQGG/KVr3wlHHjggWHzzTdPqqM6NgcddFBSF9XoEY3R S6C+j3j5k046aVwZiF5aX15LxkCnMaA0CSKs3lU1YCqLLrpokvKrszFoKsxVP/nJT1LiI00CoDd6 oFQzFUUcMSUgIdL1xx13XGDSwrAGqwWG4fTvpSI5ETMqtI7+GhOmw7eKiRT+VQKo5zYKPcdQmLKo d5iEcD0IU2Btn332CV/96ldTUhA7Iu6ssJsIjO222y4dkN/85jdpg5WHfuihh4ZsdtMo0jt1n/h3 Za0dRrbcWgrTdWpu+TkZA2XFAEEVM+hfsbuo14WWFDkjfhLo/FQrS76Sv1lNWEa8m9XMB91hMkP8 //CHP6TCjjvvvHNiOnwzg4UGmwvNQla7e9E9jE+qgECc/qYsuKdJMWnJU6P5mIcETeMMVmZ/qD3r CYaCiSgVffjhh6dCaQqpUfcUb9tpp51Shupgapv4bcxlm222CXvttVeq7GlzaCyYEuZk08sIqoaq QiqZaqiy2WVcX55zxsBwYKAo7T7UsznomZsKpz1iLSvd98rED2ROolX46FvCRCabHaPiQJeUPFhH R/fwdaB5Cj0q+cIC4/6CWfSfLwbCNGce1bXDZNHTUjCxenJQjF9ahoLD2xRdxY455pjEUPgJNJHC 0dkR1a6qBxwUDivMZc899wxrrrlmKjugzLPSJcxmzz333IDcvp7ndOpah4HNVFMtBydDxkDGQPMY YOpacsklPzQQqZ6vFgEnlLIIkPb7axZoF2ZBk+lvxnKfDw2j2kRFm/A+D1bYRDAA7Ucfle985zth 3XXXDZ///OfHZdYPtGrzcI8KGtWMCuPiU9FfBdTTO6lUDMUGCIGV+a1ZDS6stEHhF4HEWWaZpS4E DHa8SBNsompfqdBrc0RY6HbIFirCo0B480e0PSMI9YMj2pZQwQwZAxkDzWNAKC76wOxVONALExUi jZEUzAJxRkeKelj+T5sg5IkQ+9SnPjVOQFWaBVOiGSD0M88887iAIU2wCsakjL1rq4FJy7jon0+1 AFloHzSRAsxXVNpHP/rR5Ft1f3UwAI0Ik1I+ph6GMioS5gOaR3H7RsA5IVBkFge6TcSpxXjTIGwM pNSz6Hpna6PkcGAqfDDsmNpt+mBwbKEOWD3REPXOod7rSUbCBh1EKmw3za3etXT79YjA6aefnggB m7WOmBl6FwM0ED5JPU8QZb7X0aNHp0gqFgHaBZOVSCpWEj5bLXU52xVoxShEWvFtoCtaCWuUVfg0 mMVYSoo8F02zMAX9jJjkjz/++KT5IPoFoENM/3JhBoJf//rX6X5+FUEBrkVHPQc9Y+Hxd6F5+Q7d E0psXRhcLdC1iY0iDziomLUgVkgbkxZuX68pqxZENHINqcMm0VSYwj7xiU8kGymfzHAXYeRsE3OO yIl0w3wztAcDObGxPXjt9lFJ9faej5VgW/Q/If0j2gh+UeoIfeBkVxm4f/FQZjJ5LZIW0TraBcsL ILQSqEVkGcP9goZoNsz6BfAbe65Q5oGAII6ZAIzM/fJSCqCJYJRFImTxvTwWjA5tqwW6iqFACORC IhujBUI+raC621gtC+vkNUKNbah52zQbYNNwe/bJRquLNrMGcfKCCkgyTHQOUIb2YCAzlPbgNY86 MAYwFtpDkeXeTXgadoYicYcmIgoJM2GawWVJ+rI9ywY0AiqqDw2GHdJaMEXMpdOmJ4x5fAlRZcNv N843M5Ru3JU8p+HAwLAwFM6fQgWk6mEqTFpCfalhrap/MxwIrX6mpCI+DOG7Op/RVNjXaS5Uy3pD 8mpdj1ILtCV4FTbIBpqhfRjIDKV9uM0jlwsDHWUonJccWfwiiC17IMl98cUX7/m2tDQV/haaGAce ZoLY01r4hlqZdMh+q76QWHLO4i233LJcp7Jks80MpWQblqfbNgy0naEgpBJ7mLNoJULXRBaw6Uu8 GYkg5I+Zj+McTjjwOb1oLkIJmwVBApKbZMD+6Ec/Cssss0yzQ+b7x4OBzFDy8cgYGIuBtjAUTmrE zIsmSkDUgvA4mgjTVob/YQBzobFhMJhLkf/Cj1REejSKL0EOokzaZVprdF69dl9mKL22o3k9jWKg pQyFn4DUzdSijpTwWVFaTDq5U+DQWwR/GIsQPwlQkhGFHgpJrDVSTFCA+znjZfSOVC1waGy37orM UFqHyzxSuTHQNEMhVYtoImULUWWyQcgQQaFtGerHgCQmfhaJUH4q+Ia5CFqg4YnaGgxk8yunzVej rpkSMhnai4HMUNqL3zx6eTDQEENhSvESkabZ65lpZJHTSHKJj9ZuPvOhpCNMWzYsHxSmwgdVFH6r fqJidHvvvXfaG9VNla/P0F4MZIbSXvzm0cuDgZoZivIipGXZnkJhaR+Yh5R8SYeDNX4pDyq6f6YC HIRZ0wZlzypLw9eCmYuYq85x8T/laAYrd939qy3PDDNDKc9e5Zm2FwNDMhQETJQWKRlTUV6AdDwc SXrtRUW5RleiQQi2oAelH4pIMRWTmcz6l1Yo1+rKNdvMUMq1X3m27cPAgAxFHS02eA52ki6/CCkY kcp+kfZtRqMjM0FyxCu3orUxM6Q+KEr70yJbmePS6Bx7+b7MUHp5d/Pa6sHAOIYiKkslTJoIgiRk VdKhjG7mlGoYrCZ/PQ/O1zaHgcGqKx9xxBHhmmuuSULA3HPPnbLk5bhoMkaLaWdV5uZWVN67M0Mp 797lmbcWA4mh/O53v0slkZXrEN679NJLJ8lWkUNOYaU8gJIpPkUDmcxYWrsZtY6GKfTfC/faLwES NBbmSdFhfF6EBfXENt5441RePTOVWjFd23WZodSGp3xV7RhQyfhnP/tZEux1XO10DcDaZ/rBKxND kTfC0W7SiA0m0r/hiu9lu1988cWpP3t2wjeK8ubvsxeivrQnFhZc5Pjwd/Gr0CxpJUxd/ud6eS20 FWbLzFCa34PqETJDaS0+82ghNfLzbksKv+SSS2ruRzLsuMNQaoVoo69st912tV6er2sjBuzF17/+ 9Q88IZarr0RmUdlggw3a+OQ8dH8MRM2+EoMhKlHIqkS/Y0ZQxkBTGDjqqKMqsbpFJTKHyg477FCJ AThNjdfJm+tqASxslfmLBpNheDFA47AXKgoXIHxb8qP8lAwZAxkD5cPAiSeemPLHBENFgTEcfvjh XdNQsBZs1sVQahkwXzN8GFBVWHb9XnvtNXyTyE/OGMgYaAgD5513Xvj+97+fBPYtttgiFXaVBlAm yAylTLs1nrnyn5x00kkpm57/K0PGQMZAeTCgL/0uu+ySWgAL+f/pT39aKs2kwHRmKOU5cwPOtMgx ufzyy5OKvOmmm4Z//etfJV9Vnn7GwMjBwJVXXhm23377oGzSaqutFk444YTUQryMkBlKGXdtgDnL FxLuvcoqq/RMx8se2Zq8jIyBQTHw+9//Pnzzm98M//znP8MKK6wQ+FA++tGPlhZjmaGUduvGTlw+ ClhvvfVSzons+FzNoOSbmqc/IjBw6623hh133DHVSNTm4+c//3npi+tmhlLyo6v4I1X5lFNOCQ5o 9p90fkM1MCtyeySXZsgYGAoDyiTFFIxU7FW7D++vau1lhyGLQ1YvEMGikv3iF7/IDbOGeedvueWW dAh9JJt+6UtfSqryVVddlQ5op0HVBNEpRVKssEfJr7L2X3nllVSwstcSKq1JOwEJv1/72tdSqOdZ Z52VCqjqDdRr6+30mRroeXDObyhJt0jotQcAY/d7t+NdMVcRmervSUI+/fTTeybUPzOUbnhLGpgD hnLqqacmNVk5+5gMlRx5Bx54YJh55pkbGLH+W9R8Y/tFSJV50fb5kUceSd0lzYW2NNVUU4Wpp546 MZReA2uyVlLmfvvtl9Z78MEHhwUWWCAx0m4nbGXdj6LyA0EFEymEFrXrZpllltSAjjCjdp3W491U 1cNZwUyUudLJ9uyzz06Fd3sFMkMp6U5iKCeffHKqwVZIaAg7E1i7CJkkSkxDqRFJlT4vv/xy6oej 6RepkcnHfHy0I/azbLH09RwJ0rL2DiuvvHLCx4033hg+97nPjfNt1TNWvrZ2DBRJ1s46bRDunTcd ZHUt1WCOMIPhY/z2BKMfTv+id2ebbbYJN9xwQ5hjjjnCaaedVp6SKjVuTWYoNSKq2y7DUKjK2vyq LoxoL7vssm2JXfciqB3G7jvddNOlSsY0kEUXXTQxkZEOTBfLLLNMImrMwr0kcZZ5bxVIdWa143jx xReTNq3qto/GdJ0Ez+Yzueyyy5IFgTC4+uqrd3IKHXlWZigdQXPrH4Kh/OpXvwpf/vKXwxprrJF8 F5KjVl111ZY9TPTJFVdcEZ566qn0EiCaNBGSX4b/YSAXh+z+00C7dp5pB4rhzjrrrGGllVYKCy64 YNsnL1lRnskFF1yQBDDMRFRmL0KO8irxrjJx0RSUpeeUZ5NtBbBJc/QLwFCBeueddw477bRTkuwy M2kFhvMYncYADV6X2W984xupvIn2HAIofGgv7QJ+nm9961uJmTC/aYDXq8wEDjNDaddJavO47MJs x0INEf4zzzwzNUNrFkhxSmc/88wzSariQNSTIUPGQK9gQM+gWJE77Lrrrsm/oikd01irgWCm0OO5 556bmIkcMZUsehkyQynp7opuYSPGSESKtKLcyl/+8pckQUmyopFwthegk6eMXtIWjcXLeO2116ae LPJgGoEnnngiBRVwsAItpzHHoqEbDczfImMGAteJLmsF8H2cc845rRgqj1ESDPAFKsKogRVNhTms VcAErW+U8+td5evcdtttWzV8146TGUrXbs34J8YU9fe//z3sscceYfPNNw/XX399UyshobHtKky3 5pprfmgsjbtoLVtttVX6eKZmXUsuuWTqEtkIMDXoFlowkOeffz5pRXJpgDBcTMtzBwIMyIvaCsAw VWrOMPIwQIBSB4/DvBVMhSAUexOFo48+OuXM+J2ANhIgM5SS7rJDK+LqK1/5SiLwWvw2CrSbSy+9 NElq+qkMBmzQeq2I7vIh4Yn5pykVWoZ72Y05QZkT7r///kATqQbhnRyjQj77F8HjKEXYn3322RRy zGdDwgOcm5IItTQGxhAe6nvmBWVoPNN8it9d63lAOCktrJirOcKja1xf+Idcj7llGDkYcLYJSWpr iQprFJw/ZecPPfTQNIT8JGavkQKZoZR0pzXY0uaXXZZm0UwYpIgxrUYR88GAUxMxVyJfpQT3yEEh fYkEMw/mJ0Rb6W2JW7/85S9TX+zjjjsuaRqA1mEM159//vmJuBflShD4pZZaKvlsaC6IPQnP/zEP 4xjPemlnd955Z2Io5uLFZXozHqcr7cfvu+++e8pNoGFpVuQjGdTc5YxsvfXWKVoOPiVgeqb/IywZ RhYGVDiQCElDbiQRlyDyk5/8JL0TwDnUm6hdeWHduDuZoXTjrtQwJwlaCDwi++STT9Zwx8CXIKzC gocKN0bYBQGQ3BFuBJhUj7Ar9SL34jvf+U74wQ9+kDQdCZYYipIkpD+OT88yX5nLMsqFItMmCsBs vJQCARB0TAQzsVYaFE2KH0eGPt+NaJnll18+rLjiisnfIzLtt7/9bSIGV199dYqs8b2MaUxMYhuG RGNSXQAD87ukRNdhhqRLJT2Y/jKMPAwIjXd+5I3UCwSRfffdNwlNTFz777//OO263rHKen1mKCXd OURWTSBOchpCo8BcxH8wVCQXaZ+5a++9907ORmXyvTjMUSR7RNk8MDnMxXeI9RlnnJGIN6Lv+uuu u25cAibGw2xW+FCKrGdmMEmaHKXMXpgZBkXrEYDApMZ3U/SC4U+SCS0fhNbi/nvuuSc9V6gzBsFJ SgsTbeNvc8EQERBZy5jczTffnBIT5QoU1QcaxWu+r5wYEE7MfEqYqQdkvXs3aLi0XiavotZYPeOU /drMUEq6g7QF6rkcFMS0UcAoMKehquQiwP3j9RFk8yDZI/4cmxiLBEvXShoTRbPJJpuE2WefPfko zJe2IXKL6QozK55dHbVVaExMX4i9DybDZ7TuuusmhgVoShgMXGAkmIz/8y9hdhgKwEj4ZWhU5mzN mAytCdB++I8wQPXIEIhWRZA1ujf5vs5jgODinDCT1go08d122y2dF2HBzKojNV8rM5RaT02XXYfA 0wQUiGym1IdxONYLaX+wZapkXBDn4hoSGCJMmmO6IqExe2EWfC7MXcImaS6K9pH6v/rVrybmIjzZ dzrUFTZm2ctF5jITFO0LY/F/jGimmWYKxxxzTMp4xjy+8IUvpKZENBeaDg2KL8lPEWjmW+TmGAvT OOCAA8Jiiy2WNBymsOJ55uIe63RtUbajy7Y9T6cDGChMr7U8iumVGZZQs+GGGyaTLmFmpELHS6+M GVNJYaB/+9sj4bFIiN5+5+3/EpS+SDBmTgQBMZl88slG6p7UtG6EVd4EnwAC2SgwDXFCyi1hOhoM CiflQA5GmkW1hlM0/cKkaACFH6R6bNJcIcUVpe0He4bxjOVFF5FVVJMtxqNpYG7V9w80lutoNEWY cy3X12K2yKVXGj193XkfbUMosbJG4wOte5m3aOjKH2klMZTpuDtX3LpZdUxDef/9MeH222KZ9SN/ Gh20h4Vbb74hruKtMOXko8Lkk00QJostDR579MFw0ok/i47RQ8Ill/ymIcdY61DTvSNxJouQQsgu vPDCjkwUIxksWqW/uQzxLzQe0tpAFV6rTQLFuIM9oxiLOYJ/o3858oLoV98/0Fiuq86ZqeX6jiA3 P6R0GNAdlRCGmSy33HJJsBvpzMQmdoSh3PHnO8LBBx0Qbeu/DrPNOkPYdZft42ZsH76y6ZfDxl/+ UvpssvGG4evbbRX2/N63wwrLLxkeuP/OaIv8cTjv/POio+u90h24dk4YgeWrYAJqxn/SzjnmsTMG ehUDTKyy3vnjaDIiCAV2ZGgzQ2HeYmO89NILwxKLfzp8Z/edYjjmOtHGOG0yTzCVvPXfLn/MEUwb pMgvLPH5sMd3dglbbLZhePbpxyP3P7YlpUV6ZcPhiH8CUxFtlSFjIGOgMxi46667Uhl6wSTyVgSW CAjJMBYDbdNQXnrp5cQInnj84bDdtptH4rdiZBaTxkiI18eFbGIq1R8MRR6CyCNmnfli4t6OO2wX ZptlhuiMPTqGyT6U9y1iQCa5GHchijm8NR+JjIHOYOCBBx5IzES1BblVAmI6Uf6+M6trzVPawlA4 XE888fjkH/nG178WZoh271dffS0RwFoBc3k9OlBpMeutt1ZYeaUvRif0GTG/4N5ah+jZ62SiKwpZ dGjs2YXmhWUMdAkGaCTqzNFQtInggJfQm+GDGGg5Q/nPf96MzOQXYcaPTB1DRDcOUQcJb8a4/0aA 01RkD61mqS8uEVZfdbnojD4ntaEdySCEdq211krmwaJO1UjGR157xkA7MSAqVea7Ej9C20844YQU dp7hwxhoKUOhVZxz7jnh/ffeiiF3G0Tt4t2YPPZOU7VsMBVmsVdeeTU6wBYPSy+1WDj1lJNi+Y9/ jdj9lDylZ4noKr6nDBkDGQPtwYASLDQTpXzkKGm3IPcpw8AYaClDkdX82KMPhy232DiVymCuamVh NL6VlVdaMcwx+yzRfnlKQwXcyn4QlBY57LDDUkY3Bl5U4i37uvL8Mwa6CQNysiQr7rDDDuHyyy9P ibSYCctAhsEx0DKGouTz1VdfGdZZa9WEfOUtWslMLKHIYF1vvTXCC88/G6655poRt7fKlnz3u99N VU35UDJDGXFHYNgWrDabfiEKd5LY77vvvlSvTamSXgLvlBp3KliLUlUDTm8TXR4zjB8DLWMol1xy SZhrjllj1vYiyefRDsCgRH9JlltzjZXDVVde0XC3wHbMrxNjKrMioUp9LAl+9QQ6dGJ++Rm9iQFm Z2VrlMxR0VlCrXwMzupmql3DFmGUcFhUWBhuDDIla9wmWVEUpdpcashlGBoDLWEomij99aG/xKJ8 ayYtopFeAkNPdewVmMobb/wn1nFaPDKWKcOVkamMJNBNkbSkPERRjmQkrT+vdXgwQHDx0SxKLxs9 cYTQyoWS3NcMCLJRXHSoenLNPKPWe/kkJSzqn8Nsz1c5Elr31oqfoa5rmqFgHhdddGFY8guLxczt /4umrneGembT/y8im9Zea7Xw5z/9MTz9VOMd1pqeTAcHIA0qi/3rX/86qeS11Jnq4PTyo3ocA0xB TNl8o0XLAe0KlABiBisCRDAILanvuOOOlLMhKop5rABlSw488MBxTddET6kpR+MZTiAMy+9i5rJW PXtYAzLUjoGmGcrfIjf/xz+eDZ9f/HP/bbs6pvanN3GlwzvvvHOHGWacLtx86y1NjFSeWyU0qujL h6I8fHVBxPKsojdnWiTo9ubqQiKw3jkS+6677poaSSnUyfTlXDqPp59+erj77rtTjpRq0xpOYRzO qe8wGoE7iirK5Si6empFwLTknuECDFJzOOvzu6rZe+yxx3BNp7TPbZqhkEREXc0U27a+9VZRObj9 +PACTzThRGGJzy8WGyndlkKUex30jRd1oq2t0ute8FYHPvQ6DtuxPhozyb2o9NCOZwz3mEUztc02 2ywxFL1vFP30Hir0qTKv9gBKAWmmxgzGhPWlL30plQnSDoCvRLdNJnL30kqYl7R95hvs3x6hU2tm yhM5ifmZswKkq6++en63GtiAphiKQ/Lo3x8JCy04f5QuJu2oU81B9iLPP/+8sX7M+0m17nXQ54Oj UJIVaa4wO/T6urt9fXqxKGO+1VZbpYKdvQhFiwGahdpVc889d/IxYKKFzzQJeVGTKZzr/i93AyDU nN2u8buAEvkcfILMt9WtoDuNv0K7FM1FK9HXpH8zuU7PqazPa4qhUG/DmPdikbTPxPpbb3YcB3qp fOxjHw1zzTl7DGe8vuPP7+QDhWfqy65+EEkw+086if3xP2vOOedMfgJVZ/3eqyDC0qcaEGMtc887 77xUvp1JS2ixj/8VfhUanDwy/Y40MjMOxuM7bXcRcz6X4QCMjonL3EWy0VBywnBjO9EUQ/l7bJA1 zTRTx4P0sWEJX1XN2GGYZ965Yu+Uf6Tor14FCY1MXSJOhGkOp725V3Hc6LqYHUnmJPJeNUFaGwe1 oojVoGqDfiAzzzxz2HLLLROzYOKigWyzzTbj6l3JNp9vvvnStZpR6fJJ29F1k8ajS+Zwhg3z4Sy+ +OLJl4PJ9eo+NnrGa72vIYbisDC3/OO5Z8Occ80eQ4Xfr/V5Lb9OaZfZZp0ljHn/ndga9omWj98t A5LsdtxxxyRJfSJWYXboM2QMdAoDzFR8HXx31YCBMMUuu+yy45JsdVxdeumlk1+kMAFiHNosA3Ww 9txzz+RvKQi3M91MK+tW4iEzk8ax2RBDIa288MILMbrrmTD/fPOm3JPhABvPoTbbbLPGx1eSw69X YYEFFkj9qmXITznllMOiEfYqbvO6MgYyBlqDgYYYikdzpGEkiPlgFW+re51UT7d/H5T+iZCDJUYO 9D01eaqppoytXacLzz33XGuw0mWjPP/880HJegmNo0eP7rLZ5elkDGQMZAyMxUDdDIXqW4k3Ph6d xDPOMGOyOQ5E6GkPIr+USZlq6qnCBH3xvv821JoyMYDpw3SRCfj/5JNPliI/KpE50H4wiP4MyPck 8/5gTIxtnnnmihrTcz1pCnr44YfDPvvsE7797W+nfgwgq+X5FR4uDEiw1WxKP/UMGQPVGKiboSBk Y2K47gtRav6/j80QGcHY8vIF+HXCCUelz0MPPRJOO+OccNVV14b3x7yfIpMmjM7LO+64O5xy6lmx Sc2Z4fT4//vueyDdPllkLML17rrr3sRgCqKJmbz88ivp+0hKP0RM34+MaMYZNfH6d4o46TXQgwEz 4bgsesi3s7xNr+Evr6c1GOA3Pfvss8OPfvSj9GF+TZGebQC5Kr1WdLINaOq6IetiKNXx5q+9/lqY ZNJJkPcPMJQJJ5wgJRnedPNt4Y4/3xmTmZ6JUUlPhTvvvCeFCopOOvLI42K10uvC0888Hz/Phltu +2O44sqrw8SxRfBfH3ks7LnXATE0Vib42Lh1paT/9re/hyPifZGbJC2mnwoTJoua0rvvvhPe7cEE R6GoitUdc8wxqcFPJ0G450gIoSTIyOT2EYHEpOtj/RnGYkD5lIsvvjhlySsSueiii6Zs+HacD+Hx wxVGnPe7cQzUxVA8JmkoUSN47bVXk0mrL2oSBfjfqFETJk1i9Oinwpc2XDfst++esQ3w1okRXBmZ xr9ffSNpIjvssG2M+T4o7LvPd8NmX9k4MpZnwnXX3RSz3ycJU085RQwDfj68GqsWj2UeYzWgUUlr +fBihQ8zh8nUl5syUgC+B8JHI+sfaBytnLU6Pfnkk+N+v9bIsKW4R0e+b3zjG6mOE8Z9yCGHhBtv vDGex+vCU0891dQaZIdjUGUHZuVzzjknbLHFFmGOOeYI0047bWzNvV4yWWupQFgUzk5j6d9WgmlM 8cdrr702oYGmAyc+jzzySGLav/nNb1IuC+bkeia1P//5z+P8s7fffns47bTTxuHSNfyJmJy8rAzd gYG6GYpp0xr+8/p/whRR25igihJNGJnJSy+9HJ6KWsmyy3wxlleYMrwUJb//xMP2yU9+IoUQ8pP0 RX+KsNcx7/07vBylwBk/Nkv8vhIP0F1x7Ami+WqGVM7hsceeSMyrMH8NVo3UfKaMTIiGMlwRZ53f zkrE4/vRh9Xck/v65PK8N+A4XmhSop+F76a5p3Xn3QiSUHhmHJV0BT/IldD/Qq5EM3DVVVclQlx2 EHgj6KUI/bUeQhwfqppeqvNqTa1Ol3JMF1xwQVoypiHpE9O+7bbbEtNwvWoPmDfGoM4XBuIaVYz5 aJiuBaOI4rzssstSwUZlWgg4nuVcymjXlyVXjOie01U3Qyk0lDffejNMPe3UXBrjnO0TTzJReCGa qm648aYouUw7Vrr4b2jvVPHwLbvsUtE0FUszxO+ZviaYcKrEOJ4a/WiYNiZIrrLK8vGet8O7778X 5pprjsRMnoqVhCfob+Lqhz8MRW0g10866fAVmOvktk422UTh3nunjNnZfRFHjT95mmn6on9q8tiN ri9mCtvLsWN5kb3gwpUlpJHUC2btfwilF706H6Yo9kcqL0Ao9y9/+cs4V/6vsaDMBsLDpFQAyRbB GQ5wpknckvMQSWeSv8/6CxNYMS94IFVrDUtC7k/QrEHBREzKeVSv6sEHH0xEtMxQvPcDBYN4/xB1 ZVb4+Q466KBo4r4zmcdUeIATCY1wCjc0Eomgeowss8wyKWfFz4UWWij1WjGOHJV11lknMSzfLbzw wklzBKoTO4s0JTXF7FuG7sBAP2dEbZMqorXGmqP+Z4Pqiw769yMzKF6edPjiYSv6wnvBOOUdhmOO OT6qwNelSK+PxIgvfoLFPrdouOLyq+KLWElO/Tnn+HhUoe8LH4+lGRSCHB9MGv05r7z8cirwNvvs Hx80lLm2FdZ/lTUp2bDRRhulUhLthimmmC1KclvEF2qSmOgYonQY4rMrMVN5AJvgIJOJgmAs5fLx KPVtGPOKJonSeCVcEdvLzDNPXyKYJE3SJXOX/ivrrrtuIgSkSNIqjRHBlSGtJPnNN9+cBAUOVdnS CAdJFZEmgb4c9wdhUI+MsIHQMjUxZzCHIB7arirM10ngo8MkVCLwuyRS0jans2Q7a1TkENM58cQT U0a1n3PNNVdiPg899FDKClduhCZnDNI0gohpkrRJ3MqLlBW865gCc5ZERkBY4HuCK5oG7QU+ABxw qkuERA8wFUxHcUn0gKkMA2HigjdnDJ5c47w4B0XzONpjwcjGmnnH5p/J2lepOEP3YKAhhsJkNXEk LK+/9kZayX/5RnKIe+mWX27pRDAqFeatvkR4xsQorydGPxnLtMwURkVmsdC8C8TujosmxjF31Eb0 UokXhTH/FZHfffe9lFuC4Tz08CPp+8FMXp7x3ntjwovx5b34ksuGFbsqAvdnKG+88UaS0L1Y8CK7 ePbZZ//APPWU8ELRtGQdD9Vs6L333oyE/8H44n4uEvK+2LshJG1ltdVC+OpXQyxpEeJYH0ZFfA9j /4oQTQ8hahgh2r2njxdNHxZcMESiGX/z53+JhYKbhX0c8WcjV69J7wtMhQkTMcVkSKO6SK666qqJ ACMYNBP/15QJASZpIgKkVuYKY2EiriG9MjMVxQQ7uYmEAYQJ84B/8yI0IXLKgqwWkfrNb34z7R8n NIJHM9t8882TIIR5Wo/12Vf7p6IBqZvZzPqqTUWdXFurnuU8EihkuOvHY39vvfXWWEvvY/HsLJgE kMLP4X3EUDAP5qnFFlsslViRDF1UZMYwiiAdZx+eMFw49K54h2iArmF2ZAajDcK7THwCTbWG26p1 5nGaw0DdDMWLNmrUBNGxPkV4/Y3XE9MYG8obzSSRoXzkI9OHRaIU+kR0yi8aqdM004w1QXHU33nn 3WHd9dZPzGjFFZcNyy63anjnrZeStCEybEwa63/w/vtjovQ9d5RkH05RXhPE5w6kcvvO4VIoksRL Uxgs2bI5dI3/bswUAeoP+kWwFys5AbyICJAoGYDw+g4xI6Eh3qS+GWaYYcAH2oNXXnkuvqg3RjPA xrEfxWTRTj8mvowTxJ4UfeFXvwrRjBDiM0JYa61KJNLvx+tHRekyRJNDXzRXhUgsQ/SdhDiH5yOR fyD2gVgyRpBNMu55GAYiiKl4HkKPKTBnkFZJjYA0X11d1nck98L3xURE+7AWBNY4akIhHMbBlFTq vfzyyxNTck1/ZtvOPTM2nCOMtBDMETiThTBEysbsETjEjSmMmQUhde4Qz6KOF2JoDJV0mQo5jXvF r+c8yIfiE6Jx2XtMFSD8zjcNlbbiPXSeaXPw6Iy7X0Vm9feYu2gzPkxZeqksssgiqdcPTZYpS7FG z3FeOPWZWGl9K620UjIlDvZ+tPu85PEHx0BfJBb/SyIZAlNslyItjj/++Oi8PCK+hNOGjb60Xnoh i2G8WHrK33LL7VHKDunAqLf190cfDyuvtGyYN9pnNtl0y7DVlpuFtddaPR2elNQYp0EbueQ3l0cn 3Tnh7DNOirkrYx3yDuvhhx8T7ronhi1edG4yo1X3UiflPvjgQ+Gccy8M++x7QEqa7CYg0TGFYCoA kd1rr72SGclLRurz0jAHFQzGmpmS+jNQZgbRSJySL730YiRac0emPUl8id+OL5nQaeaideIHYxsV PvOZd6M0qTz4NNEUNWncK3XXnoif6yLhuzju4WNh7bUXiZL3mfG7scSURK3REOJRMEg2caGcXnSM 5Ytf/GKSKEmOiAoGZB9oIExeypKbK0aJuCLCGIU1nnvuuUkLuOSSSxIxMQa/i2ucJevrJPDf2Btr IHkD80D8mDBJw4gjzYSTWS4Qsx080D4RT/eef/75iaDCgevWX3/9tH4MVajtcGhfncIj0yahAH0o O3gv9XPR4yVDfRgYFcs1H1DrLV56hHHttdeJNvH7w/vvvR2b4iyYIrQKhkIynXzySaPk+bFI5P4Z X6YbwnvRzLPWmqsm38Z70ZSV+pjM94loHps6/j5WKykI53vvvp8I1fzzfyKNOXY8EuBEsYnXR8OC C4ytdlrNByeeeKJoRhkdHn7k8ahaLzlgRn2ta2zHdezziCtpDaNg8kE8mUbOOOOMZDYheSFizCwK 5ZGErbs/YEbK2MueR8xGj3462v+fiPbqp+P1T0TT0XURp9dF/CijPm80RYyKz5syEsUJ4/dGuzUy 6e3jtadFnP415ft8/OOfiIRz43F7gMCykxcalLtI5OZD2sYsSI8YAaLJOep6UiOhA7NhPiLBWi9t hNao/zgtzjqF5dJMEF//Y/YguYr+KbSEduzFYGNaG5t+9bP97vvCgSxAgUbi7Jm39RXaGumaWUdE HNMPpmO8opCncXqZoSSBMDJjOCo7ONvyvWigGerDQF0aCmlL2N5JJ50cbfDnhmefeTx88xtbJ6bQ v/Q0k0jxsjlsnPXMWn5XWoUzzt/VErj/TTzRxDHBceKk6hb/872cF+Mlv00/v7OX9brrbgi33HpX 2P07e4yTMutDRfuudkBJ+wiMtfAXkFgdWtoJExHJX94D1R7RwmxISv0BXpjE7AUH6U47fTNKz5NE oqe+2kSRgb8Zs5nfi4wieuojQ5lmmgkiwwpRAwjxO6ONjkTyL9GkNiqaxKaImstD0YH8aPRzHBjH GBkRcu3b6TxyL2AgayiN72LdDEUTIWrtLTffEi684LxwwP7fi8mNowa1E1czhWKaRdTXYNMe7P8D fe87DOrEk04PMa8x7LLLLkM6tBtHV2N3Mu0g/sqnAI5KHyYVTl7mH/0iOH2Fm4qIcT08D+acv+ee WL7mlJ/FjOWTo7MzxMQw/pEQ+3SHaEYM0ZQVYrRUiGp7iNJyiBolX01I/hNFmZVF49JZZJEXI6O+ KjK4DSKj6z6GggGLHiuypltZw4wQRPDhbKZltRtoqrS1IlKp3c9rdHwWBKZq0XYDRSzyCdI0BZc0 ArRwUYHLL798Eoxov/VoNoV/zjyviGGJzKitjKzMDKWRXf3vPXwotUI0Z1SiXT9dHqXayvZf36by 6N/urbz+6rOVl/41elg+r7z0VOXdt1+sfH/P3SoxaarWpXT0uuhDqcRIpw88MzrlKzFcshJt7ZWo nVQigxn3/6gFVmLkUCW+MIPO84477qmsssq+lV12ebPyyU/yg439zD13pbL33pXK7bfHuLgB4N57 K5VDDqlUPvWp4p4xlemm+09l223fr1x7baXyxhsdRc2QD4vEoxJNY/x8bftEhj/kPFpxQdQ+27aG VuMnWgMqkVh/aNmREVR22GGHSuwr/4EzWw9+YrRgJZp4KzEasBJN6JVoAq759ug7rUT/XiUy53RP ZEiVGGFW8/21XGhtMYiglkvzNf0wULeGwhHJOftqlDJ+/KNDo2lm8bDcMktFW/nw1DziP3kpiuRH HnV8jNLZNNrvx0ZSdRNwyvMtHHXUUWlaJCuObGYusf2CHDhx+RKY75jIRBaJfBlMIn/44edjw6MX okYz1s4b/d6xFEaI0naIPpGhV8/8Ras5+2x5ACK2JoxSeiVpMPPNV3suy9BPav4KDl8ho6DVGgoz Kr8Nn0jR3ja+I8ksyafTSqBlcd6DocLCW/ncesdyPvlDtttuu+QDqgYmWeuAK2HBovLgq9iXIhTY PdXf8/cJbAD8h3q3Hxxj3fWmL8D1tBfXFVGE/sfM628BD5JiPZcW4d2pBvN2rRDwwprhp+/5/qrb ZlfPsz9+soZS74n53/UNMRRmL47KY2KJir7wduwkuF3c6NfGZVk3Pp367nQAZeD/6Y47Y3TY7+Ih 22NsPkuXgQQvCWCFicC8BTeIeipCH5lCBD1gKuL2HXhEbjDCc//9d8e8jUuio3/vyJwmji92iGaI +hd+770PRUb357h/G0fH+iQxfyLGho16NyaeHpdMCcwSgNOcw1nXyKFAjoGESEyzDPkX9ma//fZL OHeuBQ0IkhBwUA3WrxpAlNC7miEMtT+N/h8j0JdHPS+EHZPnG0TECZnMYPx7IuMEZjgHfK6+FyWo XbCseO+D8GCJo8YQgCJgBbOS48T8JcJRSLnIMeHCGByTsbBsSaQ+ogEJY4I9mM3QJXskqtDZY1Y2 vj0tQpGdR3PxLEEn5to/+CUzlEZPSAP9UDyqcMDPPMus4bl/vBALMr6T6nMNB0iSVJ5l0kknT73t uxEc9mp7M6lJVFR1HP1aa62Vwk8dcFFfXqrxSbGvxiKbyyzzeNRi3o/ErzFmAlcTTvhmDC02znsx QGBsbsoEE0yYSqPw6xR1khATxLQWIA2K4ipLuRFrEz2HUciWFyiB8PWHoh5VLTjoxWswXpF98mto FsLDnQ8h/Px9kg4xAkScj4TgJJSaX5Ag4js+D+BsI/QYgLBsfkYMYO+9905akdB15wcjwEgwHKHd /ieCTjtiY/DnCGKh+Tl3BANVCn4Vk7EwNN97lwS+qNbtO/XaJKt6fi6R39qT2hQXWHTRRSIzeTc8 cP9DYfIYhdVpGCt5vBIP39+jNL1IS80hnV5Lvc+rVPoiEx2VGEAz8O67E8QSKZNEc4CKBmNH8mJ6 AWkoCvcBOSbVDc4QE2HC/UGJFYSAya5giDLsaTjdymAQPhF3NEMEC8GsZvbmjZAyuZC2C/MOKd16 EdXqtRW4MW4vAdMtYo3pItyIPnOkEjs0EgKR8GnEn7lWJCcte9ttt00huBISfY/xMDXCD/MWUxRC 73eh2JJ+Xct0ZS8UlJT0Khuf1iLPTCCLfXAmjVWcOfdLO/C3c7z22mun6g2u9wzBBkxmNCF7THjL 0DoMNMVQEJ1pp50+3Hvf/TGL/X/1dlo3vfGPxMb91JNPxyzmF5PEMtJAXkl8Z1oC1eN4ETEQZh9S I/8OXGMQiATpj+THnyZruvA9yIZm6iKtFgSCCYQpwv+UwSfldxtgFMrFHHbYYWlden3IJQEy5Em2 TDrWXdSVIhWL0JNHxHyjUjHNXfFD32lEZc18B70AtBAChFp5yspgKHxPNAQE3RkR9o5ZYLI0PIwC /tTqcj8zr/fUWXJmMBTfF1UtimRljEqFBrlWcE9rxxDcA8dwWvRgKZKqjVV8V/w0btHPxneu8SEU MIkxe5lbhtZhoCmGYhpLLrlUTCh8LCXI0Rg6JZWNdbqNCXfEci5zRsam7EqG1mAAbknfbMxyZ0ih Xk6EFyElMSIqiChTBXMRpsEHdPjhhydHrZceoaHhkApVAhAiWjjXWzPT1o5S7fB3lhHDQw89NCVp KjkjMREeSMrs//Dzgx/8INngmXUQN8xE4qcs66Jse2tnOTyjqS7Nn8Y0S5Dk/+MToREwhZL2hXer AEGLUN8MrmgdGElReJPpi7CCqBNQ/IRrddx8r2YavwvmomYXxoQxG18tMJqFsi1C6zEvmrBzRutw DplpMX29WvwsKh/YI5oN+kR4IPSou+d8Z2gdBppmKIsv/vnwxutvpeQ4EVedAkUlEb277vlLJGDL duqxI+o5zAYII5OVyJ6isqsXFaEossgRDsTEy0kqRQQQFUTBtaLWEFcEuSgv002IJPkikpgkgqQE Ox8XJkFDY84piB7pGmErpHB/cwpjmggkRoqp0GbUtlIjrBeAOZCPqdqBjcjTUmgPTE8qH8DfV1Un jUA7gB9/+54z33kQeIIRI/DyxkRr8TNiJnKzYthuYtbFmIqO+g5j4T+RN6TumrElCDOnMa2Zi/sx LXkp8E97BDQjRUrdgxFy6nter+xPt5yxphmKTV9+hRXDVb+7LklonSqboe/J76/7Q5RQ/i+Wf/l0 t+CzZ+YhcocEiICoBMvJTrIjRdJUmCSKQoiu8SKTVBVDJGHyIyAemBCpFlGgubQ6FLcVCKeZ0K44 iDEQJhdMg31dch8GISmR+YWTmEOaBOx7jIUWVphjEDImGiYVDLZ/BYlWzHc4xiAg2Pv+YO/9r9AG aCyFpleE+vJpIPrV32Mq/k9DKcKJMRj+l+rIQOdFQIufNBbPAq6hmdBAinBg/1P+xtjA3AoNxZkt avxh/MYsnjsc+OzVZzbNUCBm1dVWDW++9V6UUm9Ldbzaafbi53Swn33u2XD7H++MqvJaA9a86tUN 68S6vHCku6L21IorrpikPg7XInxTBz0+FN970ZlDEF9hnF5+JgjCBcmU/VoXRAyqlRnNrcIFQsQp zyciAkhhzKK3C6nceeNbgQeSLuJEwkWgaCKkY+A6ErcqB0V5/5HQr8Oe0jj693thjmIyzFpAq05q 94/TUB6Kl6U6Scgyr7/+hnD5ZRfFhKWdk/r/ViQi7UiPI+VMMcXkqdTK2+/0JVW4lclu3b9lY2co UZKTGxFE4BoFjlb2cT6OgYpRDjYu0w7BoTryy7XVCWxFYhvNlfnDuejWvWK2K7pPFomN1We8el20 FHlDzEDuo5XxE/AfFTgYCDeN7lG+r7MYyHkojeO7JRqKxy+99FLhozPNGrOvL4/MZuIwqohBbXxu H7ozJTLGul133nlPNE08lmyh3UqgWrjstg9FI6kXj0U59/6TqzYjFGPSWIrs5bYvpsEHML8U/TnM tb/AVL0u/+dzYeoS5SZyrbqQ52C4aXBq+bYOY6CIBuvwY3vicS1jKOyZm2y8aXj08afD9TfcFCXX AdoFNoGysTHrk8dEyn+ESy+7KqwfnXKFPbWJYUf8rfZNwlqv2Po7saGYD0e9iCZJkJzBua95JzDf mWfY324ujdMZLDT2lJYxFI//+MdnC5tvsVX43dU3RDPA/dGmOnVL/Cn8Jsw6b7z+Rjj9jPPDZxdb IqywfCxelaFpDDBzicYqYvebHnAEDUCj4TdoxuQ4gtBViqUyz3L486llqB8DLWUoHr9QjOZYa611 w3nnX5xCiTEV7YGbgcknnywm8L0Tzjzr/DDNtDOkCJsMrcGA0E+1lIQGZ8gYGOkY0PyOkDVQK++R jpta1t9yhuKhmkMtv8LK4dTTzoslN+5Mfo9Gwon7om3fvUI4j//F6WHURJOHrb+29QcqkdayyHzN 4BjgDxClJTKpyFjO+MoYGKkYEB7PDJz71Td2AtrCUExFCOkmm24errzqhphpfWkyq/Cr1JKHUCTO TRbDMO+8655w8innRCfo/DERaYccO97YPo/3LvkhmMmll17ahtHzkBkD5cCAyEn5SCwg9QaplGOF 7Z9l2xiKqS+88GfCzrt8Ozz3/CvhJ4cdE8tQX5GKtk099VSppS+thTTgM1H8iA7zPyayO2JJ+mOP OyH85tKrw1prr5cKxrkuQ+sxwBcg81hpFCHEGTIGRhoG7r777iC3ShJukRg50nDQivW2LA9lfJNR c/X2226PxeN+H17990uxkdOsMXN2vjDbrLOlci1FmB7T1kMP/S08EiuavvNOJWbALxLLTK/adT3i W4H4ZsdoVR5K9Twej72B5Rgpe6HkSoaMgZGAAQUiaeeqOajblqFxDNTNUBQBlFBX3VGtnscra3FH bHAz+olHw4uxoGSy23PaR64zVdROZp119lQWwcbWYh6r59m9dK1quIh/s4mN/XGiN4X9hXuqv/Lh GTIGehEDo0ePTozEmVfZoZ6+9r2Ij1asqS6GohyFekaIWCPmp6Kpzvvvj0mFHceWsB4T1zGWo0w8 8SQpKkxSmRLqmE07y7i0AoHDMQb7rv4iSqr7tDpsVVa7Rkiyv9Wz0ptCGGWjQsRw4Cg/M2NgIAyg J6pIX3/99akcvxpjzFxFza+MteYwUBdD0VxHRdYik7gRYl9dIK6/48t4Euxypur4NxUzhzvJdJLr 2kXo/xGTSPW4UGlYbL5KrxpQqS6bIWOgTBjQn0dvHgVN9W6heWsVXN3Tvkzr6da51sVQEHr9MLq1 8163Irkd81KIUHHCgSrAtvp5TAKqBzOzeR5NU6jxEksskRL7aJT9S5W0eg55vIyBWjEgopT1Q202 WohGXc6sGmwKnPrkxMVasVnfdXUxlPqGzlf3IgZoLYohelk1NCJckPIwmIK5FRosbVMEGZNcI9ps L+Ivr6k5DIxtrFdJRUidQYyCiZYGQlP3O5OWtgLOoQRFGj3Neo455mju4fnuITGQGcqQKMoXDIYB nQv1TXnttddSF0NRYjLuhV0WTIQW5fecNJnPUSswUJjJnTkfTKQ4fxiGqg9Fwy9FOnO9v1ZgvfYx MkOpHVf5yoyBjIGMgYyB8WCgrYmNGfMZAxkDGQMZAyMHA5mhjJy9zivNGMgYyBhoKwYyQ2krevPg GQMZAxkDIwcDmaGMnL3OK80YyBjIGGgrBjJDaSt68+AZAxkDGQMjBwOZoYycvc4rzRjIGMgYaCsG /h+RP/BAxzI3gwAAAABJRU5ErkJggg== --_004_580BEA5E3B99744AB1F5BFF5E9A3C67D18DE8F3762HE111648emea1_-- From Dirk.von-Hugo@telekom.de Fri Dec 6 00:32:01 2013 Return-Path: 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 665FE1AE2FF for ; Fri, 6 Dec 2013 00:32:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.25 X-Spam-Level: X-Spam-Status: No, score=-2.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 tvxJtmQyCwYm for ; Fri, 6 Dec 2013 00:31:58 -0800 (PST) Received: from tcmail43.telekom.de (tcmail43.telekom.de [80.149.113.173]) by ietfa.amsl.com (Postfix) with ESMTP id 4AA621AE2F6 for ; Fri, 6 Dec 2013 00:31:58 -0800 (PST) Received: from he113472.emea1.cds.t-internal.com ([10.134.93.130]) by tcmail41.telekom.de with ESMTP/TLS/AES128-SHA; 06 Dec 2013 09:31:53 +0100 Received: from HE113484.emea1.cds.t-internal.com ([10.134.93.124]) by HE113472.emea1.cds.t-internal.com ([::1]) with mapi; Fri, 6 Dec 2013 09:31:53 +0100 From: To: Date: Fri, 6 Dec 2013 09:31:52 +0100 Thread-Topic: Hiaps discussion Thread-Index: Ac7yXILYFGoRoQdFRDy6vpgl9Jr2bQ== Message-ID: <05C81A773E48DD49B181B04BA21A342A2C7912070A@HE113484.emea1.cds.t-internal.com> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: multipart/alternative; boundary="_000_05C81A773E48DD49B181B04BA21A342A2C7912070AHE113484emea1_" MIME-Version: 1.0 Subject: [hiaps] Hiaps discussion 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 08:32:01 -0000 --_000_05C81A773E48DD49B181B04BA21A342A2C7912070AHE113484emea1_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all To further discuss the use cases for Host Identification and Address/Prefix= Sharing also in a face to face manner we might have a chance at #89 in Lon= don - you'll find the BoF request we have posted on the wiki http://wiki.to= ols.ietf.org/bof/trac/# within OPS area. Please have a look and share your opinion and comment on the list. Thanks and best regards Dirk --_000_05C81A773E48DD49B181B04BA21A342A2C7912070AHE113484emea1_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all<= o:p>

To further discuss the use= cases for Host Identification and Address/Prefix Sharing also in a face to= face manner we might have a chance at #89 in London – you’ll f= ind the BoF request we have posted on the wiki http://wiki.tools.ietf.org/bof/trac/# within OPS = area.

Please have a look a= nd share your opinion and comment on the list.

Thanks and best regards

Dirk

= --_000_05C81A773E48DD49B181B04BA21A342A2C7912070AHE113484emea1_-- From sarikaya2012@gmail.com Fri Dec 6 09:50:36 2013 Return-Path: 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 011A91ADF6E for ; Fri, 6 Dec 2013 09:50:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 H3w7mWNTwntp for ; Fri, 6 Dec 2013 09:50:34 -0800 (PST) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 84D211ADF22 for ; Fri, 6 Dec 2013 09:50:34 -0800 (PST) Received: by mail-lb0-f174.google.com with SMTP id c11so411715lbj.19 for ; Fri, 06 Dec 2013 09:50:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:date:message-id:subject:from:to:cc :content-type; bh=uiBGOGxi7DQOl4jejAdVvL50d5YhtOFj80Y5S1BhSts=; b=uEtNGnneUD1U+NMxEB6oGvpd58umu6p/UQwrQpUiSsKZ1Skg0izZGBuCuS2RbBRCEf rLMg2XOkkg3+USelJDkNHusfPUfEb5/BWxB/INW/hnVu7ZnPQ4HIlU7IGtBQM4CU4UMe ZyOpJ7gX34O/lcU9mHUSeFMateVy3hDJKAaT3017Vo8/lFlrLnI+f2p+841vXvYjXgOO xyEjDzDuMNVq1JVO8134HmayIGnuZbFt3dUauMf4c8Z1+sfs4GIWTO8tKeXIECtRTY31 RxOEsUSRMgsqkNSMs8j6Sk8nNL0qV+uF5fVJBK2cCCDJ030Q38xOVT2G1kAe4mkEPMLp tMpw== MIME-Version: 1.0 X-Received: by 10.152.36.101 with SMTP id p5mr370881laj.67.1386352229954; Fri, 06 Dec 2013 09:50:29 -0800 (PST) Received: by 10.115.4.165 with HTTP; Fri, 6 Dec 2013 09:50:29 -0800 (PST) Date: Fri, 6 Dec 2013 11:50:29 -0600 Message-ID: From: Behcet Sarikaya To: hiaps@ietf.org Content-Type: multipart/alternative; boundary=089e0158b5bc33378004ece1487b Cc: Andrew Yourtchenko , "Dirk.von-Hugo@telekom.de" Subject: [hiaps] solution draft X-BeenThere: hiaps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: sarikaya@ieee.org List-Id: "Host Identification, Address and Prefix Sharing in Wi-Fi Access \(hiaps\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 17:50:36 -0000 --089e0158b5bc33378004ece1487b Content-Type: text/plain; charset=ISO-8859-1 Hello Folks, Andrew wrote a solution draft for address sharing in NAT/CGN environments which is based on Ping protocol. The draft link is as follows: http://www.ietf.org/id/draft-yourtchenko-fmc-nat-reveal-ping-00.txt Andrew presented this draft in Berlin Bar BoF we had. He now is informing us that he no longer can continue to work on this draft. We are looking for volunteer(s) who are willing to take over it and further improve this solution which looked like a viable approach. If you are interested, please let us know. Maybe Andrew can give share xml file :-). Regards, Behcet --089e0158b5bc33378004ece1487b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello Folks,

Andrew wrote a solution draft for address sharing in NAT/CGN environment= s which is based on Ping protocol.
The draft link is as follows:
http://www.ietf.org/id/draft-yourtchenko-fmc-nat-reveal-ping-00.tx= t

Andrew presented this draft in Berlin Bar BoF we had.=A0= He now is informing us that he no longer can continue to work on this draf= t.

We are looking for volunteer(s) who are willing to take over it a= nd further improve this solution which looked like a viable approach.
If you are interested, please let us know. Maybe Andrew can give sh= are xml file :-).

Regards,

Behcet
--089e0158b5bc33378004ece1487b-- From ayourtch@cisco.com Fri Dec 6 11:11:58 2013 Return-Path: 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 D69D41AE152 for ; Fri, 6 Dec 2013 11:11:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-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 MxauqCx8NyvR for ; Fri, 6 Dec 2013 11:11:57 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id A293C1AE133 for ; Fri, 6 Dec 2013 11:11:56 -0800 (PST) X-TACSUNS: Virus Scanned Received: from stew-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id rB6JBq1E017901 for ; Fri, 6 Dec 2013 20:11:52 +0100 (CET) Received: from dhcp-10-149-4-110.cisco.com (dhcp-10-149-4-110.cisco.com [10.149.4.110]) by stew-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id rB6JBpdf018124; Fri, 6 Dec 2013 20:11:51 +0100 (CET) Date: Fri, 6 Dec 2013 20:11:51 +0100 (CET) From: Andrew Yourtchenko X-X-Sender: ayourtch@ayourtch-mac To: sarikaya@ieee.org In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1260202451-1386357111=:68814" Cc: hiaps@ietf.org, "Dirk.von-Hugo@telekom.de" Subject: Re: [hiaps] solution draft 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 19:11:59 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1260202451-1386357111=:68814 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8BIT On Fri, 6 Dec 2013, Behcet Sarikaya wrote: > Hello Folks, > > Andrew wrote a solution draft for address sharing in NAT/CGN environments which is based on Ping protocol. > The draft link is as follows: > > http://www.ietf.org/id/draft-yourtchenko-fmc-nat-reveal-ping-00.txt > > Andrew presented this draft in Berlin Bar BoF we had.  He now is informing us that he no longer can continue to work on this draft. > > We are looking for volunteer(s) who are willing to take over it and further improve this solution which looked like a viable approach. > > If you are interested, please let us know. Maybe Andrew can give share xml file :-). I always try to share the XML file right during the submission: http://tools.ietf.org/html/draft-yourtchenko-fmc-nat-reveal-ping-00 - click the "xml" link :) --a > > Regards, > > Behcet > > --0-1260202451-1386357111=:68814-- From joelja@bogus.com Thu Dec 12 00:31:48 2013 Return-Path: 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 169FC1ADF51 for ; Thu, 12 Dec 2013 00:31:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 aJu2pr_Y8R-g for ; Thu, 12 Dec 2013 00:31:46 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 5F6A21AD68D for ; Thu, 12 Dec 2013 00:31:46 -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 rBC8Vd0q007052 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT) for ; Thu, 12 Dec 2013 08:31:40 GMT (envelope-from joelja@bogus.com) Message-ID: <52A97466.2060901@bogus.com> Date: Thu, 12 Dec 2013 00:31:34 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:26.0) Gecko/20100101 Thunderbird/26.0 MIME-Version: 1.0 To: hiaps@ietf.org X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HVVGFWtpf1QRefbH7kcauTCT2xjhFw6Xl" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (nagasaki.bogus.com [147.28.0.81]); Thu, 12 Dec 2013 08:31:40 +0000 (UTC) Subject: [hiaps] with respect to the BOF request. 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Dec 2013 08:31:48 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --HVVGFWtpf1QRefbH7kcauTCT2xjhFw6Xl Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable >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= =2E --HVVGFWtpf1QRefbH7kcauTCT2xjhFw6Xl Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlKpdGYACgkQ8AA1q7Z/VrId+QCgi0eiV/LAF9ebaQP6C17bzf5M ZxUAn0ovu+P0Bzp6G0BgtmC0PFru/B3v =OUQX -----END PGP SIGNATURE----- --HVVGFWtpf1QRefbH7kcauTCT2xjhFw6Xl-- From sarikaya2012@gmail.com Thu Dec 12 09:19:52 2013 Return-Path: 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 8F1531AE368 for ; Thu, 12 Dec 2013 09:19:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 4q_98scOWK9x for ; Thu, 12 Dec 2013 09:19:50 -0800 (PST) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 37BF61AE059 for ; Thu, 12 Dec 2013 09:19:50 -0800 (PST) Received: by mail-la0-f43.google.com with SMTP id n7so563279lam.30 for ; Thu, 12 Dec 2013 09:19:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=vaZP9NeVolqOOTuDubvG22UxM5+eI2pb1d0V0jOx45k=; b=MbAdA/GAY2BjxnMrcATm90BdRFF4lPYBIK94eKQRTyCQkIKkhTHNrvtkypnc/mq+Dt uGYMSifCXPIXssQkUo8rcO9f7C8kHIdqbKo60uMZsHuahM1N8q8/FPwLetvt74O/QN4l 6R6G/Ic4W/E5xDSse65X4XpaBDrYvwEP0OOt63IXECpiK2DRgvzLgbwfOI8l6Hzbarx7 Bm9RslJqadb6+SaUrCyHzUI89vD90YcnKgesUiN1X97hpIWRaumREjX7If3OIxzmRx/t FhVcaiAx7bo24DNbBipivLJIZI7HKJApeWOAgiNkASrIGIern0Ow0S1qE00SRe5+Bjor q22A== MIME-Version: 1.0 X-Received: by 10.152.1.197 with SMTP id 5mr4478935lao.0.1386868783544; Thu, 12 Dec 2013 09:19:43 -0800 (PST) Received: by 10.115.4.165 with HTTP; Thu, 12 Dec 2013 09:19:43 -0800 (PST) In-Reply-To: <52A97466.2060901@bogus.com> References: <52A97466.2060901@bogus.com> Date: Thu, 12 Dec 2013 11:19:43 -0600 Message-ID: From: Behcet Sarikaya To: joel jaeggli Content-Type: multipart/alternative; boundary=089e0112bfce317dbf04ed598d22 Cc: hiaps@ietf.org Subject: Re: [hiaps] with respect to the BOF request. X-BeenThere: hiaps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: sarikaya@ieee.org List-Id: "Host Identification, Address and Prefix Sharing in Wi-Fi Access \(hiaps\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Dec 2013 17:19:52 -0000 --089e0112bfce317dbf04ed598d22 Content-Type: text/plain; charset=ISO-8859-1 Hi Joel, Thanks for your comments. My views inline. Med can say more... On Thu, Dec 12, 2013 at 2:31 AM, joel jaeggli wrote: > >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. > > I understand there are privacy concerns. But in our case, we justify it strongly on a case-by-case basis. In our IPv6 case, host identifier is IPv6 address and it needs to be revealed to the edge router. We don't see any privacy issue here because the edge router will know IPv6 address of the communicating hosts anyway. In our IPv4 case, the situation is that the host is in the process of making an emergency call. The call server to which the host identity will be revealed has to find the position of the host in order to serve the host. Again we don't see the same effects of revealing the host identity to any server in this case. It is emergency call situation. Having said the above two, I think we need to of course clarify these issues in the drafts as much as possible. In case of IPv4 we have many other cases, e.g. CGA and the concerns you mentioned could be valid to some extent, I believe those are somewhat clarified in Med's RFCs, Med can chip in here to say more. 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. > > > I think it was clarified during email discussions on the list that there is no roaming case per se in hiaps, we do not have any case that requires a persistent host identity during roaming. Of course we consider mobile hosts but the identity will be different in each place. > _______________________________________________ > hiaps mailing list > hiaps@ietf.org > https://www.ietf.org/mailman/listinfo/hiaps > > --089e0112bfce317dbf04ed598d22 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Joel,

Thanks for your comme= nts.
My views inline.
Med can say more...


On Thu, Dec 12, 2013 at= 2:31 AM, joel jaeggli <joelja@bogus.com> wrote:
>Description: Host identification is requ= ired 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.

I understand there are privacy concerns.
But in our case, we justify it strongly on a case-by-case basis.

<= /div>
In our IPv6 case, host identifier is IPv6 address and it needs to= be revealed to the edge router. We don't see any privacy issue here be= cause the edge router will know IPv6 address of the communicating hosts any= way.

In our IPv4 case, the situation is that the host is in the p= rocess of making an emergency call. The call server to which the host ident= ity will be revealed has to find the position of the host in order to serve= the host.
Again we don't see the same effects of revealing the host id= entity=A0 to any server in this case. It is emergency call situation.
Having said the above two, I think we need to of course clarif= y these issues in the drafts as much as possible.

In case of IPv4 we have many other cases, e.g. CGA and the c= oncerns you mentioned could be valid to some extent, I believe those are so= mewhat clarified in Med's RFCs, Med can chip in here to say more.

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 =A0stakes with respect to revalation to remote observers= .


I think it was clarified during email discussions on = the list that there is no roaming case per se in hiaps, we do not have any = case that requires a persistent host identity during roaming. Of course we = consider mobile hosts but the identity will be different in each place.
=A0
=A0
_________________= ______________________________
hiaps mailing list
hiaps@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/hiaps


--089e0112bfce317dbf04ed598d22-- From joelja@bogus.com Thu Dec 12 09:40:11 2013 Return-Path: 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 93C401ADFA8 for ; Thu, 12 Dec 2013 09:40:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 QQlJx1c-Bk0Y for ; Thu, 12 Dec 2013 09:40:09 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 7E2B91ADF12 for ; Thu, 12 Dec 2013 09:40:09 -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 rBCHe0Wl010370 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Thu, 12 Dec 2013 17:40:01 GMT (envelope-from joelja@bogus.com) Message-ID: <52A9F4EB.2020103@bogus.com> Date: Thu, 12 Dec 2013 09:39:55 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:26.0) Gecko/20100101 Thunderbird/26.0 MIME-Version: 1.0 To: sarikaya@ieee.org References: <52A97466.2060901@bogus.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wx0bGHtAbbheRnfRebX53jQwRVkVrJGRC" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (nagasaki.bogus.com [147.28.0.81]); Thu, 12 Dec 2013 17:40:01 +0000 (UTC) Cc: hiaps@ietf.org Subject: Re: [hiaps] with respect to the BOF request. 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Dec 2013 17:40:11 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --wx0bGHtAbbheRnfRebX53jQwRVkVrJGRC Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 12/12/13, 9:19 AM, Behcet Sarikaya wrote: > Hi Joel, >=20 > Thanks for your comments. > My views inline. > Med can say more... >=20 >=20 > On Thu, Dec 12, 2013 at 2:31 AM, joel jaeggli wrote:= >=20 >>> Description: Host identification is required in IPv4 when the hosts a= re >> 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 Ar= ea >> Networks, aka >>> Wi-Fi access. In case the hosts are behind a NAT box, there is a stro= ng >> 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 IPv= 6 >> context I would think it antithetical to the goals of regular rotation= >> of temporary/privacy or cryptographically generated addresses to retai= n >> host identity bindings that are visible outside a limited scope e.g. a= n >> l2 domain and which persist across host address changes. >> >> I understand there are privacy concerns. > But in our case, we justify it strongly on a case-by-case basis. >=20 > In our IPv6 case, host identifier is IPv6 address and it needs to be > revealed to the edge router. We don't see any privacy issue here becaus= e > the edge router will know IPv6 address of the communicating hosts anywa= y. >=20 > In our IPv4 case, the situation is that the host is in the process of > making an emergency call. The call server to which the host identity wi= ll > be revealed has to find the position of the host in order to serve the > host. > Again we don't see the same effects of revealing the host identity to = any > server in this case. It is emergency call situation. Oddly I don't agree. being an emergency does not absolve us of dealing with the question of visibility on path. > Having said the above two, I think we need to of course clarify these > issues in the drafts as much as possible. >=20 > In case of IPv4 we have many other cases, e.g. CGA and the concerns you= > mentioned could be valid to some extent, I believe those are somewhat > clarified in Med's RFCs, Med can chip in here to say more. > 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 observ= ers. >> >> >> I think it was clarified during email discussions on the list that the= re > is no roaming case per se in hiaps, we do not have any case that requir= es a > persistent host identity during roaming. Of course we consider mobile h= osts > but the identity will be different in each place. yeah that's not what I took away from the dicussion. >=20 >=20 >> _______________________________________________ >> hiaps mailing list >> hiaps@ietf.org >> https://www.ietf.org/mailman/listinfo/hiaps >> >> >=20 --wx0bGHtAbbheRnfRebX53jQwRVkVrJGRC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlKp9OsACgkQ8AA1q7Z/VrI0uQCfalLKZYLrPmkeQa7kMxHLYYrO 548An1qbjPc6hcN62Y8rEtsYu38l7xp/ =L1lI -----END PGP SIGNATURE----- --wx0bGHtAbbheRnfRebX53jQwRVkVrJGRC-- From sarikaya2012@gmail.com Thu Dec 12 09:47:15 2013 Return-Path: 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 CD9341ADF84 for ; Thu, 12 Dec 2013 09:47:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 ePU3zTQMZ-gM for ; Thu, 12 Dec 2013 09:47:13 -0800 (PST) Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 32E1B1ADE86 for ; Thu, 12 Dec 2013 09:47:12 -0800 (PST) Received: by mail-la0-f48.google.com with SMTP id n7so567119lam.21 for ; Thu, 12 Dec 2013 09:47:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=2DRqo20959yV/0Invz9DWFcLbSI+9VkttUxzAXI+j9w=; b=MGcFF0Z8441scwuGB8/QHm0EVH74bYx0LPYpLA3k/A8YAO3PtAKEnEzcobJv1C6aF5 zsk1r9vgPe8egWRvYdBTt3PNb4yQlgkBhIIjRPrwUVM7rZr46pfa3XU37VimPowJvVmi TxgmFWXjrHEpRvcUMYJGxvxx2Cn5p87Df6/W4zJ6sbA+SVfVhPc8pKd7OBl3j1BgeBk1 Ts3SBjf6KmIVD/9m11UjIf99JdQFAQx0E7t5Qtvkoo11BEVqVpuyp3vlTb1EdnyfB5jN qbXNqVBp7yekfO85ZwoGRrjyEIt78rsl3GMgtokP3vq8AnDScKVwCxylF/wEGw6I4ei/ XlCA== MIME-Version: 1.0 X-Received: by 10.152.1.5 with SMTP id 5mr4543048lai.20.1386870425117; Thu, 12 Dec 2013 09:47:05 -0800 (PST) Received: by 10.115.4.165 with HTTP; Thu, 12 Dec 2013 09:47:05 -0800 (PST) In-Reply-To: <52A9F4EB.2020103@bogus.com> References: <52A97466.2060901@bogus.com> <52A9F4EB.2020103@bogus.com> Date: Thu, 12 Dec 2013 11:47:05 -0600 Message-ID: From: Behcet Sarikaya To: joel jaeggli Content-Type: multipart/alternative; boundary=089e013c664409e6c404ed59efc0 Cc: hiaps@ietf.org Subject: Re: [hiaps] with respect to the BOF request. X-BeenThere: hiaps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: sarikaya@ieee.org List-Id: "Host Identification, Address and Prefix Sharing in Wi-Fi Access \(hiaps\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Dec 2013 17:47:16 -0000 --089e013c664409e6c404ed59efc0 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Dec 12, 2013 at 11:39 AM, joel jaeggli wrote: > On 12/12/13, 9:19 AM, Behcet Sarikaya wrote: > > Hi Joel, > > > > Thanks for your comments. > > My views inline. > > Med can say more... > > > > > > On Thu, Dec 12, 2013 at 2:31 AM, joel jaeggli wrote: > > > >>> 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. > >> > >> I understand there are privacy concerns. > > But in our case, we justify it strongly on a case-by-case basis. > > > > In our IPv6 case, host identifier is IPv6 address and it needs to be > > revealed to the edge router. We don't see any privacy issue here because > > the edge router will know IPv6 address of the communicating hosts anyway. > > > > In our IPv4 case, the situation is that the host is in the process of > > making an emergency call. The call server to which the host identity will > > be revealed has to find the position of the host in order to serve the > > host. > > Again we don't see the same effects of revealing the host identity to > any > > server in this case. It is emergency call situation. > > Oddly I don't agree. being an emergency does not absolve us of dealing > with the question of visibility on path. > > Of course, this brings the security of the protocols used in the solutions issue, right? We need to work on that. I believe the protocols can be made secure. > > Having said the above two, I think we need to of course clarify these > > issues in the drafts as much as possible. > > > > In case of IPv4 we have many other cases, e.g. CGA and the concerns you > > mentioned could be valid to some extent, I believe those are somewhat > > clarified in Med's RFCs, Med can chip in here to say more. > > > > 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. > >> > >> > >> I think it was clarified during email discussions on the list that there > > is no roaming case per se in hiaps, we do not have any case that > requires a > > persistent host identity during roaming. Of course we consider mobile > hosts > > but the identity will be different in each place. > > yeah that's not what I took away from the dicussion. > > I hope it is clarified now? > > > > > >> _______________________________________________ > >> hiaps mailing list > >> hiaps@ietf.org > >> https://www.ietf.org/mailman/listinfo/hiaps > >> > >> > > > > > --089e013c664409e6c404ed59efc0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Thu, Dec 12, 2013 at 11:39 AM, joel jaeggli &l= t;joelja@bogus.com> wrote:
On 1= 2/12/13, 9:19 AM, Behcet Sarikaya wrote:
> Hi Joel,
>
> Thanks for your comments.
> My views inline.
> Med can say more...
>
>
> On Thu, Dec 12, 2013 at 2:31 AM, joel jaeggli <joelja@bogus.com> wrote:
>
>>> 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 L= ocal 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 vis= ible
>> 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 rota= tion
>> of temporary/privacy or cryptographically generated addresses to r= etain
>> host identity bindings that are visible outside a limited scope e.= g. an
>> l2 domain and which persist across host address changes.
>>
>> I understand there are privacy concerns.
> But in our case, we justify it strongly on a case-by-case basis.
>
> In our IPv6 case, host identifier is IPv6 address and it needs to be > revealed to the edge router. We don't see any privacy issue here b= ecause
> the edge router will know IPv6 address of the communicating hosts anyw= ay.
>
> In our IPv4 case, the situation is that the host is in the process of<= br> > making an emergency call. The call server to which the host identity w= ill
> be revealed has to find the position of the host in order to serve the=
> host.
> Again we don't see the same effects of revealing the host identity= =A0to any
> server in this case. It is emergency call situation.

Oddly I don't agree. being an emergency does not absolve us= of dealing
with the question of visibility on path.


Of course, thi= s brings the security of the protocols used in the solutions issue, right?<= br>
We need to work on that. I believe the protocols can be made = secure.

=A0
> Having said the above two, I think we need to of course clarify these<= br> > issues in the drafts as much as possible.
>
> In case of IPv4 we have many other cases, e.g. CGA and the concerns yo= u
> mentioned could be valid to some extent, I believe those are somewhat<= br> > clarified in Med's RFCs, Med can chip in here to say more.


> 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 persisten= ce
>> further raises the =A0stakes with respect to revalation to remote = observers.
>>
>>
>> I think it was clarified during email discussions on the list that= there
> is no roaming case per se in hiaps, we do not have any case that requi= res a
> persistent host identity during roaming. Of course we consider mobile = hosts
> but the identity will be different in each place.

yeah that's not what I took away from the dicussion.

<= br>
I hope it is clarified now?
=A0
>
>
>> _______________________________________________
>> hiaps mailing list
>> hiaps@ietf.org
>> https://www.ietf.org/mailman/listinfo/hiaps
>>
>>
>



--089e013c664409e6c404ed59efc0-- From Dirk.von-Hugo@telekom.de Thu Dec 19 07:46:10 2013 Return-Path: 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 AED911ADFCC for ; Thu, 19 Dec 2013 07:46:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 cqtHHsC8ehVA for ; Thu, 19 Dec 2013 07:46:07 -0800 (PST) Received: from tcmail33.telekom.de (tcmail33.telekom.de [80.149.113.247]) by ietfa.amsl.com (Postfix) with ESMTP id E95CE1ADFA3 for ; Thu, 19 Dec 2013 07:46:06 -0800 (PST) Received: from he113445.emea1.cds.t-internal.com ([10.134.93.105]) by tcmail31.telekom.de with ESMTP/TLS/AES128-SHA; 19 Dec 2013 16:46:03 +0100 Received: from HE113484.emea1.cds.t-internal.com ([10.134.93.124]) by HE113445.emea1.cds.t-internal.com ([::1]) with mapi; Thu, 19 Dec 2013 16:46:03 +0100 From: To: Date: Thu, 19 Dec 2013 16:46:02 +0100 Thread-Topic: [hiaps] with respect to the BOF request. Thread-Index: Ac73Yj1FGkmZxXwRToq6OVaaAOr/5wFbeTeQ Message-ID: <05C81A773E48DD49B181B04BA21A342A2C79618673@HE113484.emea1.cds.t-internal.com> References: <52A97466.2060901@bogus.com> <52A9F4EB.2020103@bogus.com> In-Reply-To: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: multipart/alternative; boundary="_000_05C81A773E48DD49B181B04BA21A342A2C79618673HE113484emea1_" MIME-Version: 1.0 Cc: joelja@bogus.com, sarikaya@ieee.org Subject: Re: [hiaps] with respect to the BOF request. 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Dec 2013 15:46:10 -0000 --_000_05C81A773E48DD49B181B04BA21A342A2C79618673HE113484emea1_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, If you have followed the discussion below, it might be of interest to you t= hat we are currently revising the description for the planned BoF in London= and the proposed charter focusing on the emergency call location use case = for reasons of privacy issues. The new proposal will include the identified problems and try to fix the go= al more clearly. Also the existing work of other WGs on that topic will be considered. We expect the updated text to post early next year and hope you will join. Thanks! Best seasonal greetings and kind regards Dirk From: hiaps [mailto:hiaps-bounces@ietf.org] On Behalf Of Behcet Sarikaya Sent: Donnerstag, 12. Dezember 2013 18:47 To: joel jaeggli Cc: hiaps@ietf.org Subject: Re: [hiaps] with respect to the BOF request. On Thu, Dec 12, 2013 at 11:39 AM, joel jaeggli > wrote: On 12/12/13, 9:19 AM, Behcet Sarikaya wrote: > Hi Joel, > > Thanks for your comments. > My views inline. > Med can say more... > > > On Thu, Dec 12, 2013 at 2:31 AM, joel jaeggli > wrote: > >>> 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. >> >> I understand there are privacy concerns. > But in our case, we justify it strongly on a case-by-case basis. > > In our IPv6 case, host identifier is IPv6 address and it needs to be > revealed to the edge router. We don't see any privacy issue here because > the edge router will know IPv6 address of the communicating hosts anyway. > > In our IPv4 case, the situation is that the host is in the process of > making an emergency call. The call server to which the host identity will > be revealed has to find the position of the host in order to serve the > host. > Again we don't see the same effects of revealing the host identity to an= y > server in this case. It is emergency call situation. Oddly I don't agree. being an emergency does not absolve us of dealing with the question of visibility on path. Of course, this brings the security of the protocols used in the solutions = issue, right? We need to work on that. I believe the protocols can be made secure. > Having said the above two, I think we need to of course clarify these > issues in the drafts as much as possible. > > In case of IPv4 we have many other cases, e.g. CGA and the concerns you > mentioned could be valid to some extent, I believe those are somewhat > clarified in Med's RFCs, Med can chip in here to say more. > 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 observer= s. >> >> >> I think it was clarified during email discussions on the list that there > is no roaming case per se in hiaps, we do not have any case that requires= a > persistent host identity during roaming. Of course we consider mobile hos= ts > but the identity will be different in each place. yeah that's not what I took away from the dicussion. I hope it is clarified now? > > >> _______________________________________________ >> hiaps mailing list >> hiaps@ietf.org >> https://www.ietf.org/mailman/listinfo/hiaps >> >> > --_000_05C81A773E48DD49B181B04BA21A342A2C79618673HE113484emea1_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all,=

If you have followed the = discussion below, it might be of interest to you that we are currently revi= sing the description for the planned BoF in London and the proposed charter= focusing on the emergency call location use case for reasons of privacy is= sues.

The new proposal wil= l include the identified problems and try to fix the goal more clearly.

Also the existing work of oth= er WGs on that topic will be considered.

We expect the updated text to post early next year and hope = you will join.

Thanks!

 

<= p class=3DMsoNormal>Best seasonal greetings and kind regards

Dirk

From: hiaps [mailto:hiaps-bounces@ietf.org] On Behalf Of Behcet Sarikaya
Sent: Donnerstag, 12. Dezember 2013 18:47
To: joel jaeggli
Cc: hiaps@ietf.org
Subject: Re: [= hiaps] with respect to the BOF request.

 

 

=

 <= /p>

On Thu, Dec 12, 2013 at 11:39 AM, joel jaeggli= <joelja@bogus.com= > wrote:

On 12/12/13, 9:19 AM, Behcet Sarikaya wrote:
> Hi Jo= el,
>
> Thanks for your comments.
> My views inline.
&= gt; Med can say more...
>
>
> On Thu, Dec 12, 2013 at 2:3= 1 AM, joel jaeggli <joelja@bogus.com= > wrote:
>
>>> 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
&= gt;> identification is also
>>> required in IPv6 when the ho= sts are assigned addresses from a shared
>> prefix. In most of
= >>> these scenarios, the hosts access the network using Wireless L= ocal Area
>> Networks, aka
>>> Wi-Fi access. In case t= he hosts are behind a NAT box, there is a strong
>> need for the h= ost
>>> identification when the host is accessing a fixed netwo= rk and trying to
>> place an emergency >call.
>>
&g= t;> It is likely given current events, that persistent identifiers visib= le
>> to on-path observers are going to be viewed by the IETF comm= unity in
>> general in an extraordinarily negative light. in parti= cular in the IPv6
>> context I would think it antithetical to the = goals of regular rotation
>> of temporary/privacy or cryptographic= ally 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.
>>
>> I understand = there are privacy concerns.
> But in our case, we justify it strongly= on a case-by-case basis.
>
> In our IPv6 case, host identifier= is IPv6 address and it needs to be
> revealed to the edge router. We= don't see any privacy issue here because
> the edge router will know= IPv6 address of the communicating hosts anyway.
>
> In our IPv= 4 case, the situation is that the host is in the process of
> making = an emergency call. The call server to which the host identity will
> = be revealed has to find the position of the host in order to serve the
&= gt; host.
> Again we don't see the same effects of revealing the host= identity  to any
> server in this case. It is emergency call si= tuation.

Oddly I don't agree= . being an emergency does not absolve us of dealing
with the question of= visibility on path.

 

 

Of course, this brings the security of the protocols used = in the solutions issue, right?

We need to work on that. I believe the protocols can be made secure.
<= br> 

> Having= said the above two, I think we need to of course clarify these
> iss= ues in the drafts as much as possible.
>
> In case of IPv4 we h= ave many other cases, e.g. CGA and the concerns you
> mentioned could= be valid to some extent, I believe those are somewhat
> clarified in= Med's RFCs, Med can chip in here to say more.


> In terms of = employing them for roaming, the question of how would they
>> be g= enerated and where who they be stored becomes germain. What
>> sem= antics are they actually carrying and the question of persistence
>&g= t; further raises the  stakes with respect to revalation to remote obs= ervers.
>>
>>
>> I think it was clarified during= email discussions on the list that there
> is no roaming case per se= in hiaps, we do not have any case that requires a
> persistent host = identity during roaming. Of course we consider mobile hosts
> but the= identity will be different in each place.

yeah that's not what I took away from the dicussion.

 

 

I hope it is clarified now?
 

>
>
>> _____________________= __________________________
>> hiaps mailing list
>> hiaps@ietf.org
>> https://www.ietf= .org/mailman/listinfo/hiaps
>>
>>
>

 <= /o:p>

= --_000_05C81A773E48DD49B181B04BA21A342A2C79618673HE113484emea1_--