Subject: Re: [Last-Call] Last Call: <draft-gellens-lost-validation-05.txt> (The LoST-Validation S-NAPTR Application Service Tag) to Informational RFC

From: Dan Banks <[email-masked]>
Date: Mon, 2 Mar 2020 17:45:33 +0000

I have reviewed draft-gellens-lost-validation-05.txt following the emails to the Ecrit list, and have some comments.

Within NENA, I have often been critical of the desire to have separate LoST servers for validation versus those used for routing.  Although I have several reasons for taking that position, and I am in the minority with my overall concerns, my primary objection has been that the LoST protocol does not support this separation.  This draft appears to be an attempt to fix the fundamental problem, but I am concerned that it may be insufficient as currently written.

LoST servers are resolved using U-NAPTR.  Although RFC 5222 section 4 uses language such as "clients need to use the U-NAPTR specification" rather than imperatives, further reading of the document leads to the understanding that several key features of the protocol, including redirection and recursion, rely exclusively upon U-NAPTR resolution.  This much, I think, is not in dispute.  However, RFC 5222 only defines a single application service tag (LoST), and does not appear to contemplate the use of alternatives.  An implementation that follows RFC 5222 could reasonably be expected to use the LoST application service tag exclusively.  The draft introduces an alternative service tag (LoST-Validation) and explains that "entities" needing to location validation would use the LoST-Validation tag instead.

One difficulty I have with this is that "entities" really means LoST clients, and the draft is an informational document that does not simply register a new service tag, but also describes a modification to the behavior of clients that deviates from RFC 5222.  I believe that additional behavior changes (as I will explain below), beyond what is already described, would need to be mandated to ensure success.  Although I am not especially familiar with the customs for informational versus standards track documents, my feeling is that this type of modification, even when small in scope, would be a better fit in a standards track document.

With regards to the application service tag registration itself, the draft states that it registers an S-NAPTR tag.  It also correctly notes in section 6 that the registry is the S-NAPTR Application Service Tags registry, while RFC 5222 states that it registers a U-NAPTR application service tag.  As this registration of an S-NAPTR tag caught me off guard, I believe this note is important.  However, I think it would be more correct for the draft to state that it is registering a U-NAPTR tag.  My reasoning is as follows:  RFC 4848 states in section 5 that it:
   provides the basis upon which U-NAPTR-using services can make use of
   the existing IANA registries for application service tags and
   application protocol tags (defined in RFC 3958 [2]).
Which to me makes it clear that the tags belong in the S-NAPTR registry.  However, RFC 4848 otherwise seems to make a distinction between S-NAPTR and U-NAPTR, including a statement that "x-" tags are experimental "as is the case for S-NAPTR".  My interpretation is that S-NAPTR and U-NAPTR tags therefore live together in the same registry, which is perhaps not something I would have chosen to do, but that they are still distinguished by their intended usage.  I suggest that section 6.1 state "this document registers the following U-NAPTR application service tag" to be consistent with RFC 5222, and optionally append "to be added to the S-NAPTR Application Service Tags registry" for extra clarity.  The earlier note in section 6 may not be needed if the apparent conflict (which I think is not actually a conflict) between RFCs 5222 and 3958 is sufficiently explained by also referencing RFC 4848.

Next, recursion in LoST only occurs when the client requests it and when the server decides to perform it (which it is not required to do).  When recursion is used, the server acts as a client and invokes U-NAPTR to find the target URI as any other client would.  The draft does not currently address recursion, which leaves a problematic gap.  When a client wishing to obtain location validation resolves a LoST server using the proposed LoST-Validation tag, that server does not have a direct way to know that this new tag was used.  If the request needs to be sent to another server to be answered and recursion is requested, a server attempting to perform recursion would not know that it also needed to use the LoST-Validation tag instead of the normal one.  This could effectively defeat the proposed mechanism in a significant number of cases.  Further, if the intent is for servers to use the new tag during recursion, this would be a change to the behavior of servers, not just clients.  The easiest way to fix these issues may be to eliminate the use of recursion when using the new service tag by adding language such as:
    When a client sends a <findService> or <listServicesByLocation> request to a server resolved by using the LoST-Validation service tag, it MUST set the 'recursive' attribute to "false".

