Re: [dispatch] New Version Notification for draft-gundavelli-dispatch-e911-wifi-00.txt

[Jim Fenton <[e-mail]>]

Sri (and others on this thread),

Last Friday you said that you would move this discussion to ECRIT. Would 
you do that please? It will reach the right audience there.

-Jim

On 4 Apr 2023, at 10:38, Sri Gundavelli (sgundave) wrote:

> HI Roland,
>
> Thank you for your comment.
>
> I agree,  if IMS is unavailable P-CSCF/E-CSCF will all be unavailable. 
>  The key point is non-availability of the cellular network, for PDU 
> creation and/or accessing emergency voice functions. This goes back to 
> Christer’s comment suggesting to use non-IMS terminology.  We will 
> work on that.
>
> On your other comment, access to IMS for wired/wireline devices with 
> IMS-only subscription is a possibility. But we still need to allow the 
> device to connect to the available hotspot with no access-network 
> credentials and be able to obtain the IMS configuration. The IMS 
> network in question can be based of a generic IETF defined voice 
> function, which can do call routing to the PSAP. If a MNO is willing 
> to let their IMS network be available for wired and non-cellular 
> devices, that is an option.
>
> Once the device gets connectivity to the access network based on the 
> special emergency passpoint profile, the access network can deliver 
> the associated IMS/voice-service configuration options to the device. 
> The realm that we are proposing sos.fcc-authorized.org and associated 
> IDP can be configured with the IMS/voice-service configuration. These 
> IMS/voice-service functions can be from an MNO, or some other service 
> provider that FCC will authorize.
>
> These configuration options will be signaled from the IDP to the 
> access network, and in turn will be delivered it to the device over 
> DHCP/ND/802.11. The device can perform registration with those voice 
> functions and can initiate the emergency call.
>
> Regards
> Sri
>
>
>
>
> From: "[e-mail]" <[e-mail]>
> Date: Tuesday, April 4, 2023 at 12:44 AM
> To: Sri Gundavelli <[e-mail]>, 
> "[e-mail]" <[e-mail]>, 
> "[e-mail]" <[e-mail]>
> Cc: "[e-mail]" <[e-mail]>, "Mark Grayson (mgrayson)" 
> <[e-mail]>
> Subject: AW: [dispatch] New Version Notification for 
> draft-gundavelli-dispatch-e911-wifi-00.txt
>
> Hi,
> What does this mean that IMS is unavailable?
> When IMS is unavailable also the Emergency service (E-CSCF) is 
> unavailable.
>
> Did you also discover the IMS Access possibilities with Digest, where 
> you have an IMS Subscription w/o any RAN connectivity and only via 
> wireline/WIFI?
>
> Best Regards
>
> Roland
>
> Von: dispatch <[e-mail]> Im Auftrag von Sri 
> Gundavelli (sgundave)
> Gesendet: Montag, 3. April 2023 16:56
> An: Christer Holmberg 
> <christer.holmberg=[e-mail]>; Brian Rosen 
> <[e-mail]>
> Cc: [e-mail]; Mark Grayson (mgrayson) <[e-mail]>
> Betreff: Re: [dispatch] New Version Notification for 
> draft-gundavelli-dispatch-e911-wifi-00.txt
>
> Hi Christer,
>
> Yes, 3GPP does define the interworking architecture with Wi-Fi, where 
> the UE can use Wi-Fi to reach 3GPP core network for PDU establishment. 
> The scenario that we have and what FCC CSRIC 8 looked into is where 
> H-PLMN/V-PLMN and IMS is unavailable. Also, the interworking 
> procedures assume there is Wi-Fi access connectivity. The access 
> network in question may not have any relation to the operator for the 
> UE to perform SIM based authentication to the access network.
>
> The UE may not even have a cellular modem or SIM/eSIM credentials. 
> What are trying to enable is allow the device to use a special 
> emergency passpoint profile for connecting to any of the available 
> hotspots that support emergency calling services. The device may be 
> Wi-Fi only or a dual-radio capable device. Furthermore, if I see the 
> carrier documentation for Wi-Fi calling, it requires the user to 
> configure a civic address prior making any emergency call, and which a 
> caller in distress may never configure. We are addressing this issue, 
> by allowing a trusted access network with the federation issued 
> certificates to signal the location over RADIUS to the IDP/CLF, which 
> the network can cross correlate with the reported location in the SIP 
> signaling.
>
> [cid:image001.png@01D966E1.A1D95570]
>
> Regards
> Sri
>
>
> From: Christer Holmberg 
> <christer.holmberg=[e-mail]<mailto:christer.holmberg=[e-mail]>>
> Date: Monday, April 3, 2023 at 3:21 AM
> To: Sri Gundavelli <[e-mail]<mailto:[e-mail]>> , 
> Brian Rosen <[e-mail]<mailto:[e-mail]>>
> Cc: "[e-mail]<mailto:[e-mail]> " 
> <[e-mail]<mailto:[e-mail]>> , "Mark Grayson 
> (mgrayson)" <[e-mail]<mailto:[e-mail]>>
> Subject: RE: [dispatch] New Version Notification for 
> draft-gundavelli-dispatch-e911-wifi-00.txt
>
> Hi,
>
> Note that 3GPP has defined emergency calls over WiFi, so please 
> indicate how your draft relates to that work.
>
> Regards,
>
> Christer
>
> From: dispatch 
> <[e-mail]<mailto:[e-mail]>> On 
> Behalf Of Sri Gundavelli (sgundave)
> Sent: Saturday, 1 April 2023 4.53
> To: Brian Rosen <[e-mail]<mailto:[e-mail]>>
> Cc: [e-mail]<mailto:[e-mail]> ; Mark Grayson 
> (mgrayson) <[e-mail]<mailto:[e-mail]>>
> Subject: Re: [dispatch] New Version Notification for 
> draft-gundavelli-dispatch-e911-wifi-00.txt
>
> Hi Brian,
>
> Sure. Will move the discussion to ECRIT.
>
> Thanks for the pointers to the LoST and PIDF-LO work. Will add some 
> considerations on how devices capable of LoST can obtain 
> location-specific service configuration.
>
>
>   *   LoST also provides the mechanism to validate location (which you 
> do at configuration time) to make sure the location you send is known 
> by the emergency services.
>
> Ok. We will analyze this. If the mechanisms around Location-validity 
> also covers the cases around detecting rogue/compromised clients, 
> beyond making sure the claimed civic address exists, it will be very 
> useful know. Will add the considerations.
>
>
>   *   The text has to say how the device uses the location it 
> discovers to make a call (‘perform”), which is what RFC6881 
> describes.  There are some practical differences in how NG9-1-1 and 
> NG1-1-2 actually work that has to be taken into consideration when 
> looking at 6881.
>
> Ok. Thanks for the pointers. Will add these considerations.
>
>
> Regards
> Sri
>
> From: Brian Rosen <[e-mail]<mailto:[e-mail]>>
> Date: Friday, March 31, 2023 at 11:05 AM
> To: Sri Gundavelli <[e-mail]<mailto:[e-mail]>>
> Cc: "[e-mail]<mailto:[e-mail]> " 
> <[e-mail]<mailto:[e-mail]>>
> Subject: Re: [dispatch] New Version Notification for 
> draft-gundavelli-dispatch-e911-wifi-00.txt
>
> I do think discussion on this draft should move to ecrit.
>
> Obtaining the regulatory specific calling service configuration 
> (including the numbers) is defined in LoST (RFC5222).
> The location must be provided in PIDF-LO form (RFC4119 and its 
> updates).  That is the form (at least the actual location information 
> part) that you use to query the LoST server to get the configuration 
> data and the form of the data you send to the emergency services.
> LoST also provides the mechanism to validate location (which you do at 
> configuration time) to make sure the location you send is known by the 
> emergency services.
> The text has to say how the device uses the location it discovers to 
> make a call (‘perform”), which is what RFC6881 describes.  There 
> are some practical differences in how NG9-1-1 and NG1-1-2 actually 
> work that has to be taken into consideration when looking at 6881.
>
> Brian
>
>
> On Mar 31, 2023, at 4:55 PM, Sri Gundavelli (sgundave) 
> <[e-mail]<mailto:[e-mail]>> wrote:
>
> Hi Brian,
>
> Thanks a lot for reviewing the document. I agree, the document should 
> provide the larger emergency calling context. The current art, the 
> elements in the system, interfaces with the PSAPs and other touch 
> points. We are familiar with the prior efforts in IETF and also 
> standards bodies including 3GPP and around ATIS reports. Perhaps a 
> discussion on how NG911/NG211 emergency service network are deployed 
> will be useful. The document requires more work, and this is just a 
> starting point.
>
> The key technical objective for this work is around enabling a Wi-Fi 
> capable device to be able to discover hotspots that support emergency 
> calling, ability to perform a network attach, be able to obtain the 
> regulatory-domain specific calling voice service configuration 
> (including emergency calling numbers) and be able to perform the 
> emergency call. The focus is also on how the network can obtain the 
> location of the emergency caller and the mechanisms for detecting 
> rogue device signaling incorrect location.  Finally, some 
> considerations on the emergency passpoint profiles that are required 
> to be present on the device. This work complements the prior IETF 
> efforts on emergency support for greatly improving the access to 
> emergency services. There are tens of thousands of Wi-Fi hotspots 
> supporting Wi-Fi roaming based on passpoint standards. This approach 
> allows the devices to be able to use any of those hotspots for making 
> that emergency call.
>
> On the choice of the draft title, we do understand the emergency 
> calling numbers are specific to the regulatory domain in question and 
> the proposed approach is not specific to any one regulatory domain. In 
> that sense, we should have been bit more sensitive about this. We will 
> modify the draft title to be generic and not specific to one 
> regulatory domain.
>
> Thanks a lot for the feedback.
>
> Regards
> Sri
>
>
>
> On 3/31/23, 2:02 AM, "Brian Rosen" 
> <[e-mail]<mailto:[e-mail]> 
> <mailto:[e-mail]>> wrote:
>
>
> I have read this draft.
>
>
> It is totally lacking context of current and evolving standards in 
> emergency calling, including:
> 1. Basic IETF emergency calling standards 
> (/RFC4119/RFC5222/RFC5985/RFC6881)
> 2. NG911 and NG112 standards that are being deployed, which are based 
> on the IETF standards
> 3. ETSI and ATIS standards that support the above
>
>
> While I don’t know enough about WiFi or some of the 3GPP standards 
> to comment on the technical approach in the doc, I am intimately 
> familiar with what is deployed, and about to be deployed in emergency 
> calling and this doc can’t begin to get considered until it deals 
> with the issues associated with the IETF/NENA/EENA/ETSI/ATIS work.
>
>
> As a really simple start, authors might consider that 9-1-1 is North 
> America only, while the IETF is world-wide.
>
>
> Brian
>
>
>
> On Mar 27, 2023, at 12:35 AM, Sri Gundavelli (sgundave) 
> <sgundave=[e-mail]<mailto:sgundave=[e-mail]> 
> <mailto:[e-mail]>> wrote:
>
> Dear All:
>
> Attached is the link to the document on Supporting emergency 911 
> services over Wi-Fi. The attached document proposes an approach based 
> on WBA's Wi-Fi OpenRoaming and uses many other elements which are 
> already in standards.
>
> We are looking for some technical feedback. We believe there is value 
> in IETF identifying new methods for improving e911 service access.
>
> Appreciate any feedback.
>
> Regards
> Sri
>
>
>
> Name: draft-gundavelli-dispatch-e911-wifi
> Revision: 00
> Title: Emergency 911 Services over Wi-Fi
> Document date: 2023-03-13
> Group: Individual Submission
> Pages: 15
> URL: 
> https://www.ietf.org/archive/id/draft-gundavelli-dispatch-e911-wifi-00.txt 
> <https://www.ietf.org/archive/id/draft-gundavelli-dispatch-e911-wifi-00.txt> 
> <https://www.ietf.org/archive/id/draft-gundavelli-dispatch-e911-wifi-00.txt> 
> <https://www.ietf.org/archive/id/draft-gundavelli-dispatch-e911-wifi-00.txt&gt;>
> Status: 
> https://datatracker.ietf.org/doc/draft-gundavelli-dispatch-e911-wifi/ 
> <https://datatracker.ietf.org/doc/draft-gundavelli-dispatch-e911-wifi/> 
> <https://datatracker.ietf.org/doc/draft-gundavelli-dispatch-e911-wifi/> 
> <https://datatracker.ietf.org/doc/draft-gundavelli-dispatch-e911-wifi/&gt;>
> Htmlized: 
> https://datatracker.ietf.org/doc/html/draft-gundavelli-dispatch-e911-wifi 
> <https://datatracker.ietf.org/doc/html/draft-gundavelli-dispatch-e911-wifi> 
> <https://datatracker.ietf.org/doc/html/draft-gundavelli-dispatch-e911-wifi> 
> <https://datatracker.ietf.org/doc/html/draft-gundavelli-dispatch-e911-wifi&gt;>
>
>
>
>
> Abstract:
> Proposed is an approach for supporting emergency 911 services over
> IEEE 802.11 based Wi-Fi access networks. This approach leverages the
> legal framework and the building blocks of the OpenRoaming federation
> for extending emergency 911 calling support to already deployed tens
> of thousands of OpenRoaming Wi-Fi hotspots. The proposal addresses
> the key issues in emergency calling, around discovery and
> authentication to access network supporting emergency services,
> emergency access credentials, location determination of the emergency
> caller, and delivering emergency voice service configuration to the
> device and call routing.
>
>
>
>
>
>
>
>
> The IETF Secretariat
>
>
>
>
>
>
>
> _______________________________________________
> dispatch mailing list
> [e-mail]<mailto:[e-mail]> <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/dispatch 
> <https://www.ietf.org/mailman/listinfo/dispatch>

> _______________________________________________
> dispatch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dispatch