Subject: RE: [ECRIT]: Caller Identity requirements: replacement text foremptysection in ECRIT req doc.

From: "Tim Dunn" <[email-masked]>
Date: Thu, 20 Oct 2005 15:49:12 -0600

Marc-

I'll express this in terms of ECRIT scope.  A caller's location is made up
of 2 things:  Physical location on the ground and their identity at that
physical location (i.e. callback).  What the PSAP does with the callback,
I'll agree, is out of scope.  But as a part of the basic location identity
of the caller, it's location and callback.

Tim

-----Original Message-----
From: Marc Linsner [mailto:[email-masked]] 
Sent: Thursday, October 20, 2005 3:06 PM
To: 'Tim Dunn'; [email-masked]
Cc: 'ECRIT'
Subject: RE: [ECRIT]: Caller Identity requirements: replacement text
foremptysection in ECRIT req doc.

Tim,

I'm not saying that "call-back" is not a requirement.  I'm stating that it
is not a requirement that ECRIT must solve.  I agree that Caller Identity
requirement(s) are necessary for proper emergency calling operations.

ECRIT is narrowly chartered and I interpret ECRIT's charter as 2 things:

1) Identify an emergency call.

2) Given location information, resolve to a PSAP URI.

There will be a future document from ECRIT that outlines various emergency
calling requirements that ECRIT did not/will not handle.  I suspect Caller
Identity requirement should be in that document.

-Marc-

> -----Original Message-----
> From: Tim Dunn [mailto:[email-masked]] 
> Sent: Thursday, October 20, 2005 4:19 PM
> To: 'Marc Linsner'; [email-masked]
> Cc: 'ECRIT'
> Subject: RE: [ECRIT]: Caller Identity requirements: 
> replacement text foremptysection in ECRIT req doc.
> 
> I'm assuming the charter is at:
> http://www.ietf.org/html.charters/ecrit-charter.html
> 
> A very limited view read of the charter is:
> 
> "Internet technologies available to describe location and to 
> manage call routing."
> 
> The only item explicitly out of scope is:
> 
> "... the question of pre-emption or prioritization of 
> emergency services traffic."
> 
> I would argue that the tying the location of the caller to a 
> way to re-contact that caller (especially if the call 
> disconnects and the caller cannot be located) is a part of 
> the native existing processes of "...special call centers 
> equipped to manage emergency response."
> 
> The charter does say "While this group anticipates a close 
> working relationship with groups such as NENA and ETSI EMTEL, 
> any solution presented must be useful regardless of 
> jurisdiction..."  I'll argue that NENA, ETSI EMTEL or any 
> jurisdiction that manages a "special call center" would want 
> to know why there's no standardized method to provide a call 
> back number associated with a caller's location.  What you 
> are proposing by eliminating a call back number is a solution 
> that could be considered out of scope because it is not useful.  
> 
> Tim Dunn
> 
> 
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Marc Linsner
> Sent: Thursday, October 20, 2005 1:45 PM
> To: [email-masked]
> Cc: 'ECRIT'
> Subject: RE: [ECRIT]: Caller Identity requirements: 
> replacement text foremptysection in ECRIT req doc. 
> 
> OK, I believe I have found the source of the "call-back' 
> thread (with a little bumping from Roger).
> 
> Brian,
> 
> After looking over ecrit's charter again, I can't find where 
> ecrit needs to worry about caller identity.  I sympothize 
> with your requirement, but I just can't find a place for it in ecrit.
> 
> Does anybody have a different opinion??
> 
> Caller Identity going once, going twice,.........
> 
> -Marc-
> 
> > -----Original Message-----
> > From: [email-masked] 
> [mailto:[email-masked]] On Behalf 
> > Of Roger Marshall
> > Sent: Tuesday, October 18, 2005 7:42 PM
> > To: ECRIT
> > Subject: [ECRIT]: Caller Identity requirements: replacement 
> text for 
> > emptysection in ECRIT req doc.
> > 
> > All:
> > There has been a placeholder within the ECRIT requirements draft 
> > titled, "Emergency Caller Identification".  Since this section was 
> > requested back on 8/09, I guess I'll take a crack at 
> submitting some 
> > (proposed) text for it (below):
> > 
> > 
> > "When a person places an emergency call to a PSAP, existing 
> emergency 
> > service messaging conveys associated caller information in 
> addition to 
> > receiving the caller's voice.
> > This additional information typically consists of a 
> call-back number, 
> > and the caller's location (referred to as ANI and ALI, for North 
> > American systems)."
> > 
> > "Some systems use the received callback number to perform a 
> identity 
> > lookup via a database lookup service, and then use the location 
> > information received to help verify the caller's identity presented 
> > both via voice, as well as the external data presented from the 
> > identity database query.  These external mechanisms are 
> important for 
> > many reasons, including helping callers who cannot, or will 
> not speak, 
> > to prevent false information from impeding appropriate dispatch 
> > instructions and procedures, and ultimately to enable 
> faster response 
> > in the offering of help."
> > 
> > "IP-based emergency systems in the future may be able to offer even 
> > more information about the caller, to help establish personal 
> > identity, but also for today, for near-term 
> implementations, need to 
> > provide the same minimum level of identitifcation support as in the 
> > existing legacy emergency systems."
> > 
> > "Req1: A "Call-back" number MUST be supplied within the 
> call signaling 
> > for each emergency call sent to the PSAP.  The ECRIT protocol may 
> > provide this number in the form of a tel:uri, a sip:uri, or an 
> > IP-Address."
> > 
> > "Req2: The ECRIT protocol MUST support the ability for the PSAP to 
> > perform caller identity lookup based on the tel:uri, sip:uri, or IP 
> > Address provided with call signaling.  (A variety of competing 
> > directory lookup services may exist, but is not discussed in detail 
> > here, as it is out of scope of this document.)"
> > 
> > "Req3:  The ECRIT protocol MUST support the ability to associate 
> > individual call location information with external caller identity 
> > records."
> > 
> > 
> > 
> > I have attempted to steer clear of obvious privacy 
> > concerns/objections, modeling this after what's available 
> today in ES, 
> > but there are more details that some may want to tease out.
> > 
> > Comments?
> > 
> > Roger Marshall.
> > 
> > _______________________________________________
> > Ecrit mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/ecrit
> 
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ecrit