I think it is also worth noting that while the purpose of this draft is separate validation, and validation only directly applies to <findService>, any separate LoST server intended for validation and resolved by the LoST-Validation tag is still a LoST server and should still respond correctly to the other requests, even if there is no reason to expect it would normally receive them.  It might be worth adding a statement to section 4 to the effect of "A LoST server deployed primarily for validation must meet the same level of functionality and adherence to standards as a LoST server deployed for mapping.

Along those same lines, the language of the draft tends to refer to mapping and validation as separate functions.  They may reflect separate actual needs, but because locationValidation is returned in the findServiceResponse, and the findServiceResponse requires one or more mappings, it is not possible to provide validation without also providing mapping.  The real distinction in functionality is only whether or not validation will be included in the response, so it a choice between (mapping only) or (mapping plus validation).  I would prefer that the language throughout sections 2 and 3 better reflect this.

Because a response with validation always includes a mapping, it is important to understand that not just any mapping will do.  LoST includes the concept of an authoritative source for mappings and allows mapping information to be cached.  If a client has an unexpired mapping that it obtained during validation, it is perfectly reasonable for the client to use the call routing URI included in that mapping for an emergency call without making an additional LoST query.  Further, a mapping cached by a server could be used to answer a query that would otherwise result in redirection or recursion.  LoST even considers the possibility that an expired mapping could be used when a new query cannot be completed.  All of this is to say that the mapping returned by a server intended to perform the validation function must be authoritative and correct.

The draft proposes separate validation and non-validation servers within the context of "an organization" deploying "different server clusters", and also mentions in section 4 that "the data is identical".  I think this approaches the conditions where such separation would be viable, but the language is not strong enough.  This is specifically a concern that I have due to a widespread belief within the NG9-1-1 industry that any two LoST servers using the same data should produce the same results, and that it is even reasonable to have one vendor provide the ECRF (LoST server for mapping) while another provides the LVF (LoST server for validation).  This largely disregards the complexity involved in deriving an answer from GIS data.  At the simplest level, there is some truth to this belief: the GIS data contains service boundary polygons with SIP URIs, and other feature data that may match a queried location, and different LoST server implementations that are designed to use this GIS data probably will all generate mappings having the same URI when queried with a given location that is valid.  But the way LoST servers internally represent data and create and identify mappings is likely to vary substantially.  The implementation of service boundaries may also vary substantially, and it is worth mentioning that service boundary polygons in GIS are not the same thing as the serviceBoundary element that can be included in a LoST mapping.  Noting that mappings and service boundary references are uniquely identified according to their sources, it would specifically be problematic for two different implementations to both create these while claiming to be the same source.

It is also important to understand that locations found to be invalid during the validation process may still be provisioned in a location server and used during a subsequent 9-1-1 call.  This is not the ideal scenario, but is an unavoidable reality given the number of validation errors that occur and require remediation.  When a location is invalid, the process for determining what mapping(s) to use in the response (if any) is much more likely to result in different answers between different implementations.  It is even plausible that one implementation could return a mapping and validation section while another might give up and return an error.  A situation where a validation server gives a mapping but then the server used for call routing returns an error is highly objectionable.

I realize that the hypothetical situation above goes well beyond the draft's proposal of "an entity" providing "consolidated or separate server clusters".  However, I believe without stronger language describing the requirements for successful implementation of separate validation servers, the road described above is one that will be taken - and enthusiastically so, with this draft being viewed as an endorsement or blessing.  To avoid that, I suggest requirements be added.  Specifically: both validation and non-validation LoST servers, when presented with identical queries, MUST produce responses that are identical in all substantial respects other than the presence or absence of portions related to location validation.  Additionally, all identifiers exposed in the response MUST have consistent meaning between both sets of servers.

Near the end of section 4, the draft discusses how the NENA discrepancy resolution process might force a software update of an older client that does not use the new LoST-Validation tag and is unable to reach a server for validation as a result.  This seems out of place, as not all LoST clients are necessarily going to follow NENA standards.  While NENA's desires may have prompted this draft, if it is truly useful it should be written to be applicable to a wider audience and with as few references to NENA as possible.  It is already possible that a client requesting validation will not receive validation, so there is no new problem to deal with in that regard.  This is already noted at the end of the section, and I'm not sure that much more needs to be stated beyond this and the acknowledgement that older clients may experience an increased number of validation failures until they are updated.

Additionally, the scenario that is described in section 4 is problematic:
  Even in the (unlikely) case
   of a designated mapping server that refuses to perform validation at
   any time, the server is likely to return a redirect with a different
   AUS (e.g., "lvf.example.com") that resolves to a designated
   validation server.
