Re: [Ecrit] New work in ECRIT

"Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com> Thu, 05 August 2010 06:21 UTC

Return-Path: <hannes.tschofenig@nsn.com>
X-Original-To: ecrit@core3.amsl.com
Delivered-To: ecrit@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D0F43A685F for <ecrit@core3.amsl.com>; Wed, 4 Aug 2010 23:21:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.498
X-Spam-Level:
X-Spam-Status: No, score=-102.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xrwsqkkBqhnm for <ecrit@core3.amsl.com>; Wed, 4 Aug 2010 23:21:16 -0700 (PDT)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 8F10C3A6884 for <ecrit@ietf.org>; Wed, 4 Aug 2010 23:21:15 -0700 (PDT)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o756LdH0003319 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 5 Aug 2010 08:21:39 +0200
Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o756Lc46025273; Thu, 5 Aug 2010 08:21:38 +0200
Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 5 Aug 2010 08:21:37 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB3466.757B2555"
Date: Thu, 05 Aug 2010 09:21:36 +0300
Message-ID: <3D3C75174CB95F42AD6BCC56E5555B4502DE8DA2@FIESEXC015.nsn-intra.net>
In-Reply-To: <BLU137-W933692C5ED6EC042DF1F893AE0@phx.gbl>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Ecrit] New work in ECRIT
Thread-Index: AcszMOsY6YiCVp4xSpWhPKEJInzzPQBMxpTQ
References: <C87D8FB6.2760A%mlinsner@cisco.com> <BLU137-W933692C5ED6EC042DF1F893AE0@phx.gbl>
From: "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com>
To: ext Bernard Aboba <bernard_aboba@hotmail.com>, mlinsner@cisco.com, ecrit@ietf.org
X-OriginalArrivalTime: 05 Aug 2010 06:21:37.0964 (UTC) FILETIME=[75E806C0:01CB3466]
Subject: Re: [Ecrit] New work in ECRIT
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ecrit>
List-Post: <mailto:ecrit@ietf.org>
List-Help: <mailto:ecrit-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Aug 2010 06:21:18 -0000

Hi Bernard, 

a few comments to your statements below: 
 

________________________________

	From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On
Behalf Of ext Bernard Aboba
	Sent: Tuesday, August 03, 2010 8:26 PM
	To: mlinsner@cisco.com; ecrit@ietf.org
	Subject: Re: [Ecrit] New work in ECRIT
	
	
	My humble suggestion is that draft-rosen-ecrit-additional-data
is both straightforward and highly beneficial.  While IETF tradition
would suggest that items with such a high benefit/cost ratio should be
delayed indefinitely or abandoned in favor of items that are more
intractable,  I'd suggest a concession to common sense in this isolated
instance.
	
	Of course, in order to ensure that the WG does not debase itself
in an orgy of productivity, tradition requires that the WG take on a
number of work items which are "hard" only because the wrong questions
are being asked.   I'd assert that both Unauthenticated Access and PSAP
callback  fall in this category.   
	
	Unauthenticated Access is "hard" because it represents a
solution without a real problem.  There is no regulatory requirement for
this today, nor is there likely to be one in the near future because the
"solution" would itself be a problem and because technology such as
femtocells will make the "problem" disappear in due course. 
	 
	I have to disagree with you and here are my arguments.  The
document covers a number of scenarios, even though we always just
short-cut the description and talk about "unauthenticated access":
	 a) No access authorization 
	 b) No ASP  
	 c) Zero-balance ASP 
	 
	There are differences between the legacy telephony system and
VoIP. No doubt. We do, however, see people moving towards IP-based
networks and now the question is how the existing regulatory
requirements will apply to an IP-based environment. With all the years
we have had a hard time to figure out how this is going to work out
particularly since there is no flag day. Regulators, as you know, try to
claim that they are technology neutral and therefore they are likely
going to stick with their requirements and assume that technical people
will get the rest to work. Many people had looked at the requlatory
space and have not come up with a consistent answer of what all the
regulatory requirements for VoIP systems are (given that regulators are
often not too explicit). Maybe we should interact with NENA and EENA to
hear their view on the regulatory situation. 
	 
	Let me talk about the above three items in context of the legacy