_______________________________________________
Ecrit mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit

---

From: "Marc Linsner" <[email-masked]>
Date: Thu, 20 Oct 2005 18:21:52 -0400

Tim,

I have not seen any other assertion that includes caller identity with
physical location.

BTW, the contact headers in SIP aren't good enough?

-Marc- 

> Sent: Thursday, October 20, 2005 5:49 PM
> I'll express this in terms of ECRIT scope.  A caller's 
> location is made up of 2 things:  Physical location on the 
> ground and their identity at that physical location (i.e. 
> callback).  What the PSAP does with the callback, I'll agree, 
> is out of scope.  But as a part of the basic location 
> identity of the caller, it's location and callback.
> 
> Tim
> 
> I'm not saying that "call-back" is not a requirement.  I'm 
> stating that it is not a requirement that ECRIT must solve.  
> I agree that Caller Identity
> There will be a future document from ECRIT that outlines 
> various emergency calling requirements that ECRIT did 
> not/will not handle.  I suspect Caller Identity requirement 
> should be in that document.
> 
> -Marc-
> 
> > "Internet technologies available to describe location and to manage 
> > call routing."
> > 
> > "... the question of pre-emption or prioritization of emergency 
> > services traffic."
> > 
> > I would argue that the tying the location of the caller to a way to 
> > re-contact that caller (especially if the call disconnects and the 
> > caller cannot be located) is a part of the native existing 
> processes 
> > of "...special call centers equipped to manage emergency response."
> > 
> > The charter does say "While this group anticipates a close working 
> > relationship with groups such as NENA and ETSI EMTEL, any solution 
> > presented must be useful regardless of jurisdiction..."  I'll argue 
> > that NENA, ETSI EMTEL or any jurisdiction that manages a 
> "special call 
> > center" would want to know why there's no standardized method to 
> > provide a call back number associated with a caller's 
> location.  What 
> > you are proposing by eliminating a call back number is a 
> solution that 
> > could be considered out of scope because it is not useful.
> > 
> > Tim Dunn
> > 
> > 
> > 
> > Of Marc Linsner
> > After looking over ecrit's charter again, I can't find where ecrit 
> > needs to worry about caller identity.  I sympothize with your 
> > requirement, but I just can't find a place for it in ecrit.
> >

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 20 Oct 2005 21:57:52 -0400

Just to rephrase slightly what Marc has said: I think there is general 
agreement that call signaling and civic/geo-address-to-URL mapping are 
independent and thus it seems unnecessary (and potentially a privacy 
violation) for the mapping protocol to know anything about the caller's 
identity, call back number or other similar non-location information.

(Maybe an explicit scope disclaimer in the requirements document would 
be helpful.)

---

From: "Tim DUNN" <[email-masked]>
Date: Thu, 20 Oct 2005 22:19:07 -0600

The PSAP needs is a location and a call back.  Not providing both is a 
reduction in existing capabilities in place for circuit switched and mobile 
911 calls.  Both need to be accounted for somewhere in this overall set of 
requirements/architecture.