The behavior described here not reasonable.  There is nothing that disallows a query, made because the client needs a call routing URI, from setting the validateLocation attribute to true.  It is one thing to decline to provide validation in the response, but it is entirely another to refuse to answer the query at all.  A LoST server is authoritative to answer queries for one or more services within one or more areas.  A redirect response is equivalent to saying "I am not authoritative for this combination of service and location."  A LoST server with a different AUS is a different LoST server, and having multiple LoST servers answering queries for the same service and location, but identifying themselves as different servers is problematic.

The reason that a new application service tag needs to be defined is so that the same AUS can be used.  This is stated at the end of section 2, although I believe it would be better to replace or supplement the reasoning of "DNS name conventions are inflexible and fragile" with "and using different AUSs is not consistent with the notion of a single authoritative LoST server for a given service and location."  I do not believe it makes sense to contemplate the use of a different AUS as well, as section 4 does.  I think it would be better for this document to take a clear position that there is a single mechanism to achieve the desired separation.

Thanks,
Dan Banks

---

From: Brian Rosen <[email-masked]>
Date: Mon, 2 Mar 2020 13:31:48 -0500

I want to address the recursion issue, leaving the other issues you raised for another thread.

If a client uses the new tag, and requests recursion, it will reach a server that knows it’s a validation server (what NENA would call the LVF).  That server would use the new tag to recur.  The routing server would use the existing tag.   If there is only one cluster, and the initial query resolves to that cluster, it will use the LoST tag, because there is no difference.  I don’t see a problem.  We could add text that says this.

Brian

