[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.
- [Ecrit] Benjamin Kaduk's No Objection on draft-ie… Benjamin Kaduk via Datatracker
- Re: [Ecrit] Benjamin Kaduk's No Objection on draf… Brian Rosen
- Re: [Ecrit] Benjamin Kaduk's No Objection on draf… Randall Gellens
- Re: [Ecrit] Benjamin Kaduk's No Objection on draf… Randall Gellens
- Re: [Ecrit] Benjamin Kaduk's No Objection on draf… Benjamin Kaduk