Subject: [Ecrit] FW: [ecrf-lvfwg] RE: LVF impact - IETF draft for LVF return of complete & similar civic addresses

From: "Roger Marshall" <[email-masked]>
Date: Sun, 24 Jul 2011 21:05:17 -0700

Posting some comments regarding the draft:
http://tools.ietf.org/html/draft-marshall-ecrit-similar-location-01
which were received from Jason Horning, as a NENA posting.

See thread.

-roger marshall.

From: Roger Marshall 
Sent: Tuesday, July 19, 2011 12:27 PM
To: Jason Horning; ECRF/LVF WG
Cc: [email-masked]; Winterbottom, James
Subject: RE: [ecrf-lvfwg] RE: LVF impact - IETF draft for LVF return of
complete & similar civic addresses

Jason:

Thanks for taking the time to look at this draft.  You've made some
excellent points.  Please see my comments below, denoted with [RM].

I will post these comments to the IETF ECRIT list, which I encourage all
those interested to sign up for at:

Ecrit mailing list

[email-masked]

https://www.ietf.org/mailman/listinfo/ecrit

-roger.

From: Jason Horning [mailto:[email-masked]] 
Sent: Tuesday, July 19, 2011 7:48 AM
To: ECRF/LVF WG
Cc: [email-masked]; Winterbottom, James
Subject: [ecrf-lvfwg] RE: LVF impact - IETF draft for LVF return of
complete & similar civic addresses

Roger,

Thank you for the opportunity to comment and for your attention to this
matter. 

Here are some of the concerns that I have with the draft in its present
form..

1. This extension of LoST suggests (as evidenced by at least one of the
examples) that the client has been assigned to (or somehow has
determined) the authoritative mapping server (AMS) that can provide the
answer.  It therefore bypasses the recursive or iterative nature of LoST
to seek out the AMS.  A couple of the examples describe civic addresses
without country and A1 elements.  Without those, I'd  like to know how
the client was able to reach the proper AMS to begin with.

[RM - You're right, there is an assumption that's not currently stated
with regard to LoST server discovery.  Additionally, the set of data
elements in the examples should be made more realistic, to match these
stated assumptions.]

If this is the author's intent, LoST servers will endeavor to return
results for which they may not have any authority to be providing
"hints".  It is important to first determine, by coverage, which AMS to
use.  Only then can the LoST server be asked to make decisions such as
those proposed.  LoST provides the facility to determine the AMS, it
just needs enough extremely coarse information to do so.

[RM - See above.]

2. In the example in section 6 "Similar Location returned for Invalid
Response"; to which civic address is the returned urn:service:sos
service associated?  What happens if the two "similar" addresses exist
within two different urn:service:sos service areas?  Even if one were to
associate the proper service with each civic address I'm unclear as to
whether LoST permits that. This case should be addressed specifically.

[RM - Good point.  What's missing here is some qualifying lead-in text
describing the example, as well as a few other examples that may have
different results.  This will be fixed in a subsequent update to the
draft.]

3. Another nit that I have includes intentionally using A6 to represent
a street name and then permitting the LoST server to analyze it as RD
and provide "similar" or "complete" location results.  RFC5139 (which
updated RFC4119) was quite clear on this practice.  Here is an excerpt
from RFC5139; "Where "A6" was previously used for street names in
[RFC4119], it MUST NOT be used; the "RD" element MUST be used for
thoroughfare data."  I am aware of i3's position on this topic. However,
the A6 element and the RD element represent different concepts.

[RM - Yes.  RD should & will replace A6 for these examples.]

It may be possible that the draft can be added to and the concerns that
I have expressed can be mitigated.  However, it is not the approach that
I would have preferred.  I still submit that we must first define the US
location validation process and then offer an alternate query interface
to resolve "invalid" elements.  At that point you can let the validation
vendors determine the best way to tackle the LoST response, and query
(with a non-LoST interface) for the information necessary to obtain a
completely valid address. We can try to extend LoST without creating new
problems but it seems to be a risky option.

[RM - Keep in mind that, as an IETF draft, (and despite the current
examples), this document is not constrained for application within the
US only.]

Finally, the stance taken in the Security Considerations section is a
bit troubling.  The source supplying address information to the LoST
server should control what is valid and what is not valid, not the LoST
server and not the client.  They do this through the refinement of their
data.  If they go through the trouble of building in significant detail
they are, in essence, defining the level of detail that they seek and
which they may need to target specific services.  If they provide very
coarse information then they are allowing the client to validate to a
more coarse level.  I don't believe it should be left up to LoST vendors
and service providers to determine what is acceptable.

[RM - I don't disagree - the "source" of the LoST server data does
indeed set the policy for how stuff works, and so will be taken into
account as we progress this draft.]

Regards,

Jason Horning

From: Roger Marshall [mailto:[email-masked]] 
Sent: Monday, July 18, 2011 4:02 PM
To: ECRF/LVF WG
Cc: ECRF/LVF WG; [email-masked]
Subject: [ecrf-lvfwg] LVF impact - IETF draft for LVF return of complete
& similar civic addresses

I'm forwarding an announcement (see attached) and link (below) to an
individual draft that has been sent to the IETF, and so I would like to
get some folks to weigh in with their thoughts, comments, etc.

You can do so here - on the ECRF/LVF or LTD-WG NENA lists, or on the
IETF ECRIT mailing list.  If people find it useful, then the proposal
will be to make it an ECRIT working group draft.  Therefore, your
comments will be valuable.

http://tools.ietf.org/html/draft-marshall-ecrit-similar-location-01

This draft represents a merging of the following two previously
submitted drafts:

http://tools.ietf.org/html/draft-rosen-ecrit-lost-return-li-00

http://tools.ietf.org/html/draft-marshall-ecrit-similar-location-00

Thanks.

-roger.

CONFIDENTIALITY NOTICE: The information contained in this message may be privileged and/or confidential. If you are not the intended recipient, or responsible for delivering this message to the intended recipient, any review, forwarding, dissemination, distribution or copying of this communication or any attachment(s) is strictly prohibited. If you have received this message in error, please notify the sender immediately, and delete it and all attachments from your computer and network.