Subject: Re: [Ecrit] Dan Romascanu's Discuss on draft-ietf-ecrit-phonebcp-17: (with DISCUSS and COMMENT)

From: Bernard Aboba <[email-masked]>
Date: Sun, 1 May 2011 18:13:40 -0700

> Part of the issues in the DISCUSS were raised in Bernard 
> Aboba's OPS-DIR review. I recommend all his review to be 
> addressed. I included in my DISCUSS those issues that seemed 
> to me critical. FYI, the review is available here:
https://www.ietf.org/ibin/c5i?mid=6&rid=49&gid=0&k1=933&k2=56267&tid=1304298146

Detailed comments are available here:  http://www.drizzle.com/~aboba/ops-dir/draft-ietf-ecrit-phonebcp

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 29 Apr 2011 08:13:59 +0100

On 29 Apr 2011, at 03:05, "Dawson, Martin" <[email-masked]> wrote:

>> I understand what you're saying. How about if it said that devices must be able to do this and should actually do it, which'd be something like:
>> 
>>   "a caller's device must be able to, and should, obtain..."
> 
> I think that's more in the right spirit. To tighten it further it could be:
> 
> "...must be able and attempt to obtain..." - after that it's a matter of distinguishing what it must do if it succeeds in getting location and should do if it did not.

That'd work for me,
Thanks,
S

> 
> Regards,
> Martin
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Stephen Farrell
> Sent: Thursday, 28 April 2011 10:11 PM
> To: Richard L. Barnes
> Cc: [email-masked]; [email-masked]; [email-masked] Org; The IESG
> Subject: Re: [Ecrit] Stephen Farrell's Discuss on draft-ietf-ecrit-framework-12: (with DISCUSS and COMMENT)
> 
> 
> Hi Richard,
> 
> On 28/04/11 12:50, Richard L. Barnes wrote:
>> Hey Stephen,
>> 
>> Couple of points inline below.
>> 
>>>>> (1) Section 3 says: "a caller must obtain his location...prior to making
>>>>> emergency calls." That seems overstated - if I can't find my location 
>>>>> are you saying that the call can't happen? (A "should" would be right
>>>>> here I think.)
>>>> This is in an overview section, it's not MUST and it's properly qualified later.  Anyone in emergency services will tell you that the three most important things about emergency calling are location, location and location (which is a U.S. specific reference to a joke about real estate)
>>>> We usually get all these rules must this, must that, and when you enquire what happens when something fails and you can't follow the rules, you find they take them and deal with them.
>>>> 
>>>> I'd prefer not to change it in the document, but of course we can (to should).
>>> 
>>> Well, I think must just isn't correct, even though this isn't 2119
>>> language so some other wording is needed. I'd be fine with "really
>>> should" or anything that's accurate.
>> 
>> I agree that we're sort of arguing style/taste here.  
> 
> Disagree. I think that "must" is misleading here.
> 
>> But I did want to emphasize that location actually is *really*
> important for this process.  This whole document is about how you do
> urgent, location-based call routing.
>> 
>> In order for an emergency call to work, somebody needs to know the caller's location, either the caller himself or his VoIP provider.  In general, the latter case is infeasible; the only case where that really happens is for carrier-provided VoIP services, like the Comcast "digital voice" service that they sell alongside their Internet service.   For all other VoIP services in all other classes of network, the end device needs to do the location bits, because it's the only device that talks to both the access network (for location) and VoIP system (for call delivery).
>> 
>> Given that location is such an important thing that so often has to be done by the end device, it seems to me that saying "must" here sets the proper context for the reader.
> 
> I understand what you're saying. How about if it said that devices must
> be able to do this and should actually do it, which'd be something like:
> 
>   "a caller's device must be able to, and should, obtain..."
> 
>>>>> (2) Is MESSAGE/MSRP the right IM choice to make for emergencies? Would
>>>>> xmpp be more likely to be useful? (Just checking.)
>>>> We've considered xmpp.  We would have to extend xmpp in several ways, and then extend framework and phonebcp in ways compatible with the extensions.  Absent the extensions in at least draft form, we'll probably update -framework and -phonebcp later.
>>> 
>>> Fair enough.
>>> 
>>>>> (3) How would any of this work with p2psip? (Just checking again.)
>>>> Same as above, but fall back to sip is something p2psip devices do.
>>> 
>>> Not sure I understand quite. Are you saying that a p2psip device
>>> where the user has no account with a service provider can still
>>> make an emergency call by following this framework and the phonebcp?
>>> I'd have thought that a sentence is needed somewhere about that.
>> 
>> There are two key parts to the framework:
>> (1) Figuring out where to send a call, and 
>> (2) Sending the call to the PSAP
>> 
>> The first part is not dependent on SIP at all -- you can plug in any URI you want into LoST, including XMPP.  I've done demos using the "wave:" URI scheme to allow PSAPs to invite emergency callers to join a Google Wave collaboration space.
>> 
>> The second part can also in principle be done over any protocol, but there are some features that you lose relative to this document.  In particular, this document embeds the caller's geolocation in the call signaling, and marks the call as an emergency call.  So if you were to use XMPP, you would lose these features, but still be able to talk to a PSAP.  If you were to use P2PSIP, I think the main challenge would be making sure that the call marking would not interfere with call routing -- I think in principle it shouldn't, but I don't know the P2PSIP specs very well.  
> 
> A sentence that just said that p2psip isn't covered here would
> be fine from my p-o-v. Given that this is largely about SIP,
> and p2psip exists, I think that'd be helpful to the reader who
> could otherwise be mislead.
> 
> I'm not asking that this framework say how to handle emergency
> calling in p2psip if that's not a well-known thing. (I'm not
> sure how that'd best be worded though sorry.)
> 
> S.
> 
>> 
>> Hope this helps,
>> --Richard
>> 
>> 
>> 
>> 
>> 
>> 
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ecrit