Re: [Ecrit] [Last-Call] Genart last call review of draft-ietf-ecrit-similar-location-17

Lars Eggert <lars@eggert.org> Tue, 01 March 2022 13:37 UTC

Return-Path: <lars@eggert.org>
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 0814B3A0933; Tue, 1 Mar 2022 05:37:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.227
X-Spam-Level: *
X-Spam-Status: No, score=1.227 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_SBL_CSS=3.335, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eggert.org
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 SFWN_DAWxSSf; Tue, 1 Mar 2022 05:37:51 -0800 (PST)
Received: from mail.eggert.org (mail.eggert.org [IPv6:2a00:ac00:4000:400:211:32ff:fe22:186f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3ABF53A0942; Tue, 1 Mar 2022 05:37:51 -0800 (PST)
Received: from smtpclient.apple (unknown [195.65.18.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.eggert.org (Postfix) with ESMTPSA id 0BA991D3383; Tue, 1 Mar 2022 15:37:33 +0200 (EET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eggert.org; s=dkim; t=1646141854; bh=NFdYpftD0lyGWnUWaJlyH+V5XdF7waDyHEnDJOfmLw4=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=B1L8YJq0uzLhJ16rTeU7euhWarIPiSaNbjPZ3yhcULMuN5dMlNER1V3BcMFrlSEvX uOmaWakQmNVXsXfaw0Hic7+983CKH1gntU4/qGG0ZNEKkHByqSmW9PP9V6njoqfLis qokJFxCIyzLMLYPj1NG5aeDi1i0SQoPgkFvi3OW4=
Content-Type: multipart/signed; boundary="Apple-Mail=_81BFAEB5-3AD4-483E-8A11-554F46900C36"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.60.0.1.1\))
From: Lars Eggert <lars@eggert.org>
In-Reply-To: <164350445633.30531.10572441517907261963@ietfa.amsl.com>
Date: Tue, 01 Mar 2022 14:37:33 +0100
Cc: gen-art@ietf.org, last-call@ietf.org, ecrit@ietf.org, draft-ietf-ecrit-similar-location.all@ietf.org
Message-Id: <ED43814B-DCE3-4B5A-A33D-9B5F5ED5E3E3@eggert.org>
References: <164350445633.30531.10572441517907261963@ietfa.amsl.com>
To: Russ Housley <housley@vigilsec.com>
X-MailScanner-ID: 0BA991D3383.A2E6C
X-MailScanner: Not scanned: please contact your Internet E-Mail Service Provider for details
X-MailScanner-From: lars@eggert.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/ecrit/UMguD660s9lVdzIgbZdHc_8pQL4>
Subject: Re: [Ecrit] [Last-Call] Genart last call review of draft-ietf-ecrit-similar-location-17
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: Tue, 01 Mar 2022 13:37:56 -0000

Russ, thank you for your review. I have entered a No Objection ballot for this document.

Lars


> On 2022-1-30, at 2:00, Russ Housley via Datatracker <noreply@ietf.org> wrote:
> 
> Reviewer: Russ Housley
> Review result: Almost Ready
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair. Please wait for direction from your
> document shepherd or AD before posting a new version of the draft.
> 
> For more information, please see the FAQ at
> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
> 
> Document: draft-ietf-ecrit-similar-location-17
> Reviewer: Russ Housley
> Review Date: 2022-01-29
> IETF LC End Date: 2022-02-09
> IESG Telechat date: unknown
> 
> Summary: Almost Ready
> 
> 
> Major Concerns:  None
> 
> 
> Minor Concerns:
> 
> The Abstract could be much shorter.  I suggest:
> 
>   This document describes an extension to the LoST protocol that is
>   specified in RFC 5222 that allows additional civic location
>   information to be returned in the <locationValidation> element of a
>   <findServiceResponse>.  This extension supports two use cases. First,
>   when the input location is incomplete, the LoST server can provide a
>   complete intended unique address.  Second, when the input location is
>   invalid, the LoST server can identify one or more feasible locations.
>   This extension is applicable when the location information in the
>   <findService> request uses the Basic Civic profile as described in
>   RFC 5222.
> 
> Section 1 says:
> 
>   ...  Use of this
>   enhancement increases the likelihood that the correct and/or complete
>   form of a civic location becomes known in those cases where it is
>   incomplete or incorrect.
> 
> I think it would be more clear to turn the sentence around:
> 
>   ...  When incomplete or incorrect civic location information
>   is provided, use of this enhancement increases the likelihood
>   that correct and complete civic location can be learned.
> 
> Section 1 ends with a discussion about what the document contains, but
> it is incomplete.  Either drop the paragraph, or tell what is coming in
> all of the coming sections.
> 
> Section 3 says:
> 
>   ...  A server MUST NOT include Returned Location
>   Information using a location profile that differs from the profile of
>   the location used to answer the query and, by extension, MUST NOT
>   include Returned Location Information using a location profile that
>   was not used by the client in the request.
> 
> Can this be turned into a simple MUST statement?  Perhaps:
> 
>   ...  A server MUST include only Returned Location
>   Information using a location profile that was used by the
>   client in the request.
> 
> Section 3 says:
> 
>   In a LoST <findServiceResponse> indicating a Valid Location i.e.,
>   containing the <locationValidation> element with no elements listed
>   as invalid, the LoST server can use this extension to include
>   additional location information in a <locationValidation> element.
> 
> I think this would be more clear if it defined a Valid Location, and
> then use this definition:
> 
>   A Valid Location contains a <locationValidation> element without any
>   elements listed as invalid.  In a LoST <findServiceResponse>
>   indicating a Valid Location, the LoST server can use this extension
>   to include additional location information in a <locationValidation>
>   element.
> 
> 
> Nits:
> 
> Section 2: s/here.  ./here./
> 
> Section 2: Some definitions end with a period, but one does not.
> Please add the missing period.
> 
> Section 3: s/end-user/end user/
> 
> Section 3: s/intended by the user/intended by the end user/
> 
> Section 4: s/defined in RFC5222/defined in [RFC5222]/
> 
> Section 7: s/new threat/new security concern/
> 
> 
> 
> --
> last-call mailing list
> last-call@ietf.org
> https://www.ietf.org/mailman/listinfo/last-call