RE: [Sipping-emergency] Re: [Sipping-emergency] draft-schulzrinne -sipping-emergency-req-00

["Peterson, Jon" <[e-mail]>]

inline.

- J

> -----Original Message-----
> From: Henning Schulzrinne [mailto:[e-mail]]
> Sent: Tuesday, February 25, 2003 2:54 PM
> To: Peterson, Jon
> Cc: [e-mail]
> Subject: Re: [Sipping-emergency] Re: [Sipping-emergency]
> draft-schulzrinne -sipping-emergency-req-00
> 
> 
[snip]
> 
> I would like to identify any real work which isn't just "purchasing 
> requirements for PSAP RFP" in the trunk replacement part. Can you 
> identify anything?
> 

Well, there are a number of issues, I think, many of which you identify in
your section 4 (in M1-M12). Some other things include:

- For ISUP e911 trunks, ISUP encapsulation in SIP seems like a reasonable
way to carry signaling information between the selective router and the
IECC. What about for non-ISUP signaling systems?

- What sorts of URIs are used to represent IECCs (especially in light of M4
and and M12)?

- Are there any special rules for the distribution of credentials used for
authentication between IECCs and selective routers? How many IECCs are
associated with selective routers and vice versa?

- Are there any RTP requirements that emerge from M6?

Again, this might not require radical new extensions to the SIP protocol -
it's probably doable with more or less the tools we have today. But
depicting a framework and architecture in an I-D along with the section 4
reqs would make it easier for the industry to understand how this trunking
replacement solution fits in.

> I happen to think that while end-to-end or even first-mile (something I 
> haven't called out explicitly) does need geo information that the 
> problem can be scoped properly so that it does not interfere with 
> geopriv work. At this point, I don't see the need to specify in detail 
> how the PSAP gets the location of the caller. We know it needs to - I 
> don't think geopriv is going to change that. There are only two 
> plausible ways to convey location - in a 'using protocol' and in some 
> out-of-band retrieval mode using a geopriv-specific mechanism. I don't 
> think that level of detail is controversial or likely to change.
> 

If the PSAP is expected to retrieve or receive the location information over
IP, then I would argue we've moved into the realm of geopriv. If on the
other the PSAP derives this location information from an ALI interface, then
we don't need geopriv - but, ALI is only relevant to telephone numbers, at
least at the moment. Not all SIP endpoints will have telephone numbers, etc.

> Also, the PSAP selection problem can be partially solved with existing 
> (apparently non-controversial) items in geopriv, namely the DHCP items.
> 

PSAP selection isn't really the main problem here, I think. I agree that
DHCP could help with PSAP selection.

Certainly there hasn't been much controversy about the DHCP proposal to
date, but I would note that the WG is more focused on delivering a framework
and requirements that jumping into a solution. The DHCP solution is, as far
as I understand it, oriented towards informing a telephone where it lives.
The degree to which this entails moving location information (civil or
geospatial) over an open IP network will largely dictate whether or not DHCP
would have to meet the security and policy requirements of geopriv. Until
those requirements are finished, it's hard to establish how well the DHCP
solution meets them.

> Thus, as long as we assume that geopriv does its job, we can fill in the 
> other pieces and make progress, treating geopriv as a suitable black box.
> 
> Thus, if we scope the work properly, I don't see why we'd bump into 
> geopriv issues except saying "you guys over there, we'll need you, get 
> busy".
> 
> Henning
> 
_______________________________________________
Sipping-emergency mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/sipping-emergency