Subject: [Ecrit] Review of draft-ietf-ecrit-similar-location-01

From: Theresa Reese <[email-masked]>
Date: Wed, 3 Feb 2016 15:28:41 +0000

I have reviewed draft-ietf-ecrit-similar-location-01 and consider this document to describe a useful capability.

During my review, I identified the following NITS:

1.       The word "a" is missing from the last sentence of the abstract.

Proposed change:
From: "These two types of civic addresses are referred to as either  "complete location" or "similar location", and are included as compilation of ca type xml elements within the existing LoST findServiceResponse message structure."

To:  "These two types of civic addresses are referred to as either  "complete location" or "similar location", and are included as a compilation of ca type xml elements within the existing LoST findServiceResponse message structure."

2.       There is an inconsistency in the way the term CAtype is presented throughout the document (i.e., the Abstract uses "ca type"; Section 2 uses "CAtype"; Section 3 uses "caType" and "CAtype"; Section 8 usese "CAtype).  The term should be presented consistently throughout the document.

3.       Fix the punctuation in the definition for Civic Location in Section 2

Proposed change:
From: ". . . to designates a place within a defined grid or basemap, The example used within . .  ."

To:  ". . . to designates a place within a defined grid or basemap,. The example used within . .  ."

4.       Need to add periods at the end of the definitions for:  Civic Location, Civic Address Element, Invalid, and Valid in Section 2, for consistency with the other definitions.

5.       The word "of" is missing from Section 3, paragraph 2, third sentence:

Proposed change:
From:   "As an example, there are LoST civic  address elements that could be used to define a postal location, suitable for delivery mail as well as a municipal location suitable for responding to an emergency call."

To:  "As an example, there are LoST civic  address elements that could be used to define a postal location, suitable for delivery of mail as well as a municipal location suitable for responding to an emergency call."

6.       Fix the punctuation in Section 3, paragraph 6, third sentence

Proposed change:
From: "In a valid location response, a LoST server returns a response to a findService request that contains a set of civic address elements marked valid, the location information in the findServiceResponse message MAY be extended to include additional location information specific for that location."

To:  "In a valid location response, a LoST server returns a response to a findService request that contains a set of civic address elements marked valid,.  tThe location information in the findServiceResponse message MAY be extended to include additional location information specific for that location."

7.       Replace the colon with a period at the end of the last sentence in Section 3.

8.       Consider making Sections 5 and 6 subsections of Section 4 (i.e., change Section 5 to Section 4.1; change Section 6 to Section 4.2).

Regards,
Terry Reese

---

From: Roger Marshall <[email-masked]>
Date: Wed, 3 Feb 2016 15:40:06 +0000

Terry:
Thanks for your careful review of draft-ietf-ecrit-similar-location-01.  We will soon update the draft to take into account these editorial changes.

-roger.

From: Theresa Reese [mailto:[email-masked]]
Sent: Wednesday, February 03, 2016 7:29 AM
To: Roger Marshall; [email-masked]
Cc: [email-masked]
Subject: Review of draft-ietf-ecrit-similar-location-01

Proposed change:

Proposed change:

Proposed change:

Proposed change:

Regards,
Terry Reese

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.

---

From: Jason Horning <[email-masked]>
Date: Fri, 5 Feb 2016 17:53:15 +0000

I think it is important that this draft move forward.  As it stands, LoST is not particularly helpful when it comes to validating addresses.

One question that I do have is what happens when dozens (i.e. an apartment) or hundreds (office complex) of potential complete or similar location candidates are found by the LoST server.  Is there an expectation that all complete or similar locations with the same level of completeness or similarity are returned?

Jason

From: Ecrit [mailto:[email-masked]] On Behalf Of Roger Marshall
Sent: Wednesday, February 3, 2016 9:40 AM
To: 'Theresa Reese'; [email-masked]
Cc: [email-masked]
Subject: Re: [Ecrit] Review of draft-ietf-ecrit-similar-location-01

Terry:

-roger.

From: Theresa Reese [mailto:[email-masked]]
Sent: Wednesday, February 03, 2016 7:29 AM
To: Roger Marshall; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Review of draft-ietf-ecrit-similar-location-01

Proposed change:

Proposed change:

Proposed change:

Proposed change:

Regards,
Terry Reese

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 5 Feb 2016 19:53:58 +0000

Thanks for the review.

I think the server ought to limit how many options it sends to a couple.  I think we could add words to that effect.  It might be possible to provide a way for the client to specify the max number of valid possibilities it gets, but I think that isn’t worth the complexity.

Brian

From: Jason Horning <[email-masked]<mailto:[email-masked]>>
Date: Friday, February 5, 2016 at 11:53 AM
To: Roger Marshall <[email-masked]<mailto:[email-masked]>>, Brian Rosen <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: Review of draft-ietf-ecrit-similar-location-01

Jason

To: 'Theresa Reese'; [email-masked]<mailto:[email-masked]>

Terry:

-roger.

1.       The word “a” is missing from the last sentence of the abstract.

Proposed change:
From: “These two types of civic addresses are referred to as either  "complete location" or "similar location", and are included as compilation of ca type xml elements within the existing LoST findServiceResponse message structure.”

To:  “These two types of civic addresses are referred to as either  "complete location" or "similar location", and are included as a compilation of ca type xml elements within the existing LoST findServiceResponse message structure.”

2.       There is an inconsistency in the way the term CAtype is presented throughout the document (i.e., the Abstract uses “ca type”; Section 2 uses “CAtype”; Section 3 uses “caType” and “CAtype”; Section 8 usese “CAtype).  The term should be presented consistently throughout the document.

Proposed change:
From: “. . . to designates a place within a defined grid or basemap, The example used within . .  .”

To:  “. . . to designates a place within a defined grid or basemap,. The example used within . .  .”

5.       The word “of” is missing from Section 3, paragraph 2, third sentence:

Proposed change:
From:   “As an example, there are LoST civic  address elements that could be used to define a postal location, suitable for delivery mail as well as a municipal location suitable for responding to an emergency call.”

To:  “As an example, there are LoST civic  address elements that could be used to define a postal location, suitable for delivery of mail as well as a municipal location suitable for responding to an emergency call.”

Proposed change:
From: “In a valid location response, a LoST server returns a response to a findService request that contains a set of civic address elements marked valid, the location information in the findServiceResponse message MAY be extended to include additional location information specific for that location.”

To:  “In a valid location response, a LoST server returns a response to a findService request that contains a set of civic address elements marked valid,.  tThe location information in the findServiceResponse message MAY be extended to include additional location information specific for that location.”

Regards,
Terry Reese

---

From: Jason Horning <[email-masked]>
Date: Fri, 5 Feb 2016 20:28:03 +0000

If a client provides a physical address for an apartment building but no sub-address for the individual unit, a server may be inclined to send back complete locations for all 36 units in the apartment building.  That would probably be helpful as long as the list doesn’t get too unwieldy.  For example, it probably wouldn’t be helpful in the case of “One World Trade Center” where thousands of complete locations may exist.

The thing I’m trying to determine is what the value of the extension would be in examples that are more difficult than a single family home scenario.  In those complex cases is it any more helpful than the LoST protocol as it currently exists?

Maybe it’s worth sending a message to the client that too many similar/complete results were found?

From: Rosen, Brian [mailto:[email-masked]]
Sent: Friday, February 5, 2016 1:54 PM
To: Jason Horning; Roger Marshall
Cc: [email-masked]
Subject: Re: Review of draft-ietf-ecrit-similar-location-01

Thanks for the review.

Brian

Jason

Terry:

-roger.

Proposed change:

Proposed change:

Proposed change:

Proposed change:

Regards,
Terry Reese