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:
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.
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.
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..
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
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
