Subject: [Ecrit] Problem in -planned-changes: unique records in LoST server may not match unique records in LIS

From: Brian Rosen <[email-masked]>
Date: Tue, 24 Aug 2021 16:08:47 -0400

I realized we have a problem with -planned-changes.  The text notes:
Each client of the server may only store one URI against a location, where “location” is defined by policy at the server, since a given unique location may have many combinations of location elements that resolve to the same location.  If the server receives a ‘uri’ for the same location from the same client, the URI in the request replaces the URI it previously retained.

But this means that multiple records in the LIS may be one record in the LoST server and when the LIS associates unique URIs with what it thinks is multiple records, only one is retained and it doesn’t know that.

The easiest fix is to return the replaced URI.  The client would then be able to spot that the records are linked and do the book keeping to track what it should do.
Another way to fix this is to return a unique ID of the record in the LoST server when you use the extension.  The LIS can then keep an internal record of all the related entries it has that are one record to the server.  

Brian

---

From: "Caron, Guy" <[email-masked]>
Date: Wed, 25 Aug 2021 00:50:17 +0000

I recognize the problem but do not like the proposed solutions.

I need to think more about this.

Guy

-------- Message d'origine --------
De : Brian Rosen <[email-masked]>
Date : 2021-08-24 4 h 09 p.m. (GMT-05:00)
À : ECRIT <[email-masked]>
Objet : [EXT][Ecrit] Problem in -planned-changes: unique records in LoST server may not match unique records in LIS

Brian

---

From: "Randall Gellens" <[email-masked]>
Date: Wed, 25 Aug 2021 14:56:48 -0700

Either approach would work: the server returning the prior URI if it 
replaces it, or the server always returning a "unique location ID" 
whenever it stores a URI.  In the latter case, we'd want to add this ID 
to the <locationInvalidated> object.  The latter seems a bit cleaner, as 
then the server always returns an ID, and a client always stores this ID 
whenever it sends a URI, and uses the ID to re-validate locations when 
it gets a <locationInvalidated> object.

--Randall

On 24 Aug 2021, at 13:08, Brian Rosen wrote:

> Each client of the server may only store one URI against a location, 
> where “location” is defined by policy at the server, since a given 
> unique location may have many combinations of location elements that 
> resolve to the same location.  If the server receives a ‘uri’ for 
> the same location from the same client, the URI in the request 
> replaces the URI it previously retained.
>
> But this means that multiple records in the LIS may be one record in 
> the LoST server and when the LIS associates unique URIs with what it 
> thinks is multiple records, only one is retained and it doesn’t know 
> that.
>
> The easiest fix is to return the replaced URI.  The client would then 
> be able to spot that the records are linked and do the book keeping to 
> track what it should do.
> Another way to fix this is to return a unique ID of the record in the 
> LoST server when you use the extension.  The LIS can then keep an 
> internal record of all the related entries it has that are one record 
> to the server.
>
> Brian
>
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ecrit

---

From: Brian Rosen <[email-masked]>
Date: Wed, 25 Aug 2021 17:58:26 -0400

Yeah, of the two options, I like the second.  I would like to wait to here from Guy, who didn’t like either.

Either of the two I came up with can be added quickly to the doc.

Brian

> On Aug 25, 2021, at 5:56 PM, Randall Gellens <[email-masked]> wrote:
> 
> Either approach would work: the server returning the prior URI if it replaces it, or the server always returning a "unique location ID" whenever it stores a URI.  In the latter case, we'd want to add this ID to the <locationInvalidated> object.  The latter seems a bit cleaner, as then the server always returns an ID, and a client always stores this ID whenever it sends a URI, and uses the ID to re-validate locations when it gets a <locationInvalidated> object.
> 
> --Randall
>

---

From: "Caron, Guy" <[email-masked]>
Date: Thu, 26 Aug 2021 02:33:19 +0000

I did not have much cycle time to think about this but I can share my initial concerns with the proposed solutions.

The concerns I have are security-related.  A LoST server used in the context of emergency calling (the scope of ECRIT) holds critical information about how emergency calls are routed and their destinations. Both solutions would allow a malevolent client to rebuild the server's internal data structure and use that as an attack of some form (impersonalisation, MITM, SWATting, etc.).

