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

Benjamin Kaduk <kaduk@mit.edu> Fri, 04 March 2022 22:05 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: ecrit@ietfa.amsl.com
Delivered-To: ecrit@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E17FB3A10EB; Fri, 4 Mar 2022 14:05:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.721
X-Spam-Level:
X-Spam-Status: No, score=-1.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.186, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AQv_DnXdJU9E; Fri, 4 Mar 2022 14:05:03 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC5673A10E7; Fri, 4 Mar 2022 14:05:02 -0800 (PST)
Received: from mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 224M4qhV023291 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 4 Mar 2022 17:04:58 -0500
Date: Fri, 04 Mar 2022 14:04:52 -0800
From: Benjamin Kaduk <kaduk@mit.edu>
To: Brian Rosen <br@brianrosen.net>
Cc: The IESG <iesg@ietf.org>, draft-ietf-ecrit-similar-location@ietf.org, ecrit-chairs@ietf.org, ecrit@ietf.org, dwightpurtle@gmail.com
Message-ID: <20220304220452.GA22457@mit.edu>
References: <164608019887.14867.9078735069677970948@ietfa.amsl.com> <F6617978-7A12-463D-8F79-FC8D26E10F3C@brianrosen.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <F6617978-7A12-463D-8F79-FC8D26E10F3C@brianrosen.net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ecrit/AhIt5is-NmpL26VDnQO6ckvcE_w>
Subject: Re: [Ecrit] Benjamin Kaduk's No Objection on draft-ietf-ecrit-similar-location-18: (with COMMENT)
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Emergency Context Resolution with Internet Technologies <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ecrit/>
List-Post: <mailto:ecrit@ietf.org>
List-Help: <mailto:ecrit-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 04 Mar 2022 22:05:06 -0000

Hi Brian,

Also inline...

On Wed, Mar 02, 2022 at 02:12:55PM -0500, Brian Rosen wrote:
> Thanks for the careful review of this document.
> 
> Comments inline
> 
> > On Feb 28, 2022, at 3:29 PM, Benjamin Kaduk via Datatracker <noreply@ietf.org> 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.

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

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

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

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

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.

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

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.

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

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.)

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

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

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