>From: Henning Schulzrinne <[email-masked]>
>To: Tim Dunn <[email-masked]>
>CC: "'Marc Linsner'" <[email-masked]>, [email-masked],        
>"'ECRIT'" <[email-masked]>
>Subject: Re: [ECRIT]: Caller Identity requirements: replacement 
>text	foremptysection in ECRIT req doc.
>Date: Thu, 20 Oct 2005 21:57:52 -0400
>
>(Maybe an explicit scope disclaimer in the requirements document would be 
>helpful.)
>
>Tim Dunn wrote:
>>Marc-
>>

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 21 Oct 2005 09:25:19 -0400

Tim DUNN wrote:
> reduction in existing capabilities in place for circuit switched and 
> mobile 911 calls.  Both need to be accounted for somewhere in this 
> overall set of requirements/architecture.
> 

It's pretty simple: The call setup request reaching the PSAP provides 
call back information and location information, in-band. I agree with 
the need for an architecture document; I've written (long-expired) 
versions of something approximating those.

Henning

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Mon, 24 Oct 2005 16:36:41 -0400

I think you're under the mistaken impression that ECRIT is producing a 
complete solution to emergency service calling.  That simply isn't so. 
The complete solution has to be worked in bodies that create 
architectures and not just protocols.

---

From: Andrew Newton <[email-masked]>
Date: Wed, 26 Oct 2005 12:56:53 -0400

Given this message: http://www1.ietf.org/mail-archive/web/ecrit/ 
current/msg01077.html
Perhaps the scope of ECRIT is even more restrictive in that we are  
not even suppose to contemplate the other pieces that make the total  
solution.

I understand the IESG's reluctance to grant working group charters  
for work that seems open ended, prone to rat holes, and quite easy to  
drive into the weeds.  But I also think it equally unwise to be so  
restrictive as to generate incomplete and/or unworkable solutions.

-andy

On Oct 24, 2005, at 4:36 PM, Tom-PT Taylor wrote:

> I think you're under the mistaken impression that ECRIT is  
> producing a complete solution to emergency service calling.  That  
> simply isn't so. The complete solution has to be worked in bodies  
> that create architectures and not just protocols.
>
> Tim DUNN wrote:
>
>> The PSAP needs is a location and a call back.  Not providing both  
>> is a reduction in existing capabilities in place for circuit  
>> switched and mobile 911 calls.  Both need to be accounted for  
>> somewhere in this overall set of requirements/architecture.
>>
>
>

---

From: "Marc Linsner" <[email-masked]>
Date: Wed, 26 Oct 2005 13:58:52 -0400

Andy,

I struggling to grasp your point.

Emergency Context Routing - I think the operative word is 'routing'.  As Tom
alluded to, ECRIT is not the end-all, be-all to an Emergency Calling
Architecture.  Tim Dunn is not the only one to express displeasure with this
fact.

Delivering caller information and location information to a PSAP is
orthogonal to routing the call.  ECRIT will figure out how to identify an
emergency call, then how to route an emergency call.

As you stated, the IESG believes that managing small tasks is a better
process than tackling large tasks.  I believe this mechanism is prudent as
evidenced by ECRIT's slow progress to date even with such a narrow scope.
Alternatively, I also believe that ECRIT would be moving faster if there was
common understanding to an overall architecture, which is why Hannes and I
don't want to deter such contributions along this topic, yet we must keep
moving towards the chartered goals.

Do you have suggestions that would better our process?

Thanks,

-Marc-

> On Behalf Of Andrew Newton
> Sent: Wednesday, October 26, 2005 12:57 PM
> To: Tom-PT Taylor
> Cc: [email-masked]
> Subject: Re: [ECRIT]: Caller Identity requirements: 
> replacementtext foremptysection in ECRIT req doc.
> 
> Perhaps the scope of ECRIT is even more restrictive in that 
> we are not even suppose to contemplate the other pieces that 
> make the total solution.
> 
> I understand the IESG's reluctance to grant working group 
> charters for work that seems open ended, prone to rat holes, 
> and quite easy to drive into the weeds.  But I also think it 
> equally unwise to be so restrictive as to generate incomplete 
> and/or unworkable solutions.
> 
> -andy
>

---

From: Andrew Newton <[email-masked]>
Date: Wed, 26 Oct 2005 14:30:27 -0400

On Oct 26, 2005, at 1:58 PM, Marc Linsner wrote:
> Emergency Context Routing - I think the operative word is 'routing'.

In the title of this working group, the operative word is  
"resolution".  :)

> moving towards the chartered goals.

I agree that we would be moving faster if there were a common  
understanding for the architecture.  But why produce a solution  
before you understand the architecture?

-andy