Re: [sipcore] location-conveyance-03 just submitted

[Francois Menard <[e-mail]>]

I've challenged the Canadian PSAPs to put their NG-911 use cases in writing.

This is being met with fierce resistance at this time.

Has anyone made an IETF draft of NG-9-1-1 PSAP use cases ?

I'm thinking of adding digitally-signed-by-the-PSAP ALI data in ENUM and allowing PSAP access to Carrier ENUM.

Why allowing PSAPs to fetch MSAG-dispatcheable from Carrier ENUM records be a good idea ?

Regards,

F.


On 2010-07-14, at 9:33 PM, Thomson, Martin wrote:

> Hi Jon,
> 
> There’s a number of issues here.  I think that we need to disentangle them.  The role of the intermediary in this dealing with this problem is a secondary concern.
> 
> There are two primary reasons for having both value and reference: authorization and dynamism.
> 
> Dynamism is the easiest one to pin down.  It's obviously very important to the emergency scenario - the ability of a PSAP to acquire updated location information in a timely fashion is central to many of their use cases.
> 
> draft-ecrit-rough-loc describes a scenario where the UAC is less authorized than the UAS; intermediaries are authorized differently.  In the canonical example, the UAS gets a rubbish location value and a location reference that they can't use.  The rubbish location is enough to get them to a PSAP.  The PSAP uses the reference because they are authorized.
> 
> In either case, it's possible to leave the intermediary out of consideration and concentrate on the information that the UAC provides.  The great thing with the solution that you've proposed is that this is ultimately what happens in any case.  Leaving the b2bua case aside, the UAC is ultimately responsible for what Geolocation is placed in the request.
> 
> The interactions with the intermediary add complexity to the scenario, including some privacy model problems, primarily with retransmission.  I'd like to solve the easier problem first.
> 
> --Martin
> 
> 
> From: Peterson, Jon [mailto:[e-mail]] 
> Sent: Thursday, 15 July 2010 3:09 AM
> To: Thomson, Martin; James M. Polk; [e-mail]
> Subject: Re: [sipcore] location-conveyance-03 just submitted
> 
> 
> [snip]
>> We mean to have the intermediary do the
>> dereference (if one is needed) and compose in the
>> SIP 424 response a MIME body with both the
>> server's version or both locations of the Target,
>> and for that dual location single presence
>> document to be copied into the next SIP request
>> from that UAC (towards that same intermediary).
> 
> Elegant as it is, this just doesn't work.  The UAS (PSAP, LR, etc...) needs to be the entity that does the dereference.  They need to do this because they know how (and when) to make this request so that they get the information they need.  If the intermediary does the dereference, then location information is set in stone from that point onward.
> 
> <JFP> I see your point, but I think the difficulty is deeper still than this. The whole use case for an intermediary providing different (or supplementary) location information above and beyond the location provided by the UAC is based on the intermediary inspecting, and disliking, the location present in the request. If that location is constantly changing, what would it mean for the intermediary to dislike it? Maybe it likes it one minute and not the next? Would it –ever- be safe for a picky intermediary to allow a reference to pass it, given that it couldn’t control what location the LR would ultimately get from it? Moreover, what if the creator of the reference authorizes the end recipient (the PSAP) but not the intermediary that wants to judge location information? I think we’d need to look further into the motivations here to understand the underlying requirement.
> 
> Practically speaking, however, there are a number of potential work-arounds to enable this semantic – I don’t necessarily think that once the intermediary performs the dereference, then the location information must be set in stone. If you seriously want to retain the dynamism of location information, it could become the responsibility of the compositor to deliver a similarly dynamic reference, and every time someone dereferences the composed object, the compositor creates a new PIDF-LO document based on freshly dereferencing any dynamic components of the location information. Another possibility would be to specify external references in PIDF, so we could compose location information from dynamic sources by reference in the PIDF object, rather than by value. One composed object could even have a mix of by-value and by-reference location information in that case. The important thing is that we solve this down in the PIDF level, within the parameters of RFC4479, rather than trying to cobble together some relationship between devices, services and users in the Geolocation header.
> 
> Anyway, none of this is to suggest that this is adequately specified in the current draft, or something. We’d need to have a more lengthy discussion about some of the issues above before figuring out what we’d add, though.
> 
> Jon Peterson
> NeuStar, Inc.
> _______________________________________________
> sipcore mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sipcore