Subject: [Ecrit] lost-planned-changes-04: Locations are not always invalidated

From: "Caron, Guy" <[email-masked]>
Date: Mon, 23 Aug 2021 21:24:40 +0000

This new version introduces variability in whether a location is indeed invalidated or not by a change, which I agree with.

Given this, the names “locationInvalidated” and “invalidatedAsOf” seem misleading. Should “invalidated” be changed to something like “Impacted”?

Thanks,

Guy

---

From: Brian Rosen <[email-masked]>
Date: Mon, 23 Aug 2021 17:32:22 -0400

One of the reasons I didn’t do this is the name of the draft should change.

But of course, I will do whatever consensus of the work group is.

Brian

> On Aug 23, 2021, at 5:24 PM, Caron, Guy <[email-masked]> wrote:
>

---

From: "Caron, Guy" <[email-masked]>
Date: Mon, 23 Aug 2021 21:35:41 +0000

I don’t see why the name of the draft would change. It is still planned changes that are notified. It is just the assumption that the notification is always about a location becoming invalid that changes.

Thanks,

Guy

De : Brian Rosen <[email-masked]>
Envoyé : 23 août 2021 17:32
À : Caron, Guy <[email-masked]>
Cc : [email-masked]
Objet : [EXT]Re: lost-planned-changes-04: Locations are not always invalidated

Brian

On Aug 23, 2021, at 5:24 PM, Caron, Guy <[email-masked]<mailto:[email-masked]>> wrote:

Thanks,

Guy

________________________________
External Email: Please use caution when opening links and attachments / Courriel externe: Soyez prudent avec les liens et documents joints

---

From: "Randall Gellens" <[email-masked]>
Date: Mon, 23 Aug 2021 14:41:38 -0700

Using 'impacted' is not really better, because a location may or may not 
actually be impacted.  If we go down the path of precise names we should 
use something such as 'locationPotentiallyInvalidated', which seems 
silly.  I think the draft makes it clear (especially with my suggested 
edits) that a notified location is potentially invalidated.

--Randall

On 23 Aug 2021, at 14:24, Caron, Guy wrote:

> This new version introduces variability in whether a location is 
> indeed invalidated or not by a change, which I agree with.
>
> Given this, the names “locationInvalidated” and 
> “invalidatedAsOf” seem misleading. Should “invalidated” be 
> changed to something like “Impacted”?
>
> Thanks,
>
> Guy

> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ecrit

---

From: "Caron, Guy" <[email-masked]>
Date: Mon, 23 Aug 2021 21:48:33 +0000

I think these locations are impacted in one way or the other otherwise, the LoST server would not be able to determine that it should send notifications; they may just not become invalid in the LoST sense.

Thanks,

Guy

De : Randall Gellens <[email-masked]>
Envoyé : 23 août 2021 17:42
À : Caron, Guy <[email-masked]>
Cc : Brian Rosen <[email-masked]>; [email-masked]
Objet : [EXT]Re: [Ecrit] lost-planned-changes-04: Locations are not always invalidated

Using 'impacted' is not really better, because a location may or may not actually be impacted. If we go down the path of precise names we should use something such as 'locationPotentiallyInvalidated', which seems silly. I think the draft makes it clear (especially with my suggested edits) that a notified location is potentially invalidated.

--Randall

Thanks,

Guy

_______________________________________________
Ecrit mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ecrit

---

From: "Randall Gellens" <[email-masked]>
Date: Mon, 23 Aug 2021 14:51:12 -0700

I don't know that that's true.  My interpretation is that a LoST server 
might maintain a list of URIs but not associate each with specific 
location records, and when there is a change, it would then send a 
notification to each stored URI.  The location that was used for the 
original validation query might not be impacted.

--Randall

On 23 Aug 2021, at 14:48, Caron, Guy wrote:

> I think these locations are impacted in one way or the other 
> otherwise, the LoST server would not be able to determine that it 
> should send notifications; they may just not become invalid in the 
> LoST sense.
>
> Thanks,
>
> Guy
>
>
>
> Using 'impacted' is not really better, because a location may or may 
> not actually be impacted. If we go down the path of precise names we 
> should use something such as 'locationPotentiallyInvalidated', which 
> seems silly. I think the draft makes it clear (especially with my 
> suggested edits) that a notified location is potentially invalidated.
>
> --Randall
>
> External Email: Please use caution when opening links and attachments 
> / Courriel externe: Soyez prudent avec les liens et documents joints