infrastructure: 
	For (a) and (c) there are regulatory requirements. (b) is a case
that cannot happen in the legacy technology but is quite likely in the
VoIP case (see the more verbose description at
http://tools.ietf.org/html/draft-winterbottom-ecrit-direct-02). 
	 
	From a VoIP point of view I would be really surprised if (c) is
not useful in a VoIP context as well. As mentioned in the previous
paragraph, (b) might actually be desirable from a communication point of
view and I hear the argument about the applicable jurisdiction all the
time. (a) is clearly tough and maybe the only thing we can do in this
document is to point out some of the challenges and discourage it. With
the ESWs we have lots of presenters talking about this topic and we
tried to convince people that (a) is not a good approach but
nevertheless the feedback we got is that people from the regulatory side
still see some value in it.  I fear that just because we do not like it
does not make it go away. For the same reason the 3GPP has worked on
solutions for IMS in this space. 
	

	 In a nutshell, I believe that this document is very useful
already if it only provides a way to describe the differences between
the legacy technology and why certain concepts cannot be mapped 1-to-1.
Talking about the architectural challenges and what aspects need to be
considered will be useful for readers as well. There are simpler cases
that can be tackled, such as (b) and (c), with a somewhat detailed
description.
	 
	PSAP Callback is "hard" largely because of the disconnect
between the PSTN way of thinking and the reality of VOIP, which will
result in extended (and largely fruitless) "discussions", until the
passage of the leaves the obvious solution in plain view, like a whale
washed up on the beach.  Serializing other work items until this "hard"
problem is "solved" will essentially cause them to wait in the queue
until our teeth are but a memory.  
	 
	As we discussed during the IETF week I will interview some more
emergency services people about the user interface experience to gather
some more data about this aspect. 
	 
	Ciao
	Hannes
	 
	
	
	> Date: Tue, 3 Aug 2010 09:19:50 -0400
	> From: mlinsner@cisco.com
	> To: ecrit@ietf.org
	> Subject: [Ecrit] New work in ECRIT
	> 
	> During the meeting last week the following drafts were
discussed in the
	> context of accepting them as WG items.
	> 
	> draft-rosen-ecrit-additional-data
	> draft-schulzrinne-ecrit-psap-callback
	> draft-schulzrinne-ecrit-unauthenticated-access
	> draft-tschofenig-ecrit-trustworthy-location
	> draft-rosen-ecrit-data-only-ea
	> 
	> The chairs and ADs have reviewed the level of interest in
these, compared
	> the work to the current charter and believe these fit within
the scope of
	> ECRIT.
	> 
	> We asked during the meeting if anyone objects to accepting any
or all of
	> these drafts as WG items. So, now, we're asking on the list.
	> 
	> If you object to any of these drafts becoming WG items, please
explain if
	> you think the work is something ECRIT should not do, or if you
simply have
	> problems with current version of the particular draft. No
response is a
	> show of support for all of this work.
	> 
	> Once the above question is answered, the chairs will devise a
work plan to
	> finish the accepted work.
	> 
	> Also discussed in the meeting was the priority order of
getting these drafts
	> completed, and it was the general feeling that psap-callback,
	> unauthenticated-access, and trustworthy-location were the most
difficult and
	> would take more time. Of those three the general feeling was
the
	> psap-callback was the highest priority. If you have an opinion
on which
	> draft should completed first, please send it to the list.
	> 
	> Please respond by COB on Wednesday, 8/11/2010 if you have
objections to any
	> of this work, or you have strong feelings on the priority of
the work.
	> 
	> Thanks,
	> 
	> -Marc, Richard, Roger-
	> 
	> 
	> _______________________________________________
	> Ecrit mailing list
	> Ecrit@ietf.org
	> https://www.ietf.org/mailman/listinfo/ecrit