> On Mar 2, 2020, at 12:45 PM, Dan Banks <dbanks=[email-masked]> wrote:
> 
> LoST servers are resolved using U-NAPTR.  Although RFC 5222 section 4 uses language such as “clients need to use the U-NAPTR specification” rather than imperatives, further reading of the document leads to the understanding that several key features of the protocol, including redirection and recursion, rely exclusively upon U-NAPTR resolution.  This much, I think, is not in dispute.  However, RFC 5222 only defines a single application service tag (LoST), and does not appear to contemplate the use of alternatives.  An implementation that follows RFC 5222 could reasonably be expected to use the LoST application service tag exclusively.  The draft introduces an alternative service tag (LoST-Validation) and explains that “entities” needing to location validation would use the LoST-Validation tag instead.
>  
> One difficulty I have with this is that “entities” really means LoST clients, and the draft is an informational document that does not simply register a new service tag, but also describes a modification to the behavior of clients that deviates from RFC 5222.  I believe that additional behavior changes (as I will explain below), beyond what is already described, would need to be mandated to ensure success.  Although I am not especially familiar with the customs for informational versus standards track documents, my feeling is that this type of modification, even when small in scope, would be a better fit in a standards track document.
>  
> Which to me makes it clear that the tags belong in the S-NAPTR registry.  However, RFC 4848 otherwise seems to make a distinction between S-NAPTR and U-NAPTR, including a statement that “x-“ tags are experimental “as is the case for S-NAPTR”.  My interpretation is that S-NAPTR and U-NAPTR tags therefore live together in the same registry, which is perhaps not something I would have chosen to do, but that they are still distinguished by their intended usage.  I suggest that section 6.1 state “this document registers the following U-NAPTR application service tag” to be consistent with RFC 5222, and optionally append “to be added to the S-NAPTR Application Service Tags registry” for extra clarity.  The earlier note in section 6 may not be needed if the apparent conflict (which I think is not actually a conflict) between RFCs 5222 and 3958 is sufficiently explained by also referencing RFC 4848.
>  
>     When a client sends a <findService> or <listServicesByLocation> request to a server resolved by using the LoST-Validation service tag, it MUST set the ‘recursive’ attribute to “false”.
>  
> I think it is also worth noting that while the purpose of this draft is separate validation, and validation only directly applies to <findService>, any separate LoST server intended for validation and resolved by the LoST-Validation tag is still a LoST server and should still respond correctly to the other requests, even if there is no reason to expect it would normally receive them.  It might be worth adding a statement to section 4 to the effect of “A LoST server deployed primarily for validation must meet the same level of functionality and adherence to standards as a LoST server deployed for mapping.
>  
> The draft proposes separate validation and non-validation servers within the context of “an organization” deploying “different server clusters”, and also mentions in section 4 that “the data is identical”.  I think this approaches the conditions where such separation would be viable, but the language is not strong enough.  This is specifically a concern that I have due to a widespread belief within the NG9-1-1 industry that any two LoST servers using the same data should produce the same results, and that it is even reasonable to have one vendor provide the ECRF (LoST server for mapping) while another provides the LVF (LoST server for validation).  This largely disregards the complexity involved in deriving an answer from GIS data.  At the simplest level, there is some truth to this belief: the GIS data contains service boundary polygons with SIP URIs, and other feature data that may match a queried location, and different LoST server implementations that are designed to use this GIS data probably will all generate mappings having the same URI when queried with a given location that is valid.  But the way LoST servers internally represent data and create and identify mappings is likely to vary substantially.  The implementation of service boundaries may also vary substantially, and it is worth mentioning that service boundary polygons in GIS are not the same thing as the serviceBoundary element that can be included in a LoST mapping.  Noting that mappings and service boundary references are uniquely identified according to their sources, it would specifically be problematic for two different implementations to both create these while claiming to be the same source.
>  
> I realize that the hypothetical situation above goes well beyond the draft’s proposal of “an entity” providing “consolidated or separate server clusters”.  However, I believe without stronger language describing the requirements for successful implementation of separate validation servers, the road described above is one that will be taken – and enthusiastically so, with this draft being viewed as an endorsement or blessing.  To avoid that, I suggest requirements be added.  Specifically: both validation and non-validation LoST servers, when presented with identical queries, MUST produce responses that are identical in all substantial respects other than the presence or absence of portions related to location validation.  Additionally, all identifiers exposed in the response MUST have consistent meaning between both sets of servers.
>  
> Near the end of section 4, the draft discusses how the NENA discrepancy resolution process might force a software update of an older client that does not use the new LoST-Validation tag and is unable to reach a server for validation as a result.  This seems out of place, as not all LoST clients are necessarily going to follow NENA standards.  While NENA’s desires may have prompted this draft, if it is truly useful it should be written to be applicable to a wider audience and with as few references to NENA as possible.  It is already possible that a client requesting validation will not receive validation, so there is no new problem to deal with in that regard.  This is already noted at the end of the section, and I’m not sure that much more needs to be stated beyond this and the acknowledgement that older clients may experience an increased number of validation failures until they are updated.
>  
>    AUS (e.g., "lvf.example.com <http://lvf.example.com/>") that resolves to a designated
>    validation server.
> The behavior described here not reasonable.  There is nothing that disallows a query, made because the client needs a call routing URI, from setting the validateLocation attribute to true.  It is one thing to decline to provide validation in the response, but it is entirely another to refuse to answer the query at all.  A LoST server is authoritative to answer queries for one or more services within one or more areas.  A redirect response is equivalent to saying “I am not authoritative for this combination of service and location.”  A LoST server with a different AUS is a different LoST server, and having multiple LoST servers answering queries for the same service and location, but identifying themselves as different servers is problematic.
>  
> The reason that a new application service tag needs to be defined is so that the same AUS can be used.  This is stated at the end of section 2, although I believe it would be better to replace or supplement the reasoning of “DNS name conventions are inflexible and fragile” with “and using different AUSs is not consistent with the notion of a single authoritative LoST server for a given service and location.”  I do not believe it makes sense to contemplate the use of a different AUS as well, as section 4 does.  I think it would be better for this document to take a clear position that there is a single mechanism to achieve the desired separation.
>  
> Thanks,
> Dan Banks
> -- 
> last-call mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/last-call <https://www.ietf.org/mailman/listinfo/last-call>

---

From: Dan Banks <[email-masked]>
Date: Mon, 2 Mar 2020 21:21:59 +0000

If the initial server that is reached is a validation server, and the only way to discover that server’s URI is to use the new tag, I agree in that circumstance the initial server could then use the new tag to resolve the next server’s URI.  However, this is a (small) change in the expected behavior of a server.

But suppose the initial server is a combined server that is intended to be used for both validation and mapping and the next server after that is separated.  The initial server would not know the purpose of the incoming query and would need to use the original tag, causing validation queries to land on a non-validation instance.  This is the problem I think needs to be solved by prohibiting recursion.  Prohibiting it at the client would only need to break recursion for validation queries.  The initial server could also refuse to perform recursion, but that would affect all queries, or at least all queries that request validation.

Dan

From: Brian Rosen <[email-masked]>
Sent: Monday, March 2, 2020 1:32 PM
To: Dan Banks <[email-masked]>
Cc: [email-masked]
Subject: Re: [Last-Call] Last Call: <draft-gellens-lost-validation-05.txt> (The LoST-Validation S-NAPTR Application Service Tag) to Informational RFC

Brian

On Mar 2, 2020, at 12:45 PM, Dan Banks <dbanks=[email-masked]<mailto:dbanks=[email-masked]>> wrote:

   AUS (e.g., "lvf.example.com<https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Flvf.example.com%2F&data=02%7C01%7Cdbanks%40ddti.net%7C1adce8f60d3c470c307e08d7bed7fd49%7C4c0f48ba5f2944b1b29c1aff8251101b%7C0%7C0%7C637187707202702223&sdata=Yth2Sww3VI9yp6A1zJmKiPO5F7gessscscp7TnlOmr4%3D&reserved=0>") that resolves to a designated

Thanks,
Dan Banks
--
last-call mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/last-call<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flast-call&data=02%7C01%7Cdbanks%40ddti.net%7C1adce8f60d3c470c307e08d7bed7fd49%7C4c0f48ba5f2944b1b29c1aff8251101b%7C0%7C0%7C637187707202712177&sdata=y5b9FIKZLCX53n4KyoMzYuN286W%2Fyoaq41GvFQbKZSk%3D&reserved=0>

---

From: Brian Rosen <[email-masked]>
Date: Mon, 2 Mar 2020 16:27:27 -0500

I would prefer to not prohibit recursion.  I think we can just point out the issue.  It’s not going to be a very big deal in any event.  If I were implementing a combined service, I would still maintain two addresses so that I knew what service was being requested, but the consequences of doing the wrong thing is minor.  The combined service would always recur to the route service if it didn’t know.  You would never guess validation.  That is the behavior of a service that was unaware of the new tag, so it’s all okay I think.

Brian

> On Mar 2, 2020, at 4:21 PM, Dan Banks <[email-masked]> wrote:
> 
> On Mar 2, 2020, at 12:45 PM, Dan Banks <dbanks=[email-masked] <mailto:dbanks=[email-masked]>> wrote:
>  
>    AUS (e.g., "lvf.example.com <https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Flvf.example.com%2F&data=02%7C01%7Cdbanks%40ddti.net%7C1adce8f60d3c470c307e08d7bed7fd49%7C4c0f48ba5f2944b1b29c1aff8251101b%7C0%7C0%7C637187707202702223&sdata=Yth2Sww3VI9yp6A1zJmKiPO5F7gessscscp7TnlOmr4%3D&reserved=0>") that resolves to a designated
>    validation server.
> https://www.ietf.org/mailman/listinfo/last-call <https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flast-call&data=02%7C01%7Cdbanks%40ddti.net%7C1adce8f60d3c470c307e08d7bed7fd49%7C4c0f48ba5f2944b1b29c1aff8251101b%7C0%7C0%7C637187707202712177&sdata=y5b9FIKZLCX53n4KyoMzYuN286W%2Fyoaq41GvFQbKZSk%3D&reserved=0>

---

From: "Randall Gellens" <[email-masked]>
Date: Mon, 09 Mar 2020 08:13:12 -0700

Hi Dan,

Thank you for your review.  Please see in-line:

On 2 Mar 2020, at 9:45, Dan Banks wrote:

> I have reviewed draft-gellens-lost-validation-05.txt following the 
> emails to the Ecrit list, and have some comments.
>
> Within NENA, I have often been critical of the desire to have separate 
> LoST servers for validation versus those used for routing.  Although I 
> have several reasons for taking that position, and I am in the 
> minority with my overall concerns, my primary objection has been that 
> the LoST protocol does not support this separation.

RFC 5222 makes validation optional; it allows a LoST server to perform 
requested validation or not.  So, regardless of adding a new tag or not, 
there is the possibility of service separation.  The new tag is an 
optimization that improves this situation.

