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

Brian Rosen <br@brianrosen.net> Fri, 31 March 2023 18:05 UTC

Return-Path: <br@brianrosen.net>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E449C151B30 for <dispatch@ietfa.amsl.com>; Fri, 31 Mar 2023 11:05:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.084
X-Spam-Level:
X-Spam-Status: No, score=-2.084 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=brianrosen.net
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uUEiT59rGfxs for <dispatch@ietfa.amsl.com>; Fri, 31 Mar 2023 11:05:24 -0700 (PDT)
Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A7C0C151B20 for <dispatch@ietf.org>; Fri, 31 Mar 2023 11:05:24 -0700 (PDT)
Received: by mail-qt1-x832.google.com with SMTP id d75a77b69052e-3e632def808so1507071cf.1 for <dispatch@ietf.org>; Fri, 31 Mar 2023 11:05:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen.net; s=google; t=1680285923; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=1rf++VqJ/s2/qNhJHg3RU08kuals5vH0npP0yS4UKZI=; b=XSSY7c8MzzssYmjhea24YSQ391MOy2Bi7yKQpvzpTaGy502DxJYSeY3MU+u0sKLgHp UmLohvPRDiFVSml3xFmMD+lLEEZsDTznydUFDg1dCnBUB5oADI+xGfJqrVvmhytW5QIN hk1TvZTOvXYvDkTC8EV5oO+hvk7ArnvEP+Lg8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680285923; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=1rf++VqJ/s2/qNhJHg3RU08kuals5vH0npP0yS4UKZI=; b=amzvgzWH98FzlRDnq+kTXAcy8p8JxJUoxi4O9ouZMLSfWHFk+bUNbdCrs+jq+xpwJm sE8WAfwOlA7LqTeC9DCb9t6dysl3X0zVr5aBYeajbhtBMkOmojxuEWNk9Zb8LWOQDBSK 2Xip/1A3IxAeSFEXEZOH3oUKQZG9h4IXMmIvZ/frBnypoSoayJ03B7c/vczA6xMuQD7w Mav5TrJtwtFhxnFgXcVQ+Mk4SrMvKySsgWmXmxGkVMN1iSXYczBhtFKw7HKc7fcT63JW ULhSC7/CDObq/I1aNIqkeX4oV4OBUmnzIWf/IWB7sg+Xw2G4732DtTM/a9JPtezmiKwH Qb7Q==
X-Gm-Message-State: AAQBX9e8TzI/91aX1JR7EJqT6FcyLnkgHcJ0Cfb/f/tgVINAUXjY4lhR GcrUXqvW7ybXHbfiGy0xwt0SFSw2yj5suw/iv8k=
X-Google-Smtp-Source: AKy350YNQg9Ekg2u2QPuncGTxW8aiiVuIfmET8w8A4/U5lt2ZgNvvVfGdM5508XL2QiBvYDwcQB/dQ==
X-Received: by 2002:a05:622a:199a:b0:3e4:eb39:eb8b with SMTP id u26-20020a05622a199a00b003e4eb39eb8bmr11494973qtc.5.1680285921667; Fri, 31 Mar 2023 11:05:21 -0700 (PDT)
Received: from smtpclient.apple ([185.199.103.122]) by smtp.gmail.com with ESMTPSA id o15-20020ac8698f000000b003bf9f9f1844sm766426qtq.71.2023.03.31.11.05.18 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 31 Mar 2023 11:05:20 -0700 (PDT)
From: Brian Rosen <br@brianrosen.net>
Message-Id: <79EE2266-C2D9-4022-98D9-23549987EC6A@brianrosen.net>
Content-Type: multipart/alternative; boundary="Apple-Mail=_60245A81-C1A7-44CD-98FD-FB59C8AF82DE"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.300.101.1.3\))
Date: Fri, 31 Mar 2023 21:05:05 +0300
In-Reply-To: <39CED79A-41C3-4EDD-AC5D-E12EC3961DB4@cisco.com>
Cc: "dispatch@ietf.org" <dispatch@ietf.org>
To: "Sri Gundavelli (sgundave)" <sgundave@cisco.com>
References: <167875162972.58518.19006032661356449@ietfa.amsl.com> <385DA58A-5118-44EF-9E8A-B8FA5F28F4EA@cisco.com> <3E83FA22-CF07-4C38-B73C-41AC1AEEB688@brianrosen.net> <39CED79A-41C3-4EDD-AC5D-E12EC3961DB4@cisco.com>
X-Mailer: Apple Mail (2.3731.300.101.1.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dispatch/lMvFnzEzuekZ3t2wGtRnM5JrN7Q>
Subject: Re: [dispatch] New Version Notification for draft-gundavelli-dispatch-e911-wifi-00.txt
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dispatch/>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 31 Mar 2023 18:05:29 -0000

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) <sgundave@cisco.com> 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" <br@brianrosen.net <mailto:br@brianrosen.net> <mailto:br@brianrosen.net>> 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=40cisco.com@dmarc.ietf.org <mailto:sgundave=40cisco.com@dmarc.ietf.org> <mailto:40cisco.com@dmarc.ietf.org>> 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
>> dispatch@ietf.org <mailto:dispatch@ietf.org> <mailto:dispatch@ietf.org>
>> https://www.ietf.org/mailman/listinfo/dispatch <https://www.ietf.org/mailman/listinfo/dispatch>