I have re-read the Security section of RFC 5222 and perhaps these concerns are already addressed but would like to hear the opinion of others.

Thanks,

Guy

-----Message d'origine-----
De : Ecrit <[email-masked]> De la part de Brian Rosen
Envoyé : 25 août 2021 17:58
À : Randall Gellens <[email-masked]>
Cc : ECRIT <[email-masked]>
Objet : [EXT]Re: [Ecrit] Problem in -planned-changes: unique records in LoST server may not match unique records in LIS

Brian

_______________________________________________
Ecrit mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ecrit
------------------------------------------------------------------------------
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: Wed, 25 Aug 2021 21:39:44 -0700

Hi Guy,

I'm not following how "Both solutions would allow a malevolent client to 
rebuild the server's internal data structure".  In either solution, the 
LoST server returns something to the LoST client that the LoST client 
uses to mark one or more of its location records. If/when the LoST 
server sends the client a <locationInvalidated> object, the object 
contains this same marker, which the client uses to know which of its 
records should be revalidated.

--Randall

On 25 Aug 2021, at 19:33, Caron, Guy wrote:

> I did not have much cycle time to think about this but I can share my 
> initial concerns with the proposed solutions.
>
> The concerns I have are security-related.  A LoST server used in the 
> context of emergency calling (the scope of ECRIT) holds critical 
> information about how emergency calls are routed and their 
> destinations. Both solutions would allow a malevolent client to 
> rebuild the server's internal data structure and use that as an attack 
> of some form (impersonalisation, MITM, SWATting, etc.).
>
> I have re-read the Security section of RFC 5222 and perhaps these 
> concerns are already addressed but would like to hear the opinion of 
> others.
>
> Thanks,
>
> Guy
>
>
>
> Objet : [EXT]Re: [Ecrit] Problem in -planned-changes: unique records 
> in LoST server may not match unique records in LIS
>
>> whenever it stores a URI.  In the latter case, we'd want to add this 
>> ID to the <locationInvalidated> object.  The latter seems a bit 
>> cleaner, as then the server always returns an ID, and a client always 
>> stores this ID whenever it sends a URI, and uses the ID to 
>> re-validate locations when it gets a <locationInvalidated> object.
>>
>> --Randall
>>
>>> where “location” is defined by policy at the server, since a 
>>> given unique location may have many combinations of location 
>>> elements that resolve to the same location.  If the server receives 
>>> a ‘uri’ for the same location from the same client, the URI in 
>>> the request replaces the URI it previously retained.
>>>
>>> thinks is multiple records, only one is retained and it doesn’t 
>>> know that.
>>>
>>> The easiest fix is to return the replaced URI.  The client would 
>>> then be able to spot that the records are linked and do the book 
>>> keeping to track what it should do.
>>> Another way to fix this is to return a unique ID of the record in 
>>> the LoST server when you use the extension.  The LIS can then keep 
>>> an internal record of all the related entries it has that are one 
>>> record to the server.
>>>
>>> Brian
>>>
> 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: Thu, 26 Aug 2021 13:09:47 +0000

Both solutions reveal the granularity of the underlying data in the LoST server.

Here is an example:

1. Client sends a URI for each discrete location (think civic numbers) of a street.
2. Server is only provisioned with road centerline data for that street and thus return one URI (or ID) back to the client for each discrete location it has.
3. Client stores this unique URI (or ID) against all discrete locations.
4. After all the Client's locations have gotten the URIs (or (IDs) from the Server, the Client has a detailed view of the Server's underlying data.

Then, put this in the hands of an attacker.

Thanks,

Guy

-----Message d'origine-----
De : Randall Gellens <[email-masked]> 
Envoyé : 26 août 2021 00:40
À : Caron, Guy <[email-masked]>
Cc : Brian Rosen <[email-masked]>; ECRIT <[email-masked]>
Objet : [EXT]Re: [Ecrit] Problem in -planned-changes: unique records in LoST server may not match unique records in LIS

Hi Guy,

I'm not following how "Both solutions would allow a malevolent client to rebuild the server's internal data structure".  In either solution, the LoST server returns something to the LoST client that the LoST client uses to mark one or more of its location records. If/when the LoST server sends the client a <locationInvalidated> object, the object contains this same marker, which the client uses to know which of its records should be revalidated.

--Randall

