|
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