---

From: "Caron, Guy" <[email-masked]>
Date: Mon, 23 Aug 2021 22:08:29 +0000

Taken from section 3:

The URI will be stored by the server against the location in the request for subsequent use with the notification function defined  below.

Guy

Envoyé : 23 août 2021 17:51

I don't know that that's true. My interpretation is that a LoST server might maintain a list of URIs but not associate each with specific location records, and when there is a change, it would then send a notification to each stored URI. The location that was used for the original validation query might not be impacted.

--Randall

Thanks,

Guy

De : Randall Gellens <[email-masked]<mailto:[email-masked]>>
Envoyé : 23 août 2021 17:42
À : Caron, Guy <[email-masked]<mailto:[email-masked]>>
Cc : Brian Rosen <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Objet : [EXT]Re: [Ecrit] lost-planned-changes-04: Locations are not always invalidated

--Randall

Thanks,

Guy

---

From: "Randall Gellens" <[email-masked]>
Date: Mon, 23 Aug 2021 15:12:09 -0700

In my suggested edits I changed this to add "may".

--Randall

On 23 Aug 2021, at 15:08, Caron, Guy wrote:

> Taken from section 3:
>
> The URI will be stored by the server against the location in the 
> request for subsequent use with the notification function defined  
> below.
>
> Guy
>
> De : Randall Gellens 
> <[email-masked]<mailto:[email-masked]>>

---

From: Brian Rosen <[email-masked]>
Date: Mon, 23 Aug 2021 18:22:06 -0400

The MAY is because it may not allow/have room/… for the URI (or not implement it).  If you think the text would allow it, for example, to send a notification where some location other than the one the URI was sent on changed, then I would like to prohibit that.  I especially don’t want a lazy server sending notifications all over the place when some change to some location was made, and it sends notifications to every URI it has. 

Hmmm.  We might want to say that if the location was invalid (regardless of whether validation was requested), and the LI sent matches more than one location, the server MUST NOT save the URI, and MUST send the error.  The text that says you may get a notification even if it’s still valid could be expanded to cover that case as an alternative to that.

Brian

> On Aug 23, 2021, at 6:12 PM, Randall Gellens <[email-masked]> wrote:
> 
> De : Randall Gellens <[email-masked] <mailto:[email-masked]>> 
> À : Caron, Guy <[email-masked] <mailto:[email-masked]>>
> Cc : Brian Rosen <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/ecrit <https://www.ietf.org/mailman/listinfo/ecrit>

---

From: Brian Rosen <[email-masked]>
Date: Mon, 23 Aug 2021 19:11:45 -0400

Anything that shows up on the unchecked list.  An example might be the NAM element,   The US has pretty tight rules on this, so it really would only be for things like NAM if you had no elements on the invalid list.  But other countries may not have as stringent rules as the US on how the invalid/unchecked lists are populated.

Brian

> On Aug 23, 2021, at 6:29 PM, Randall Gellens <[email-masked]> wrote:
> 
> I interpreted it as allowing a server to save URIs but for an approximate location rather than an exact one, or not associated with a location, and hence it would send a notification if a change might invalidate the location in the query that supplied the URI. If that's not what we mean, then let's be explicit about what we do mean. Under what circumstances would a LoST server save a URI and know that the location in the query might be invalidated but not know for sure?
> 
> --Randall
> 
> On 23 Aug 2021, at 15:22, Brian Rosen wrote:
> 
>> On Aug 23, 2021, at 6:12 PM, Randall Gellens <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: "Randall Gellens" <[email-masked]>
Date: Mon, 23 Aug 2021 15:29:44 -0700

I interpreted it as allowing a server to save URIs but for an 
approximate location rather than an exact one, or not associated with a 
location, and hence it would send a notification if a change might 
invalidate the location in the query that supplied the URI.  If that's 
not what we mean, then let's be explicit about what we do mean.  Under 
what circumstances would a LoST server save a URI and know that the 
location in the query might be invalidated but not know for sure?

--Randall

On 23 Aug 2021, at 15:22, Brian Rosen wrote:

> The MAY is because it may not allow/have room/… for the URI (or not 
> implement it).  If you think the text would allow it, for example, to 
> send a notification where some location other than the one the URI was 
> sent on changed, then I would like to prohibit that.  I especially 
> don’t want a lazy server sending notifications all over the place 
> when some change to some location was made, and it sends notifications 
> to every URI it has.
>
> Hmmm.  We might want to say that if the location was invalid 
> (regardless of whether validation was requested), and the LI sent 
> matches more than one location, the server MUST NOT save the URI, and 
> MUST send the error.  The text that says you may get a notification 
> even if it’s still valid could be expanded to cover that case as an 
> alternative to that.
>
> Brian
>
>> I don't know that that's true. My interpretation is that a LoST 
>> server might maintain a list of URIs but not associate each with 
>> specific location records, and when there is a change, it would then 
>> send a notification to each stored URI. The location that was used 
>> for the original validation query might not be impacted.
>>
>> --Randall
>>
>> <https://www.ietf.org/mailman/listinfo/ecrit>

---

From: "Randall Gellens" <[email-masked]>
Date: Mon, 23 Aug 2021 16:37:39 -0700

You mean if only the NAM field changes?  Such as if there's a civic 
address with NAM but no other address elements, and NAM changes?  Or a 
civic address with NAM as well as other elements sufficient to form a 
valid address on their own?

What text would you add to the document to make it clear under what 
circumstances a LoST server might save a URI and know that the location 
in the query might be invalidated but not know for sure?

--Randall

On 23 Aug 2021, at 16:11, Brian Rosen wrote:

> Anything that shows up on the unchecked list.  An example might be the 
> NAM element,   The US has pretty tight rules on this, so it really 
> would only be for things like NAM if you had no elements on the 
> invalid list.  But other countries may not have as stringent rules as 
> the US on how the invalid/unchecked lists are populated.
>
> Brian
>
>> approximate location rather than an exact one, or not associated with 
>> a location, and hence it would send a notification if a change might 
>> send a notification where some location other than the one the URI 
>> was sent on changed, then I would like to prohibit that.  I 
>> especially don’t want a lazy server sending notifications all over 
>> the place when some change to some location was made, and it sends 
>> notifications to every URI it has.
>>
>>> On Aug 23, 2021, at 6:12 PM, Randall Gellens 
>>> <[email-masked] <mailto:[email-masked]>> 
>>> wrote:
>>>
>>> External Email: Please use caution when opening links and 
>>> attachments / Courriel externe: Soyez prudent avec les liens et 
>>> documents joints
>>>
>>> External Email: Please use caution when opening links and 
>>> attachments / Courriel externe: Soyez prudent avec les liens et 
>>> documents joints
>>

---

From: Brian Rosen <[email-masked]>
Date: Mon, 23 Aug 2021 20:03:40 -0400

I think the text is clear as is: the server doesn’t save the LI, and consequently a change could occur that wasn’t in the LI and still cause a notification.  Again, for US addresses, we have rules about how validation is done that limit how often this could happen.  NAM is an example.  It’s not defined, but it could occur in the LoST server data.  If it did, and it was not sent in the LI of a LoST findService, and it was subsequently changed in the LoST server, there could be a notification.  But other countries could have profiles that, for example explicitly ignore Neighborhood - any value is valid regardless of what is in the server’s data.  They may send unchecked for such cases.  

The implementation for this is simple - revalidate and allow the result to be valid without choking.  I’m just trying to make sure the client doesn’t assume that if they revalidate it is guaranteed to fail.

Brian
> On Aug 23, 2021, at 7:37 PM, Randall Gellens <[email-masked]> wrote:
> 
> You mean if only the NAM field changes? Such as if there's a civic address with NAM but no other address elements, and NAM changes? Or a civic address with NAM as well as other elements sufficient to form a valid address on their own?
> 
> What text would you add to the document to make it clear under what circumstances a LoST server might save a URI and know that the location in the query might be invalidated but not know for sure?
> 
> --Randall
> 
>> On Aug 23, 2021, at 6:29 PM, Randall Gellens <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: "Randall Gellens" <[email-masked]>
Date: Mon, 23 Aug 2021 18:58:46 -0700

What the text says now:

3.  <plannedChange> element

    request

4.  <locationInvalidated> object

    When the server needs to invalidate a location where the client
    provided a URI in <plannedChange>,

You don't think it would be helpful to add some explanatory text about 
how a location is invalidated and yet is still valid?

--Randall

On 23 Aug 2021, at 17:03, Brian Rosen wrote:

