From nobody Tue Feb  1 07:00:19 2022
Return-Path: <housley@vigilsec.com>
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 D14873A1174; Tue,  1 Feb 2022 07:00:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NONE=0.001] autolearn=ham autolearn_force=no
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 gjftCnCjf30E; Tue,  1 Feb 2022 07:00:13 -0800 (PST)
Received: from mail3.g24.pair.com (mail3.g24.pair.com [66.39.134.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF8023A117A; Tue,  1 Feb 2022 07:00:13 -0800 (PST)
Received: from mail3.g24.pair.com (localhost [127.0.0.1]) by mail3.g24.pair.com (Postfix) with ESMTP id 070CDD48EF; Tue,  1 Feb 2022 10:00:11 -0500 (EST)
Received: from [192.168.1.161] (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail3.g24.pair.com (Postfix) with ESMTPSA id E181AD4670; Tue,  1 Feb 2022 10:00:10 -0500 (EST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\))
From: Russ Housley <housley@vigilsec.com>
In-Reply-To: <B2B4054F-C543-4B7D-B77F-5079A72D87EC@coretechnologyconsulting.com>
Date: Tue, 1 Feb 2022 10:00:09 -0500
Cc: last-call@ietf.org, IETF Gen-ART <gen-art@ietf.org>, ecrit@ietf.org, draft-ietf-ecrit-similar-location.all@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <23AA425C-1B5C-4403-92F2-9E3CC7AA1EA4@vigilsec.com>
References: <164350445633.30531.10572441517907261963@ietfa.amsl.com> <B2B4054F-C543-4B7D-B77F-5079A72D87EC@coretechnologyconsulting.com>
To: Randall Gellens <rg+ietf@coretechnologyconsulting.com>
X-Mailer: Apple Mail (2.3445.104.21)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ecrit/qa1ZPU98upaAt5EBkKck2hN1H4k>
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 Feb 2022 15:00:18 -0000

Randall:

This direction seem fine to me, but I think you misunderstood my =
suggestion (4).  I am just suggesting a change in ordering,  State the =
definition, and then use the defined term.

Russ


> On Jan 31, 2022, at 5:59 PM, Randall Gellens =
<rg+ietf@coretechnologyconsulting.com> wrote:
>=20
> (1) I'm fine with the Abstract as it is, I don't think it needs to be =
shortened, but if Russ' suggestion is taken, I'd want his new text "This =
extension is applicable when the location information in the =
<findService> request uses the Basic Civic profile as described in RFC =
5222" deleted, as the extension can potentially be used with future =
profiles.
>=20
> (2) Regarding the suggestion to either delete the final paragraph of =
Section 1 or expand it to list all the sections, an alternative is to =
edit it down to list only what's most useful to a reader, e.g., change:
>=20
>   The structure of this document includes terminology, Section 2,
>   followed by a discussion of the basic elements involved in location
>   validation.  The use of these elements, by way of example, is
>   discussed in an overview section, Section 3, with accompanying
>   rationale, and a brief discussion of the impacts to LoST, and its
>   current schema.
>=20
> To something such as:
>=20
>   A discussion of the basic elements involved in location
>   validation, along with definitions of certain terms used in this
>   document, is in Section 2.  Usage, with examples, accompanying
>   rationale, and a brief discussion of the impacts to LoST and its
>   current schema, is in Section 3.
>=20
>=20
> (3) Regarding the MUST NOT text in Section 3, I'm fine with Dan's =
suggestions, but if we are rewording it, I suggest:
>=20
>   The location profile of Location Information returned by a server
>   MUST be the same as the profile of the location used to answer
>   the query. By extension, this means that the profile of Location
>   Information returned by a server MUST be a location profile used
>   by the client in the request.
>=20
> (4) Regarding the suggestion to add a definition of Valid Location, =
the document currently defines it; perhaps the suggestion is to define a =
new term such as "Valid Location Response" or "Valid Location =
Indication"? At any rate, since the document already defines Valid =
Location, we can just delete the explanatory:
>=20
>   i.e.,
>   containing the <locationValidation> element with no elements listed
>   as invalid,
>=20
> This also aligns with Dan's suggested rewording. I'm also fine with =
leaving the text as is.
>=20
> --Randall
>=20
> On 29 Jan 2022, at 17:00, Russ Housley via Datatracker wrote:
>=20
>> Reviewer: Russ Housley
>> Review result: Almost Ready
>>=20
>> 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.
>>=20
>> For more information, please see the FAQ at
>> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>>=20
>> 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
>>=20
>> Summary: Almost Ready
>>=20
>>=20
>> Major Concerns:  None
>>=20
>>=20
>> Minor Concerns:
>>=20
>> The Abstract could be much shorter.  I suggest:
>>=20
>>   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.
>>=20
>> Section 1 says:
>>=20
>>   ...  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.
>>=20
>> I think it would be more clear to turn the sentence around:
>>=20
>>   ...  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.
>>=20
>> 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.
>>=20
>> Section 3 says:
>>=20
>>   ...  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.
>>=20
>> Can this be turned into a simple MUST statement?  Perhaps:
>>=20
>>   ...  A server MUST include only Returned Location
>>   Information using a location profile that was used by the
>>   client in the request.
>>=20
>> Section 3 says:
>>=20
>>   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.
>>=20
>> I think this would be more clear if it defined a Valid Location, and
>> then use this definition:
>>=20
>>   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.
>>=20
>>=20
>> Nits:
>>=20
>> Section 2: s/here.  ./here./
>>=20
>> Section 2: Some definitions end with a period, but one does not.
>> Please add the missing period.
>>=20
>> Section 3: s/end-user/end user/
>>=20
>> Section 3: s/intended by the user/intended by the end user/
>>=20
>> Section 4: s/defined in RFC5222/defined in [RFC5222]/
>>=20
>> Section 7: s/new threat/new security concern/
>=20
> --=20
> last-call mailing list
> last-call@ietf.org
> https://www.ietf.org/mailman/listinfo/last-call


From nobody Wed Feb  2 16:14:06 2022
Return-Path: <rg+ietf@randy.pensive.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 04BB83A0D5E for <ecrit@ietfa.amsl.com>; Wed,  2 Feb 2022 16:14:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 yOuunoquAXg8 for <ecrit@ietfa.amsl.com>; Wed,  2 Feb 2022 16:14:00 -0800 (PST)
Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 0C3443A0D5B for <ecrit@ietf.org>; Wed,  2 Feb 2022 16:13:59 -0800 (PST)
Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Wed, 2 Feb 2022 16:13:59 -0800
From: "Randall Gellens" <rg+ietf@randy.pensive.org>
To: ECRIT <ecrit@ietf.org>
Date: Wed, 02 Feb 2022 16:13:57 -0800
X-Mailer: MailMate (1.13.2r5673)
Message-ID: <1CA21AC2-3722-481C-9437-A83451B03BC0@randy.pensive.org>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_MailMate_0805B13D-1DE3-4627-95DB-291DACE11F7C_="
Archived-At: <https://mailarchive.ietf.org/arch/msg/ecrit/i6pjscrIXflvqXWh_yHxYJcFtno>
Subject: [Ecrit] Resolving open issue in planned-changes
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: Thu, 03 Feb 2022 00:14:05 -0000

--=_MailMate_0805B13D-1DE3-4627-95DB-291DACE11F7C_=
Content-Type: text/plain; format=flowed; markup=markdown
Content-Transfer-Encoding: quoted-printable

Regarding the planned-changes draft, notification vs polling is the =

primary open issue. The other issues that have been discussed are =

secondary and are different depending on which mechanism is selected.

As the next step in measuring consensus, the chairs want to identify =

technical objections to either mechanism. An important part of reaching =

consensus is making sure that all technical objections have been given =

appropriate consideration. Below is a summary of the objections that =

I've identified from the email list and the Doodle poll. If I've missed =

anything or left out anything crucial, please let me know.

---
**Doodle poll:**

- URL: =

https://doodle.com/poll/3krg2xh2yk3iww8r?utm_source=3Dpoll&utm_medium=3Dl=
ink
- Technical objection to polling: Gunnar, Guy
- Technical objection to notification: Dan Banks

**Dan:**
    Asking a LoST server to store information in response to a query =

creates an undue burden and presents multiple opportunities for abuse. =

It is also impractical for a LoST server to make the necessary =

determinations to support notifications.

**Gunnar:**
    Polling for rare events causes waste of resources. Planned-changes =

are expected to be rare per location.

---
**Email:**

**Objections to notification:**

**Jeff Martin**:
    Date: Thu, 9 Sep 2021 20:08:44 +0000
    Message-ID: =

<CO6PR09MB8600D17E58AECCC9E80C20889FD59@CO6PR09MB8600.namprd09.prod.outlo=
ok.com>
    Archive URL: =

https://mailarchive.ietf.org/arch/msg/ecrit/ZUQK2J_iZQvEo99JZFw3qAWQ0tg/

    "Asking a server to store and later user a client-provided uri opens =

the door for abuse by malicious actors."


**Dan Banks**:
    Date: Fri, 10 Sep 2021 16:13:17 +0000
    Message-ID: =

<DM5PR1701MB181841BF7E917A62D89BACD0A7D69@DM5PR1701MB1818.namprd17.prod.o=
utlook.com>
    Archive URL: =

https://mailarchive.ietf.org/arch/msg/ecrit/TRIHMZHi27yWKvJNbAh9hOCJcoc/

    "I am opposed to asking LoST servers to store URIs as well.  I =

believe it significantly overcomplicates the solution and is the biggest =

reason why I have not supported the planned changes draft."

    "Several years ago we implemented a mechanism to allow a LIS to know =

that it needs to revalidate."

    "Yes, the LIS has to poll the various LoST servers and ask if there =

have been any changes.  That is a cheap operation to implement, and the =

practical difference between knowing the very instant a change is =

published versus finding out within a few minutes is not significant in =

any way."


**Objections to polling**:

**Brian Rosen**:
    Date: Thu, 9 Sep 2021 17:14:54 -0400
    Message-Id: <68AD2A9E-FB9D-45B3-95CF-358C89D912CA@brianrosen.net>
    Archive URL: =

https://mailarchive.ietf.org/arch/msg/ecrit/Q_DcEcRvkPLYjVXjkcwcpcVj5hY/

    "sometimes, there is not a lot of planning.  The advantage to the =

notification is that it works immediately."

**Guy Caron**:
    Date: Mon, 13 Sep 2021 19:43:30 +0000
    Message-ID: <e616f4832db442c7bcaf883aba634188@bell.ca>
    Archive URL: =

https://mailarchive.ietf.org/arch/msg/ecrit/kke7q2UwZ2RoSxtkNAt3AFHAG44/

    "...there is no filtering based on the Clients being made; every =

Client gets the list of all upcoming changes. Further, it is yet another =

interface to support on the Server while the current mechanism leverages =

an existing one."

---
If I've left out anything crucial, or didn't accurately summarize your =

objection or omitted it, please let me know.


--Randall

--=_MailMate_0805B13D-1DE3-4627-95DB-291DACE11F7C_=
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html>
<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/xhtml; charset=3Dutf-8"=
>
</head>
<body>
<div style=3D"font-family:sans-serif"><div style=3D"white-space:normal">
<p dir=3D"auto">Regarding the planned-changes draft, notification vs poll=
ing is the primary open issue. The other issues that have been discussed =
are secondary and are different depending on which mechanism is selected.=
</p>

<p dir=3D"auto">As the next step in measuring consensus, the chairs want =
to identify technical objections to either mechanism. An important part o=
f reaching consensus is making sure that all technical objections have be=
en given appropriate consideration. Below is a summary of the objections =
that I've identified from the email list and the Doodle poll. If I've mis=
sed anything or left out anything crucial, please let me know.</p>

<hr style=3D"background:#333; background-image:linear-gradient(to right, =
#ccc, #333, #ccc); border:0; height:1px" height=3D"1">

<p dir=3D"auto"><strong>Doodle poll:</strong></p>

<ul>
<li>URL: <a href=3D"https://doodle.com/poll/3krg2xh2yk3iww8r?utm_source=3D=
poll&amp;utm_medium=3Dlink" style=3D"color:#3983C4">https://doodle.com/po=
ll/3krg2xh2yk3iww8r?utm_source=3Dpoll&amp;utm_medium=3Dlink</a></li>
<li>Technical objection to polling: Gunnar, Guy</li>
<li>Technical objection to notification: Dan Banks</li>
</ul>

<p dir=3D"auto"><strong>Dan:</strong><br>
   Asking a LoST server to store information in response to a query creat=
es an undue burden and presents multiple opportunities for abuse. It is a=
lso impractical for a LoST server to make the necessary determinations to=
 support notifications.</p>

<p dir=3D"auto"><strong>Gunnar:</strong><br>
   Polling for rare events causes waste of resources. Planned-changes are=
 expected to be rare per location.</p>

<hr style=3D"background:#333; background-image:linear-gradient(to right, =
#ccc, #333, #ccc); border:0; height:1px" height=3D"1">

<p dir=3D"auto"><strong>Email:</strong></p>

<p dir=3D"auto"><strong>Objections to notification:</strong></p>

<p dir=3D"auto"><strong>Jeff Martin</strong>:<br>
   Date: Thu, 9 Sep 2021 20:08:44 +0000<br>
   Message-ID: <a href=3D"mailto:CO6PR09MB8600D17E58AECCC9E80C20889FD59@C=
O6PR09MB8600.namprd09.prod.outlook.com" style=3D"color:#3983C4">CO6PR09MB=
8600D17E58AECCC9E80C20889FD59@CO6PR09MB8600.namprd09.prod.outlook.com</a>=
<br>
   Archive URL: <a href=3D"https://mailarchive.ietf.org/arch/msg/ecrit/ZU=
QK2J_iZQvEo99JZFw3qAWQ0tg/" style=3D"color:#3983C4">https://mailarchive.i=
etf.org/arch/msg/ecrit/ZUQK2J_iZQvEo99JZFw3qAWQ0tg/</a></p>

<p dir=3D"auto">"Asking a server to store and later user a client-provide=
d uri opens the door for abuse by malicious actors."</p>

<p dir=3D"auto"><strong>Dan Banks</strong>:<br>
   Date: Fri, 10 Sep 2021 16:13:17 +0000<br>
   Message-ID: <a href=3D"mailto:DM5PR1701MB181841BF7E917A62D89BACD0A7D69=
@DM5PR1701MB1818.namprd17.prod.outlook.com" style=3D"color:#3983C4">DM5PR=
1701MB181841BF7E917A62D89BACD0A7D69@DM5PR1701MB1818.namprd17.prod.outlook=
=2Ecom</a><br>
   Archive URL: <a href=3D"https://mailarchive.ietf.org/arch/msg/ecrit/TR=
IHMZHi27yWKvJNbAh9hOCJcoc/" style=3D"color:#3983C4">https://mailarchive.i=
etf.org/arch/msg/ecrit/TRIHMZHi27yWKvJNbAh9hOCJcoc/</a></p>

<p dir=3D"auto">"I am opposed to asking LoST servers to store URIs as wel=
l.  I believe it significantly overcomplicates the solution and is the bi=
ggest reason why I have not supported the planned changes draft."</p>

<p dir=3D"auto">"Several years ago we implemented a mechanism to allow a =
LIS to know that it needs to revalidate."</p>

<p dir=3D"auto">"Yes, the LIS has to poll the various LoST servers and as=
k if there have been any changes.  That is a cheap operation to implement=
, and the practical difference between knowing the very instant a change =
is published versus finding out within a few minutes is not significant i=
n any way."</p>

<p dir=3D"auto"><strong>Objections to polling</strong>:</p>

<p dir=3D"auto"><strong>Brian Rosen</strong>:<br>
   Date: Thu, 9 Sep 2021 17:14:54 -0400<br>
   Message-Id: <a href=3D"mailto:68AD2A9E-FB9D-45B3-95CF-358C89D912CA@bri=
anrosen.net" style=3D"color:#3983C4">68AD2A9E-FB9D-45B3-95CF-358C89D912CA=
@brianrosen.net</a><br>
   Archive URL: <a href=3D"https://mailarchive.ietf.org/arch/msg/ecrit/Q_=
DcEcRvkPLYjVXjkcwcpcVj5hY/" style=3D"color:#3983C4">https://mailarchive.i=
etf.org/arch/msg/ecrit/Q_DcEcRvkPLYjVXjkcwcpcVj5hY/</a></p>

<p dir=3D"auto">"sometimes, there is not a lot of planning.  The advantag=
e to the notification is that it works immediately."</p>

<p dir=3D"auto"><strong>Guy Caron</strong>:<br>
   Date: Mon, 13 Sep 2021 19:43:30 +0000<br>
   Message-ID: <a href=3D"mailto:e616f4832db442c7bcaf883aba634188@bell.ca=
" style=3D"color:#3983C4">e616f4832db442c7bcaf883aba634188@bell.ca</a><br=
>
   Archive URL: <a href=3D"https://mailarchive.ietf.org/arch/msg/ecrit/kk=
e7q2UwZ2RoSxtkNAt3AFHAG44/" style=3D"color:#3983C4">https://mailarchive.i=
etf.org/arch/msg/ecrit/kke7q2UwZ2RoSxtkNAt3AFHAG44/</a></p>

<p dir=3D"auto">"...there is no filtering based on the Clients being made=
; every Client gets the list of all upcoming changes. Further, it is yet =
another interface to support on the Server while the current mechanism le=
verages an existing one."</p>

<hr style=3D"background:#333; background-image:linear-gradient(to right, =
#ccc, #333, #ccc); border:0; height:1px" height=3D"1">

<p dir=3D"auto">If I've left out anything crucial, or didn't accurately s=
ummarize your objection or omitted it, please let me know.</p>

<p dir=3D"auto">--Randall</p>
</div>
</div>
</body>
</html>

--=_MailMate_0805B13D-1DE3-4627-95DB-291DACE11F7C_=--


From nobody Thu Feb  3 15:00:59 2022
Return-Path: <rg+ietf@randy.pensive.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 2DB163A0987 for <ecrit@ietfa.amsl.com>; Thu,  3 Feb 2022 15:00:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 T7pXL-AYvXat for <ecrit@ietfa.amsl.com>; Thu,  3 Feb 2022 15:00:53 -0800 (PST)
Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 602603A0981 for <ecrit@ietf.org>; Thu,  3 Feb 2022 15:00:53 -0800 (PST)
Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Thu, 3 Feb 2022 15:00:52 -0800
From: "Randall Gellens" <rg+ietf@randy.pensive.org>
To: ECRIT <ecrit@ietf.org>
Date: Thu, 03 Feb 2022 15:00:52 -0800
X-Mailer: MailMate (1.13.2r5673)
Message-ID: <794C93B0-0F88-4427-8FDE-9B1428D3F29E@randy.pensive.org>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_MailMate_3338A6C6-71D7-4609-9041-E51410FC85D4_="
Archived-At: <https://mailarchive.ietf.org/arch/msg/ecrit/GU93pS2Pe4CC4mAMkc6bzmVN3UI>
Subject: [Ecrit] [updated] Resolving open issue in planned-changes
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: Thu, 03 Feb 2022 23:00:58 -0000

--=_MailMate_3338A6C6-71D7-4609-9041-E51410FC85D4_=
Content-Type: text/plain; format=flowed; markup=markdown
Content-Transfer-Encoding: quoted-printable

Regarding the planned-changes draft, notification vs polling is the =

primary open issue. The other issues that have been discussed are =

secondary and are different depending on which mechanism is selected.

As the next step in measuring consensus, the chairs want to identify =

technical objections to either mechanism. An important part of reaching =

consensus is making sure that all technical objections have been given =

appropriate consideration. Below is a summary of the objections that =

I've identified from the email list and the Doodle poll. If I've missed =

anything or left out anything crucial, please let me know.

---
**Doodle poll:**

- URL: =

https://doodle.com/poll/3krg2xh2yk3iww8r?utm_source=3Dpoll&utm_medium=3Dl=
ink
- Technical objection to polling: Gunnar, Guy
- Technical objection to notification: Dan Banks

**Dan:**
    Asking a LoST server to store information in response to a query =

creates an undue burden and presents multiple opportunities for abuse. =

It is also impractical for a LoST server to make the necessary =

determinations to support notifications.

**Jeff**
    Requiring a server to store and later use a client-provided uri =

opens the door for abuse by malicious actors.

**Gunnar:**
    Polling for rare events causes waste of resources. Planned-changes =

are expected to be rare per location.

---
**Email:**

**Objections to notification:**

**Jeff Martin**:
    Date: Thu, 9 Sep 2021 20:08:44 +0000
    Message-ID: =

<CO6PR09MB8600D17E58AECCC9E80C20889FD59@CO6PR09MB8600.namprd09.prod.outlo=
ok.com>
    Archive URL: =

https://mailarchive.ietf.org/arch/msg/ecrit/ZUQK2J_iZQvEo99JZFw3qAWQ0tg/

    "Asking a server to store and later use a client-provided uri opens =

the door for abuse by malicious actors."


**Dan Banks**:
    Date: Fri, 10 Sep 2021 16:13:17 +0000
    Message-ID: =

<DM5PR1701MB181841BF7E917A62D89BACD0A7D69@DM5PR1701MB1818.namprd17.prod.o=
utlook.com>
    Archive URL: =

https://mailarchive.ietf.org/arch/msg/ecrit/TRIHMZHi27yWKvJNbAh9hOCJcoc/

    "I am opposed to asking LoST servers to store URIs as well.  I =

believe it significantly overcomplicates the solution and is the biggest =

reason why I have not supported the planned changes draft."

    "Several years ago we implemented a mechanism to allow a LIS to know =

that it needs to revalidate."

    "Yes, the LIS has to poll the various LoST servers and ask if there =

have been any changes.  That is a cheap operation to implement, and the =

practical difference between knowing the very instant a change is =

published versus finding out within a few minutes is not significant in =

any way."


**Objections to polling**:

**Brian Rosen**:
    Date: Thu, 9 Sep 2021 17:14:54 -0400
    Message-Id: <68AD2A9E-FB9D-45B3-95CF-358C89D912CA@brianrosen.net>
    Archive URL: =

https://mailarchive.ietf.org/arch/msg/ecrit/Q_DcEcRvkPLYjVXjkcwcpcVj5hY/

    "sometimes, there is not a lot of planning.  The advantage to the =

notification is that it works immediately."

**Guy Caron**:
    Date: Mon, 13 Sep 2021 19:43:30 +0000
    Message-ID: <e616f4832db442c7bcaf883aba634188@bell.ca>
    Archive URL: =

https://mailarchive.ietf.org/arch/msg/ecrit/kke7q2UwZ2RoSxtkNAt3AFHAG44/

    "...there is no filtering based on the Clients being made; every =

Client gets the list of all upcoming changes. Further, it is yet another =

interface to support on the Server while the current mechanism leverages =

an existing one."

---
If I've left out anything crucial, or didn't accurately summarize your =

objection or omitted it, please let me know.


--Randall

--=_MailMate_3338A6C6-71D7-4609-9041-E51410FC85D4_=
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html>
<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/xhtml; charset=3Dutf-8"=
>
</head>
<body>
<div style=3D"font-family:sans-serif"><div style=3D"white-space:normal">
<p dir=3D"auto">Regarding the planned-changes draft, notification vs poll=
ing is the primary open issue. The other issues that have been discussed =
are secondary and are different depending on which mechanism is selected.=
</p>

<p dir=3D"auto">As the next step in measuring consensus, the chairs want =
to identify technical objections to either mechanism. An important part o=
f reaching consensus is making sure that all technical objections have be=
en given appropriate consideration. Below is a summary of the objections =
that I've identified from the email list and the Doodle poll. If I've mis=
sed anything or left out anything crucial, please let me know.</p>

<hr style=3D"background:#333; background-image:linear-gradient(to right, =
#ccc, #333, #ccc); border:0; height:1px" height=3D"1">

<p dir=3D"auto"><strong>Doodle poll:</strong></p>

<ul>
<li>URL: <a href=3D"https://doodle.com/poll/3krg2xh2yk3iww8r?utm_source=3D=
poll&amp;utm_medium=3Dlink" style=3D"color:#3983C4">https://doodle.com/po=
ll/3krg2xh2yk3iww8r?utm_source=3Dpoll&amp;utm_medium=3Dlink</a></li>
<li>Technical objection to polling: Gunnar, Guy</li>
<li>Technical objection to notification: Dan Banks</li>
</ul>

<p dir=3D"auto"><strong>Dan:</strong><br>
   Asking a LoST server to store information in response to a query creat=
es an undue burden and presents multiple opportunities for abuse. It is a=
lso impractical for a LoST server to make the necessary determinations to=
 support notifications.</p>

<p dir=3D"auto"><strong>Jeff</strong><br>
   Requiring a server to store and later use a client-provided uri opens =
the door for abuse by malicious actors.</p>

<p dir=3D"auto"><strong>Gunnar:</strong><br>
   Polling for rare events causes waste of resources. Planned-changes are=
 expected to be rare per location.</p>

<hr style=3D"background:#333; background-image:linear-gradient(to right, =
#ccc, #333, #ccc); border:0; height:1px" height=3D"1">

<p dir=3D"auto"><strong>Email:</strong></p>

<p dir=3D"auto"><strong>Objections to notification:</strong></p>

<p dir=3D"auto"><strong>Jeff Martin</strong>:<br>
   Date: Thu, 9 Sep 2021 20:08:44 +0000<br>
   Message-ID: <a href=3D"mailto:CO6PR09MB8600D17E58AECCC9E80C20889FD59@C=
O6PR09MB8600.namprd09.prod.outlook.com" style=3D"color:#3983C4">CO6PR09MB=
8600D17E58AECCC9E80C20889FD59@CO6PR09MB8600.namprd09.prod.outlook.com</a>=
<br>
   Archive URL: <a href=3D"https://mailarchive.ietf.org/arch/msg/ecrit/ZU=
QK2J_iZQvEo99JZFw3qAWQ0tg/" style=3D"color:#3983C4">https://mailarchive.i=
etf.org/arch/msg/ecrit/ZUQK2J_iZQvEo99JZFw3qAWQ0tg/</a></p>

<p dir=3D"auto">"Asking a server to store and later use a client-provided=
 uri opens the door for abuse by malicious actors."</p>

<p dir=3D"auto"><strong>Dan Banks</strong>:<br>
   Date: Fri, 10 Sep 2021 16:13:17 +0000<br>
   Message-ID: <a href=3D"mailto:DM5PR1701MB181841BF7E917A62D89BACD0A7D69=
@DM5PR1701MB1818.namprd17.prod.outlook.com" style=3D"color:#3983C4">DM5PR=
1701MB181841BF7E917A62D89BACD0A7D69@DM5PR1701MB1818.namprd17.prod.outlook=
=2Ecom</a><br>
   Archive URL: <a href=3D"https://mailarchive.ietf.org/arch/msg/ecrit/TR=
IHMZHi27yWKvJNbAh9hOCJcoc/" style=3D"color:#3983C4">https://mailarchive.i=
etf.org/arch/msg/ecrit/TRIHMZHi27yWKvJNbAh9hOCJcoc/</a></p>

<p dir=3D"auto">"I am opposed to asking LoST servers to store URIs as wel=
l.  I believe it significantly overcomplicates the solution and is the bi=
ggest reason why I have not supported the planned changes draft."</p>

<p dir=3D"auto">"Several years ago we implemented a mechanism to allow a =
LIS to know that it needs to revalidate."</p>

<p dir=3D"auto">"Yes, the LIS has to poll the various LoST servers and as=
k if there have been any changes.  That is a cheap operation to implement=
, and the practical difference between knowing the very instant a change =
is published versus finding out within a few minutes is not significant i=
n any way."</p>

<p dir=3D"auto"><strong>Objections to polling</strong>:</p>

<p dir=3D"auto"><strong>Brian Rosen</strong>:<br>
   Date: Thu, 9 Sep 2021 17:14:54 -0400<br>
   Message-Id: <a href=3D"mailto:68AD2A9E-FB9D-45B3-95CF-358C89D912CA@bri=
anrosen.net" style=3D"color:#3983C4">68AD2A9E-FB9D-45B3-95CF-358C89D912CA=
@brianrosen.net</a><br>
   Archive URL: <a href=3D"https://mailarchive.ietf.org/arch/msg/ecrit/Q_=
DcEcRvkPLYjVXjkcwcpcVj5hY/" style=3D"color:#3983C4">https://mailarchive.i=
etf.org/arch/msg/ecrit/Q_DcEcRvkPLYjVXjkcwcpcVj5hY/</a></p>

<p dir=3D"auto">"sometimes, there is not a lot of planning.  The advantag=
e to the notification is that it works immediately."</p>

<p dir=3D"auto"><strong>Guy Caron</strong>:<br>
   Date: Mon, 13 Sep 2021 19:43:30 +0000<br>
   Message-ID: <a href=3D"mailto:e616f4832db442c7bcaf883aba634188@bell.ca=
" style=3D"color:#3983C4">e616f4832db442c7bcaf883aba634188@bell.ca</a><br=
>
   Archive URL: <a href=3D"https://mailarchive.ietf.org/arch/msg/ecrit/kk=
e7q2UwZ2RoSxtkNAt3AFHAG44/" style=3D"color:#3983C4">https://mailarchive.i=
etf.org/arch/msg/ecrit/kke7q2UwZ2RoSxtkNAt3AFHAG44/</a></p>

<p dir=3D"auto">"...there is no filtering based on the Clients being made=
; every Client gets the list of all upcoming changes. Further, it is yet =
another interface to support on the Server while the current mechanism le=
verages an existing one."</p>

<hr style=3D"background:#333; background-image:linear-gradient(to right, =
#ccc, #333, #ccc); border:0; height:1px" height=3D"1">

<p dir=3D"auto">If I've left out anything crucial, or didn't accurately s=
ummarize your objection or omitted it, please let me know.</p>

<p dir=3D"auto">--Randall</p>
</div>
</div>
</body>
</html>

--=_MailMate_3338A6C6-71D7-4609-9041-E51410FC85D4_=--


From nobody Fri Feb  4 10:09:20 2022
Return-Path: <rg+ietf@randy.pensive.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 EE47F3A1DBB for <ecrit@ietfa.amsl.com>; Fri,  4 Feb 2022 10:09:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 4d2NvLt42f_K for <ecrit@ietfa.amsl.com>; Fri,  4 Feb 2022 10:08:56 -0800 (PST)
Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 7991B3A1DB6 for <ecrit@ietf.org>; Fri,  4 Feb 2022 10:08:56 -0800 (PST)
Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Fri, 4 Feb 2022 10:08:55 -0800
From: "Randall Gellens" <rg+ietf@randy.pensive.org>
To: ECRIT <ecrit@ietf.org>
Date: Fri, 04 Feb 2022 10:08:54 -0800
X-Mailer: MailMate (1.13.2r5673)
Message-ID: <D8AF83C0-EEB0-4DA4-A2E4-36BAACF4DA47@randy.pensive.org>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_MailMate_109C8BB2-2FD7-4F28-8ACE-E1CF8A4B8848_="
Archived-At: <https://mailarchive.ietf.org/arch/msg/ecrit/M_2khI7cJta_y-wwVNyPnbIAOnY>
Subject: [Ecrit] [2nd update] Resolving open issue in planned-changes
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: Fri, 04 Feb 2022 18:09:10 -0000

--=_MailMate_109C8BB2-2FD7-4F28-8ACE-E1CF8A4B8848_=
Content-Type: text/plain; format=flowed; markup=markdown
Content-Transfer-Encoding: quoted-printable

Regarding the planned-changes draft, notification vs polling is the =

primary open issue. The other issues that have been discussed are =

secondary and are different depending on which mechanism is selected.

As the next step in measuring consensus, the chairs want to identify =

technical objections to either mechanism. An important part of reaching =

consensus is making sure that all technical objections have been given =

appropriate consideration. Below is a summary of the objections that =

I've identified from the email list and the Doodle poll. If I've missed =

anything or left out anything crucial, please let me know.

---
**Doodle poll:**

- URL: =

https://doodle.com/poll/3krg2xh2yk3iww8r?utm_source=3Dpoll&utm_medium=3Dl=
ink
- Technical objection to polling: Gunnar, Guy
- Technical objection to notification: Dan Banks

**Dan:**
    Asking a LoST server to store information in response to a query =

creates an undue burden and presents multiple opportunities for abuse. =

It is also impractical for a LoST server to make the necessary =

determinations to support notifications.

**Jeff**
    Requiring a server to store and later use a client-provided uri =

opens the door for abuse by malicious actors.

**Gunnar:**
    Polling for rare events causes waste of resources. Planned-changes =

are expected to be rare per location.

---
**Email:**

**Objections to notification:**

**Jeff Martin**:
    Date: Thu, 9 Sep 2021 20:08:44 +0000
    Message-ID: =

<CO6PR09MB8600D17E58AECCC9E80C20889FD59@CO6PR09MB8600.namprd09.prod.outlo=
ok.com>
    Archive URL: =

https://mailarchive.ietf.org/arch/msg/ecrit/ZUQK2J_iZQvEo99JZFw3qAWQ0tg/

    "Asking a server to store and later use a client-provided uri opens =

the door for abuse by malicious actors."


**Dan Banks**:
    Date: Fri, 10 Sep 2021 16:13:17 +0000
    Message-ID: =

<DM5PR1701MB181841BF7E917A62D89BACD0A7D69@DM5PR1701MB1818.namprd17.prod.o=
utlook.com>
    Archive URL: =

https://mailarchive.ietf.org/arch/msg/ecrit/TRIHMZHi27yWKvJNbAh9hOCJcoc/

    "I am opposed to asking LoST servers to store URIs as well.  I =

believe it significantly overcomplicates the solution and is the biggest =

reason why I have not supported the planned changes draft."

    "Several years ago we implemented a mechanism to allow a LIS to know =

that it needs to revalidate."

    "Yes, the LIS has to poll the various LoST servers and ask if there =

have been any changes.  That is a cheap operation to implement, and the =

practical difference between knowing the very instant a change is =

published versus finding out within a few minutes is not significant in =

any way."


**Objections to polling**:

**Brian Rosen**:
    Date: Thu, 9 Sep 2021 17:14:54 -0400
    Message-Id: <68AD2A9E-FB9D-45B3-95CF-358C89D912CA@brianrosen.net>
    Archive URL: =

https://mailarchive.ietf.org/arch/msg/ecrit/Q_DcEcRvkPLYjVXjkcwcpcVj5hY/

    "sometimes, there is not a lot of planning.  The advantage to the =

notification is that it works immediately."

**Guy Caron**:
    Date: Mon, 13 Sep 2021 19:43:30 +0000
    Message-ID: <e616f4832db442c7bcaf883aba634188@bell.ca>
    Archive URL: =

https://mailarchive.ietf.org/arch/msg/ecrit/kke7q2UwZ2RoSxtkNAt3AFHAG44/

    "...there is no filtering based on the Clients being made; every =

Client gets the list of all upcoming changes. Further, it is yet another =

interface to support on the Server while the current mechanism leverages =

an existing one."

**Guy Caron**:
    Date: Tue, 14 Dec 2021 19:05:31 +0000
    Message-ID: <f089c820be53407ca93aefa7c68bbde7@bell.ca>
    Archive URL: =

https://mailarchive.ietf.org/arch/msg/ecrit/PgLf0saWkI_s_oBJq3lreQzgniI/#=


    "the original request that initiate this draft in the first place =

was to move away from blind polling of a LoST Server for validation =

requests. The new proposal moves us right back where we started."

---
If I've left out anything crucial, or didn't accurately summarize your =

objection or omitted it, please let me know.


--Randall

--=_MailMate_109C8BB2-2FD7-4F28-8ACE-E1CF8A4B8848_=
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html>
<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/xhtml; charset=3Dutf-8"=
>
</head>
<body>
<div style=3D"font-family:sans-serif"><div style=3D"white-space:normal">
<p dir=3D"auto">Regarding the planned-changes draft, notification vs poll=
ing is the primary open issue. The other issues that have been discussed =
are secondary and are different depending on which mechanism is selected.=
</p>

<p dir=3D"auto">As the next step in measuring consensus, the chairs want =
to identify technical objections to either mechanism. An important part o=
f reaching consensus is making sure that all technical objections have be=
en given appropriate consideration. Below is a summary of the objections =
that I've identified from the email list and the Doodle poll. If I've mis=
sed anything or left out anything crucial, please let me know.</p>

<hr style=3D"background:#333; background-image:linear-gradient(to right, =
#ccc, #333, #ccc); border:0; height:1px" height=3D"1">

<p dir=3D"auto"><strong>Doodle poll:</strong></p>

<ul>
<li>URL: <a href=3D"https://doodle.com/poll/3krg2xh2yk3iww8r?utm_source=3D=
poll&amp;utm_medium=3Dlink" style=3D"color:#3983C4">https://doodle.com/po=
ll/3krg2xh2yk3iww8r?utm_source=3Dpoll&amp;utm_medium=3Dlink</a></li>
<li>Technical objection to polling: Gunnar, Guy</li>
<li>Technical objection to notification: Dan Banks</li>
</ul>

<p dir=3D"auto"><strong>Dan:</strong><br>
   Asking a LoST server to store information in response to a query creat=
es an undue burden and presents multiple opportunities for abuse. It is a=
lso impractical for a LoST server to make the necessary determinations to=
 support notifications.</p>

<p dir=3D"auto"><strong>Jeff</strong><br>
   Requiring a server to store and later use a client-provided uri opens =
the door for abuse by malicious actors.</p>

<p dir=3D"auto"><strong>Gunnar:</strong><br>
   Polling for rare events causes waste of resources. Planned-changes are=
 expected to be rare per location.</p>

<hr style=3D"background:#333; background-image:linear-gradient(to right, =
#ccc, #333, #ccc); border:0; height:1px" height=3D"1">

<p dir=3D"auto"><strong>Email:</strong></p>

<p dir=3D"auto"><strong>Objections to notification:</strong></p>

<p dir=3D"auto"><strong>Jeff Martin</strong>:<br>
   Date: Thu, 9 Sep 2021 20:08:44 +0000<br>
   Message-ID: <a href=3D"mailto:CO6PR09MB8600D17E58AECCC9E80C20889FD59@C=
O6PR09MB8600.namprd09.prod.outlook.com" style=3D"color:#3983C4">CO6PR09MB=
8600D17E58AECCC9E80C20889FD59@CO6PR09MB8600.namprd09.prod.outlook.com</a>=
<br>
   Archive URL: <a href=3D"https://mailarchive.ietf.org/arch/msg/ecrit/ZU=
QK2J_iZQvEo99JZFw3qAWQ0tg/" style=3D"color:#3983C4">https://mailarchive.i=
etf.org/arch/msg/ecrit/ZUQK2J_iZQvEo99JZFw3qAWQ0tg/</a></p>

<p dir=3D"auto">"Asking a server to store and later use a client-provided=
 uri opens the door for abuse by malicious actors."</p>

<p dir=3D"auto"><strong>Dan Banks</strong>:<br>
   Date: Fri, 10 Sep 2021 16:13:17 +0000<br>
   Message-ID: <a href=3D"mailto:DM5PR1701MB181841BF7E917A62D89BACD0A7D69=
@DM5PR1701MB1818.namprd17.prod.outlook.com" style=3D"color:#3983C4">DM5PR=
1701MB181841BF7E917A62D89BACD0A7D69@DM5PR1701MB1818.namprd17.prod.outlook=
=2Ecom</a><br>
   Archive URL: <a href=3D"https://mailarchive.ietf.org/arch/msg/ecrit/TR=
IHMZHi27yWKvJNbAh9hOCJcoc/" style=3D"color:#3983C4">https://mailarchive.i=
etf.org/arch/msg/ecrit/TRIHMZHi27yWKvJNbAh9hOCJcoc/</a></p>

<p dir=3D"auto">"I am opposed to asking LoST servers to store URIs as wel=
l.  I believe it significantly overcomplicates the solution and is the bi=
ggest reason why I have not supported the planned changes draft."</p>

<p dir=3D"auto">"Several years ago we implemented a mechanism to allow a =
LIS to know that it needs to revalidate."</p>

<p dir=3D"auto">"Yes, the LIS has to poll the various LoST servers and as=
k if there have been any changes.  That is a cheap operation to implement=
, and the practical difference between knowing the very instant a change =
is published versus finding out within a few minutes is not significant i=
n any way."</p>

<p dir=3D"auto"><strong>Objections to polling</strong>:</p>

<p dir=3D"auto"><strong>Brian Rosen</strong>:<br>
   Date: Thu, 9 Sep 2021 17:14:54 -0400<br>
   Message-Id: <a href=3D"mailto:68AD2A9E-FB9D-45B3-95CF-358C89D912CA@bri=
anrosen.net" style=3D"color:#3983C4">68AD2A9E-FB9D-45B3-95CF-358C89D912CA=
@brianrosen.net</a><br>
   Archive URL: <a href=3D"https://mailarchive.ietf.org/arch/msg/ecrit/Q_=
DcEcRvkPLYjVXjkcwcpcVj5hY/" style=3D"color:#3983C4">https://mailarchive.i=
etf.org/arch/msg/ecrit/Q_DcEcRvkPLYjVXjkcwcpcVj5hY/</a></p>

<p dir=3D"auto">"sometimes, there is not a lot of planning.  The advantag=
e to the notification is that it works immediately."</p>

<p dir=3D"auto"><strong>Guy Caron</strong>:<br>
   Date: Mon, 13 Sep 2021 19:43:30 +0000<br>
   Message-ID: <a href=3D"mailto:e616f4832db442c7bcaf883aba634188@bell.ca=
" style=3D"color:#3983C4">e616f4832db442c7bcaf883aba634188@bell.ca</a><br=
>
   Archive URL: <a href=3D"https://mailarchive.ietf.org/arch/msg/ecrit/kk=
e7q2UwZ2RoSxtkNAt3AFHAG44/" style=3D"color:#3983C4">https://mailarchive.i=
etf.org/arch/msg/ecrit/kke7q2UwZ2RoSxtkNAt3AFHAG44/</a></p>

<p dir=3D"auto">"...there is no filtering based on the Clients being made=
; every Client gets the list of all upcoming changes. Further, it is yet =
another interface to support on the Server while the current mechanism le=
verages an existing one."</p>

<p dir=3D"auto"><strong>Guy Caron</strong>:<br>
   Date: Tue, 14 Dec 2021 19:05:31 +0000<br>
   Message-ID: <a href=3D"mailto:f089c820be53407ca93aefa7c68bbde7@bell.ca=
" style=3D"color:#3983C4">f089c820be53407ca93aefa7c68bbde7@bell.ca</a><br=
>
   Archive URL: <a href=3D"https://mailarchive.ietf.org/arch/msg/ecrit/Pg=
Lf0saWkI_s_oBJq3lreQzgniI/#" style=3D"color:#3983C4">https://mailarchive.=
ietf.org/arch/msg/ecrit/PgLf0saWkI_s_oBJq3lreQzgniI/#</a></p>

<p dir=3D"auto">"the original request that initiate this draft in the fir=
st place was to move away from blind polling of a LoST Server for validat=
ion requests. The new proposal moves us right back where we started."</p>=


<hr style=3D"background:#333; background-image:linear-gradient(to right, =
#ccc, #333, #ccc); border:0; height:1px" height=3D"1">

<p dir=3D"auto">If I've left out anything crucial, or didn't accurately s=
ummarize your objection or omitted it, please let me know.</p>

<p dir=3D"auto">--Randall</p>
</div>
</div>
</body>
</html>

--=_MailMate_109C8BB2-2FD7-4F28-8ACE-E1CF8A4B8848_=--


From nobody Sun Feb  6 13:56:57 2022
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 BF7DC3A0E38; Sun,  6 Feb 2022 13:56:36 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Claudio Allocchio via Datatracker <noreply@ietf.org>
To: <art@ietf.org>
Cc: draft-ietf-ecrit-similar-location.all@ietf.org, ecrit@ietf.org, last-call@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.44.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <164418459665.11182.16534615518046717365@ietfa.amsl.com>
Reply-To: Claudio Allocchio <Claudio.Allocchio@garr.it>
Date: Sun, 06 Feb 2022 13:56:36 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/ecrit/ZOJoCe5VIN5nSoWAkl5qSWsUPj0>
Subject: [Ecrit] Artart last call review of draft-ietf-ecrit-similar-location-17
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: Sun, 06 Feb 2022 21:56:46 -0000

Reviewer: Claudio Allocchio
Review result: Ready with Issues

The document does not have major issues, so it can be considered "ready".
However the way the document is written is often very narrative, instead of
preferring schemas, diagrams etc. and this can sometimes confuse the
implementer while reading it. Here are my suggestions for improvement:

- the abstract can be shortened just to specify directly why we need this
extension - there are in section 3 cases where the sentence id a double
negative (a MUST NOT followed by a negative sentence). They are correct, but
may I suggest to turn them into a single positive (a MUST and a positive
sentence to follow) ? - a "query", "response" etc flow schema may help in
making sections 3 less narrative and more easy to read - all examples are just
"US centric" (e.g. using US style postal addresses): I would suggest
considering also examples take from other different postal addresses schema,
both to show how they fit into the schema itself - there are some typos/nits to
fix with a proof reading

all the best



From nobody Mon Feb  7 15:17:50 2022
Return-Path: <iana-shared@icann.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 38ED63A111E for <ecrit@ietfa.amsl.com>; Mon,  7 Feb 2022 15:17:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.628
X-Spam-Level: 
X-Spam-Status: No, score=-0.628 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, MISSING_HEADERS=1.021, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
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 am13O4gL2aaL for <ecrit@ietfa.amsl.com>; Mon,  7 Feb 2022 15:17:35 -0800 (PST)
Received: from smtp.lax.icann.org (smtp.lax.icann.org [IPv6:2620:0:2d0:201::1:81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17E7C3A0EFB for <ecrit@ietf.org>; Mon,  7 Feb 2022 15:17:32 -0800 (PST)
Received: from request4.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by smtp.lax.icann.org (Postfix) with ESMTP id 59CFDE087B; Mon,  7 Feb 2022 23:17:30 +0000 (UTC)
Received: by request4.lax.icann.org (Postfix, from userid 48) id 5373C2071C; Mon,  7 Feb 2022 23:17:30 +0000 (UTC)
RT-Owner: sabrina.tanamal
From: "Sabrina Tanamal via RT" <drafts-expert-review@iana.org>
Reply-To: drafts-expert-review@iana.org
In-Reply-To: <rt-4.4.3-30874-1644275659-1074.1224717-37-0@icann.org>
References: <RT-Ticket-1224717@icann.org> <rt-4.4.3-30874-1644275659-1074.1224717-37-0@icann.org>
Message-ID: <rt-4.4.3-30874-1644275850-1287.1224717-37-0@icann.org>
X-RT-Loop-Prevention: IANA
X-RT-Ticket: IANA #1224717
X-Managed-BY: RT 4.4.3 (http://www.bestpractical.com/rt/)
X-RT-Originator: sabrina.tanamal@icann.org
CC: mt@lowentropy.net, tbray@textuality.com, ecrit@ietf.org
Content-Type: text/plain; charset="utf-8"
X-RT-Original-Encoding: utf-8
Precedence: bulk
Date: Mon, 07 Feb 2022 23:17:30 +0000
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ecrit/HQl8VNOPGn8JkyllSR79AugIMiM>
Subject: [Ecrit] [IANA #1224717] expert review for draft-ietf-ecrit-similar-location (xml-registry)
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, 07 Feb 2022 23:17:49 -0000

Hi Martin and Tim (cc: ecrit WG), 

As the designated experts for the ns and schema IETF XML registries, can you review the proposed registration in draft-ietf-ecrit-similar-location for us? Please see

https://datatracker.ietf.org/doc/draft-ietf-ecrit-similar-location/

If these are OK, when the IESG approves the document for publication, we'll make the registrations at

https://www.iana.org/assignments/xml-registry

The IESG has asked us to set a two-week deadline for registration reviews. The due date for this request is 21 February 2022.

thanks,

Sabrina Tanamal
Lead IANA Services Specialist


From nobody Mon Feb  7 15:22:20 2022
Return-Path: <tbray@textuality.com>
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 217963A0EE0 for <ecrit@ietfa.amsl.com>; Mon,  7 Feb 2022 15:22:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=textuality-com.20210112.gappssmtp.com
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 CDISI8P0niRi for <ecrit@ietfa.amsl.com>; Mon,  7 Feb 2022 15:22:14 -0800 (PST)
Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (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 CA5393A0E30 for <ecrit@ietf.org>; Mon,  7 Feb 2022 15:22:12 -0800 (PST)
Received: by mail-lf1-x12a.google.com with SMTP id b9so29892801lfq.6 for <ecrit@ietf.org>; Mon, 07 Feb 2022 15:22:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=textuality-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SC41DdEiyHSmTtLSM3dB7DY23AzYICiue+6QUujoDGk=; b=lpPhGF6r1sDQxWrR+OcRT4BEKsZ6FsAyY7ufzlmY2W130oISzP3PRadUU1EDlonYmX LzGvPs4juj5X85/nk/bzbFBA6t4S0e9/FV1dRHSvIvFgwvPuGj5UfRCWLW6QM1aJXrM7 13QPGDQKsM0ScL+SKfQU+v0kXjIHtwVjkSJDaAB754/3frpWqZQD9m4GLY4rPKvy+KXm 3gfyOkBmP5t/8jcu9iIPh0EzLhgyVuW3nSX8kizi9PnfmG8k3/uECO2laL/LZ3NgWc1i 71VRFyfwgGZWnPwCLGKErx1F4cArSJGxsJXvQysWKwLM+3HyqGPt5K2hAsRKgJnolH8I IbDA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=SC41DdEiyHSmTtLSM3dB7DY23AzYICiue+6QUujoDGk=; b=Kdia7Zkoba9ACA6Al+9guQ2NMDApNl5xLvSIgUIe3lTcbe1fYhpHFQGd9/HVc48eky LjBnn9DK++EOX/AYUTMAmsxv6WZhT7U6NQ2ISjg4NAlloOpqWhuRIn9EhZulpo/DQDb0 u81zhxLk5zBGaFidhyT9W0pc3ydI3tr89yuqSwwFIJLWRt7wbDkfNeuxR6LJCYFGtZ1Q iLykv2TvafIggqvPkychf9NJ4SAnbTFfYLJJMa2U5MZLH6m1BRo0MqCXol8QbNfGzH78 5mZJV/V3nR06l1NTs3uNRpXfYYfrFGPAqjU85C47twvwcqDYVfx2eaUzqnVgv5kUFxXp fdoA==
X-Gm-Message-State: AOAM533cQcmC7NmdNqf1kmLXVlGCVxQ/cGjsaZd7xilFVpnacDANVI/M 4Dkj4eomz4TwvO/hnSlOLt/AllbXsSzkVoeGeVZY5w==
X-Google-Smtp-Source: ABdhPJwt3BixsMnF8YJxvBq5VL5t8mLDDSRZTzuM83DnrA07k3LOiKwg4D1E/wGBKkzNzTfaJIrN2cxdaKPQy/QMAC4=
X-Received: by 2002:a05:6512:3a8d:: with SMTP id q13mr1171803lfu.637.1644276129673;  Mon, 07 Feb 2022 15:22:09 -0800 (PST)
MIME-Version: 1.0
References: <RT-Ticket-1224717@icann.org> <rt-4.4.3-30874-1644275659-1074.1224717-37-0@icann.org> <rt-4.4.3-30874-1644275850-1287.1224717-37-0@icann.org>
In-Reply-To: <rt-4.4.3-30874-1644275850-1287.1224717-37-0@icann.org>
From: Tim Bray <tbray@textuality.com>
Date: Mon, 7 Feb 2022 15:21:58 -0800
Message-ID: <CAHBU6iv3cMLpCuztiCnC=JJ+F5vtODY8jbOfZKc7xLRd4Fv1oQ@mail.gmail.com>
To: drafts-expert-review@iana.org
Cc: Martin Thomson <mt@lowentropy.net>, ecrit@ietf.org
Content-Type: multipart/alternative; boundary="0000000000009f670905d775de1a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ecrit/_YRil6c2DRAXVwZB3Kgw43pCS6Y>
Subject: Re: [Ecrit] [IANA #1224717] expert review for draft-ietf-ecrit-similar-location (xml-registry)
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: Mon, 07 Feb 2022 23:22:18 -0000

--0000000000009f670905d775de1a
Content-Type: text/plain; charset="UTF-8"

Looks good to me, except for this:

  BEGIN
   <?xml version="2.0"?>
   <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"

That should be 1.0 not 2.0

On Mon, Feb 7, 2022 at 3:17 PM Sabrina Tanamal via RT <
drafts-expert-review@iana.org> wrote:

> Hi Martin and Tim (cc: ecrit WG),
>
> As the designated experts for the ns and schema IETF XML registries, can
> you review the proposed registration in draft-ietf-ecrit-similar-location
> for us? Please see
>
> https://datatracker.ietf.org/doc/draft-ietf-ecrit-similar-location/
>
> If these are OK, when the IESG approves the document for publication,
> we'll make the registrations at
>
> https://www.iana.org/assignments/xml-registry
>
> The IESG has asked us to set a two-week deadline for registration reviews.
> The due date for this request is 21 February 2022.
>
> thanks,
>
> Sabrina Tanamal
> Lead IANA Services Specialist
>

--0000000000009f670905d775de1a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-size:small">Loo=
ks good to me, except for this:</div><div class=3D"gmail_default" style=3D"=
font-size:small"><pre style=3D"box-sizing:border-box;overflow:auto;font-fam=
ily:&quot;PT Mono&quot;,Monaco,monospace;font-size:14px;padding:10px;margin=
-top:0px;margin-bottom:10.5px;line-height:1.214;color:rgb(0,0,0);word-break=
:break-all;word-wrap:break-word;background-color:rgb(255,253,245);border:1p=
x solid rgb(204,204,204);border-top-left-radius:4px;border-top-right-radius=
:4px;border-bottom-right-radius:4px;border-bottom-left-radius:4px">  BEGIN
   &lt;?xml version=3D&quot;2.0&quot;?&gt;
   &lt;!DOCTYPE html PUBLIC &quot;-//W3C//DTD XHTML Basic 1.0//EN&quot;</pr=
e></div><div class=3D"gmail_default" style=3D"font-size:small">That should =
be 1.0 not 2.0<br></div></div><br><div class=3D"gmail_quote"><div dir=3D"lt=
r" class=3D"gmail_attr">On Mon, Feb 7, 2022 at 3:17 PM Sabrina Tanamal via =
RT &lt;<a href=3D"mailto:drafts-expert-review@iana.org">drafts-expert-revie=
w@iana.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;=
border-left-color:rgb(204,204,204);padding-left:1ex">Hi Martin and Tim (cc:=
 ecrit WG), <br>
<br>
As the designated experts for the ns and schema IETF XML registries, can yo=
u review the proposed registration in draft-ietf-ecrit-similar-location for=
 us? Please see<br>
<br>
<a href=3D"https://datatracker.ietf.org/doc/draft-ietf-ecrit-similar-locati=
on/" rel=3D"noreferrer" target=3D"_blank">https://datatracker.ietf.org/doc/=
draft-ietf-ecrit-similar-location/</a><br>
<br>
If these are OK, when the IESG approves the document for publication, we&#3=
9;ll make the registrations at<br>
<br>
<a href=3D"https://www.iana.org/assignments/xml-registry" rel=3D"noreferrer=
" target=3D"_blank">https://www.iana.org/assignments/xml-registry</a><br>
<br>
The IESG has asked us to set a two-week deadline for registration reviews. =
The due date for this request is 21 February 2022.<br>
<br>
thanks,<br>
<br>
Sabrina Tanamal<br>
Lead IANA Services Specialist<br>
</blockquote></div>

--0000000000009f670905d775de1a--


From nobody Mon Feb  7 16:39:33 2022
Return-Path: <rg+ietf@randy.pensive.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 388D83A10BB for <ecrit@ietfa.amsl.com>; Mon,  7 Feb 2022 16:39:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 mWMCgi2dZriR for <ecrit@ietfa.amsl.com>; Mon,  7 Feb 2022 16:39:27 -0800 (PST)
Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id C2C0F3A1076 for <ecrit@ietf.org>; Mon,  7 Feb 2022 16:39:27 -0800 (PST)
Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Mon, 7 Feb 2022 16:39:25 -0800
From: "Randall Gellens" <rg+ietf@randy.pensive.org>
To: "Sabrina Tanamal via RT" <drafts-expert-review@iana.org>
Cc: tbray@textuality.com, ecrit@ietf.org
Date: Mon, 07 Feb 2022 16:39:25 -0800
X-Mailer: MailMate (1.13.2r5673)
Message-ID: <A4CDBCD0-F962-491B-A493-CB3BA8F849E8@randy.pensive.org>
In-Reply-To: <rt-4.4.3-30874-1644275850-1287.1224717-37-0@icann.org>
References: <RT-Ticket-1224717@icann.org> <rt-4.4.3-30874-1644275659-1074.1224717-37-0@icann.org> <rt-4.4.3-30874-1644275850-1287.1224717-37-0@icann.org>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
Archived-At: <https://mailarchive.ietf.org/arch/msg/ecrit/lEjaJcU8bPt2HvoYIl5DvC7SFBU>
Subject: Re: [Ecrit] [IANA #1224717] expert review for draft-ietf-ecrit-similar-location (xml-registry)
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, 08 Feb 2022 00:39:32 -0000

Hi Sabrina,

Thanks for initiating the expert review and to Tim for such a quick 
review and response.

Sabrina, nothing to do with this document, but just for my own 
curiosity, did your email get sent to Martin as well as Tim? I ask 
because in the Cc that was sent to ecrit there is no 'To' header, and 
your salutation included both Martin and Tim, and I only see Tim (in the 
'Cc' along with ecrit).

--Randall

On 7 Feb 2022, at 15:17, Sabrina Tanamal via RT wrote:

> Hi Martin and Tim (cc: ecrit WG),
>
> As the designated experts for the ns and schema IETF XML registries, 
> can you review the proposed registration in 
> draft-ietf-ecrit-similar-location for us? Please see
>
> https://datatracker.ietf.org/doc/draft-ietf-ecrit-similar-location/
>
> If these are OK, when the IESG approves the document for publication, 
> we'll make the registrations at
>
> https://www.iana.org/assignments/xml-registry
>
> The IESG has asked us to set a two-week deadline for registration 
> reviews. The due date for this request is 21 February 2022.
>
> thanks,
>
> Sabrina Tanamal
> Lead IANA Services Specialist
>
> _______________________________________________
> Ecrit mailing list
> Ecrit@ietf.org
> https://www.ietf.org/mailman/listinfo/ecrit


From nobody Mon Feb  7 16:44:00 2022
Return-Path: <tbray@textuality.com>
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 DFDC33A10C6 for <ecrit@ietfa.amsl.com>; Mon,  7 Feb 2022 16:43:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=textuality-com.20210112.gappssmtp.com
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 sr_lnitxCyQW for <ecrit@ietfa.amsl.com>; Mon,  7 Feb 2022 16:43:53 -0800 (PST)
Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (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 E48C23A10B3 for <ecrit@ietf.org>; Mon,  7 Feb 2022 16:43:52 -0800 (PST)
Received: by mail-lj1-x22b.google.com with SMTP id u7so20581696lji.2 for <ecrit@ietf.org>; Mon, 07 Feb 2022 16:43:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=textuality-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FCUkJ+uQC7xL6jOC3X0ts3WL/16GaVKZllwXLziPCoY=; b=f8rPMgq46aiqG4NYnIhiwejKh/g35CDfIa0+jX5s+nizYyGJKO5aL5rOUF6kdLWwxQ RWbp4NLHL80mw9+oW6KoZGcT2QKIPSN3eC/5s6CGknVz8R+Yc1e/wsVO2BEkYDzHPEps uNwPTbG9gq/af3i9rqsM7J471Y6pmTBgQBWFxPflEg3v7blbwV38fkg+goCexfKAWMwe r9SSwJS2yRWPHxTZ3bmdKajFDZpbzu0psC7jR5dPRI5+xCM7JlZRwrMy7quPUm8zLAOy sNMRt6hzTcKCkQ9pU9qImZG/SOjkvosGIB6p1rIbbPMcHAnyf4u/iFG1VVM+ckkeim1g Gkbg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=FCUkJ+uQC7xL6jOC3X0ts3WL/16GaVKZllwXLziPCoY=; b=KbHjhDKsvZplwKJsMwjpRGui6h7ERhO+ycj3i13mSaiVqeCGpVovyCcz+tLwG28um3 s4GPJimlEfpU/RJqzhltwiSM9HEfiycnqOPoR57tsxZeHgxVyR5HwOCThLnu5V9b/ryc e13oSwOviZrRJH1PKKaBR7g8By2ipZuhc2EiZARVUOSg4BrWPJ+uU4gzmpEHWFtsVGDu DaLIfmMZYAzk+R++HifkN9w0/ISmrRgnOu/9qWpyoOC/hA/i2tDPKxvCR0Vx+wTfDhWd udbfdWpXU1O3a+fzN68C+UGn+KKQdy8H2EeT2Pm7e4Rj9D3ucgAm5wiFPUm9X7WKQzOp RA2Q==
X-Gm-Message-State: AOAM533L3pN9VdhBACbL2DELqyCMieNpWU2DLefOp8vYuZYIvpG14KNE qa+DxTrlhr+dVYtxiuKdONdYJ7vhU2oOOrbCigWDyrb2EicTyQ==
X-Google-Smtp-Source: ABdhPJwcDo5y1OEv1fs+LOBiFio3+7Lf43MoebBqkj8oUebpsrO48HcT99UB7oIex8ZOljVJeM2sL7sjPxJ2g33Cyl4=
X-Received: by 2002:a2e:8798:: with SMTP id n24mr1257500lji.404.1644281029269;  Mon, 07 Feb 2022 16:43:49 -0800 (PST)
MIME-Version: 1.0
References: <RT-Ticket-1224717@icann.org> <rt-4.4.3-30874-1644275659-1074.1224717-37-0@icann.org> <rt-4.4.3-30874-1644275850-1287.1224717-37-0@icann.org> <A4CDBCD0-F962-491B-A493-CB3BA8F849E8@randy.pensive.org>
In-Reply-To: <A4CDBCD0-F962-491B-A493-CB3BA8F849E8@randy.pensive.org>
From: Tim Bray <tbray@textuality.com>
Date: Mon, 7 Feb 2022 16:43:38 -0800
Message-ID: <CAHBU6isMFeP=ogFY2Zr=_AHq7RDQBU_QvL7_5k9ozB3xWmm=5g@mail.gmail.com>
To: Randall Gellens <rg+ietf@randy.pensive.org>
Cc: Sabrina Tanamal via RT <drafts-expert-review@iana.org>, ecrit@ietf.org
Content-Type: multipart/alternative; boundary="000000000000a936fa05d77702a6"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ecrit/nS1L-7f24tv5NBajH2dAVGCdCXY>
Subject: Re: [Ecrit] [IANA #1224717] expert review for draft-ietf-ecrit-similar-location (xml-registry)
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, 08 Feb 2022 00:43:58 -0000

--000000000000a936fa05d77702a6
Content-Type: text/plain; charset="UTF-8"

If my email headers are to be trusted, it went to us both, so Martin got my
response too.

On Mon, Feb 7, 2022 at 4:39 PM Randall Gellens <rg+ietf@randy.pensive.org>
wrote:

> Hi Sabrina,
>
> Thanks for initiating the expert review and to Tim for such a quick
> review and response.
>
> Sabrina, nothing to do with this document, but just for my own
> curiosity, did your email get sent to Martin as well as Tim? I ask
> because in the Cc that was sent to ecrit there is no 'To' header, and
> your salutation included both Martin and Tim, and I only see Tim (in the
> 'Cc' along with ecrit).
>
> --Randall
>
> On 7 Feb 2022, at 15:17, Sabrina Tanamal via RT wrote:
>
> > Hi Martin and Tim (cc: ecrit WG),
> >
> > As the designated experts for the ns and schema IETF XML registries,
> > can you review the proposed registration in
> > draft-ietf-ecrit-similar-location for us? Please see
> >
> > https://datatracker.ietf.org/doc/draft-ietf-ecrit-similar-location/
> >
> > If these are OK, when the IESG approves the document for publication,
> > we'll make the registrations at
> >
> > https://www.iana.org/assignments/xml-registry
> >
> > The IESG has asked us to set a two-week deadline for registration
> > reviews. The due date for this request is 21 February 2022.
> >
> > thanks,
> >
> > Sabrina Tanamal
> > Lead IANA Services Specialist
> >
> > _______________________________________________
> > Ecrit mailing list
> > Ecrit@ietf.org
> > https://www.ietf.org/mailman/listinfo/ecrit
>

--000000000000a936fa05d77702a6
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-size:small">If =
my email headers=C2=A0are to be trusted, it went to us both, so Martin got =
my response too.</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr"=
 class=3D"gmail_attr">On Mon, Feb 7, 2022 at 4:39 PM Randall Gellens &lt;<a=
 href=3D"mailto:rg%2Bietf@randy.pensive.org">rg+ietf@randy.pensive.org</a>&=
gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-colo=
r:rgb(204,204,204);padding-left:1ex">Hi Sabrina,<br>
<br>
Thanks for initiating the expert review and to Tim for such a quick <br>
review and response.<br>
<br>
Sabrina, nothing to do with this document, but just for my own <br>
curiosity, did your email get sent to Martin as well as Tim? I ask <br>
because in the Cc that was sent to ecrit there is no &#39;To&#39; header, a=
nd <br>
your salutation included both Martin and Tim, and I only see Tim (in the <b=
r>
&#39;Cc&#39; along with ecrit).<br>
<br>
--Randall<br>
<br>
On 7 Feb 2022, at 15:17, Sabrina Tanamal via RT wrote:<br>
<br>
&gt; Hi Martin and Tim (cc: ecrit WG),<br>
&gt;<br>
&gt; As the designated experts for the ns and schema IETF XML registries, <=
br>
&gt; can you review the proposed registration in <br>
&gt; draft-ietf-ecrit-similar-location for us? Please see<br>
&gt;<br>
&gt; <a href=3D"https://datatracker.ietf.org/doc/draft-ietf-ecrit-similar-l=
ocation/" rel=3D"noreferrer" target=3D"_blank">https://datatracker.ietf.org=
/doc/draft-ietf-ecrit-similar-location/</a><br>
&gt;<br>
&gt; If these are OK, when the IESG approves the document for publication, =
<br>
&gt; we&#39;ll make the registrations at<br>
&gt;<br>
&gt; <a href=3D"https://www.iana.org/assignments/xml-registry" rel=3D"noref=
errer" target=3D"_blank">https://www.iana.org/assignments/xml-registry</a><=
br>
&gt;<br>
&gt; The IESG has asked us to set a two-week deadline for registration <br>
&gt; reviews. The due date for this request is 21 February 2022.<br>
&gt;<br>
&gt; thanks,<br>
&gt;<br>
&gt; Sabrina Tanamal<br>
&gt; Lead IANA Services Specialist<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; Ecrit mailing list<br>
&gt; <a href=3D"mailto:Ecrit@ietf.org" target=3D"_blank">Ecrit@ietf.org</a>=
<br>
&gt; <a href=3D"https://www.ietf.org/mailman/listinfo/ecrit" rel=3D"norefer=
rer" target=3D"_blank">https://www.ietf.org/mailman/listinfo/ecrit</a><br>
</blockquote></div>

--000000000000a936fa05d77702a6--


From nobody Tue Feb  8 05:24:09 2022
Return-Path: <rg+ietf@randy.pensive.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 75C9D3A0C68 for <ecrit@ietfa.amsl.com>; Tue,  8 Feb 2022 05:24:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 i8Uk7PfxfDRm for <ecrit@ietfa.amsl.com>; Tue,  8 Feb 2022 05:24:02 -0800 (PST)
Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 0C7E93A0C7D for <ecrit@ietf.org>; Tue,  8 Feb 2022 05:24:02 -0800 (PST)
Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Tue, 8 Feb 2022 05:24:00 -0800
From: "Randall Gellens" <rg+ietf@randy.pensive.org>
To: "Tim Bray" <tbray@textuality.com>
Cc: "Sabrina Tanamal via RT" <drafts-expert-review@iana.org>, ecrit@ietf.org
Date: Tue, 08 Feb 2022 05:23:59 -0800
X-Mailer: MailMate (1.13.2r5673)
Message-ID: <E3A6CAB6-0D8C-45C7-B7BD-07DA128C288B@randy.pensive.org>
In-Reply-To: <CAHBU6isMFeP=ogFY2Zr=_AHq7RDQBU_QvL7_5k9ozB3xWmm=5g@mail.gmail.com>
References: <RT-Ticket-1224717@icann.org> <rt-4.4.3-30874-1644275659-1074.1224717-37-0@icann.org> <rt-4.4.3-30874-1644275850-1287.1224717-37-0@icann.org> <A4CDBCD0-F962-491B-A493-CB3BA8F849E8@randy.pensive.org> <CAHBU6isMFeP=ogFY2Zr=_AHq7RDQBU_QvL7_5k9ozB3xWmm=5g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_MailMate_6BAFF2FB-59B5-4464-8A48-C8F29BA7D76C_="
Embedded-HTML: [{"HTML":[521, 2467], "plain":[190, 1515], "uuid":"6CB15AE7-357F-4AE2-A1BD-C48D1C3245EA"}]
Archived-At: <https://mailarchive.ietf.org/arch/msg/ecrit/uV8eZyh6MNFfEJehvMp7KgjXmIk>
Subject: Re: [Ecrit] [IANA #1224717] expert review for draft-ietf-ecrit-similar-location (xml-registry)
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, 08 Feb 2022 13:24:07 -0000

--=_MailMate_6BAFF2FB-59B5-4464-8A48-C8F29BA7D76C_=
Content-Type: text/plain; format=flowed

Thanks, Tim; I was just curious if something was removing some header 
fields, e.g., people on the 'cc' don't see 'To' and vice versa.

--Randall

On 7 Feb 2022, at 16:43, Tim Bray wrote:

> If my email headers are to be trusted, it went to us both, so Martin 
> got my
> response too.
>
> On Mon, Feb 7, 2022 at 4:39 PM Randall Gellens 
> <rg+ietf@randy.pensive.org>
> wrote:
>
>> Hi Sabrina,
>>
>> Thanks for initiating the expert review and to Tim for such a quick
>> review and response.
>>
>> Sabrina, nothing to do with this document, but just for my own
>> curiosity, did your email get sent to Martin as well as Tim? I ask
>> because in the Cc that was sent to ecrit there is no 'To' header, and
>> your salutation included both Martin and Tim, and I only see Tim (in 
>> the
>> 'Cc' along with ecrit).
>>
>> --Randall
>>
>> On 7 Feb 2022, at 15:17, Sabrina Tanamal via RT wrote:
>>
>>> Hi Martin and Tim (cc: ecrit WG),
>>>
>>> As the designated experts for the ns and schema IETF XML registries,
>>> can you review the proposed registration in
>>> draft-ietf-ecrit-similar-location for us? Please see
>>>
>>> https://datatracker.ietf.org/doc/draft-ietf-ecrit-similar-location/
>>>
>>> If these are OK, when the IESG approves the document for 
>>> publication,
>>> we'll make the registrations at
>>>
>>> https://www.iana.org/assignments/xml-registry
>>>
>>> The IESG has asked us to set a two-week deadline for registration
>>> reviews. The due date for this request is 21 February 2022.
>>>
>>> thanks,
>>>
>>> Sabrina Tanamal
>>> Lead IANA Services Specialist
>>>
>>> _______________________________________________
>>> Ecrit mailing list
>>> Ecrit@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ecrit
>>



--=_MailMate_6BAFF2FB-59B5-4464-8A48-C8F29BA7D76C_=
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html>
<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/xhtml; charset=3Dutf-8"=
>
</head>
<body>
<div style=3D"font-family:sans-serif"><div style=3D"white-space:normal"><=
p dir=3D"auto">Thanks, Tim; I was just curious if something was removing =
some header fields, e.g., people on the 'cc' don't see 'To' and vice vers=
a.</p>
<p dir=3D"auto">--Randall</p>
<p dir=3D"auto">On 7 Feb 2022, at 16:43, Tim Bray wrote:</p>
</div>
<blockquote style=3D"border-left:2px solid #777; color:#777; margin:0 0 5=
px; padding-left:5px"><div id=3D"6CB15AE7-357F-4AE2-A1BD-C48D1C3245EA"><d=
iv dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-size:small">If =
my email headers=C2=A0are to be trusted, it went to us both, so Martin go=
t my response too.</div></div><br><div class=3D"gmail_quote"><div dir=3D"=
ltr" class=3D"gmail_attr">On Mon, Feb 7, 2022 at 4:39 PM Randall Gellens =
&lt;<a href=3D"mailto:rg%2Bietf@randy.pensive.org">rg+ietf@randy.pensive.=
org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;bord=
er-left-color:rgb(204,204,204);padding-left:1ex">Hi Sabrina,<br>
<br>
Thanks for initiating the expert review and to Tim for such a quick <br>
review and response.<br>
<br>
Sabrina, nothing to do with this document, but just for my own <br>
curiosity, did your email get sent to Martin as well as Tim? I ask <br>
because in the Cc that was sent to ecrit there is no &#39;To&#39; header,=
 and <br>
your salutation included both Martin and Tim, and I only see Tim (in the =
<br>
&#39;Cc&#39; along with ecrit).<br>
<br>
--Randall<br>
<br>
On 7 Feb 2022, at 15:17, Sabrina Tanamal via RT wrote:<br>
<br>
&gt; Hi Martin and Tim (cc: ecrit WG),<br>
&gt;<br>
&gt; As the designated experts for the ns and schema IETF XML registries,=
 <br>
&gt; can you review the proposed registration in <br>
&gt; draft-ietf-ecrit-similar-location for us? Please see<br>
&gt;<br>
&gt; <a href=3D"https://datatracker.ietf.org/doc/draft-ietf-ecrit-similar=
-location/" rel=3D"noreferrer" target=3D"_blank">https://datatracker.ietf=
=2Eorg/doc/draft-ietf-ecrit-similar-location/</a><br>
&gt;<br>
&gt; If these are OK, when the IESG approves the document for publication=
, <br>
&gt; we&#39;ll make the registrations at<br>
&gt;<br>
&gt; <a href=3D"https://www.iana.org/assignments/xml-registry" rel=3D"nor=
eferrer" target=3D"_blank">https://www.iana.org/assignments/xml-registry<=
/a><br>
&gt;<br>
&gt; The IESG has asked us to set a two-week deadline for registration <b=
r>
&gt; reviews. The due date for this request is 21 February 2022.<br>
&gt;<br>
&gt; thanks,<br>
&gt;<br>
&gt; Sabrina Tanamal<br>
&gt; Lead IANA Services Specialist<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; Ecrit mailing list<br>
&gt; <a href=3D"mailto:Ecrit@ietf.org" target=3D"_blank">Ecrit@ietf.org</=
a><br>
&gt; <a href=3D"https://www.ietf.org/mailman/listinfo/ecrit" rel=3D"noref=
errer" target=3D"_blank">https://www.ietf.org/mailman/listinfo/ecrit</a><=
br>
</blockquote></div></div></blockquote>
<div style=3D"white-space:normal"><blockquote style=3D"border-left:2px so=
lid #777; color:#777; margin:0 0 5px; padding-left:5px">
</blockquote></div>
</div>
</body>
</html>

--=_MailMate_6BAFF2FB-59B5-4464-8A48-C8F29BA7D76C_=--


From nobody Sat Feb 12 10:45:41 2022
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 17DF03A0C35; Sat, 12 Feb 2022 10:45:29 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Scott Kelly via Datatracker <noreply@ietf.org>
To: <secdir@ietf.org>
Cc: draft-ietf-ecrit-similar-location.all@ietf.org, ecrit@ietf.org, last-call@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.44.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <164469152903.22389.17221318381823098353@ietfa.amsl.com>
Reply-To: Scott Kelly <scott@hyperthought.com>
Date: Sat, 12 Feb 2022 10:45:29 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/ecrit/ybxplKOxrDYi9cnjKUaKlXx26NA>
Subject: [Ecrit] Secdir last call review of draft-ietf-ecrit-similar-location-17
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: Sat, 12 Feb 2022 18:45:37 -0000

Reviewer: Scott Kelly
Review result: Ready

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the security area directors.
 Document editors and WG chairs should treat these comments just like any other
last call comments.

The summary of the review is ready.

>From the abstract, this document introduces a new way to provide returned
location information in LoST responses that is either of a completed or similar
form to the original input civic location, based on whether valid or invalid
civic address elements are returned within the  <findServiceResponse> message.

The security considerations section considers that this mechanism may disclose
information, and that implementers should consider the implications of this in
the context of their service.  If I were writing this section, I might start by
saying (because this doc extends RFC 5222) that all of the security
considerations of 5222 apply, but this is implicit, and I don't feel strongly
about this.

>From a security considerations perspective, I think this document is ready.



From nobody Sun Feb 13 11:56:51 2022
Return-Path: <superuser@gmail.com>
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 1CCCA3A089A; Sun, 13 Feb 2022 11:56:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level: 
X-Spam-Status: No, score=-2.096 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 R6Bp3HZA__Io; Sun, 13 Feb 2022 11:56:45 -0800 (PST)
Received: from mail-ua1-x92b.google.com (mail-ua1-x92b.google.com [IPv6:2607:f8b0:4864:20::92b]) (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 B2D643A0895; Sun, 13 Feb 2022 11:56:42 -0800 (PST)
Received: by mail-ua1-x92b.google.com with SMTP id g18so7146659uak.5; Sun, 13 Feb 2022 11:56:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DPmZsUYp6Sbhpug2/fLNwz2FDF98bgM2DQB8Xb+gdG0=; b=RL83Mvmnbd1moelugDWxbTZFeRjjSTDoR9IJFM0v6vPhqrX/bI6xIYV9m8Lkp1/wma 5fGbtctyCua/LOmULq/CctFgVJQagfGzCd1QTIzw18SSqsU1kqbU/I2hDGfXwMyhYcEQ 88Vmqg3cV81CS+N82qp2/a+dcuC3xjVYbxSMNjEfDa7FmsTXJ9HWe24Pth2fUn+8JPET n+NbvF77rpVtI8tShFal0dK+69JUVUeHOsNbxCsfyIQzlr0wGRBr1CKPHArTFzhSoyl5 Y+X4bt0doRZo+NF1kHqXGJtN9brhOfi6gejym51Cb/Db7qPqywckYtquwNbvDB6zQu02 JMWQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=DPmZsUYp6Sbhpug2/fLNwz2FDF98bgM2DQB8Xb+gdG0=; b=fPndb/ZB3prUYSsn4mVVaje3y8WzT/Fn3VwC+ToSb1VpxAcCqWkhwrKRd71qKOA1C3 zbzNmrMOUzuUd/o+c7TKGLm2kW0HDG6hKoM4u8OWqohcWArilTs759n2PGWqGyPCWwkS IFSbFEv2/5JuZoN1ovkoyO/DuXdI7ourqwm+7MR2o9FpMeLWGGLmwxC2Jv/UMu1Z6K4J +LquKdAIRtukZ5PTuVGWjCEapAQAsGSOtiF50jC+JQUCHxewLb1jbP6sEW3cKwhw/nZx wktOVBrasA7Tycnw5kZMb72e/CsJN+aMvLUNHv1N4UEC9W3AVAdSbxCamNawn673jRa4 UmAg==
X-Gm-Message-State: AOAM531/3w0ad/7yppc5K97HRgULSFdAYM6Ox8THfgTEfWPVuaziHib8 i5UV8MunOGZrNBetOCbN5BCv4zSh0l45PCNuXjFAajXn
X-Google-Smtp-Source: ABdhPJwGoRCCcnoT+xtv6v+x3WXoqK4/6pxqQ7GbSEnbyrv+hT1KGflwjCF/5Qa/F9S6ehL53uFq4gcxvgIICQMEKOU=
X-Received: by 2002:ab0:36b3:: with SMTP id v19mr2781953uat.101.1644782200892;  Sun, 13 Feb 2022 11:56:40 -0800 (PST)
MIME-Version: 1.0
References: <164320893056.22411.15797607316561970461@ietfa.amsl.com>
In-Reply-To: <164320893056.22411.15797607316561970461@ietfa.amsl.com>
From: "Murray S. Kucherawy" <superuser@gmail.com>
Date: Sun, 13 Feb 2022 11:56:29 -0800
Message-ID: <CAL0qLwYzpEam7c6CexgqwgZECKH5LrYRU9xewYFOn0q1N9h3GQ@mail.gmail.com>
To: ecrit@ietf.org
Cc: draft-ietf-ecrit-similar-location@ietf.org,  Dwight Purtle <dwightpurtle@gmail.com>, ecrit-chairs@ietf.org
Content-Type: multipart/alternative; boundary="000000000000d12ff205d7ebb2b8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ecrit/okzs6E3llrY6CBs8-dOV_BEo_VA>
Subject: Re: [Ecrit] Last Call: <draft-ietf-ecrit-similar-location-17.txt> (A LoST extension to return complete and similar location info) to Proposed Standard
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: Sun, 13 Feb 2022 19:56:48 -0000

--000000000000d12ff205d7ebb2b8
Content-Type: text/plain; charset="UTF-8"

Hi all,

Last call completed on this document with some directorate review feedback
worth considering but nothing I'd consider a showstopper.  I'm going to
issue the ballot shortly, and we can fold the directorate reviews into the
IESG reviews.

If you happen to have a revision ready quickly, go ahead and post it, but
there's no hurry to do so.

-MSK

On Wed, Jan 26, 2022 at 6:55 AM The IESG <iesg-secretary@ietf.org> wrote:

>
> The IESG has received a request from the Emergency Context Resolution with
> Internet Technologies WG (ecrit) to consider the following document: - 'A
> LoST extension to return complete and similar location info'
>   <draft-ietf-ecrit-similar-location-17.txt> as Proposed Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits final
> comments on this action. Please send substantive comments to the
> last-call@ietf.org mailing lists by 2022-02-09. Exceptionally, comments
> may
> be sent to iesg@ietf.org instead. In either case, please retain the
> beginning
> of the Subject line to allow automated sorting.
>
> Abstract
>
>
>    This document introduces a new way to provide returned location
>    information in LoST responses that is either of a completed or
>    similar form to the original input civic location, based on whether
>    valid or invalid civic address elements are returned within the
>    <findServiceResponse> message.  This document defines a new extension
>    to the <findServiceResponse> message within the LoST protocol
>    (RFC5222) that enables the LoST protocol to return in a response a
>    completed civic address element set for a valid location response,
>    and one or more suggested sets of similar location information for an
>    invalid location.  These two types of civic addresses are referred to
>    as either "complete location" or "similar location", and are included
>    as a compilation of CAtype XML elements within the existing LoST
>    <findServiceResponse> message structure.
>
>
>
>
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-ietf-ecrit-similar-location/
>
>
>
> No IPR declarations have been submitted directly on this I-D.
>
>
>
>
>
>

--000000000000d12ff205d7ebb2b8
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi all,</div><div><br></div><div>Last call completed =
on this document with some directorate review feedback worth considering bu=
t nothing I&#39;d consider a showstopper.=C2=A0 I&#39;m going to issue the =
ballot shortly, and we can fold the directorate reviews into the IESG revie=
ws.</div><div><br></div><div>If you happen to have a revision ready quickly=
, go ahead and post it, but there&#39;s no hurry to do so.<br></div><div><b=
r></div><div>-MSK<br></div></div><br><div class=3D"gmail_quote"><div dir=3D=
"ltr" class=3D"gmail_attr">On Wed, Jan 26, 2022 at 6:55 AM The IESG &lt;<a =
href=3D"mailto:iesg-secretary@ietf.org">iesg-secretary@ietf.org</a>&gt; wro=
te:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px =
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
The IESG has received a request from the Emergency Context Resolution with<=
br>
Internet Technologies WG (ecrit) to consider the following document: - &#39=
;A<br>
LoST extension to return complete and similar location info&#39;<br>
=C2=A0 &lt;draft-ietf-ecrit-similar-location-17.txt&gt; as Proposed Standar=
d<br>
<br>
The IESG plans to make a decision in the next few weeks, and solicits final=
<br>
comments on this action. Please send substantive comments to the<br>
<a href=3D"mailto:last-call@ietf.org" target=3D"_blank">last-call@ietf.org<=
/a> mailing lists by 2022-02-09. Exceptionally, comments may<br>
be sent to <a href=3D"mailto:iesg@ietf.org" target=3D"_blank">iesg@ietf.org=
</a> instead. In either case, please retain the beginning<br>
of the Subject line to allow automated sorting.<br>
<br>
Abstract<br>
<br>
<br>
=C2=A0 =C2=A0This document introduces a new way to provide returned locatio=
n<br>
=C2=A0 =C2=A0information in LoST responses that is either of a completed or=
<br>
=C2=A0 =C2=A0similar form to the original input civic location, based on wh=
ether<br>
=C2=A0 =C2=A0valid or invalid civic address elements are returned within th=
e<br>
=C2=A0 =C2=A0&lt;findServiceResponse&gt; message.=C2=A0 This document defin=
es a new extension<br>
=C2=A0 =C2=A0to the &lt;findServiceResponse&gt; message within the LoST pro=
tocol<br>
=C2=A0 =C2=A0(RFC5222) that enables the LoST protocol to return in a respon=
se a<br>
=C2=A0 =C2=A0completed civic address element set for a valid location respo=
nse,<br>
=C2=A0 =C2=A0and one or more suggested sets of similar location information=
 for an<br>
=C2=A0 =C2=A0invalid location.=C2=A0 These two types of civic addresses are=
 referred to<br>
=C2=A0 =C2=A0as either &quot;complete location&quot; or &quot;similar locat=
ion&quot;, and are included<br>
=C2=A0 =C2=A0as a compilation of CAtype XML elements within the existing Lo=
ST<br>
=C2=A0 =C2=A0&lt;findServiceResponse&gt; message structure.<br>
<br>
<br>
<br>
<br>
The file can be obtained via<br>
<a href=3D"https://datatracker.ietf.org/doc/draft-ietf-ecrit-similar-locati=
on/" rel=3D"noreferrer" target=3D"_blank">https://datatracker.ietf.org/doc/=
draft-ietf-ecrit-similar-location/</a><br>
<br>
<br>
<br>
No IPR declarations have been submitted directly on this I-D.<br>
<br>
<br>
<br>
<br>
<br>
</blockquote></div>

--000000000000d12ff205d7ebb2b8--


From nobody Sun Feb 13 16:06:35 2022
Return-Path: <wwwrun@rfc-editor.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 CE43B3A0A1D for <ecrit@ietfa.amsl.com>; Sat, 12 Feb 2022 16:00:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level: 
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 UJ3luU-YyfI5 for <ecrit@ietfa.amsl.com>; Sat, 12 Feb 2022 16:00:35 -0800 (PST)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EDD33A0A16 for <ecrit@ietf.org>; Sat, 12 Feb 2022 16:00:35 -0800 (PST)
Received: by rfc-editor.org (Postfix, from userid 499) id 4123C4C1CE; Sat, 12 Feb 2022 16:00:35 -0800 (PST)
To: rg+ietf@randy.pensive.org, br@brianrosen.net, Hannes.Tschofenig@gmx.net, rmarshall@telecomsys.com, a.james.winterbottom@gmail.com, superuser@gmail.com,  francesca.palombini@ericsson.com, allison.mankin@gmail.com, rg+ietf@coretechnologyconsulting.com, roger.marshall@comtechtel.com
From: RFC Errata System <rfc-editor@rfc-editor.org>
Cc: james.benner@gmail.com, ecrit@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset=UTF-8
Message-Id: <20220213000035.4123C4C1CE@rfc-editor.org>
Date: Sat, 12 Feb 2022 16:00:35 -0800 (PST)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ecrit/9t6j4NqnbzcRr0_Qzh3cQXexgWw>
X-Mailman-Approved-At: Sun, 13 Feb 2022 16:06:34 -0800
Subject: [Ecrit] [Technical Errata Reported] RFC7852 (6849)
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: Sun, 13 Feb 2022 00:00:40 -0000

The following errata report has been submitted for RFC7852,
"Additional Data Related to an Emergency Call".

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6849

--------------------------------------
Type: Technical
Reported by: James Benner <james.benner@gmail.com>

Section: 11.7

Original Text
-------------
Example(s):  TEL;VALUE=uri;TYPE="main,voice";PREF=1:tel:+1-418-656-90
      00

Corrected Text
--------------
Example(s):  TEL;VALUE=uri;TYPE="main-number,voice";PREF=1:tel:+1-418-656-90
      00

Notes
-----
The type value is specified as "main-number" but in the example is simply "main".

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC7852 (draft-ietf-ecrit-additional-data-38)
--------------------------------------
Title               : Additional Data Related to an Emergency Call
Publication Date    : July 2016
Author(s)           : R. Gellens, B. Rosen, H. Tschofenig, R. Marshall, J. Winterbottom
Category            : PROPOSED STANDARD
Source              : Emergency Context Resolution with Internet Technologies
Area                : Applications and Real-Time
Stream              : IETF
Verifying Party     : IESG


From nobody Tue Feb 15 11:04:28 2022
Return-Path: <internet-drafts@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 8C61C3A00AF; Tue, 15 Feb 2022 11:04:25 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: <i-d-announce@ietf.org>
Cc: ecrit@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.45.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: ecrit@ietf.org
Message-ID: <164495186536.32031.13377583964583738486@ietfa.amsl.com>
Date: Tue, 15 Feb 2022 11:04:25 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/ecrit/kDgLLpy-EqijNfRpljQXGfRZOQ8>
Subject: [Ecrit] I-D Action: draft-ietf-ecrit-similar-location-18.txt
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: Tue, 15 Feb 2022 19:04:26 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Emergency Context Resolution with Internet Technologies WG of the IETF.

        Title           : A LoST extension to return complete and similar location info
        Authors         : Brian Rosen
                          Roger Marshall
                          Jeff Martin
	Filename        : draft-ietf-ecrit-similar-location-18.txt
	Pages           : 19
	Date            : 2022-02-15

Abstract:
   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


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ecrit-similar-location/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-ecrit-similar-location-18

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ecrit-similar-location-18


Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts



From nobody Tue Feb 15 11:27:36 2022
Return-Path: <br@brianrosen.net>
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 3FAF53A07FD for <ecrit@ietfa.amsl.com>; Tue, 15 Feb 2022 11:27:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.888
X-Spam-Level: 
X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20210112.gappssmtp.com
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 TouLUDCZqmOn for <ecrit@ietfa.amsl.com>; Tue, 15 Feb 2022 11:27:31 -0800 (PST)
Received: from mail-pg1-x534.google.com (mail-pg1-x534.google.com [IPv6:2607:f8b0:4864:20::534]) (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 D905F3A0877 for <ecrit@ietf.org>; Tue, 15 Feb 2022 11:27:31 -0800 (PST)
Received: by mail-pg1-x534.google.com with SMTP id z4so42664pgh.12 for <ecrit@ietf.org>; Tue, 15 Feb 2022 11:27:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20210112.gappssmtp.com; s=20210112; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=6zfQJGbtCg0mDJTNBVsObvZcTLHh9Sy2FCegflGGfsE=; b=8A95AB5C7Iks1Dj13gG4cNqEMnkbyH1ZeCiOOcueXYOToPcIuED5ya/wjCQZwIErlI XeLw0ood68M44rgxkiXRof3IQGPbopidFhsV1m0y5EC1J6ssVqmOtpFXSZkJgy2XINH4 7woGtBimUThA4I53xjon/F9+Mv/TLZBKgs1bJ9S1ete2PM4cytI0sAckl3w05F8F7FoN hgTxr2zdE8Fup7enjLTamEPVDE3Kk2gjx0nAbyjAxicng3vJua1NtW6FbtgF5scuGI42 tKFKp9GVxmgs+r3DZCJYIIVwtBETQO5h0qC/DuVQi4M+NZYmAOHUOLcoFOx6VsKofWJR A04Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=6zfQJGbtCg0mDJTNBVsObvZcTLHh9Sy2FCegflGGfsE=; b=1ZJRmFtsQjFCMBWByz1o7FPaHYCNJQxIhUWwqKNu1aoxOGu45zXFyVnvbzbmU/kFAB YonrefxfuzwzU8Yk2G1i7/wR/WayiDMcbTnwVWxdAukpYh/rvobcOzlk6d/GRlIIwpjk se2MqoPZJwsQfKkUA3RNDR2rShkuxsVrqypUv4DrOFwes2fspmwXgzpRjezKvCP/EQnq OSQPMv28bxwTAAcbCHf8LqQ/nZAQlETlsmLZtQ+HeNKcqcvq+LRwHYThRtN410nzmDxH X3YKfuquq7oma7PoCDszfm5jLhiEvISHy4M0ESVc/MOwLeMgp2l+QZbANDa0glPQC0AC Xubw==
X-Gm-Message-State: AOAM532Il0T36WzXkcWJcIEzzY+FlD+6t2Xj8wVtJVWWuUUc5Zas1cag iNR/MzGEZ3OEWpVfJGPqnzXIJGRfW0rF/LPG
X-Google-Smtp-Source: ABdhPJwArAGXtXoncejQssENvm4phyYQ5iS0ce+dqkWrika6ETD728jnUrdq0yg1WzPEwMH1IfYK0w==
X-Received: by 2002:aa7:8891:: with SMTP id z17mr242380pfe.76.1644953250382; Tue, 15 Feb 2022 11:27:30 -0800 (PST)
Received: from smtpclient.apple ([91.196.220.143]) by smtp.gmail.com with ESMTPSA id l11sm17998733pjm.23.2022.02.15.11.27.29 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 15 Feb 2022 11:27:29 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.20.0.1.32\))
From: Brian Rosen <br@brianrosen.net>
In-Reply-To: <164495186536.32031.13377583964583738486@ietfa.amsl.com>
Date: Tue, 15 Feb 2022 11:27:28 -0800
Cc: Russ Housley <housley@vigilsec.com>, Claudio.Allocchio@garr.it
Content-Transfer-Encoding: quoted-printable
Message-Id: <E440F3CD-F057-461C-B235-3EDE8BB284B5@brianrosen.net>
References: <164495186536.32031.13377583964583738486@ietfa.amsl.com>
To: ECRIT <ecrit@ietf.org>
X-Mailer: Apple Mail (2.3693.20.0.1.32)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ecrit/MNdf4fzCyQAgi0ZbfFiA5ImvayU>
Subject: Re: [Ecrit] I-D Action: draft-ietf-ecrit-similar-location-18.txt
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, 15 Feb 2022 19:27:34 -0000

This addresses all comments except:
1. I left the text in Section 3 (Russ Housley=E2=80=99s comment [4]) as =
I agree with Dan Banks about the issues with multiple locations.
2. I left the text in Section 3 (Russ Housley=E2=80=99s comment [5]) =
largely alone for the same reason.  I did add a reference to the =
terminology section after 'Valid Location=E2=80=99
3. I did not modify Section 3 per Claudio=E2=80=99s comment.  This =
section is largely informative =E2=80=94 the only normative statement is =
the one about profiles (1 above), and only discusses motivations and =
examples.  I really think that the way it is presented is the best way =
to explain what the extension does.  The following sections have the =
normative text.
4. I have not yet change one or more examples to non-us addresses.  =
While I could do some Canadian examples, using a completely different =
address scheme would need an expert in that country to assist me.  =
I=E2=80=99ll find a volunteer, so I will do this change, but did not do =
it in this rev.

Brian

> On Feb 15, 2022, at 11:04 AM, internet-drafts@ietf.org wrote:
>=20
>=20
> A New Internet-Draft is available from the on-line Internet-Drafts =
directories.
> This draft is a work item of the Emergency Context Resolution with =
Internet Technologies WG of the IETF.
>=20
>        Title           : A LoST extension to return complete and =
similar location info
>        Authors         : Brian Rosen
>                          Roger Marshall
>                          Jeff Martin
> 	Filename        : draft-ietf-ecrit-similar-location-18.txt
> 	Pages           : 19
> 	Date            : 2022-02-15
>=20
> Abstract:
>   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
>=20
>=20
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-ecrit-similar-location/
>=20
> There is also an htmlized version available at:
> =
https://datatracker.ietf.org/doc/html/draft-ietf-ecrit-similar-location-18=

>=20
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ecrit-similar-location-18=

>=20
>=20
> Internet-Drafts are also available by rsync at =
rsync.ietf.org::internet-drafts
>=20
>=20
> _______________________________________________
> Ecrit mailing list
> Ecrit@ietf.org
> https://www.ietf.org/mailman/listinfo/ecrit


From nobody Fri Feb 25 11:26:09 2022
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 A9EB73A136A; Fri, 25 Feb 2022 11:26:07 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Tatuya Jinmei via Datatracker <noreply@ietf.org>
To: <int-dir@ietf.org>
Cc: draft-ietf-ecrit-similar-location.all@ietf.org, ecrit@ietf.org, last-call@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.46.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <164581716753.7745.821114178315815901@ietfa.amsl.com>
Reply-To: Tatuya Jinmei <jinmei@wide.ad.jp>
Date: Fri, 25 Feb 2022 11:26:07 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/ecrit/fLzdXnkXGR8AdxR3MBzYFIQySig>
Subject: [Ecrit] Intdir telechat review of draft-ietf-ecrit-similar-location-18
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: Fri, 25 Feb 2022 19:26:08 -0000

Reviewer: Tatuya Jinmei
Review result: Ready

I am an assigned INT directorate reviewer for
<draft-ietf-ecrit-similar-location-18.txt>. These comments were written
primarily for the benefit of the Internet Area Directors. Document editors and
shepherd(s) should treat these comments just like they would treat comments
from any other IETF contributors and resolve them along with any other Last
Call comments that have been received. For more details on the INT Directorate,
see https://datatracker.ietf.org/group/intdir/about/
<https://datatracker.ietf.org/group/intdir/about/>.

This draft defines a few optional extensions to the LoST protocol as defined in
RFC5222 so that the server can provide supplemental information that may be
useful for the client.  I'm not familiar with the LoST protocol, so it's quite
possible my review miss something.  With noting that, the draft is very well
written, its purpose and explanations are clear, and I didn't find any obvious
problem, especially those related to the INT area.  I think it's ready for
publication.

I have a couple of comments, making mostly just out of curiosity.  I'd be happy
to get clarifications on these points, but these are not blocking issues at all.

- The definition of similarity (in Section 2) looks loose to me:

   Similar Location:  A suggested civic location that is similar to an
      Invalid Location which was used in a LoST query, but which has one
      or more elements added, modified, or removed such that the
      suggested location is a Valid Location.

  If we apply this definition literally, a completely "different" location
  could be considered to be "similar" as long as it's valid, since all
  editorial operations can be applied for arbitrary times, right?  Perhaps it's
  intentionally kept loose and left to the server implementation and
  discretion, but it would be also nice if it gives some example of what would
  NOT be considered to be similar (for example, what if an element contains a
  misspelling and fixing it would make it valid?).

- Also related to the above definition, can "Similar Location" be used only
when the input is invalid?  For example, what if both "6000 15th Avenue
Northwest" and "6000 15th Avenue Southwest" exist and the input is either of
them in a complete form, can we include the other as a "Similar Location"?




From nobody Fri Feb 25 12:47:48 2022
Return-Path: <br@brianrosen.net>
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 407403A08B5 for <ecrit@ietfa.amsl.com>; Fri, 25 Feb 2022 12:47:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.888
X-Spam-Level: 
X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20210112.gappssmtp.com
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 yuzPn3IWKX1V for <ecrit@ietfa.amsl.com>; Fri, 25 Feb 2022 12:47:40 -0800 (PST)
Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (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 0C0F23A08AD for <ecrit@ietf.org>; Fri, 25 Feb 2022 12:47:12 -0800 (PST)
Received: by mail-io1-xd35.google.com with SMTP id h16so7881545iol.11 for <ecrit@ietf.org>; Fri, 25 Feb 2022 12:47:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20210112.gappssmtp.com; s=20210112; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=zW2uqvh0VnKAqiuI+5uF+ZBVgFYYkedDuYiYucNFA30=; b=kkPTi2bZbmE/peLa6YEWO0aN6va03WOQfPv+qUngsgY9+XIt5oM3iOsAks3sA8xJPj p6ZsM0Slot4V59Qn3XolYtM8gZ5aF+eh6tK5Dxi+/LIIUePvEbZwiNlTmUMi3wDU5Kho 8RZb0UizFedHwvD3pOHMdID2yOFvMqL8UyiabNxGMqBfin9A7T9B19vJGnIag/cbYxHu cRDItgBJY4Z4O9OV1hUB7x5Lqg1WcPLtsVfHvqIKhzVKXJf1b/0/mh39iNCcRLNk8VKQ xvxYlVv6qpJPRsusJX0lyCh+MIyYK70ZE4lDmsHwU5+oKa+u2n8kOXU4Ry4QApmbr+pI Ho4Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=zW2uqvh0VnKAqiuI+5uF+ZBVgFYYkedDuYiYucNFA30=; b=6RoOw+EmJHZO5IZQX6kt3V3BQTON4BAz6qa9K/imZmT6DYwP1nwlPagqLwaah2ryX5 yWhI8OzdD4IZoiUfZJ1NO9+i0+lcF08iMch+nPMLoipQ1bXHF+11CYMyCNL9abMNpIef 2ZbPCpBxg/pRikW9LdVIwIdY0MLzVW1MVmIQ7SriBBjhJBrjgoz++8dUTx/gTjFF9Ja0 r5brx15pfTIFuUzQ+7+ch8wGWgErwZSvW/cynQDhYU9YVM+qzMU+P42G/swt/+tishKe HYeGQbG+CA8Gwd+04FdZ0QPvuxEdmfqupOK1Sr/d5g0jUbJQWbcDfWUWZSp1almiP4kD K9Sg==
X-Gm-Message-State: AOAM532NkXU33c0gZPOVbyd1aXbDeUe1zJrrJL3TdvThAQ0mNqgOzgFS +AkIvPNqMf9MQz8TUrchk26jpQ==
X-Google-Smtp-Source: ABdhPJxwQDcCNm7r2XgELyz3NVAdLVGHVtvPki1VkNuRAOEp+5VDb+suDRScWL6EuRHWKxS9N1sRDw==
X-Received: by 2002:a05:6638:4102:b0:314:32a6:90bc with SMTP id ay2-20020a056638410200b0031432a690bcmr7469697jab.168.1645822030866;  Fri, 25 Feb 2022 12:47:10 -0800 (PST)
Received: from smtpclient.apple (dynamic-acs-24-154-121-237.zoominternet.net. [24.154.121.237]) by smtp.gmail.com with ESMTPSA id c18-20020a05660221d200b00640a0083089sm1933479ioc.30.2022.02.25.12.47.09 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 25 Feb 2022 12:47:10 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.20.0.1.32\))
From: Brian Rosen <br@brianrosen.net>
In-Reply-To: <164581716753.7745.821114178315815901@ietfa.amsl.com>
Date: Fri, 25 Feb 2022 15:47:08 -0500
Cc: int-dir@ietf.org, draft-ietf-ecrit-similar-location.all@ietf.org, ECRIT <ecrit@ietf.org>, last-call@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <A702198B-0EFF-450B-B13E-98D0C86C3423@brianrosen.net>
References: <164581716753.7745.821114178315815901@ietfa.amsl.com>
To: Tatuya Jinmei <jinmei@wide.ad.jp>
X-Mailer: Apple Mail (2.3693.20.0.1.32)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ecrit/NyTUSA06s2iBfII4gAOnO8jC5dA>
Subject: Re: [Ecrit] Intdir telechat review of draft-ietf-ecrit-similar-location-18
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: Fri, 25 Feb 2022 20:47:46 -0000

Thanks for the review.  See inline.

> On Feb 25, 2022, at 2:26 PM, Tatuya Jinmei via Datatracker =
<noreply@ietf.org> wrote:
>=20
> Reviewer: Tatuya Jinmei
> Review result: Ready
>=20
> I am an assigned INT directorate reviewer for
> <draft-ietf-ecrit-similar-location-18.txt>. These comments were =
written
> primarily for the benefit of the Internet Area Directors. Document =
editors and
> shepherd(s) should treat these comments just like they would treat =
comments
> from any other IETF contributors and resolve them along with any other =
Last
> Call comments that have been received. For more details on the INT =
Directorate,
> see https://datatracker.ietf.org/group/intdir/about/
> <https://datatracker.ietf.org/group/intdir/about/>.
>=20
> This draft defines a few optional extensions to the LoST protocol as =
defined in
> RFC5222 so that the server can provide supplemental information that =
may be
> useful for the client.  I'm not familiar with the LoST protocol, so =
it's quite
> possible my review miss something.  With noting that, the draft is =
very well
> written, its purpose and explanations are clear, and I didn't find any =
obvious
> problem, especially those related to the INT area.  I think it's ready =
for
> publication.
>=20
> I have a couple of comments, making mostly just out of curiosity.  I'd =
be happy
> to get clarifications on these points, but these are not blocking =
issues at all.
>=20
> - The definition of similarity (in Section 2) looks loose to me:
>=20
>   Similar Location:  A suggested civic location that is similar to an
>      Invalid Location which was used in a LoST query, but which has =
one
>      or more elements added, modified, or removed such that the
>      suggested location is a Valid Location.
>=20
>  If we apply this definition literally, a completely "different" =
location
>  could be considered to be "similar" as long as it's valid, since all
>  editorial operations can be applied for arbitrary times, right?  =
Perhaps it's
>  intentionally kept loose and left to the server implementation and
>  discretion, but it would be also nice if it gives some example of =
what would
>  NOT be considered to be similar (for example, what if an element =
contains a
>  misspelling and fixing it would make it valid?).
The server can=E2=80=99t know what the intended location is.  So it very =
well could be different in the sense you mean.
Yes, it is intended to be loose, because the server might use all kinds =
of info that isn=E2=80=99t specified: think about an AI that looked at =
all the invocations of the command, and subsequent validations, to see =
how it=E2=80=99s advice was used and tuned the advice accordingly.  It =
is, by definition, guessing.  We don=E2=80=99t say how wild a guess it =
can make, or not make.  A misspelled word is an excellent example of =
what it could be used for: suppose the postal code was specific enough =
to see that it likely was a misspelled municipality name.  Perfectly =
reasonable Similar location.    The original has municipality on the =
<invalid> list, and all the other lower level submitted fields on the =
<unchecked> list.  The Similar Location has all the same fields with the =
correct municipality (A3). =20


>=20
> - Also related to the above definition, can "Similar Location" be used =
only
> when the input is invalid?  For example, what if both "6000 15th =
Avenue
> Northwest" and "6000 15th Avenue Southwest" exist and the input is =
either of
> them in a complete form, can we include the other as a "Similar =
Location=E2=80=9D?

The text describes the use case when the input If you had a valid =
location in the input, then you can=E2=80=99t get a field with a =
different value in Similar Location.   You can get Similar Location, but =
it would have additional fields that were not in the input.  Looking at =
the text, we could make that more clear.

Brian


From nobody Mon Feb 28 12:30:11 2022
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.