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

Benjamin Kaduk via Datatracker <noreply@ietf.org> Mon, 28 February 2022 20:29 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: ecrit@ietf.org
Delivered-To: ecrit@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DBEA83A14C5; Mon, 28 Feb 2022 12:29:58 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-ecrit-similar-location@ietf.org, ecrit-chairs@ietf.org, ecrit@ietf.org, dwightpurtle@gmail.com, dwightpurtle@gmail.com
X-Test-IDTracker: no
X-IETF-IDTracker: 7.46.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Benjamin Kaduk <kaduk@mit.edu>
Message-ID: <164608019887.14867.9078735069677970948@ietfa.amsl.com>
Date: Mon, 28 Feb 2022 12:29:58 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/ecrit/oaNn0qdcf2tzkEhsV0xejQfH4Lk>
Subject: [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
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: Mon, 28 Feb 2022 20:29:59 -0000

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

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

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

Also, we don't define what "incomplete" or an "incomplete location" is...

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

                                 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.


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?

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.