> This draft appears to be an attempt to fix the fundamental problem, 
> but I am concerned that it may be insufficient as currently written.
>
> LoST servers are resolved using U-NAPTR.  Although RFC 5222 section 4 
> uses language such as "clients need to use the U-NAPTR specification" 
> rather than imperatives, further reading of the document leads to the 
> understanding that several key features of the protocol, including 
> redirection and recursion, rely exclusively upon U-NAPTR resolution.  
> This much, I think, is not in dispute.  However, RFC 5222 only defines 
> a single application service tag (LoST), and does not appear to 
> contemplate the use of alternatives.  An implementation that follows 
> RFC 5222 could reasonably be expected to use the LoST application 
> service tag exclusively.

Yes, I agree.  If the new tag is not defined, or if an implementation 
(client or server) does not follow a future i3 directive to use the new 
tag for validation, then there is the possibility of a client reaching a 
server that refuses to perform validation.  Presumably, the client would 
then back up and retry with a different server.  Using the new tag is an 
optimization that avoids that.

> The draft introduces an alternative service tag (LoST-Validation) and 
> explains that "entities" needing to location validation would use the 
> LoST-Validation tag instead.
>
> One difficulty I have with this is that "entities" really means LoST 
> clients,

In the context of the draft, it means both clients and server 
administrators; clients use the tag when resolving an application unique 
string, and server administrators use the tag when provisioning DNS 
records.

> and the draft is an informational document that does not simply 
> register a new service tag, but also describes a modification to the 
> behavior of clients that deviates from RFC 5222.

The draft currently includes explanatory text that describes the 
intended use of the new tag, largely added at Ben's request, but which 
Pete has requested be removed (so the draft only adds the tag, without 
explaining anything about its use, but pointing to NENA i3 as a 
work-in-progress that will use the tag).

> I believe that additional behavior changes (as I will explain below), 
> beyond what is already described, would need to be mandated to ensure 
> success.  Although I am not especially familiar with the customs for 
> informational versus standards track documents, my feeling is that 
> this type of modification, even when small in scope, would be a better 
> fit in a standards track document.
>
> With regards to the application service tag registration itself, the 
> draft states that it registers an S-NAPTR tag.  It also correctly 
> notes in section 6 that the registry is the S-NAPTR Application 
> Service Tags registry, while RFC 5222 states that it registers a 
> U-NAPTR application service tag.  As this registration of an S-NAPTR 
> tag caught me off guard, I believe this note is important.  However, I 
> think it would be more correct for the draft to state that it is 
> registering a U-NAPTR tag.  My reasoning is as follows:  RFC 4848 
> states in section 5 that it:
> Which to me makes it clear that the tags belong in the S-NAPTR 
> registry.  However, RFC 4848 otherwise seems to make a distinction 
> between S-NAPTR and U-NAPTR, including a statement that "x-" tags are 
> experimental "as is the case for S-NAPTR".  My interpretation is that 
> S-NAPTR and U-NAPTR tags therefore live together in the same registry, 
> which is perhaps not something I would have chosen to do, but that 
> they are still distinguished by their intended usage. I suggest that 
> section 6.1 state "this document registers the following U-NAPTR 
> application service tag" to be consistent with RFC 5222, and 
> optionally append "to be added to the S-NAPTR Application Service Tags 
> registry" for extra clarity.  The earlier note in section 6 may not be 
> needed if the apparent conflict (which I think is not actually a 
> conflict) between RFCs 5222 and 3958 is sufficiently explained by also 
> referencing RFC 4848.

If there was intended to be this distinction in the registry, it would 
have been very easy to have added a field to the registry when it was 
created that would contain the intended usage.  You could be right that 
there was originally a desire to maintain such a distinction, but I 
think what we have now is a registry that contains the service tags, and 
RFCs that define the tags.  Up to now, the RFCs have also described the 
use of the tags, but if we adopt Pete's suggestion, this draft will only 
add the tag and point to NENA i3, which would be the document that 
describes the tag's use.

> Next, recursion in LoST only occurs when the client requests it and 
> when the server decides to perform it (which it is not required to 
> do).  When recursion is used, the server acts as a client and invokes 
> U-NAPTR to find the target URI as any other client would.  The draft 
> does not currently address recursion, which leaves a problematic gap.  
> When a client wishing to obtain location validation resolves a LoST 
> server using the proposed LoST-Validation tag, that server does not 
> have a direct way to know that this new tag was used.  If the request 
> needs to be sent to another server to be answered and recursion is 
> requested, a server attempting to perform recursion would not know 
> that it also needed to use the LoST-Validation tag instead of the 
> normal one.  This could effectively defeat the proposed mechanism in a 
> significant number of cases.  Further, if the intent is for servers to 
> use the new tag during recursion, this would be a change to the 
> behavior of servers, not just clients.

