(Untitled)
agenda-interim-2022-ecrit-01-ecrit-01-00

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."