On 25 Aug 2021, at 19:33, Caron, Guy wrote:

> De : Ecrit <[email-masked]> De la part de Brian Rosen Envoyé : 
> 25 août 2021 17:58 À : Randall Gellens <[email-masked]> Cc 
> : ECRIT <[email-masked]> Objet : [EXT]Re: [Ecrit] Problem in 
> -planned-changes: unique records in LoST server may not match unique 
> records in LIS
>
> ----------------------------------------------------------------------
> -------- 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: Thu, 26 Aug 2021 09:31:35 -0400

I don’t see how this knowledge aids an attack.  Yes, it knows what is a road centerline and what is an address point (or equivalent), but I don’t see how an attacker could use that information.  

Also, you get exactly the same information already: address number will be in “unchecked” for a road centerline (assuming it’s in a range, if it’s not, it’s in invalid).
This is because 4-100 includes 55 and there may or may not be an actual 55 address number.  Now, that really is specific to North America: the NENA standard says that’s how you populate the unchecked list: 5222 isn’t specific.

Brian

> On Aug 26, 2021, at 9:09 AM, Caron, Guy <[email-masked]> wrote:
>

---

From: "Caron, Guy" <[email-masked]>
Date: Thu, 26 Aug 2021 13:35:52 +0000

An attacker can mimic the LoST Server's behaviour very closely while manipulating the data so that routing is affected.

I don't know to what extent this is realistic. If folks do not see arm then let's move on.

Thanks,

Guy

-----Message d'origine-----
De : Brian Rosen <[email-masked]> 
Envoyé : 26 août 2021 09:32
À : Caron, Guy <[email-masked]>
Cc : Randall Gellens <[email-masked]>; ECRIT <[email-masked]>
Objet : [EXT]Re: [Ecrit] Problem in -planned-changes: unique records in LoST server may not match unique records in LIS

Brian

> De : Randall Gellens <[email-masked]> Envoyé : 26 août 2021 
> 00:40 À : Caron, Guy <[email-masked]> Cc : Brian Rosen 
> <[email-masked]>; ECRIT <[email-masked]> Objet : [EXT]Re: [Ecrit] 
> Problem in -planned-changes: unique records in LoST server may not 
> match unique records in LIS
> 
> Hi Guy,
> 
>> rebuild the server's internal data structure and use that as an 
>> attack of some form (impersonalisation, MITM, SWATting, etc.).
>> 
>>> cleaner, as then the server always returns an ID, and a client 
>>> always stores this ID whenever it sends a URI, and uses the ID to 
>>>> Each client of the server may only store one URI against a 
>>>> location, where “location” is defined by policy at the server, 
>>>> since a given unique location may have many combinations of 
>>>> location elements that resolve to the same location.  If the server 
>>>> receives a ‘uri’ for the same location from the same client, the 
>>>> URI in the request replaces the URI it previously retained.
>>>> 
>>>> But this means that multiple records in the LIS may be one record 
>>>> in the LoST server and when the LIS associates unique URIs with 
>>>> what it thinks is multiple records, only one is retained and it 
>>>> doesn’t know that.
>>>>

---

From: "Caron, Guy" <[email-masked]>
Date: Thu, 26 Aug 2021 13:46:04 +0000

"arm" should be "harm", obviously.

Guy

-----Message d'origine-----
De : Ecrit <[email-masked]> De la part de Caron, Guy
Envoyé : 26 août 2021 09:36
À : Brian Rosen <[email-masked]>
Cc : ECRIT <[email-masked]>
Objet : [EXT]Re: [Ecrit] Problem in -planned-changes: unique records in LoST server may not match unique records in LIS

Thanks,

Guy

-----Message d'origine-----
De : Brian Rosen <[email-masked]>
Envoyé : 26 août 2021 09:32
À : Caron, Guy <[email-masked]>
Cc : Randall Gellens <[email-masked]>; ECRIT <[email-masked]> Objet : [EXT]Re: [Ecrit] Problem in -planned-changes: unique records in LoST server may not match unique records in LIS

Brian

------------------------------------------------------------------------------
External Email: Please use caution when opening links and attachments / Courriel externe: Soyez prudent avec les liens et documents joints _______________________________________________
Ecrit mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ecrit
------------------------------------------------------------------------------
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: Thu, 26 Aug 2021 10:05:33 -0700

