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

Francesca Palombini via Datatracker <noreply@ietf.org> Wed, 02 March 2022 16:17 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 A85B23A0BFB; Wed, 2 Mar 2022 08:17:15 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Francesca Palombini 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: Francesca Palombini <francesca.palombini@ericsson.com>
Message-ID: <164623783560.17994.7272285681906239949@ietfa.amsl.com>
Date: Wed, 02 Mar 2022 08:17:15 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/ecrit/wdaBUKD1JWCunnyr8SdL75C8AYc>
Subject: [Ecrit] Francesca Palombini'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: Wed, 02 Mar 2022 16:17:16 -0000

Francesca Palombini 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:
----------------------------------------------------------------------

Thank you for the work on this document

Many thanks to Claudio Allocchio for his ART ART review:
https://mailarchive.ietf.org/arch/msg/art/gTqJGjkpYHmcYZPoX1oTvPqC_Zg/.

I only have one comment on two uses of SHOULD in the text.

Francesca

1. -----

   call, it might not be as desirable for other services.  Individual
   LoST server implementations SHOULD consider the risk of releasing
   more detail versus the value in doing so.  Generally, supplying more

   LoST server implementations SHOULD evaluate the particular use cases
   where this extension is supported, and weigh the risks around its
   use.

FP: I believe the use of BCP 14 SHOULD is inappropriate here - these statements
are not for interoperability, and as 2119 states, BCP 14 terms must only be
used where it is actually required for interoperation or to limit behavior
which has potential for causing harm. "SHOULD consider" and "SHOULD evaluate"
fall out of this case. Replacing SHOULD with "should" or "ought to" would be my
choice.