Subject: [hiaps] Draft Charter Revised

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 8 Jan 2014 14:14:28 -0600

Hi all,

Based on the comments received so far and based on our contacts with ETSI,
we have revised the charter. Please check the current version at:

http://trac.tools.ietf.org/bof/trac/

Please direct all comments and support to the list.

Kind regards,

Behcet

---

From: joel jaeggli <[email-masked]>
Date: Wed, 08 Jan 2014 14:55:03 -0800

I realize that it's early january  but given that the BOF scheduling
call is on or about the 17th. this needs to happen rather fast.

The has ben effectively minimal input since the list renaming, save for
the discussion of a mobility use case. This isn't the basis for a
successful outing on this and it's far short of a working group
chartering activity.

I appreciate the effort that Behcet and Dirk have done to keep this
going, but I'm not feeling the love so far. thanks.

joel

On 1/8/14, 12:14 PM, Behcet Sarikaya wrote:
> _______________________________________________
> hiaps mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hiaps
>

---

From: Qiong <[email-masked]>
Date: Fri, 10 Jan 2014 14:05:56 +0800

Hi, Behcet, and all,

I support the revised charter. It is clear, concentrated.

One simple comment: Now that we mainly focus on emergency call use case, I
think the use case drafts should also be modified accordingly.

Best wishes
Qiong

-- 
==============================================
Qiong Sun
China Telecom Beijing Research Institude

Open source code:
lightweight 4over6: *http://sourceforge.net/projects/laft6/
<http://sourceforge.net/projects/laft6/>*
PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/
<http://sourceforge.net/projects/pcpportsetdemo/> *
===============================================

---

From: <[email-masked]>
Date: Wed, 15 Jan 2014 15:52:31 +0100

Hi Behcet, all,

I just read the proposed charter text. I don't understand why the scope is limited to the emergency case. IMHO, the emergency case is only a use case among others. I don't understand either why "Wi-Fi" access is mentioned in the title of the proposed bof.

Cheers,
Med

De : Behcet Sarikaya [mailto:[email-masked]]
Envoyé : mercredi 8 janvier 2014 21:14
À : [email-masked]
Cc : [email-masked]
Objet : Draft Charter Revised

Hi all,
Based on the comments received so far and based on our contacts with ETSI, we have revised the charter. Please check the current version at:

---

From: <[email-masked]>
Date: Wed, 15 Jan 2014 19:19:26 +0100

Hi Med and all,
Thanks for the question. I agree that emergency call is just one of multiple use cases where host identification is an issue and currently no viable solution is agreed on.
On the other hand we have to realize and keep in mind that (not only nowadays) the privacy issues for location and identity are a major concern towards everyone. It seems that for most of the use cases thus a satisfying solution will be hard to find - the narrowed down scenario with limited actors to which the identity is uncovered (emergency and call service providers) might allow to manage the issue here.
We have chosen WiFi as typical and widespread environment providing guest access where - as opposite to cellular service - the identity may be not accessible to any intermediate connectivity provider.
Surely after successful solution of this case one can try to extend it to others ...

Hope this helps to understand. Any further comments and opinions welcome!
Best regards
Dirk
From: [email-masked] [mailto:[email-masked]]
Sent: Mittwoch, 15. Januar 2014 15:53
To: [email-masked]; [email-masked]
Cc: von Hugo, Dirk
Subject: RE: Draft Charter Revised

Hi Behcet, all,

Cheers,
Med

Hi all,

---

From: joel jaeggli <[email-masked]>
Date: Wed, 15 Jan 2014 10:34:39 -0800

> I just read the proposed charter text. I don't understand why the scope is limited to the emergency case. IMHO, the emergency case is only a use case among others. I don't understand either why "Wi…

my 12/12/13 observation was as follows

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

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

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

---

From: <[email-masked]>
Date: Fri, 17 Jan 2014 17:44:00 +0100

Dear all,
We have some people being active on the list who are working on new drafts to discuss requirements and potential solutions tailored for the emergency call use case. Thanks for that!
While approaching the next mile stones could you please post on the list the status of the documents and the expected time frame for submission?
Thanks a lot!
I think we also have already volunteers for reviewing available.
This is very much appreciated.

Best regards and have a nice weekend 

Dirk
-----Original Message-----
From: hiaps [mailto:[email-masked]] On Behalf Of joel jaeggli
Sent: Mittwoch, 8. Januar 2014 23:55
To: [email-masked]; [email-masked]
Cc: von Hugo, Dirk
Subject: Re: [hiaps] Draft Charter Revised

I realize that it's early january  but given that the BOF scheduling call is on or about the 17th. this needs to happen rather fast.

The has ben effectively minimal input since the list renaming, save for the discussion of a mobility use case. This isn't the basis for a successful outing on this and it's far short of a working group chartering activity.

I appreciate the effort that Behcet and Dirk have done to keep this going, but I'm not feeling the love so far. thanks.

joel

On 1/8/14, 12:14 PM, Behcet Sarikaya wrote:
> Hi all,
> 
> Based on the comments received so far and based on our contacts with 
> ETSI, we have revised the charter. Please check the current version at:
>

---

From: Qiong <[email-masked]>
Date: Sat, 18 Jan 2014 11:36:49 +0800

Dear Drik,

Yes, we are working on a requirement draft. We have finished a 00 version
and are now under review of our co-authors. Hopefully, we will be able to
submit the draft early next week.

Best wishes
Qiong

On Sat, Jan 18, 2014 at 12:44 AM, <[email-masked]> wrote:

> Dear all,
> We have some people being active on the list who are working on new drafts
> to discuss requirements and potential solutions tailored for the emergency
> call use case. Thanks for that!
> While approaching the next mile stones could you please post on the list
> the status of the documents and the expected time frame for submission?
> Thanks a lot!
> I realize that it's early january  but given that the BOF scheduling call
> is on or about the 17th. this needs to happen rather fast.
>
> successful outing on this and it's far short of a working group chartering
> activity.
>
> I appreciate the effort that Behcet and Dirk have done to keep this going,
> but I'm not feeling the love so far. thanks.
>
> joel
>

Open source code: