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

From: Brian Rosen <[email-masked]>
Date: Wed, 2 Mar 2022 14:12:55 -0500

Thanks for the careful review of this document.

Comments inline

> On Feb 28, 2022, at 3:29 PM, Benjamin Kaduk via Datatracker <[email-masked]> 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

---

From: "Randall Gellens" <[email-masked]>
Date: Wed, 02 Mar 2022 10:34:26 -0800

Please see inline.

--Randall

On 28 Feb 2022, at 12:29, Benjamin Kaduk via Datatracker wrote:

> Please refer to 
> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/

The draft does define POD but not STS. Maybe it would be helpful to add 
a reference to RFC 4119 (which defines STS, POD, and others) to the 
definition of Civic Location?

> might contain.  In other words, in what sense is this "complete"?

It might be helpful to add a definition of Incomplete Location, such as 
"A Civic Location that the LoST server considers valid but which omits 
one or more Civic Address Elements that the LoST server considers 
necessary or helpful." The definition of Complete Location could then be 
reworded to reference it, e.g.,:

    A Civic Location that was considered by the LoST server to be an
    Incomplete Location but that with the addition of one or more
    Civic Address Elements is considered complete by the LoST server.

>
> Also, we don't define what "incomplete" or an "incomplete location" 
> is...
>
> Section 7
>
> the correct one without performing its own validation".

You're saying that there's a security risk if a LoST client were to 
blindly assume that a returned Complete Location or Similar Location is 
correct? I suppose it wouldn't hurt to say that, but I don't think it 
warrants more than a very few words.

> consumers.  Am I misunderstanding the LoST protocol flow?

I think the confusion stems from the draft's use of "location servers" 
when I think it would be more clear to say "LoST clients." The 
assumption is that this extension will primarily be used by Location 
Information Server (LIS) services that e.g., maintain civic address 
information for customers of a voice service, and "location server" was 
used to refer to that class of LoST client. I think the draft should 
just say "LoST client".

> I think a comma or other punctuation before "but" would aid 

I suggest replacing the "but" with a semicolon.

---

From: "Randall Gellens" <[email-masked]>
Date: Wed, 02 Mar 2022 11:19:05 -0800

> 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 use cases for non-public LoST servers (e.g., the 
Service/Agency Location), but those wouldn't be accessible without 
credentials, and such use cases are entirely separate from 
similar/complete civic location service in this document.

--Randall

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 4 Mar 2022 14:04:52 -0800

Hi Brian,

Also inline...

> I’ll add a reference to RFC4776 that has these.

Randall suggested 4119, which looks like it would also work (but just one
of the two will be plenty)

> The only issue with that is that country is one of the Civic Address Elements.  I think that’s okay for this document.

Ignoring that issue for this document seems okay to me as well, and I think
the proposed update is a good clarification.

> 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…

I did figure out what was intended eventually, with the help of examples,
but definition-by-example is something of an antipattern in any kind of
formal specification.  Randall's suggestion in his first reply seemed
promising to me, so I'd be interested to hear your thoughts on it.

> Yeah, it’s redundant, but I’d rather keep it.

To be clear, "leave the text as-is" is fine with me.  I am not sure my
point came through as intended, though, as my proposal was to *add* some
redundant text (to be able to include a topic in the security
considerations section) rather than to remove some already-existing
redundant text.

> 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 w…

I agree that that's an argument to not include the last part of my
suggestion.  Basically this was just me looking for potential edge cases
and trying to identify them clearly, since edge cases are more likely to be
sources of security issues than expected cases.  (But of course, not all
edge cases lead to security issues, and your analysis of this one is a
useful conversation to have even if the result is that no text is added to
the document.)

> 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 L…

Randall's reply here also was helpful to me; I think I was looking at the
phrase "location server" and inferring "LoST server" rather than "location
information server", which is a well-defined term in (the union of this
document and its normative references) -- "location server", if I remember
correctly, is not.  So it sounds like picking one of LIS and LoST Client to
use here instead of "location server" would be a good change.

Thanks for all the updates and explanations,

Ben