> I think the text is clear as is: the server doesn’t save the LI, and 
> consequently a change could occur that wasn’t in the LI and still 
> cause a notification.  Again, for US addresses, we have rules about 
> how validation is done that limit how often this could happen.  NAM is 
> an example.  It’s not defined, but it could occur in the LoST server 
> data.  If it did, and it was not sent in the LI of a LoST findService, 
> and it was subsequently changed in the LoST server, there could be a 
> notification.  But other countries could have profiles that, for 
> example explicitly ignore Neighborhood - any value is valid regardless 
> of what is in the server’s data.  They may send unchecked for such 
> cases.
>
> The implementation for this is simple - revalidate and allow the 
> result to be valid without choking.  I’m just trying to make sure 
> the client doesn’t assume that if they revalidate it is guaranteed 
> to fail.
>
> Brian
>> circumstances a LoST server might save a URI and know that the 
>> Anything that shows up on the unchecked list.  An example might be 
>> the NAM element,   The US has pretty tight rules on this, so it 
>> really would only be for things like NAM if you had no elements on 
>> the invalid list.  But other countries may not have as stringent 
>> rules as the US on how the invalid/unchecked lists are populated.
>>
>> Brian
>>
>>> On Aug 23, 2021, at 6:29 PM, Randall Gellens 
>>> approximate location rather than an exact one, or not associated 
>>> with a location, and hence it would send a notification if a change 
>>> might invalidate the location in the query that supplied the URI. If 
>>> that's not what we mean, then let's be explicit about what we do 
>>> mean. Under what circumstances would a LoST server save a URI and 
>>> know that the location in the query might be invalidated but not 
>>> know for sure?
>>>
>>> --Randall
>>>
>>> The MAY is because it may not allow/have room/… for the URI (or 
>>> not implement it).  If you think the text would allow it, for 
>>> example, to send a notification where some location other than the 
>>> one the URI was sent on changed, then I would like to prohibit that. 
>>>  I especially don’t want a lazy server sending notifications all 
>>> over the place when some change to some location was made, and it 
>>> sends notifications to every URI it has.
>>>
>>> matches more than one location, the server MUST NOT save the URI, 
>>> and MUST send the error.  The text that says you may get a 
>>> notification even if it’s still valid could be expanded to cover 
>>> that case as an alternative to that.
>>>
>>> Brian
>>>
>>>> specific location records, and when there is a change, it would 
>>>> then send a notification to each stored URI. The location that was 
>>>> used for the original validation query might not be impacted.
>>>>
>>>> --Randall
>>>>
>>>> Using 'impacted' is not really better, because a location may or 
>>>> may not actually be impacted. If we go down the path of precise 
>>>> names we should use something such as 
>>>> 'locationPotentiallyInvalidated', which seems silly. I think the 
>>>> draft makes it clear (especially with my suggested edits) that a 
>>>> notified location is potentially invalidated.
>>>>
>>>> --Randall
>>>>

---

From: "Randall Gellens" <[email-masked]>
Date: Mon, 23 Aug 2021 20:31:18 -0700

Let me try this again.

What the text says now:

    When the server needs to invalidate a location where the client
    provided a URI in <plannedChange>,
...
    The LoST server is NOT REQUIRED to store the Location Information
    supplied in the original findService request.  This means the server
    may not know if a planned change will in fact invalidate the 
location
    stored in the LoST client, because changes could be made in the LoST
    server that do not affect validation of the Location Information.
    The LoST client may find that upon revalidation with the changed

I had misunderstood this to mean that the server could store the URI in 
any way it wants, and so the server may not know if a change to some 
location information that it has configured would invalidate a location 
for which it stored a URI.  You clarified in email that your intent is 
to constrain the server so that a notification is only triggered for a 
change to the underlying location information, even if that change 
doesn't invalidate the specific location of the query.  Based on this, I 
think we need clarifying text to better explain this (to help a reader 
understand the intent), and also some normative language added regarding 
the server, to the effect that if it decides to store the URI, it needs 
to store it associated with something that if it changes, the location 
in the query is or is likely affected, even if not invalidated.  We 
obviously don't constrain LoST server implementations, they can store 
data in any way they like (we only specify a configuration interface in 
LoST-sync and of course the query interface in LoST).  But if we want 
the draft to reflect your intent, I think we need some kind of normative 
text about what the server stores.

--Randall