Re: [Ecrit] Benjamin Kaduk's No Objection on draft-ietf-ecrit-similar-location-18: (with COMMENT)

[Brian Rosen <[e-mail]>]

Thanks for the careful review of this document.

Comments inline

> On Feb 28, 2022, at 3:29 PM, Benjamin Kaduk via Datatracker <[e-mail]> wrote:
> 
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-ecrit-similar-location-18: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
> for more information about how to handle DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-ecrit-similar-location/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> There were a few terms/XML elements used that I couldn't readily find a
> clear definition for, across this document, RFC 5139, and RFC 5222, which
> makes me wonder if there are any additional references we could list as
> background reading for relevant terminology.  (Things like <POD> and
> <STS>, though the latter is slightly harder to do a plaintext search for
> so I may have just missed it.)
I’ll add a reference to RFC4776 that has these.


> 
> Section 2
> 
>   Civic Location:  The term Civic Location applies to a set of one or
>      more Civic Address Elements that are used in conjunction with each
>      other, and in accordance with a known ruleset to designate a
>      specific place within a region of geography, or a region of
>      geography by itself as defined in [RFC5139].
> 
> Interestingly, I find neither the word "region" nor the word "geography"
> in RFC 5139 ... perhaps we should say more about specifically which parts
> of RFC 5139 are relevant here (particularly for the "as defined in" statement)?
Since this talks about the ruleset, we could really just say “country” and make the 5139 reference to the civic address elements:
     The term Civic Location applies to a set of one or
     more Civic Address Elements as defined in [RFC5139] that are used in conjunction with each
     other, and in accordance with a known ruleset to designate a
     specific place within a country

The only issue with that is that country is one of the Civic Address Elements.  I think that’s okay for this document.
> 
>   Complete Location:  An expanded civic location that includes other
>      Civic Address Elements in addition to the existing validated Civic
>      Address Elements provided as input to a LoST server.  Complete
>      Location may be returned when the input location is valid but
>      incomplete
> 
> This definition seems to be purely observational, relying on the LoST
> server providing more elements than were supplied to it, without any
> mention of why the server would do so or what information the new elements
> might contain.  In other words, in what sense is this "complete”?
The “may be returned when the input location is valid but incomplete” is supposed to tell the reader why it might be useful.  The document does have examples. I could add “such as when an important element is missing, but the provided elements still identify a unique location”

> 
> Also, we don't define what "incomplete" or an "incomplete location" is…
But we also don’t use those terms.
-
> 
> Section 7
> 
> We do pretty clearly state earlier that "the client cannot assume that any
> [of the response locations] is the correct location", so I'm on the fence
> about whether there's value in restating here that "though the intent of
> this extension is to allow the LoST server to provide more accurate
> location information to the client, only the client is in a position to
> assess whether the response accurately reflects the intended location; in
> particular, the client cannot assume that any of the returned locations is
> the correct one without performing its own validation”.
Yeah, it’s redundant, but I’d rather keep it.

> 
>                                 Providing more CAtypes generally
>   doesn't actually reveal anything more.  [...]
> 
> The main route to a potential exception of the "generally" qualifier here
> would be if the LoST server somehow had particularly sensitive or
> non-public information in its database (but I can't come up with any
> particularly plausible examples of that at the moment).  That said, this
> sentence also reads a bit strangely to me, so I might consider
> NEW:
> % Providing more CAtypes generally doesn't actually reveal anything more
> % than the unique location of the address in question, unless the LoST
> % server has particularly sensitive or non-address information in its
> % database.
There is no defined use case of a LoST server containing non-address information (other than the URIs and other data that are associated with the address information which the LoST server returns when given an address).  There are some circumstances where there could be sensitive location information (say, address data in a sensitive military facility where local authorities still respond to some kinds of emergency calls).  However, the extension doesn’t make any of that more sensitive or provide any other data that isn’t reasonably guessable.  That’s an argument for not including the second sentence in your proposed new text.  
> 
> 
> NITS
> 
> Section 1
> 
>                                      The use of this protocol extension
>   facilitates the timely correction of errors, and allows location
>   servers to be more easily provisioned with complete address
>   information.
> 
> I'm a little confused at how specifically this extension allows *location
> servers* to be more easily *provisioned* with complete address
> information.  I would have thought that rather it allows location servers
> to more readily *provide* complete address information to location
> consumers.  Am I misunderstanding the LoST protocol flow?
You use LoST’s validation function when you load an address in a Location Information Server (LIS).  You do that to make sure that any address you keep in the LIS is valid.
The easy use case is a consumer orders a new landline phone service.  The database that holds the address that would be associated with the phone number of the subscriber for emergency calls is a LIS.  The address is validated as the LIS is provisioned with the address.  That will assure that it’s valid before any emergency call is placed.

> 
> Section 4
> 
>   These elements MAY contain location information either in the Basic
>   Civic profile defined in [RFC5222] or in another profile whose
>   definition provides instructions concerning its use with this
>   extension but this MUST be the same profile as the location in the
>   query.  [...]
> 
> I think a comma or other punctuation before "but" would aid readability.
Will do
> 
> 
>