Re: [Ecrit] planned-changes: two questions

[Brian Rosen <[e-mail]>]

Yes, I agree.

Brian

On Mon, Aug 30, 2021 at 5:51 PM Randall Gellens <[e-mail]>
wrote:

> Works for me, but the draft should be updated to say this (once a server
> successfully sends a notification, it deletes the URI, and the ID
> returned is entirely up to the server and might or might not be
> different on a subsequent request for the same location).
>
> --Randall
>
> On 30 Aug 2021, at 8:22, Brian Rosen wrote:
>
> > Answer 1: yes.  Since there is going to be a revalidation, just
> > deleting the setting seems right to me.
> > Answer 2: Up to server.  If I were implementing, I would hash the real
> > ID with the URI and some kind of predictable nonce.
> >
> > We probably have to say more about how the server identifies the
> > client, so that replacement of the URI works.  Could we say we use the
> > domain of the URI (the entire domain with all the dots) to identify
> > the client, and anything can occur after it (meaning a slash and
> > whatever)?  If we do that, then how would delete the notification?
> > Force there to be something other than the domain (ugly).  Explicit
> > delete request?
> >
> > Hmmm, we’ve opened a DoS attack: a rogue client stores a bunch of
> > URIs for servers it wants to victimize.  In North America we have a
> > real simple solution for that, because we have a PKI, so we know, for
> > sure, who the client is, and could restrict who we allow to store
> > URIs, but that wouldn’t be true in general.  Also, it would be nice
> > for the client to have confidence the mechanism worked before it
> > needed it.
> >
> > So
> > Let’s add a “command” to plannedChange in the findService
> > request.  And, have the client have a response to the notification
> > which is the ID (json with the 200)
> >
> >
> > The client starts by sending a command of “initialize”.  The
> > domain is the identity of the client.  The response is an immediate
> > notification to the with whatever LI was in the request and an ID.
> > The  response by the client (which is the notification web server) is
> > a piece of json containing the ID.  We can say that the LI in this
> > initialize command could be something simple like the Country Code
> > that wouldn’t get a planned change.
> >
> > Thereafter, the LoST server (notification client) periodically repeats
> > this keepalive notification every day or week with the initialize LI.
> > The client has to respond with the ID.
> >
> > The regular notification request is a command of “notify”.  The
> > server ignores a request for notification from an uninitialized
> > client.
> > The notification can be deleted with a command of “delete”.  If
> > you delete the initialize LI, then the server won’t send any more
> > notifications to that client and deletes all URIs it was saving for
> > that client.  The client would have to re-initialize to reset.
> >
> > Brian
> >
> >> On Aug 27, 2021, at 5:41 PM, Randall Gellens
> >> <[e-mail]> wrote:
> >>
> >> I think we're moving to a model where:
> >> - In a query, a client can request to be notified when the location
> >> should be revalidated;
> >> - In the response, the server provides an ID which the client
> >> associates with the location it just validated;
> >> - The server sends a notification to the URI, containing the ID;
> >> - The client revalidates each location with which that ID is
> >> associated.
> >>
> >> Question 1: Does the server delete/inactivate the URI once it has
> >> sent the notification?
> >>
> >> Question 2: Presumably, when the client revalidates the location(s),
> >> it will again request notification.  Does the server return the same
> >> ID as before, or a different ID?  A different ID could perhaps be
> >> useful in edge cases where the server didn't send or the client
> >> didn't get the notification, but any utility seems small.  If it's
> >> the same ID, then the answer to question 1 can be that the URI
> >> remains active until the client asks to no longer be notified (by
> >> sending an empty URI?).
> >>
> >> --Randall
> >>
> >> _______________________________________________
> >> Ecrit mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/ecrit
>