Subject: [Last-Call] Intdir telechat review of draft-ietf-ecrit-similar-location-18

From: Tatuya Jinmei via Datatracker <[email-masked]>
Date: Fri, 25 Feb 2022 11:26:07 -0800

Reviewer: Tatuya Jinmei
Review result: Ready

I am an assigned INT directorate reviewer for
<draft-ietf-ecrit-similar-location-18.txt>. These comments were written
primarily for the benefit of the Internet Area Directors. Document editors and
shepherd(s) should treat these comments just like they would treat comments
from any other IETF contributors and resolve them along with any other Last
Call comments that have been received. For more details on the INT Directorate,
see https://datatracker.ietf.org/group/intdir/about/
<https://datatracker.ietf.org/group/intdir/about/>.

This draft defines a few optional extensions to the LoST protocol as defined in
RFC5222 so that the server can provide supplemental information that may be
useful for the client.  I'm not familiar with the LoST protocol, so it's quite
possible my review miss something.  With noting that, the draft is very well
written, its purpose and explanations are clear, and I didn't find any obvious
problem, especially those related to the INT area.  I think it's ready for
publication.

I have a couple of comments, making mostly just out of curiosity.  I'd be happy
to get clarifications on these points, but these are not blocking issues at all.

- The definition of similarity (in Section 2) looks loose to me:

   Similar Location:  A suggested civic location that is similar to an
      Invalid Location which was used in a LoST query, but which has one
      or more elements added, modified, or removed such that the
      suggested location is a Valid Location.

  If we apply this definition literally, a completely "different" location
  could be considered to be "similar" as long as it's valid, since all
  editorial operations can be applied for arbitrary times, right?  Perhaps it's
  intentionally kept loose and left to the server implementation and
  discretion, but it would be also nice if it gives some example of what would
  NOT be considered to be similar (for example, what if an element contains a
  misspelling and fixing it would make it valid?).

- Also related to the above definition, can "Similar Location" be used only
when the input is invalid?  For example, what if both "6000 15th Avenue
Northwest" and "6000 15th Avenue Southwest" exist and the input is either of
them in a complete form, can we include the other as a "Similar Location"?

---

From: Brian Rosen <[email-masked]>
Date: Fri, 25 Feb 2022 15:47:08 -0500

Thanks for the review.  See inline.

> On Feb 25, 2022, at 2:26 PM, Tatuya Jinmei via Datatracker <[email-masked]> wrote:
> 
> Reviewer: Tatuya Jinmei
> Review result: Ready
> 
The server can’t know what the intended location is.  So it very well could be different in the sense you mean.
Yes, it is intended to be loose, because the server might use all kinds of info that isn’t specified: think about an AI that looked at all the invocations of the command, and subsequent validations, to see how it’s advice was used and tuned the advice accordingly.  It is, by definition, guessing.  We don’t say how wild a guess it can make, or not make.  A misspelled word is an excellent example of what it could be used for: suppose the postal code was specific enough to see that it likely was a misspelled municipality name.  Perfectly reasonable Similar location.    The original has municipality on the <invalid> list, and all the other lower level submitted fields on the <unchecked> list.  The Similar Location has all the same fields with the correct municipality (A3).  

> them in a complete form, can we include the other as a "Similar Location”?

The text describes the use case when the input If you had a valid location in the input, then you can’t get a field with a different value in Similar Location.   You can get Similar Location, but it would have additional fields that were not in the input.  Looking at the text, we could make that more clear.

Brian