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

[Brian Rosen <br@xxxxxxxxxxxxxx>]

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 <dbanks@xxxxxxxx> wrote:

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 <br@xxxxxxxxxxxxxx> 
Sent: Monday, March 2, 2020 1:32 PM
To: Dan Banks <dbanks@xxxxxxxx>
Cc: last-call@xxxxxxxx
Subject: Re: [Last-Call] Last Call: <draft-gellens-lost-validation-05.txt> (The LoST-Validation S-NAPTR Application Service Tag) to Informational RFC

 

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=40ddti.net@xxxxxxxxxxxxxx> 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.  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

-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call

-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call