[Ecrit] Agenda for ECRIT virtual interim 18-August

[Randall Gellens <[e-mail]>]

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: 
<[e-mail]>
    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: 
<[e-mail]>
    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: <[e-mail]>
    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: <[e-mail]>
    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: <[e-mail]>
    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."

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