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
- [Ecrit] Genart last call review of draft-ietf-ecr… Russ Housley via Datatracker
- Re: [Ecrit] Genart last call review of draft-ietf… Dan Banks
- Re: [Ecrit] Genart last call review of draft-ietf… Randall Gellens
- Re: [Ecrit] [Last-Call] Genart last call review o… Russ Housley
- Re: [Ecrit] [Last-Call] Genart last call review o… Lars Eggert