Fundamentally, the situation you describe exists now: any LoST client 
can request validation and recursion, and any server can refuse to 
perform validation.  With the existence of the new tag, it's possible 
operationally for servers to be aware of and maintain the separation, 
regardless of servers that perform both validation and mapping, although 
neither this draft nor i3 discuss this.  Assuming the new tag is 
defined, I intend to draft a contribution for NENA i3 that explains the 
new tag and how it is used.  One aspect of that would be to mention 
techniques that could be used (without mandating any specific ones) for 
a server to know how it was accessed and hence which tag to use during 
recursion.  (For example, use of the two tags could resolve to different 
host names even if the different names have the same address records, 
with the TLS Server Name Indication to know which was used, or different 
address records could be used to reach a multihomed server.)

>  The easiest way to fix these issues may be to eliminate the use of 
> recursion when using the new service tag by adding language such as:
>     When a client sends a <findService> or <listServicesByLocation> 
> request to a server resolved by using the LoST-Validation service tag, 
> it MUST set the 'recursive' attribute to "false".

I don't think that's necessary.

> I think it is also worth noting that while the purpose of this draft 
> is separate validation, and validation only directly applies to 
> <findService>, any separate LoST server intended for validation and 
> resolved by the LoST-Validation tag is still a LoST server and should 
> still respond correctly to the other requests, even if there is no 
> reason to expect it would normally receive them.  It might be worth 
> adding a statement to section 4 to the effect of "A LoST server 
> deployed primarily for validation must meet the same level of 
> functionality and adherence to standards as a LoST server deployed for 
> mapping.

I think any such text would be better placed in i3.  Especially if we 
accept Pete's suggestion to strip all explanatory material from this 
draft.  Fundamentally, the text should say that if validation and 
mapping services are separated, they MUST use the same data.

> Along those same lines, the language of the draft tends to refer to 
> mapping and validation as separate functions.  They may reflect 
> separate actual needs, but because locationValidation is returned in 
> the findServiceResponse, and the findServiceResponse requires one or 
> more mappings, it is not possible to provide validation without also 
> providing mapping.  The real distinction in functionality is only 
> whether or not validation will be included in the response, so it a 
> choice between (mapping only) or (mapping plus validation).  I would 
> prefer that the language throughout sections 2 and 3 better reflect 
> this.

I think this discussion would be better placed in i3.

> Because a response with validation always includes a mapping, it is 
> important to understand that not just any mapping will do.  LoST 
> includes the concept of an authoritative source for mappings and 
> allows mapping information to be cached.  If a client has an unexpired 
> mapping that it obtained during validation, it is perfectly reasonable 
> for the client to use the call routing URI included in that mapping 
> for an emergency call without making an additional LoST query.  
> Further, a mapping cached by a server could be used to answer a query 
> that would otherwise result in redirection or recursion.  LoST even 
> considers the possibility that an expired mapping could be used when a 
> new query cannot be completed.  All of this is to say that the mapping 
> returned by a server intended to perform the validation function must 
> be authoritative and correct.

Sure, and I think clarifying/explanatory text to this effect could be 
added to i3.

> The draft proposes separate validation and non-validation servers 
> within the context of "an organization" deploying "different server 
> clusters", and also mentions in section 4 that "the data is 
> identical".  I think this approaches the conditions where such 
> separation would be viable, but the language is not strong enough.  
> This is specifically a concern that I have due to a widespread belief 
> within the NG9-1-1 industry that any two LoST servers using the same 
> data should produce the same results, and that it is even reasonable 
> to have one vendor provide the ECRF (LoST server for mapping) while 
> another provides the LVF (LoST server for validation).  This largely 
> disregards the complexity involved in deriving an answer from GIS 
> data.  At the simplest level, there is some truth to this belief: the 
> GIS data contains service boundary polygons with SIP URIs, and other 
> feature data that may match a queried location, and different LoST 
> server implementations that are designed to use this GIS data probably 
> will all generate mappings having the same URI when queried with a 
> given location that is valid.  But the way LoST servers internally 
> represent data and create and identify mappings is likely to vary 
> substantially.  The implementation of service boundaries may also vary 
> substantially, and it is worth mentioning that service boundary 
> polygons in GIS are not the same thing as the serviceBoundary element 
> that can be included in a LoST mapping.  Noting that mappings and 
> service boundary references are uniquely identified according to their 
> sources, it would specifically be problematic for two different 
> implementations to both create these while claiming to be the same 
> source.

