Re: [Ecrit] planned-changes: two questions

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 
>> <rg+ietf@randy.pensive.org> 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
>> Ecrit@ietf.org
>> https://www.ietf.org/mailman/listinfo/ecrit