Emergency Context Resolution with Internet Technologies WG

ECRIT virtual interim meeting agenda 18 August 2022 7:30-9:00 PDT / 10:30-noon EDT

Meeting location: Zoom: https://nena-org.zoom.us/j/4867827164?pwd=UFhUc1JycnJ3V0Z2ZWJJTmcrb3pLdz09

Times in PDT:

7:30-7:40 * meeting preliminaries, agenda bashing (chairs)

7:40-7:45 * status of planned-changes draft (chairs)

7:45-8:15 * discussion of planned-changes draft (chairs)

https://datatracker.ietf.org/doc/draft-ietf-ecrit-lost-planned-changes/

  - Separating serious technical objections that present an obstacle to implementation or deployment from technical preferences (e.g., preferred deployment models, client vs server load, etc.)

  - Discussion of any identified serious technical objections that present an obstacle to implementation or deployment

  - Discussion of technical preferences

8:15-8:20 * wrap-up

Note: the NENA i3 WG weekly call will reclaim time unused by the ECRIT meeting; NENA i3 may start earlier or later than the slotted time of 8:20 PDT (11:20 EDT).

Status of planned-changes draft:

  - Notification vs polling is the primary open issue. The other issues that have been discussed are secondary and are different depending on which mechanism is selected.

  - The chairs identified the technical objections raised by WG participants against either mechanism. An important part of reaching consensus is making sure that all technical objections have been given appropriate consideration. Below is a summary of the objections that I've identified from the email list and the Doodle poll and follow-up discussion:

Doodle poll:

  - URL: https://doodle.com/poll/3krg2xh2yk3iww8r?utm_source=poll&utm_medium=link
  - Technical objection to polling: Gunnar, Guy
  - Technical objection to notification: Dan Banks

Dan:
Asking a LoST server to store information in response to a query creates an undue burden and presents multiple opportunities for abuse. It is also impractical for a LoST server to make the necessary determinations to support notifications.

Jeff
Requiring a server to store and later use a client-provided uri opens the door for abuse by malicious actors.

Gunnar:
Polling for rare events causes waste of resources. Planned-changes are expected to be rare per location.

Email:

Objections to notification:

Jeff Martin:
Date: Thu, 9 Sep 2021 20:08:44 +0000
Message-ID: CO6PR09MB8600D17E58AECCC9E80C20889FD59@CO6PR09MB8600.namprd09.prod.outlook.com
Archive URL: https://mailarchive.ietf.org/arch/msg/ecrit/ZUQK2J_iZQvEo99JZFw3qAWQ0tg/

"Asking a server to store and later use a client-provided uri opens the door for abuse by malicious actors."

Dan Banks:
Date: Fri, 10 Sep 2021 16:13:17 +0000
Message-ID: DM5PR1701MB181841BF7E917A62D89BACD0A7D69@DM5PR1701MB1818.namprd17.prod.outlook.com
Archive URL: https://mailarchive.ietf.org/arch/msg/ecrit/TRIHMZHi27yWKvJNbAh9hOCJcoc/

"I am opposed to asking LoST servers to store URIs as well. I believe it significantly overcomplicates the solution and is the biggest reason why I have not supported the planned changes draft."

"Several years ago we implemented a mechanism to allow a LIS to know that it needs to revalidate."

"Yes, the LIS has to poll the various LoST servers and ask if there have been any changes. That is a cheap operation to implement, and the practical difference between knowing the very instant a change is published versus finding out within a few minutes is not significant in any way."

Objections to polling:

Brian Rosen:
Date: Thu, 9 Sep 2021 17:14:54 -0400
Message-Id: 68AD2A9E-FB9D-45B3-95CF-358C89D912CA@brianrosen.net
Archive URL: https://mailarchive.ietf.org/arch/msg/ecrit/Q_DcEcRvkPLYjVXjkcwcpcVj5hY/

"sometimes, there is not a lot of planning. The advantage to the notification is that it works immediately."

Guy Caron:
Date: Mon, 13 Sep 2021 19:43:30 +0000
Message-ID: e616f4832db442c7bcaf883aba634188@bell.ca
Archive URL: https://mailarchive.ietf.org/arch/msg/ecrit/kke7q2UwZ2RoSxtkNAt3AFHAG44/

"...there is no filtering based on the Clients being made; every Client gets the list of all upcoming changes. Further, it is yet another interface to support on the Server while the current mechanism leverages an existing one."

Guy Caron:
Date: Tue, 14 Dec 2021 19:05:31 +0000
Message-ID: f089c820be53407ca93aefa7c68bbde7@bell.ca
Archive URL: https://mailarchive.ietf.org/arch/msg/ecrit/PgLf0saWkI_s_oBJq3lreQzgniI/#

"the original request that initiate this draft in the first place was to move away from blind polling of a LoST Server for validation requests. The new proposal moves us right back where we started."