This is useful text that I think should be in i3, not this draft 
(especially if we adopt Pete's suggestion, but even if we don't).

> It is also important to understand that locations found to be invalid 
> during the validation process may still be provisioned in a location 
> server and used during a subsequent 9-1-1 call.  This is not the ideal 
> scenario, but is an unavoidable reality given the number of validation 
> errors that occur and require remediation.  When a location is 
> invalid, the process for determining what mapping(s) to use in the 
> response (if any) is much more likely to result in different answers 
> between different implementations.  It is even plausible that one 
> implementation could return a mapping and validation section while 
> another might give up and return an error.  A situation where a 
> validation server gives a mapping but then the server used for call 
> routing returns an error is highly objectionable.

Again, this is useful text that I think should be in i3.

> I realize that the hypothetical situation above goes well beyond the 
> draft's proposal of "an entity" providing "consolidated or separate 
> server clusters".  However, I believe without stronger language 
> describing the requirements for successful implementation of separate 
> validation servers, the road described above is one that will be taken 
> - and enthusiastically so, with this draft being viewed as an 
> endorsement or blessing.  To avoid that, I suggest requirements be 
> added.  Specifically: both validation and non-validation LoST servers, 
> when presented with identical queries, MUST produce responses that are 
> identical in all substantial respects other than the presence or 
> absence of portions related to location validation.  Additionally, all 
> identifiers exposed in the response MUST have consistent meaning 
> between both sets of servers.

I don't think this draft is the place for such mandates.  I think this 
belongs in i3.

> Near the end of section 4, the draft discusses how the NENA 
> discrepancy resolution process might force a software update of an 
> older client that does not use the new LoST-Validation tag and is 
> unable to reach a server for validation as a result.  This seems out 
> of place, as not all LoST clients are necessarily going to follow NENA 
> standards.  While NENA's desires may have prompted this draft, if it 
> is truly useful it should be written to be applicable to a wider 
> audience and with as few references to NENA as possible.  It is 
> already possible that a client requesting validation will not receive 
> validation, so there is no new problem to deal with in that regard.  
> This is already noted at the end of the section, and I'm not sure that 
> much more needs to be stated beyond this and the acknowledgement that 
> older clients may experience an increased number of validation 
> failures until they are updated.

That's reasonable.  If we delete Section 4 per Pete's suggestion, it 
goes away, and if we leave it, I'd be happy to delete the mention of 
discrepancy resolution and software updates.

> The behavior described here not reasonable.  There is nothing that 
> disallows a query, made because the client needs a call routing URI, 
> from setting the validateLocation attribute to true.  It is one thing 
> to decline to provide validation in the response, but it is entirely 
> another to refuse to answer the query at all.  A LoST server is 
> authoritative to answer queries for one or more services within one or 
> more areas.  A redirect response is equivalent to saying "I am not 
> authoritative for this combination of service and location."  A LoST 
> server with a different AUS is a different LoST server, and having 
> multiple LoST servers answering queries for the same service and 
> location, but identifying themselves as different servers is 
> problematic..

Yes, a server asked to perform validation could provide mapping and no 
validation.  Currently, there is no text anywhere that I can find (not 
in any of the RFCs nor in i3) that describes how application unique 
strings are used.  We say that the AUS is in the form of a domain name, 
and that's it.  Using an additional DNS label, either in the AUS or in 
the DNS records, to distinguish validation from mapping is an approach 
that could be used operationally, and in the absence of this new tag, 
some such approach is probably the only way to separate the two.  I 
think it would be helpful to provide text in i3 that describes how LoST 
AUSs are used.

> The reason that a new application service tag needs to be defined is 
> so that the same AUS can be used.  This is stated at the end of 
> section 2, although I believe it would be better to replace or 
> supplement the reasoning of "DNS name conventions are inflexible and 
> fragile" with "and using different AUSs is not consistent with the 
> notion of a single authoritative LoST server for a given service and 
> location."  I do not believe it makes sense to contemplate the use of 
> a different AUS as well, as section 4 does.  I think it would be 
> better for this document to take a clear position that there is a 
> single mechanism to achieve the desired separation.

Again, I think such clarification and direction would be a good thing to 
add to i3, but not in this draft.

--Randall