[Ecrit] Resolving open issue in planned-changes

[Randall Gellens <[e-mail]>]

Regarding the 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.

As the next step in measuring consensus, the chairs want to identify 
technical objections to 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. If I've missed 
anything or left out anything crucial, please let me know.

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

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

---
If I've left out anything crucial, or didn't accurately summarize your 
objection or omitted it, please let me know.


--Randall