On 26 Aug 2021, at 6:31, Brian Rosen wrote:

> I don’t see how this knowledge aids an attack.  Yes, it knows what 
> is a road centerline and what is an address point (or equivalent), but 
> I don’t see how an attacker could use that information.

[rg] Yes, exactly.  There's a lot of information an attacker can have, 
but most of it doesn't help an attack.

> Also, you get exactly the same information already: address number 
> will be in “unchecked” for a road centerline (assuming it’s in a 
> range, if it’s not, it’s in invalid).
> This is because 4-100 includes 55 and there may or may not be an 
> actual 55 address number.  Now, that really is specific to North 
> America: the NENA standard says that’s how you populate the 
> unchecked list: 5222 isn’t specific.
>
> Brian
>
>> 2. Server is only provisioned with road centerline data for that 
>> street and thus return one URI (or ID) back to the client for each 
>> discrete location it has.
>> 4. After all the Client's locations have gotten the URIs (or (IDs) 
>> from the Server, the Client has a detailed view of the Server's 
>> underlying data.
>>
>> I'm not following how "Both solutions would allow a malevolent client 
>> to rebuild the server's internal data structure".  In either 
>> solution, the LoST server returns something to the LoST client that 
>> the LoST client uses to mark one or more of its location records. 
>> If/when the LoST server sends the client a <locationInvalidated> 
>> object, the object contains this same marker, which the client uses 
>> to know which of its records should be revalidated.
>>
>> --Randall
>>
>>> attack
>>> Envoyé :
>>> Yeah, of the two options, I like the second.  I would like to wait 
>>> to
>>> here from Guy, who didn’t like either.
>>>
>>>> always
>>>>> location,
>>>>> given
>>>>> in
>>>>> know

---

From: "Randall Gellens" <[email-masked]>
Date: Thu, 26 Aug 2021 10:08:06 -0700

On 26 Aug 2021, at 6:35, Caron, Guy wrote:

> An attacker can mimic the LoST Server's behaviour very closely while 
> manipulating the data so that routing is affected.

[rg] I'm not following.  You mean an attacker pretending to be a LoST 
server?  Using DNS cache poisoning or routing protocol attacks to 
redirect LoST queries to itself?  I don't see how the extension helps 
that kind of an attack.

> I don't know to what extent this is realistic. If folks do not see arm 

[rg] I'm having trouble imagining how the extension helps an attacker.

---

From: "Caron, Guy" <[email-masked]>
Date: Thu, 26 Aug 2021 17:35:39 +0000

As I said, if no one sees harm with the proposed solutions, let's move on.

Thanks,

Guy

-----Message d'origine-----
Envoyé : 26 août 2021 13:08

> manipulating the data so that routing is affected.

[rg] I'm not following.  You mean an attacker pretending to be a LoST server?  Using DNS cache poisoning or routing protocol attacks to redirect LoST queries to itself?  I don't see how the extension helps that kind of an attack.

> Cc : Randall Gellens <[email-masked]>; ECRIT 
> <[email-masked]> Objet : [EXT]Re: [Ecrit] Problem in -planned-changes: 
> unique records in LoST server may not match unique records in LIS
>
> I don’t see how this knowledge aids an attack.  Yes, it knows what is 
> a road centerline and what is an address point (or equivalent), but I 
> don’t see how an attacker could use that information.
>
> America: the NENA standard says that’s how you populate the unchecked 
> list: 5222 isn’t specific.
>
> Brian
>
>>> I did not have much cycle time to think about this but I can share 
>>> my initial concerns with the proposed solutions.
>>>
>>> to here from Guy, who didn’t like either.
>>>
>>>> Either approach would work: the server returning the prior URI if 
>>>> it replaces it, or the server always returning a "unique location 
>>>> ID"
>>>> whenever it stores a URI.  In the latter case, we'd want to add 
>>>> this ID to the <locationInvalidated> object.  The latter seems a 
>>>> bit cleaner, as then the server always returns an ID, and a client 
>>>>> location elements that resolve to the same location.  If the 
>>>>> server receives a ‘uri’ for the same location from the same 
>>>>> client, the URI in the request replaces the URI it previously 
>>>>> retained.
>>>>>
>>> --------------------------------------------------------------------
>>> -
>>> -

---

From: "Caron, Guy" <[email-masked]>
Date: Fri, 27 Aug 2021 16:58:26 +0000

You make a good point about getting exactly the same information already: address number will be in “unchecked” for a road centerline (assuming it’s in a range, if it’s not, it’s in invalid).

I therefore rescind my concern about the proposed solutions.

Thanks,

Guy

-----Message d'origine-----

Brian

---

From: Brian Rosen <[email-masked]>
Date: Fri, 27 Aug 2021 13:06:07 -0400

Okay, good.  Do you have a preference between the options I came up with?  I think we’re leaning towards the second: the server returns a unique ID for every record it has.

Brian

> On Aug 27, 2021, at 12:58 PM, Caron, Guy <[email-masked]> wrote:
>

---

From: "Caron, Guy" <[email-masked]>
Date: Fri, 27 Aug 2021 17:08:00 +0000

I too prefer the solution with an ID.

One side benefit to this solution is that the Client no longer needs a different URI for each location it validates. It only need a generic one (but specific to itself) since the revalidation request to the Server will include the ID received in the <locationInvalidated> field of the notification.

Less burden on the Clients. We may want to say that.

I still think we need to change <locationInvalided> to something like <locationImpacted>.

Thanks,

Guy

-----Message d'origine-----

Brian

---

From: "Caron, Guy" <[email-masked]>
Date: Fri, 27 Aug 2021 17:10:01 +0000

Less burden on the Servers too since they would no longer need to replace the URI.

Guy

-----Message d'origine-----
De : Ecrit <[email-masked]> De la part de Caron, Guy
Envoyé : 27 août 2021 13:08
À : Brian Rosen <[email-masked]>; Randall Gellens <[email-masked]>
Cc : ECRIT <[email-masked]>
Objet : [EXT]Re: [Ecrit] Problem in -planned-changes: unique records in LoST server may not match unique records in LIS

Thanks,

Guy

-----Message d'origine-----
De : Ecrit <[email-masked]> De la part de Brian Rosen Envoyé : 25 août 2021 17:58 À : Randall Gellens <[email-masked]> Cc : ECRIT <[email-masked]> Objet : [EXT]Re: [Ecrit] Problem in -planned-changes: unique records in LoST server may not match unique records in LIS

Brian

---

From: Brian Rosen <[email-masked]>
Date: Fri, 27 Aug 2021 13:17:38 -0400

Good idea.  I’ll do it that way: the response contains an ID which is also present in the Notification.  The client still has to recognize that more than one of its records may have the same ID, but it is simpler for both, I agree.

Brian

> On Aug 27, 2021, at 1:10 PM, Caron, Guy <[email-masked]> wrote:
>

---

From: "Caron, Guy" <[email-masked]>
Date: Fri, 27 Aug 2021 17:23:51 +0000

Yes. The Client requesting notification of planned changes only needs to store the ID against locations it validates.

Thanks,

Guy

-----Message d'origine-----
De : Brian Rosen <[email-masked]> 
Envoyé : 27 août 2021 13:18
À : Caron, Guy <[email-masked]>
Cc : Caron, Guy <g.caron=[email-masked]>; Randall Gellens <[email-masked]>; ECRIT <[email-masked]>
Objet : [EXT]Re: [Ecrit] Problem in -planned-changes: unique records in LoST server may not match unique records in LIS

Brian

> De : Ecrit <[email-masked]> De la part de Caron, Guy Envoyé : 
> 27 août 2021 13:08 À : Brian Rosen <[email-masked]>; Randall 
> Gellens <[email-masked]> Cc : ECRIT <[email-masked]> Objet 
> : [EXT]Re: [Ecrit] Problem in -planned-changes: unique records in LoST 
> server may not match unique records in LIS
> 
> documents joints _______________________________________________
> Ecrit mailing list
> [email-masked]

---

From: "Randall Gellens" <[email-masked]>
Date: Fri, 27 Aug 2021 13:26:58 -0700

I don't see any benefit to changing "invalidated" to "impacted", but if 
you want a neutral term, just call it "notification" or 
"revalidateNotification".  It's a notification that the client should 
revalidate any of its records for which notification was requested and 
for which the ID was returned when notification was requested.

--Randall

On 27 Aug 2021, at 10:23, Caron, Guy wrote:

> Yes. The Client requesting notification of planned changes only needs 
> to store the ID against locations it validates.
>
> Thanks,
>
> Guy
>
> Cc : Caron, Guy <g.caron=[email-masked]>; Randall Gellens 
> <[email-masked]>; ECRIT <[email-masked]>
> Good idea.  I’ll do it that way: the response contains an ID which 
> is also present in the Notification.  The client still has to 
> recognize that more than one of its records may have the same ID, but 
> it is simpler for both, I agree.
>
> Brian
>
>> One side benefit to this solution is that the Client no longer needs 
>> a different URI for each location it validates. It only need a 
>> generic one (but specific to itself) since the revalidation request 
>> to the Server will include the ID received in the 
>> <locationInvalidated> field of the notification.
>>
>>>> receives a ‘uri’ for the same location from the same client, 
>>>> the URI in the request replaces the URI it previously retained.
>>>>

---

From: "Caron, Guy" <[email-masked]>
Date: Fri, 27 Aug 2021 20:33:31 +0000

"Invalidated" indicates explicitly that the location is  now invalid whereby Impacted indicates that it may be invalidated. I see a big difference between the two.

That said, I could go with something like <revalidateLocation>, which would be indicative of the action to take by the Client rather than the status of the location.

Guy

-----Message d'origine-----
De : Randall Gellens <[email-masked]> 
Envoyé : 27 août 2021 16:27
À : Caron, Guy <[email-masked]>
Cc : Brian Rosen <[email-masked]>; Caron, Guy <g.caron=[email-masked]>; ECRIT <[email-masked]>
Objet : [EXT]Re: [Ecrit] Problem in -planned-changes: unique records in LoST server may not match unique records in LIS

I don't see any benefit to changing "invalidated" to "impacted", but if you want a neutral term, just call it "notification" or "revalidateNotification".  It's a notification that the client should revalidate any of its records for which notification was requested and for which the ID was returned when notification was requested.

--Randall

On 27 Aug 2021, at 10:23, Caron, Guy wrote:

> <[email-masked]>; ECRIT <[email-masked]> Objet : [EXT]Re: 
> [Ecrit] Problem in -planned-changes: unique records in LoST server may 
> not match unique records in LIS
>
> Good idea.  I’ll do it that way: the response contains an ID which is 
> also present in the Notification.  The client still has to recognize 
> that more than one of its records may have the same ID, but it is 
> simpler for both, I agree.
>
> Brian
>
>> : [EXT]Re: [Ecrit] Problem in -planned-changes: unique records in 
>> LoST server may not match unique records in LIS
>>

---

From: "Randall Gellens" <[email-masked]>
Date: Fri, 27 Aug 2021 14:27:55 -0700

On 27 Aug 2021, at 13:33, Caron, Guy wrote:

> "Invalidated" indicates explicitly that the location is  now invalid 
> whereby Impacted indicates that it may be invalidated. I see a big 
> difference between the two.

Yes, of course there's a difference in meaning.  I said I don't see a 
benefit in changing from one to the other.  The location the client 
previously validated isn't necessarily invalidated nor impacted.

> That said, I could go with something like <revalidateLocation>, which 
> would be indicative of the action to take by the Client rather than 
> the status of the location.

Works for me.  Brian, are you OK with this?

> Cc : Brian Rosen <[email-masked]>; Caron, Guy 
> <g.caron=[email-masked]>; ECRIT <[email-masked]>
> I don't see any benefit to changing "invalidated" to "impacted", but 
> if you want a neutral term, just call it "notification" or 
>> is
>>> I still think we need to change <locationInvalided> to something 
>>> like
>>> <locationImpacted>.
>>>
>>> Thanks,
>>>
>>> Guy
>>>
>>> Envoyé
>>> :
>>>> it
>>>> this
>>>>> server
>>>>> the

---

From: Brian Rosen <[email-masked]>
Date: Mon, 30 Aug 2021 08:38:53 -0400

Yeah, I can do that.

Brian

> On Aug 27, 2021, at 5:27 PM, Randall Gellens <[email-masked]> wrote:
> 
> Yes, of course there's a difference in meaning.  I said I don't see a benefit in changing from one to the other.  The location the client previously validated isn't necessarily invalidated nor impacted.
>